التحليلات وذكاء الأعمال

تكرار حدث الشراء: الأسباب وكيف تعمل إزالة التكرار

بقلم Mohamed Abo Younes4 د قراءة

غلاف ABOYOUNES لمقال تكرار حدث الشراء، يظهر فيه لوحان يجب أن ينتهيا إلى حدث واحد

تفتح Events Manager فتجد 140 عملية شراء، ومتجرك يعرض 100 طلب. أول رد فعل غالبًا أن تفرح بالرقم الأعلى، أو أن تلوم منصة الإعلانات. كلاهما خطأ. في أغلب الأحيان أُبلغ عن الطلب نفسه أكثر من مرة، والمنصة تتعلم من صورة ليست حقيقية.

يعرض هذا المقال الأسباب الشائعة، وكيف تعثر على سببك، وكيف يُفترض أن تعمل إزالة التكرار.

لماذا يهم التكرار

الشراء المكرر يضر من وجهين. يضخّم الإيراد المُبلَّغ عنه فتبدو الحملات أفضل مما هي. ويدرّب منصة الإعلانات على أحداث لم تقع كما عُدّت. المدخلات الخاطئة تقود إلى تحسين خاطئ مهما كانت الميزانية جيدة.

الأسباب الشائعة

ست جهات يأتي منها التكرارافحصها بهذا الترتيب
  • بكسل مثبّت مرتين

    مرة من القالب أو التطبيق، ومرة من Tag Manager أو كود مخصص.

  • إعادة تحميل صفحة الشكر

    يحدّث العميل الصفحة أو يعود إليها من رابط فيعمل حدث الشراء من جديد.

  • متصفح وخادم دون معرّف مشترك

    المساران يبلّغان عن الشراء ولا شيء يخبر المنصة أنهما واحد.

  • أكثر من أداة ترسل الحدث نفسه

    إضافة وتكامل مخصص يرسل كل منهما أحداث الخادم.

  • طلب واحد في أكثر من صفحة

    يعمل حدث الشراء في أكثر من خطوة من خطوات إتمام الطلب.

  • طلبات تجريبية

    تُحسب مشتريات الاختبار والمشتريات الداخلية مع الحقيقية.

كيف يُفترض أن تعمل إزالة التكرار

عندما يصف تقريران الإجراء نفسه تحتاج المنصة إلى مفتاح مشترك لدمجهما.

  • Meta تستخدم اسم الحدث مع معرّف الحدث. إذا كان لحدث المتصفح وحدث الخادم الاسم نفسه والمعرّف نفسه، تحتفظ بواحد.
  • GA4 تستخدم معرّف المعاملة في حدث الشراء. المشتريان بمعرّف المعاملة نفسه يُفترض أن يُعاملا كواحد.
  • تيك توك تتبع فكرة مشابهة بمعرّف حدث مشترك بين حدث المتصفح وحدث الخادم.

القاعدة سهلة في القول وسهلة الكسر: الإجراء الواقعي نفسه يجب أن يحمل المعرّف نفسه دائمًا، أيًّا كان المسار الذي أبلغ عنه.

الطلب نفسه، مع معرّف مشترك وبدونهتوضيحي

شراء من المتصفح، الطلب 1042

المعرّف: 1042

النتيجة: يُطابَق

شراء من الخادم، الطلب 1042

المعرّف: 1042

النتيجة: يُحسب مرة واحدة

شراء من المتصفح، الطلب 1042

المعرّف: a81f (عشوائي)

النتيجة: يُحسب منفصلًا

شراء من الخادم، الطلب 1042

المعرّف: c3b2 (عشوائي)

النتيجة: يُحسب مرة أخرى

مع معرّف ثابت مثل رقم الطلب ينصهر التقريران في واحد. ومع معرّفات عشوائية في كل مسار يتحول الطلب الواحد إلى اثنين.

اعثر على سببك في أربع خطوات

  1. قارن الأعداد. لفترة قصيرة قارن المشتريات في منصة الإعلانات وفي GA4 بالطلبات في متجرك. فجوة كبيرة في اتجاه واحد هي أول دليل.
  2. راقب ما يعمل فعلًا. استخدم أداة الاختبار في المنصة ومفتش المتصفح على طلب تجريبي حقيقي. عدّ كم حدث شراء يعمل ومن أين.
  3. افحص التكرار في الإعداد. اكتب كل مكان يمكن تثبيت بكسل أو وسم فيه: القالب، تطبيقات المتجر، Tag Manager، الكود المخصص. إذا كان الحدث نفسه يخرج من مكانين فهذا سببك.
  4. افحص المعرّفات. افتح حدث المتصفح وحدث الخادم وقارن معرّفيهما. يجب أن يتطابقا للطلب الواحد.

أصلحه مرة واحدة

  • أبقِ مصدرًا واحدًا لكل حدث في المتصفح، وأزل التثبيتات الزائدة.
  • أرسل الشراء بعد تأكيد الطلب فقط، وامنع الإرسال الثاني عند إعادة التحميل، مثلًا بوسم الطلب بأنه أُبلغ عنه.
  • استخدم معرّفًا ثابتًا، غالبًا رقم الطلب، كمعرّف للحدث وكمعرّف معاملة في GA4.
  • استبعد الطلبات التجريبية من البيانات الحقيقية أو سمّها بحيث لا تصل إلى أحداث الإنتاج.
  • أعد الاختبار بطلب حقيقي بعد كل تغيير.

ماذا تتوقع بعد الإصلاح

بعد الإصلاح سينخفض عدد المشتريات في المنصة غالبًا. قد يبدو هذا كأن الأمور ساءت، وهي لم تسُء. صار لديك رقم يمكن مقارنته بمتجرك، وحساب تعادل مبني على طلبات حقيقية. وإذا بقي العدد مختلفًا فتذكّر أن نوافذ الإسناد واختلاف التعريفات قد تصنع فجوات مشروعة. يغطي مقال لماذا تختلف مبيعات متجرك عن نتائج Meta وGoogle Ads؟ هذه الفجوات.

وللمسار القادم من الخادم نفسه اقرأ Meta Conversions API: ما الذي تضيفه إلى البكسل. وإن فضّلت أن تُختبر السلسلة كلها لك فخدمة إعداد التتبع تشمل إزالة التكرار والاختبار، والمراجعة تُظهر مصدر التكرار في حساب تديره فعلًا.

→ كل المقالات

ناقش احتياجات مشروعك