طلب واحد في المتجر، ونسخة من الحدث يرسلها المتصفح، وأخرى يرسلها الخادم. وجود النسختين ليس خطأ بحد ذاته؛ المشكلة تبدأ عندما لا يستطيع التكامل التعرف إليهما بوصفهما الفعل نفسه. لهذا نختبر هوية الحدث، لا مجرد نجاح الاتصال.
Events API مسار لإرسال الأحداث من الأنظمة إلى TikTok. وإذا كنت ترسل نسخًا متداخلة من الفعل نفسه عبره وعبر Pixel، تطلب TikTok استخدام event_id في المسارين لمعالجة التكرار. راجع أيضًا تطابق اسم الحدث وشروط المطابقة الحالية. TikTok — منع تكرار الأحداث
1. اتفق مع المطور على بطاقة تعريف الحدث
اكتب متى يحدث الشراء في نظامك، وما الاسم المستخدم، ومن يولّد معرّفه، وما القيمة والعملة ووقت الفعل. لا تجعل إعادة تحميل الصفحة أو تعديل ملاحظة داخل الطلب ينشئ هوية شراء جديدة للعملية نفسها.
راجع الأسماء والمعاملات في قائمة الأحداث القياسية لـTikTok. إذا كان نشاطك يفرّق بين تقديم الطلب وإتمام الشراء، اجعل الخريطة تعكس هذا الفرق؛ تغيير الاسم في التقرير لا يصلح تعريفًا تجاريًا خاطئًا. TikTok — الأحداث القياسية والمعاملات
2. اختبر النسختين وإعادة المحاولة
ابدأ بحالة عبر المتصفح فقط، ثم حالة عبر الخادم فقط، ثم فعل واحد يصل من المسارين. قارن الاسم والمعرّف والوقت والقيمة، وسجّل كيف عولجت النسختان وفق وثائق التكامل.
بعد ذلك اختبر فشل تسليم مؤقتًا وإعادة محاولة مناسبة. المحاولة الجديدة ليست عملية شراء جديدة؛ على تصميم التكامل أن يحافظ على هوية الفعل. أما خطأ القيمة أو العملة فيحتاج تصحيح البيانات، وليس إرسال النسخة الخاطئة مرارًا.
تطبيق عملي: سجل قبول للتكامل
هذه حالات افتراضية يملؤها المطور ومختص القياس في بيئة اختبار مأذون بها:
| السيناريو | الهدف من الفحص | دليل القبول المقترح |
|---|---|---|
| فعل واحد بمسارين | اختبار منع التكرار | تفسير موثق لكيفية معالجة النسختين |
| إعادة محاولة | الحفاظ على هوية الفعل | سجل إرسال يميز المحاولة عن الطلب |
| قيمة خاطئة | اكتشاف خطأ المعنى | حالة رفض أو تشخيص وإجراء تصحيح |
| تأخر مصطنع | فهم الحداثة وحدود القبول | وقت الفعل والتسليم والنتيجة |
| فعل غير مأذون بإرساله | مراجعة ضوابط المشاركة | عدم إرساله وفق التصميم المعتمد |
أضف إلى كل صف النتيجة الفعلية ورابط دليل داخلي ومسؤول المعالجة. عبارة «API يعمل» لا تكفي؛ المطلوب أن تتمكن من تتبع الحالة من نظام الطلبات إلى الإرسال ثم التشخيص، دون الخلط بين عدد المحاولات وعدد الطلبات.
لا تضع رموز الوصول أو بيانات العملاء في سجل مشترك. استخدم معرّفات تجريبية، واحفظ ما يلزم للتحقيق ضمن صلاحيات الفريق وسياسة الاحتفاظ المعتمدة.
3. اقرأ التشخيص مع سجل المصدر
يوفر Web Diagnostics تفاصيل عن المشكلات وشدتها ومجموعة البيانات المتأثرة. اربط التنبيه بحالة من سجلك: هل الخلل في إنشاء الحدث، أم تحويل بياناته، أم تسليمه؟ هذا يحدد من يصلحه وما الذي يجب إعادة اختباره. TikTok — تشخيص بيانات الموقع في Events Manager
افحص أيضًا التأخر بين وقت الفعل ووقت الإرسال. لا تستبدل وقت الشراء بوقت إعادة المحاولة لمجرد جعل السجل يبدو حديثًا. وحدّد مع المطور طريقة التعامل مع الحالات التي تفشل باستمرار بدل تركها خارج المتابعة.
4. افصل قبول الربط عن تقييم أثره
اكتمال اختبارات الربط يعني اجتياز الحالات المتفق عليها، لا إثبات أن المبيعات زادت. تحسن التغطية قد يغيّر الأرقام المنسوبة، لذلك اقرأ أثر القياس منفصلًا عن التقييم التجاري.
سلّم خريطة أحداث وسجل اختبار ومالك تشغيل وخطة رجوع. لا توقف Pixel تلقائيًا لأن API نجح، ولا تعتبر الإرسال من الخادم بديلًا عن ضوابط مشاركة البيانات. القرار الصحيح يعتمد على تصميم المسارات والبيانات المسموح بإرسالها وحاجة النشاط.
المراجع الرسمية
- TikTok — منع تكرار الأحداث
- TikTok — الأحداث القياسية والمعاملات
- TikTok — تشخيص بيانات الموقع في Events Manager
تاريخ مراجعة المراجع: 16 أكتوبر 2026. يُعاد التحقق من الواجهة والإصدار والأهلية قبل أي تنفيذ على حساب فعلي.
