اختلاف مبيعات Meta عن مبيعات المتجر قد يكون سببه Tracking Problem فعلية، أو Attribution وReporting، أو خليط من الاثنين.
المتجر يسجل Orders حدثت بالفعل. أما Meta فتعرض Conversions بناءً على Event Data التي تستقبلها وقواعد Attribution وReporting الخاصة بها. لذلك ليس مطلوبًا أن يعرض النظامان نفس الرقم حرفيًا. السؤال الصحيح ليس: “أي Dashboard صح؟” بل: “هل نستطيع ربط كل Order حقيقية بالـEvents التي يفترض أن تمثلها، وهل يمكن تفسير الفرق المتبقي؟”
ابدأ بفهم ما الذي يحسبه كل نظام
قبل مقارنة Totals، حدد وظيفة كل رقم.
المتجر هو Source of Truth للـTransactions المكتملة.
منه تعرف Order IDs والقيمة والعملة والتوقيت وحالة الطلب وأي تغييرات أو Refunds حسب طريقة عمل المتجر.
Meta ليست Order Database.
هي تستقبل Conversion Signals وتعرضها داخل نظام القياس الإعلاني الخاص بها.
هذا الفرق البسيط يغير طريقة التشخيص بالكامل.
إذا كان المتجر يعرض 100 Order مكتملة وMeta تعرض رقمًا مختلفًا، فأنت لا تعرف بعد هل هناك مشكلة أصلًا.
يجب أولًا أن تعرف:
- هل كل Order أنشأت Purchase Event المتوقعة؟
- هل Event تم إرسالها من Browser أو Server أو الاثنين؟
- هل Value وCurrency تطابقان Order؟
- هل نفس Order تم تمثيلها أكثر من مرة؟
- هل Meta استقبلت Event؟
- هل تقارن نفس الفترة ونفس منطق Attribution/Reporting؟
لا تبدأ بمحاولة إجبار الرقمين على التطابق.
ابدأ بالتأكد أنك تقارن نفس مجموعة Transactions خلال Period واضحة.
أفضل وحدة للتشخيص ليست Total.
هي Order حقيقية واحدة لها Event Path يمكن تتبعها.
الـAttribution قد يسبب اختلافات طبيعية في الأرقام
حتى مع Tracking سليمة، قد تختلف مبيعات Meta عن أرقام المتجر.
المتجر يجيب عن سؤال:
ما Transactions التي حدثت؟
أما Advertising Platform فتحتاج أيضًا إلى الإجابة عن سؤال آخر:
أي Ad Interaction يحصل على Credit لهذه Transaction؟
وهذان سؤالان مختلفان.
قواعد Attribution قد تغير Conversions التي تظهر داخل Campaign أو Ad Account report، كما أن توقيت Reporting قد يؤثر على الفترة التي تظهر فيها Conversion.
تفاصيل Meta الحالية مثل Attribution Settings أو Windows أو Reporting Behavior يجب مراجعتها من الحساب نفسه ومن Official Meta Documentation الحالية قبل نشر Claim دقيقة عنها.
لكن مبدأ التشخيص أبسط:
الفرق الناتج عن Attribution ليس Missing Event.
افترض أن Source Order موجودة، وPurchase Event صحيحة، وDelivery مؤكدة، وMeta استقبلت Event.
إذا ظل Store Revenue وMeta attributed revenue مختلفين، فقد يكون الجزء المتبقي من الفرق Reporting أو Attribution، وليس Transport Failure.
ولهذا تغيير Tracking Architecture قبل التأكد من Event Path قد يحل المشكلة الخطأ.
قد تعيد بناء Delivery System سليمة لأن الفريق كان يتوقع من نظامين لهما وظيفتان مختلفتان أن يعرضا نفس Total.
أحداث الشراء المفقودة قد تسبب فجوة في البيانات
بعض الاختلافات ليست Attribution.
قد توجد Order حقيقية في المتجر بينما Purchase Event المفترض أن تمثلها لا تكمل رحلة القياس.
يمكن أن يحدث ذلك في أكثر من مرحلة.
قد لا يتم إنشاء Event من المصدر أصلًا.
Browser Implementation قد تفشل.
Server-Side workflow قد لا تعالج Event.
Outgoing Delivery قد تفشل.
أو Destination قد لا تستقبل أو تعالج Event بالشكل المتوقع.
عندما يحدث ذلك، Meta لديها Conversion Data أقل من عدد Transactions الموجودة في المتجر.
الحل ليس النظر فقط إلى Gap percentage بين Dashboardين.
تتبع Orders حقيقية.
اختر عينة من Completed Transactions واسأل:
هل تم إنشاء Purchase Event لكل واحدة؟
ثم أكمل المسار:
هل Value وCurrency صحيحتان؟
هل Event خرجت من النظام؟
ما Destination Outcome؟
هنا تتحول المشكلة من “Meta بتقلل المبيعات” إلى سؤال تقني يمكن إثباته أو نفيه.
إذا وجدت Source Orders ليس لها Events بسبب Source Implementation فاشلة، أصبح لديك Evidence على Tracking Issue.
إذا كانت Events كلها موجودة وتم Delivery لها، انتقل إلى Layer أخرى في التشخيص.
الأحداث المكررة قد تضخم عدد التحويلات
العكس ممكن أيضًا.
Purchase حقيقية واحدة قد يتم تمثيلها أكثر من مرة.
Browser Tag قد ترسل Purchase Event.
Server Workflow قد ترسل نفس Purchase.
Legacy Tag أو Plugin قد تظل تعمل.
وقد يكون هناك أكثر من Server-Side workflow ترسل نفس Transaction.
إذا لم يتم تنسيق هذه التمثيلات بشكل صحيح، قد يرتفع Conversion Count أو Reported Value عن الواقع.
لهذا إذا كانت Meta أعلى من Store Revenue، لا تفترض تلقائيًا أن السبب Attribution.
قد تكون Duplication.
مرة أخرى، شخّص على مستوى Transaction.
خذ Order مكتملة واحدة وحدد كل Purchase Events التي تم إنشاؤها لها عبر Browser وServer.
قارن Event أو Order IDs وValues وCurrency وTimestamps.
بعدها حدد هل هذه Events مجرد Overlapping representations مقصودة وDeduplication تعمل عليها، أم أنها Events مستقلة يتم التعامل معها كConversions منفصلة.
لا تشخّص Duplicate Events من Value المتشابهة فقط.
عميلان مختلفان يمكن أن يشتريا بنفس المبلغ.
Order Identity وEvent Identity أقوى بكثير كـEvidence.
السؤال المهم هو:
هل Transaction واحدة أنشأت Conversion Trail واحدة مفهومة، أم عدة Events تبدو غير مرتبطة؟
كيف تقارن بيانات Meta ببيانات المتجر بشكل صحيح؟
Reconciliation الجيدة لا تبدأ برقم Revenue من Meta ورقم Revenue من Store ثم حساب الفرق.
ابدأ بعينة Transactions.
حدد Date Range واضحة، واستخدم المتجر كـSource of Truth للطلبات.
بعدها قارن Tracking Evidence Order by Order.
Order IDs
ابدأ بالـOrders الفريدة.
لكل Completed Order، تحقق هل تستطيع ربط Transaction بالـTechnical Event أو Events المتوقعة.
Order ID مفيدة لأنها تربط التشخيص بعملية حقيقية، وليس Aggregate داخل Dashboard.
إذا كان Implementation يستخدم Event ID منفصلة للـmatching أو Deduplication، سجلها أيضًا.
أما متطلبات Meta الدقيقة للIdentifiers فيجب مراجعتها من Official Documentation الحالية.
Revenue وCurrency
قارن Purchase Value داخل Event مع Final Transaction في Source.
وراجع Currency في نفس الوقت.
Event تم Delivery لها لكن Value فيها خاطئة ستصنع Revenue discrepancy حتى لو Event Count يبدو طبيعيًا.
إذا كان Browser وServer يمثلان نفس Purchase، قارن Values بينهما أيضًا.
لا يجب أن يختلف المساران في تعريف قيمة Transaction الأصلية.
Event counts
عدّ Business Transactions أولًا.
ثم عدّ Technical representations لكل Transaction.
غالبًا ستجد واحدًا من ثلاثة Patterns:
Source Order بدون Event متوقعة.
Source Order لها Event Path واحدة متسقة.
أو Source Order ممثلة أكثر من مرة بدون Coordination واضحة.
هذه الأنماط تخبرك أكثر بكثير من Top-line percentage difference.
Date وTime window
تأكد أنك تقارن الأنظمة خلال Period يمكن الدفاع عنها.
راجع Source Transaction timestamp وEvent timestamps والفترة الظاهرة في Reporting.
لا تفترض أن كل System ستضع Conversion في نفس التاريخ أو الفترة بنفس الطريقة.
وهنا تظهر أهمية Attribution/Reporting configuration الحالية في Meta، لذلك يجب مراجعة Account-specific settings بدل افتراضها.
في نهاية Reconciliation، يجب أن تستطيع فصل البيانات إلى أربع مجموعات:
Source Transactions مؤكدة، Events تم Delivery لها، Tracking Failures مثبتة، وفروق Reporting/Attribution متبقية.
هنا يصبح فرق Meta عن المتجر مفيدًا بدل ما يكون مجرد رقم مربك.
إذا كان Event Path سليمًا، لا تخترع Tracking Problem فقط لأن Dashboardين مختلفان.
أما إذا وجدت Orders مفقودة أو مكررة، أو Values خاطئة، أو Delivery تفشل، فقد أصبح لديك Evidence على Measurement Problem تستحق الإصلاح.
وإذا ظل Failure Point غير واضح بعد Transaction-level reconciliation، هنا يصبح Tracking Health Audit منطقيًا.
الـAudit لا يجب أن يعدك بأن كل Dashboards ستتطابق.
وظيفته أن يحدد أي جزء من الفرق سببه Tracking، ويعرض Evidence، ثم يقترح أقل Fix مناسب للمشكلة.
أدلة مرتبطة
الأسئلة الشائعة
هل Meta والمتجر يقيسان الشيء نفسه؟
ليس بالضرورة؛ المتجر يسجل الطلبات الفعلية والمنصة تطبق Attribution/Reporting الخاصة بها.
هل يمكن لـAttribution أن يسبب فرقًا طبيعيًا؟
نعم؛ النوافذ والقواعد قد تنسب الطلبات بشكل مختلف، وتفاصيل Meta الحالية تُراجع رسميًا.
هل الأحداث المفقودة تقلل Revenue المبلغ عنه؟
نعم؛ مشتريات حقيقية لم تُنشأ أو تُرسل كأحداث قد تجعل المنصة ترى Conversions أقل.
هل التكرار قد يضخم المبيعات؟
نعم؛ تمثيل طلب واحد أكثر من مرة قد يضخم Counts/Value.
ما الذي يجب مقارنته؟
Order IDs والأعداد والإيراد/القيمة والعملة والتوقيت وEvent IDs ونتائج Delivery.