إزاي أتأكد إن Server-Side Tracking شغال صح؟

ارسم نقاط المرور

اكتب مصدر الحدث والـendpoint الذي يستقبله والحاوية أو الخدمة التي تعالجه والوجهة النهائية. في GTM server-side مثلًا توجد مسؤوليات للاستقبال والتفسير والتشغيل، وليست الحاوية مجرد نسخة من سكربت المتصفح. حدد ما يُسمح بتمريره وما يجب حذفه أو تحويله قبل الإرسال.

نفّذ اختبارًا بمعرف معروف

1. أرسل حدثًا اصطناعيًا مصرحًا به من المسار الفعلي، لا طلبًا منفصلًا لا يمثل التطبيق.
2. تحقق من استقباله في الخادم مرة واحدة وبالاسم والمعرف والتوقيت المتوقعين.
3. راجع شروط تشغيل الوجهة والتحويلات والعملة والقيمة والحقول المطلوبة.
4. افحص استجابة الوجهة وأداة اختبارها أو سجل قبولها، لا نتيجة الخادم الوسيط فقط.

اختبر الفشل وإعادة المحاولة

ماذا يحدث عند انقطاع الوجهة أو تأخر الرد؟ يجب أن تكون إعادة المحاولة منظمة وتحافظ على هوية العملية حتى لا تتحول إلى أحداث جديدة. لا تسجل جسم الطلب كاملًا إذا احتوى معلومات حساسة، وحدد مدة الاحتفاظ والوصول للسجلات. راجع كذلك منع مرور أحداث دون موافقة لازمة بحسب سياسة النظام.

إذا كان المتصفح والخادم يرسلان نفس الشراء، فافحص تنظيم التكرار في الوجهة وفق تكاملها. وجود عدد أحداث أعلى بعد الإطلاق لا يثبت تحسن الجودة؛ قد يعني أن المصدر الجديد يكرر القديم.

تحقق تشغيليًا

راجع الدومين والشهادة والصلاحيات والموارد والتنبيهات وزمن المعالجة، ولا تترك خدمة مكشوفة تقبل أي بيانات بلا ضوابط مناسبة. قارن عينة من العمليات مع مصدرها الحقيقي، وسجل ما لا يمكن قياسه. بعد تغيير الحاوية أو القالب أو مزود الدفع أعد نفس الاختبار. النتيجة المطلوبة مسار موثق وبيانات صحيحة قابلة للمراقبة، لا وعد بتجاوز الحجب أو جمع كل زيارة بغض النظر عن اختيار المستخدم.