اختلاف أحداث المتصفح والخادم يظهر عندما لا يتفق Browser وServer على نفس Business Event: هل Event موجودة أصلًا، كم مرة تم تمثيلها، ما القيم والـIDs التي تحملها، وهل تم Delivery لها بنجاح.
أول خطوة ليست مقارنة Total في Browser مع Total في Server. ابدأ بـSource Transaction حقيقية واحدة وتتبع كيف تم تمثيلها في المسارين. إذا كان Browser وServer يفترض أن يمثلا نفس Conversion، يجب أن تستطيع عمل Reconciliation بينهما على مستوى Event. أما إذا كان كل مسار يمثل Business Condition مختلفة، فقد تكون مقارنة Counts مضللة من البداية.
كيف يظهر اختلاف أحداث المتصفح والخادم؟
Mismatch قد يظهر بأكثر من شكل.
Purchase موجودة في Browser Path ولا تظهر في Server Path.
Server يرسل Purchase لا توجد لها Browser Event.
المساران يرسلان Event لكن Purchase Value مختلفة.
Event IDs لا تتطابق.
Currency صحيحة في Path وخاطئة في الأخرى.
Browser يرسل Event واحدة بينما Server يرسل اثنتين.
أو قد يبدو المساران صحيحين داخليًا لكن Delivery Outcome مؤكدة في Path واحدة فقط.
هذه ليست مشكلة واحدة.
تسميتها كلها “الأعداد مختلفة” تخفي التفاصيل التي تحتاجها للتشخيص.
ابدأ من Business Transaction حقيقية.
خذ Order مكتملة واسأل:
- هل Browser أنشأ Purchase Event؟
- هل Server أنشأ أو استقبل Purchase Event؟
- هل Eventان تعودان لنفس Order؟
- هل الحقول المهمة متسقة؟
- هل كل Path قامت بالـDelivery المتوقع؟
الـMismatch تصبح مفيدة للتشخيص عندما تستطيع ربط الاختلاف بنفس Source Transaction.
بدون هذا الربط، قد تكون ببساطة تقارن مجموعتين من Events لم يكن مطلوبًا أن تتطابقا أصلًا.
تحقق أن المسارين يبدأان من نفس الحدث التجاري
قبل مقارنة Browser وServer، تأكد أن الاثنين يفترض أن يمثلا نفس Business Event.
هذه الخطوة تمنع كثيرًا من False Alarms.
Browser Event قد تعمل بسبب Page Interaction.
Server Event قد يتم إنشاؤها فقط بعد تأكيد Condition داخل Backend.
وقد يكون اختلاف Coverage بينهما مقصودًا.
إذا قارنت Raw Event Counts بدون مراجعة Event Definition، قد يبدو الفرق كأنه Tracking Failure رغم أن Implementation تعمل كما صُممت.
في Purchase Conversion، ابدأ من Source Order.
حدد Business Condition التي تعني أن “عملية الشراء اكتملت”.
بعدها راجع كيف يمثل كل Path هذه الحالة.
إذا كان Browser وServer يفترض أن يمثلا نفس Completed Order، يجب أن تستطيع ربط الاثنين بنفس Transaction.
أما إذا كانت Path تعتبر Checkout Completion هي Purchase، بينما الأخرى تنتظر Payment Confirmation، فهما ليسا بالضرورة نفس Event حتى لو استخدم الاثنان اسم “Purchase”.
لهذا Event Name وحدها لا تكفي.
المهم هو Business Condition التي أنشأت Event.
قاعدة التشخيص المفيدة هنا:
نفس Source Transaction + نفس Intended Conversion، وبعدها قارن المسارين.
إذا لم يتحقق هذا الشرط، أصلح Event Definition قبل محاولة جعل Counts متطابقة.
قارن بيانات الحدث وليس العدد فقط
بعد التأكد أن Browser وServer يمثلان نفس Business Event، ابدأ بمقارنة الحقول داخل Event نفسها.
Count Difference مجرد Signal واحدة.
وغالبًا Field-level comparison تصل إلى Root Cause أسرع.
Event IDs
Event Identity مهمة جدًا عندما يتداخل Browser وServer.
راجع هل تستطيع ربط Eventين بنفس Source Transaction، وهل Identifiers المستخدمة في Implementation متسقة بما يكفي للـmatching أو Deduplication.
متطلبات الحقول الدقيقة تختلف حسب Destination ويجب التحقق منها للمنصة المطلوبة.
لكن السؤال التشخيصي العام هو:
هل تستطيع إثبات أن Technical Eventين تمثلان نفس Business Conversion؟
إذا كانت الإجابة لا، فعمل Reconciliation سيكون صعبًا حتى قبل النظر إلى Delivery.
Values
قارن Purchase Value في Browser وServer مع Final Source Order.
قد يرسل Browser قيمة ويرسل Server قيمة أخرى.
السبب قد يكون Mapping مختلف، أو Cart Data قديمة، أو اختلاف في Tax/Discount handling، أو مشكلة من Source نفسها.
لا تحدد القيمة الصحيحة بناءً على أي رقم ظهر داخل Platform.
ارجع إلى Source Transaction.
هي التي تحدد Value التي تتوقع أن يمثلها المساران.
Currency
Currency Error يمكن أن يصنع Data-quality mismatch واضحًا حتى لو Event Counts متطابقة تمامًا.
راجع هل Browser وServer يستخدمان نفس Currency لنفس Order، وهل تتطابق مع Source.
رقم صحيح بعملة خاطئة ما زال Event Data خاطئة.
Customer وEvent Identifiers
راجع أي Identifiers مسموح بها وتستخدمها الـworkflow الموثقة.
ليس ضروريًا أن يكون كل Field متطابقًا بين Browser وServer، لكن Missing أو inconsistent identifiers قد تجعل Matching وDelivery diagnostics وReconciliation أصعب.
لا تضف Identifiers فقط لزيادة حجم Payload.
استخدم ما هو مسموح، ومهم، ومتاح فعليًا من Source.
Timestamps
قارن Source Transaction Time مع Browser Event Time وServer Event Time.
قد يكون وجود Timing Difference طبيعيًا.
Server Path قد تعالج Event بعد Browser.
Timing وحدها لا تثبت وجود Mismatch.
لكنها تساعدك على التأكد أنك تقارن نفس Transaction، وقد تكشف Events تم إنشاؤها مبكرًا جدًا أو متأخرًا جدًا أو أكثر من مرة.
تعامل مع Timing كـContext بجانب IDs وValue وCurrency وDelivery Status.
افصل بين فقدان الأحداث ومشكلة Deduplication
Delivery Failure وDeduplication Failure قد يصنعا أعراضًا متشابهة، لكنهما مشكلتان مختلفتان.
سؤال Delivery هو:
هل تم إنشاء Event ومعالجتها وإرسالها بنجاح؟
وسؤال Deduplication هو:
إذا مثل أكثر من Path نفس Conversion، هل تم تنسيق هذه التمثيلات بشكل صحيح؟
افصل التحقيقين.
في Delivery، تتبع:
Source Transaction → Event Creation → Browser/Server Processing → Outgoing Request → Destination Outcome
إذا كانت Server Event موجودة داخليًا لكن لا توجد Outgoing Request، فالمشكلة غالبًا Processing أو Routing.
إذا خرجت Request وفشلت، فالمشكلة Delivery.
وإذا وصلت إلى Destination، فقد يكون Transport سليمًا حتى لو Reporting ما زالت مختلفة.
أما في Deduplication، فتتبع كل Representations لنفس Order.
راجع هل Browser وServer يستخدمان Event Identity منسقة، وهل Business Conversion واحدة تم التعامل معها بالخطأ كعدة Events مستقلة.
لا تعتبر Event تم Deduplicate لها بنجاح وكأنها “اختفت”.
ولا تعتبر Delivery Failure حقيقي مشكلة Deduplication.
الخلط بين المرحلتين قد يؤدي إلى Fix خاطئ.
على سبيل المثال، إعادة إرسال Event تبدو “مفقودة” قد تخلق Duplicate حقيقية إذا كانت Event الأصلية وصلت بالفعل وتم Matching لها.
التشخيص الأفضل يثبت Creation وDelivery أولًا، ثم يراجع Overlap وDeduplication بشكل منفصل.
متى يحتاج الاختلاف إلى Audit أعمق؟
فرق بسيط ظهر مرة واحدة قد يكون سهل التفسير.
لكن Pattern مستمرة تحتاج تشخيصًا أعمق.
Tracking Health Audit تصبح مناسبة عندما Browser/Server mismatch:
- تؤثر على Conversions مهمة مثل Purchases.
- تتكرر في أكثر من Source Transaction.
- تشمل Values أو Currency أو Identifiers غير متسقة.
- تجمع بين Missing Events وDuplicate Events.
- لا يمكن تحديد هل السبب Source Creation أو Processing أو Delivery أو Deduplication.
- تعود مرة أخرى بعد Point Fixes.
هنا قد تكون المشكلة أكبر من Tag واحدة أو API Request واحدة.
الـAudit يجب أن تبدأ من Source-of-Truth Transactions وترسم Event Path كاملة.
إذا أثبتت Evidence أن Browser وServer سليمين لكن الاختلاف بينهما مقصود، يجب أن تكون هذه نتيجة مقبولة.
أما إذا كان هناك Tracking Failure حقيقي، فيجب تحديد الـLayer التي بدأ عندها الاختلاف واقتراح أقل Fix مناسب.
الهدف ليس جعل Counterين يعرضان نفس الرقم.
الهدف هو أن تستطيع تتبع نفس Business Conversion وفهمها والثقة بها عبر المسارات التي يفترض أن تمثلها.
أدلة مرتبطة
الأسئلة الشائعة
كيف يظهر الـMismatch؟
يختلف المساران في وجود الحدث أو عدده أو قيمه/IDs أو Delivery لنفس المعاملة.
هل يجب أن يبدأ المساران من نفس الحدث؟
نعم عند تمثيل نفس Conversion؛ وإلا قد تكون مقارنة Counts مضللة.
ما الحقول المهمة بجانب العدد؟
Event/Order IDs والقيمة والعملة والتوقيت والمعرّفات وحالة Delivery.
كيف تفصل Delivery Loss عن Deduplication؟
تتبع إنشاء/إرسال الحدث بشكل منفصل عن مطابقة التكرار.
متى يحتاج Mismatch Audit كامل؟
عندما يستمر أو يؤثر على Conversions مهمة أو لا يمكن عزله بالفحص الأساسي.