العودة إلى المدونة

المدونة

الوسم من جانب الخادم لمتجر Shopify أو WooCommerce: ما الذي يُطلَق، وما الذي لا يُطلَق، وما الذي تثبّته

نُشر · حُدّث · 4 دقائق قراءة

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

الأحداث التسعة، والشيء الوحيد المشترك بينها

يحدد GA4 تسعة أحداث لمسار الشراء: view_item_list و view_item و add_to_cart و remove_from_cart و view_cart و begin_checkout و add_shipping_info و add_payment_info و purchase. الأسماء أسماء GA4 لا أسماء أي منصة — التسعة نفسها تعمل مع Shopify وWooCommerce ومتجر بنيته بنفسك.

ما تتشاركه هو الآلية. كل واحد منها دفعٌ إلى dataLayer الصفحة، بهذا الاسم بالضبط، يحمل كائن ecommerce بشكل GA4. مشغّل في Tag Manager يستمع للاسم؛ ووسم حدث GA4 يقرأ كائن ecommerce ويرسله. أخطئ في كتابة الاسم، أو ضع الكائن في مستوى أعمق بدرجة، أو ادفعه في الصفحة الخطأ، فيبقى الوسم ساكنًا إلى الأبد دون خطأ. هكذا يبدو دفع الشراء:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'ORD-10442',
    value: 89.90,
    currency: 'EUR',
    items: [
      { item_id: 'SKU-118', item_name: 'Trail jacket', price: 89.90, quantity: 1 }
    ]
  }
});

دفع ecommerce: null أولًا ليس زينة. من دونه، قد تتسرّب عناصر الحدث السابق إلى الحدث التالي، فيظهر view_item من ثلاث صفحات مضت داخل purchase.

Shopify: القالب لا يرى صفحة الدفع

الحاوي المثبّت في قالب Shopify يُحمَّل في واجهة المتجر — صفحات المنتجات والمجموعات والسلة. ولا يُحمَّل في صفحة الدفع ولا في صفحة الشكر، اللتين تقدّمهما Shopify من نطاقها الخاص وبقوالبها الخاصة. لذا يمكن لحاوي مثبّت في القالب أن يرسل view_item و add_to_cart، ولن يرسل أبدًا، بأي إعداد كان، begin_checkout أو add_shipping_info أو add_payment_info أو purchase.

هذه الأربعة تأتي من Custom Pixel. تكشف بيئة البكسل المعزولة في Shopify أحداث الدفع (checkout_started و checkout_shipping_info_submitted و payment_info_submitted و checkout_completed) وتتيح للبكسل أن يدفع إلى dataLayer خاص به — وسكربت صغير يربط كل واحد منها باسم حدث GA4 وشكله المذكورين أعلاه. أحداث واجهة المتجر تظل تأتي من القالب، فالإعداد الكامل يضم الاثنين: تطبيق dataLayer أو مقطع في القالب لنصف التصفح، وCustom Pixel لنصف الدفع.

قرار آخر. قناة Google وYouTube في Shopify تستطيع إرسال أحداث GA4 مباشرة خارج أي حاوي. إن ربطت هناك عقار GA4 ومرّرت العقار نفسه عبر حاويك، فسيُحتسب كل شراء مرتين. اختر مسارًا واحدًا. إن كان الهدف هو الجمع من الطرف الأول، فالمسار هو الحاوي، ويبقى اتصال Analytics في القناة مغلقًا.

WooCommerce: النواة لا تدفع شيئًا

WooCommerce بذاته لا يكتب أي dataLayer. تفعل ذلك إضافة — وGTM4WP هي ما يلجأ إليه معظم الناس — وخيار التجارة الإلكترونية GA4 فيها ينتج هذه الأحداث بالشكل الصحيح في الصفحات الصحيحة: view_item في المنتج، و add_to_cart عند الزر، و begin_checkout في صفحة الدفع، و purchase في صفحة استلام الطلب.

