قبل ما تحسن الحملات بناءً على conversion data، لازم تقدر تشرح: لطلب حقيقي واحد، ماذا سجل المتجر؟ ماذا أرسلت أدوات tracking؟ وماذا استلمت كل منصة؟ مقارنة dashboard totals وحدها لا تكفي.
1. حدد Business Source of Truth
في ecommerce، order platform أو قاعدة الطلبات هي المرجع الأساسي للطلبات المكتملة والقيمة والعملة والإلغاءات/refunds. منصات الإعلانات ليست نظام محاسبة.
2. عرّف Purchase بدقة
هل Purchase عند order created؟ payment captured؟ processing؟ confirmed COD؟ لازم الفريق كله يستخدم تعريفًا واحدًا قبل مقارنة أي أرقام.
3. تأكد أن الحدث موجود
لعينة orders، هل Purchase انطلقت أصلًا؟ من browser أم server أم الاثنين؟ من أي plugin أو integration؟
4. افحص التكرار
عد browser/server Purchases لنفس order، وقارن event IDs، واختبر reload/retry behavior.
5. راجع Order ID
يجب أن يكون موجودًا وثابتًا ومطابقًا للمتجر وغير معاد الاستخدام بشكل خاطئ.
6. راجع Value
حدد rule واضح: هل القيمة تشمل tax؟ shipping؟ discount؟ هل تقارن gross أم net revenue؟
7. راجع Currency
Currency ناقصة أو خاطئة قد تجعل revenue comparison مضللًا حتى لو event count صحيح.
8. راجع Items وProduct IDs
تأكد من item IDs وvariants وquantity والقيم عندما تكون مطلوبة للتحليل أو destination mapping.
9. راجع Customer Identifiers
استخدم فقط بيانات دقيقة ومسموح بها، وراجع coverage عبر sample من الأحداث بدل event ناجحة واحدة.
10. راجع Click Identifiers
افحص هل click IDs تستمر من landing إلى checkout ثم payment redirect ثم Purchase عندما تكون متاحة ومسموحًا باستخدامها.
11. راجع Browser Context
إذا كانت destination تعتمد على browser/session context، تأكد أن المسار لا يفقدها في checkout مختلف أو cross-domain flow.
12. وثّق Consent Behavior
ماذا يحدث قبل consent؟ بعد الموافقة؟ عند الرفض؟ Server-side لا يعني consent-free tracking.
13. افحص كل Destination منفصلة
نجاح GA4 لا يثبت نجاح Meta أو Google Ads. لكل destination راجع received/accepted/rejected/delayed.
14. افصل Raw Events عن Attributed Conversions
أولًا تأكد أن event وصلت. بعد ذلك فقط ناقش attribution window أو reporting model.
15. راجع Timezone
اختلاف timezone بين المتجر والمنصات قد يصنع فرقًا يوميًا وهميًا عند منتصف الليل.
16. راجع Refunds وCancellations
حدد كيف تؤثر refunds الكاملة والجزئية على reporting وهل يوجد event أو adjustment منفصل.
17. اختبر طرق الدفع
جرّب card وwallet وpayment redirect وCOD إذا كانت موجودة؛ نجاح طريقة واحدة لا يثبت صحة كل checkout paths.
18. اختبر Mobile وDesktop
نفس checkout قد يتصرف بشكل مختلف على الهاتف والمتصفح المكتبي.
19. اعمل Inventory للـPlugins وApps
اكتب كل أداة يمكن أن ترسل Meta Purchase أو Google Ads conversion أو GA4 purchase. overlap غير المقصود من أشهر أسباب duplication.
20. اعمل Regression Process
أعد الاختبار بعد theme/app/plugin updates أو checkout changes أو consent changes أو GTM changes أو destination updates.
صنّف الفرق بدل كلمة “Attribution”
استخدم فئات واضحة: Missing Event، Duplicate Event، Value Mismatch، Identity Loss، Attribution Difference، Reporting Definition. هذا يحدد من يصلح المشكلة.
Sample عملي
اختر 10–20 order موزعة على mobile/desktop وطرق دفع ومصادر traffic مختلفة. تتبع كل order end-to-end؛ عينة صغيرة جيدة غالبًا تكشف أكثر من مقارنة إجمالي dashboardين.
أين KePixel؟
Tracking Health Audit في KePixel يركز على event ownership وmissing/duplicate events وidentifier continuity وrouting والفروقات بين store truth وplatform reporting، مع تأكيد حالة كل integration قبل أي تنفيذ.
الخطوة التالية
إذا لم تستطع تحديد من يرسل Purchase اليوم، ابدأ بهذه الخريطة قبل تثبيت app أو CAPI integration جديدة.
