أحداث الخادم لا تظهر في Meta غالبًا لأن مشكلة حدثت قبل Delivery أو أثناءه أو بعده، وليس لأن المنصة “فقدت” Conversion بدون سبب.
أسرع طريقة للتشخيص هي تتبع Purchase حقيقية واحدة من Source of Truth حتى Destination. تأكد أولًا أن Purchase Event تم إنشاؤها أصلًا، ثم افحص Payload، والمعالجة Server-Side، ونتيجة Delivery، وبعدها Browser/Server matching. إذا بدأت من Dashboard وتجاهلت Source، قد تقضي وقتًا طويلًا في فحص Layer ليست هي المشكلة.
تأكد أولًا أن حدث الشراء تم إنشاؤه من المصدر
ابدأ من Transaction تعرف أنها حدثت فعلًا.
افتح المتجر أو الـbackend أو Order System أو أي Source of Truth تستخدمه، وتأكد أن Purchase موجودة.
بعدها اسأل:
هل Tracking implementation أنشأت Event المفترض أن تمثل هذه Transaction؟
هذه الخطوة تبدو بسيطة، لكنها أهم خطوة في التشخيص.
Server-Side workflow لا تستطيع إرسال Event لم تدخل أصلًا إلى Tracking System.
إذا كانت Order موجودة لكن Purchase Event لم يتم إنشاؤها، فالمشكلة Upstream.
أما إذا تم إنشاء Event ثم اختفت بعد ذلك، وقتها انتقل إلى Processing وDelivery.
لكل Order تريد تتبعها، سجل:
- Order أو Transaction ID.
- Event timestamp.
- Purchase value.
- Currency.
- Event ID إن كانت موجودة.
- Source الذي أنشأ Event.
الهدف هو أن يكون لديك Reference واضح يمكن تتبعه.
لا تبدأ من Total داخل Dashboard.
ابدأ بـOrder حقيقية وEvent واحدة متوقعة.
افحص بيانات الحدث قبل اعتبار المشكلة من المنصة
بعد التأكد أن Source Event موجودة، راجع ما تحتوي عليه Event نفسها.
Request يمكن أن يصل بنجاح بينما Data داخله غير صحيحة.
وفي المقابل، Destination قد لا تعالج Event كما تتوقع إذا كانت Payload لا تطابق متطلبات التنفيذ الحالي.
متطلبات Meta الدقيقة يجب مراجعتها من Official Meta Documentation الحالية قبل أي Implementation Change.
لكن على مستوى التشخيص، توجد عناصر في Event Path يجب أن يفهمها فريقك أصلًا.
Event Name
تأكد أن Event تمثل الفعل التجاري الذي تعتقد أنها تمثله.
Purchase لا يجب أن تتحول بالخطأ إلى Event أخرى بسبب Mapping أو Transformation غير صحيح.
راجع أيضًا أن Browser وServer لا يستخدمان تعريفات متعارضة لنفس Business Action.
اختلاف Naming قد يصنع Diagnostics مربكة حتى لو خرج كلا Requestين من النظام بنجاح.
Timestamp
قارن توقيت Transaction الأصلية بتوقيت إنشاء أو إرسال Server Event.
Timestamp تساعدك على تتبع Event خلال Logs وDelivery Records.
وجود Timing مختلف لا يعني تلقائيًا أن Event غير صحيحة.
لكن Timestamp مفقودة أو غير منطقية تجعل إثبات أنك تتابع نفس Purchase أصعب.
لا تستخدم Timing Rule عامة للمنصة إلا بعد التحقق منها من الوثائق الرسمية الحالية.
Value وCurrency
قارن Event Value وCurrency مع Order الحقيقية.
Purchase Event بقيمة خاطئة تظل Tracking Data سيئة حتى لو استقبلتها Meta.
راجع مشاكل مثل:
- Value مفقودة.
- Currency خاطئة.
- قيمة مأخوذة من Cart قبل تغير Final Order.
- Mapping أو Formatting غير صحيح.
- Browser وServer يرسلان قيمًا مختلفة لنفس Purchase.
Source Transaction يجب أن تظل نقطة المرجع.
Identifiers
راجع Identifiers التي تربط Technical Event بالـTransaction الحقيقية.
قد يشمل ذلك Event أو Order Identifier وأي Identifiers أخرى مسموح بها ومناسبة للـworkflow الموثق.
الهدف ليس إرسال كل Identifier موجودة.
الهدف هو جعل Event قابلة للتتبع والمعالجة بشكل صحيح.
وإذا كانت نفس Purchase موجودة في Browser وServer، فإن اتساق Identifiers يصبح مهمًا أيضًا للـmatching وDeduplication.
افحص هل فشل إرسال الحدث
إذا كانت Source Event صحيحة وPayload تبدو سليمة، انتقل إلى Server-Side Delivery Layer.
السؤال الآن تغير.
لم يعد:
“هل Purchase حدثت؟”
أصبح:
“هل Event خرجت من Tracking System بنجاح؟”
راجع Evidence المتاحة داخل Implementation.
حسب النظام، قد يكون عندك Processing Logs أو Delivery Status أو Response Codes أو Error States أو Destination Diagnostics.
أنت تحاول تحديد النقطة التي توقف عندها Event.
المسار المفيد هو:
Source Event → Server Processing → Outgoing Request → Destination Outcome
إذا كانت Source Event موجودة لكن لا يوجد Outgoing Request، فالمشكلة غالبًا في Mapping أو Processing أو Routing أو Server-Side Logic.
إذا خرج Request لكنها فشلت، راجع Request ومتطلبات Destination المرتبطة بالفشل.
أما إذا كان Request يبدو ناجحًا لكنك لا ترى النتيجة المتوقعة في Destination، فلا تبدأ بإعادة إرسال Event مباشرة.
تأكد أولًا أنك تراجع Transaction الصحيحة وTime Range الصحيح وEvent representation الصحيحة وDiagnostic Surface المناسبة.
Blind Retries قد تحول Delivery Problem إلى Duplication Problem أيضًا.
لهذا Delivery Validation يجب أن تكون جزءًا من النظام، وليس شيء نستخدمه فقط بعد اكتشاف اختلاف الأرقام.
افحص مطابقة أحداث المتصفح والخادم
Server Event قد تبدو “مفقودة” في Reporting View حتى لو Transport ليست أصل المشكلة.
طريقة Browser وServer matching قد تؤثر على كيفية معالجة أو عرض Events المتداخلة.
لذلك Deduplication يجب تشخيصها بشكل منفصل عن Delivery.
خذ نفس Source Order وقارن Browser وServer representations.
راجع:
- Event أو Order IDs.
- Event Name.
- Value.
- Currency.
- Timestamps.
- هل المساران يمثلان نفس Transaction.
إذا كان Browser وServer يرسلان نفس Purchase، يحتاجان Event Identity منسقة حسب متطلبات Destination الموثقة.
إذا استخدم المساران Identifiers لا علاقة بينها أو Event Definitions مختلفة، قد يفشل Matching.
وفي الاتجاه الآخر، إذا كانت Event تُعامل كتمثيل متداخل مع Event أخرى، فلا يجب اعتبار عدم ظهور Conversionين منفصلتين دليلًا تلقائيًا على Transport Failure.
الفرق الأساسي هو:
**Transport يسأل: هل وصلت Event؟
Deduplication تسأل: هل Eventان متداخلتان تمثلان Conversion واحدة أم أكثر؟**
السؤالان مختلفان.
لا تصلح Deduplication عن طريق إعادة إرسال Events بشكل متكرر.
ولا تصلح Delivery Failure حقيقي عن طريق إلغاء Deduplication.
تتبع المرحلتين بشكل منفصل.
متى تحتاج المشكلة إلى Tracking Audit كامل؟
Event واحدة فشلت يمكن غالبًا تشخيصها بتتبع Event Path.
لكن Pattern مستمرة شيء مختلف.
Tracking Health Audit أوسع يصبح منطقيًا عندما:
- Purchase Events مهمة تختفي بشكل متكرر.
- نفس المشكلة تظهر في عدة Orders.
- Browser وServer يختلفان باستمرار.
- Delivery Status غير واضحة أو غير موثوقة.
- Values أو Identifiers غير متسقة.
- Missing Events وDuplicates يظهران معًا.
- الفريق لا يستطيع تحديد هل المشكلة في Source أو Server أو Destination.
وقتها Debugging لكل Event منفردة قد لا يكشف مشكلة Architecture الأساسية.
الـAudit يجب أن يبدأ من Source-of-Truth Transactions ويتحرك للخارج.
يعني ذلك التأكد أن Events موجودة وصحيحة، وكيف تتحرك عبر Browser وServer، وهل Deduplication يعمل، وهل Delivery Outcomes قابلة للتفسير.
الهدف ليس إثبات أن “Meta غلط” أو أن “Server مكسور”.
الهدف هو تحديد الـLayer التي تتوقف عندها Conversion Data الموثوقة عن كونها موثوقة.
أدلة مرتبطة
الأسئلة الشائعة
هل تم إنشاء Purchase Event من المصدر؟
افحص هذا أولًا؛ Delivery لا يصلح حدثًا لم يتم إنشاؤه أصلًا.
ما الحقول التي يجب فحصها؟
تعريف الحدث والقيمة/العملة وEvent ID والمعرّفات؛ متطلبات Meta الدقيقة تُراجع رسميًا.
كيف تفرق بين مشكلة المصدر وفشل Delivery؟
أكد وجود الحدث في المصدر، ثم راجع المعالجة Server-Side وحالة الإرسال.
هل قد يجعل Deduplication الحدث يبدو مفقودًا؟
قد يؤثر على ظهوره في التقارير، لكن Deduplication وTransport Failure مرحلتان مختلفتان.
متى تحتاج Audit كامل؟
عند استمرار فقد أحداث مهمة أو عدم القدرة على تحديد مكان الخلل بين المصدر والخادم والوجهة.