العطل الكلاسيكي في WooCommerce هو شراء مضاعف، وله سبب محدد: صفحة استلام الطلب تُعاد تحميلها. يحدّثها الزائر، أو يعود إليها من مزوّد الدفع، أو يعيد القالب التوجيه عبرها مرتين، فيُدفع purchase مجددًا بنفس transaction_id. يزيل GA4 تكرار المشتريات بحسب transaction_id داخل الجلسة، وهذا يلتقط معظم الحالات، لكنه لا يلتقط إعادة تحميل في اليوم التالي. إعداد الإضافة «الإطلاق مرة واحدة فقط لكل طلب» يستحق التفعيل؛ فهو يحتفظ بالعلامة في جانب الخادم حيث لا تستطيع إعادة التحميل تصفيرها.

ما الذي تبنيه SignalHost لك

في كل حاوي SignalHost، داخل حاوي الويب الخاص به، مشغّل حدث مخصص ووسم حدث GA4 لكل من الأحداث التسعة — وللسبعة التي يحتاجها أيضًا موقع بلا متجر: التسجيلات والفترات التجريبية والعملاء المحتملون. كلها بالبادئة SH، فلا تتعارض أبدًا مع ما لديك. كل وسم يرسل كائن ecommerce مباشرة من dataLayer، فتمرّ items و value و currency و transaction_id دون متغير لكل حقل، وكل وسم يسمّي معرّف القياس الخاص بك صراحةً بدلًا من وراثته.

لا يُثبَّت شيء في متجرك. المشغّلات تستمع؛ والدفعات من الإضافة أو البكسل. إن كان حاويك يرسل أحد هذه الأحداث إلى GA4 بوسم خاص بك — إضافة جلبت وسم purchase الخاص بها مثلًا — تترك SignalHost ذلك الحدث له ولا تبني وسمًا ثانيًا، فلا يُحتسب أي طلب مرتين. وكل وسم يمرّر أيضًا event_id الذي تدفعه مع الحدث، فمنصة الإعلانات التي تتلقى الحدث نفسه من البكسل الخاص بها تحتسبه مرة واحدة.

في جانب الخادم لا يوجد شيء لكل حدث. وسم GA4 في حاوي الخادم يمرّر كل حدث يتلقاه مهما كان اسمه، فالحدث الجديد في موقعك لا يحتاج إلى أي تغيير في جانبنا. ومنصات الإعلانات التي تربطها — Google Ads وMeta وTikTok وReddit وPinterest وSnapchat وLinkedIn — تتلقى الأحداث نفسها: فيصبح purchase هو Purchase لدى Meta وTikTok، مع منتجاته وقيمته، وتتلقى كل منصة من الدفعة نفسها الأحداث التي تفيدها.

التحقق بطلب تجريبي واحد

أنشئ طلبًا حقيقيًا في وضع الاختبار، أو طلبًا رخيصًا تسترد ثمنه لاحقًا، وراقب قائمة الأحداث في صفحة الحاوي. ينبغي أن ترى بالتسلسل view_item و add_to_cart و begin_checkout و add_payment_info و purchase — كلٌّ مرة واحدة، وبينها view_cart و add_shipping_info إن كان إعدادك يدفعهما. غياب purchase في Shopify يعني أن Custom Pixel غير مثبّت أو لا يدفع؛ وغياب begin_checkout في WooCommerce يعني عادةً أن حدث الدفع في الإضافة معطّل.

إن كنت تمرّر تحويلات Google Ads عبر الحاوي، فإن purchase هو حدث التحويل ما لم تختر غيره، وتُقرأ قيمته وعملته ومعرّف معاملته من كائن ecommerce نفسه. دفعة شراء بلا value تسجّل تحويلًا لا قيمة له — وهو رقم حقيقي في التقرير، والرقم الخاطئ.

إذا ظل GA4 يحتسب طلبات أقل من متجرك بعد ذلك، فإليك لماذا يحتسب GA4 أقل، وما الذي يمكن استعادته.

كفى خسارةً للبيانات أمام أدوات الحجب

ابدأ مجانًا. شغّل حاويتك الأولى خلال دقائق.