Google Tag Manager للمتاجر: أساسيات طبقة البيانات

في أغلب المتاجر التي تستخدم Google Tag Manager (GTM) تكون الحاوية مثبّتة والبيانات خارج السيطرة. الوسوم تعمل والأرقام تظهر، ولا أحد يعرف من أين تأتي قيمة الطلب. وحين يتغير قالب المتجر تتغير الأرقام معه.
طبقة البيانات هي الجزء الذي يعالج ذلك، وهي أيضًا الجزء الذي يُتجاوز كثيرًا.
ما هي طبقة البيانات
طبقة البيانات كائن JavaScript في صفحتك يعلن فيه موقعك ما يحدث، ببنية تتحكم أنت بها. تصفها وثائق Google بأنها وسيلة تمرير المعلومات إلى Tag Manager. يكتب موقعك فيها بالأمر `dataLayer.push(...)`، ويقرؤها Tag Manager ليقرر أي الوسوم يعمل.
تخيلها لوحة رسائل بين طرفين. المتجر ينشر وقائع: عُرض منتج، أُضيفت قطعة، اكتمل طلب. وGTM ووسومه تستهلك هذه الوقائع. لا يحتاج أي طرف إلى معرفة طريقة بناء الآخر.
لماذا تفشل قراءة الصفحة مباشرة
بلا طبقة بيانات، كثيرًا ما يُضبط GTM على قراءة القيم من الصفحة نفسها، كعنصر السعر أو اسم صنف الزر. ينجح ذلك إلى أن يتغير شيء.
- إعادة تصميم تغيّر اسم صنف، فتتوقف القيمة عن الوصول دون أي إنذار.
- يظهر السعر برمز العملة أو بفاصل آلاف، فيستلم الوسم نصًا بدل رقم.
- تكون الكمية في قالب مختلف لنسخة الجوال.
القراءة من الصفحة تربط القياس بالتصميم، أما طبقة البيانات فتربطه بعقد ثابت. ولمتجر يغيّر البنرات والقوالب وتطبيقات الدفع باستمرار، هذا الفرق هو لب الموضوع.
- صفحات المتجرقوالب المنتج والسلة وصفحة الشكر
- نظام الطلباترقم الطلب والقيمة والعملة والمنتجات
تقرأ الوسوم من مكان واحد، فتغيّر المتجر دون إعادة كتابة كل وسم.
النموذج: أحداث ومتغيرات ومشغّلات ووسوم
أربعة أجزاء بهذا الترتيب.
الدفع
المتجر يدفع حدث شراء مع بياناته
dataLayerالمشغّل
مشغّل حدث مخصص يطابق اسم الحدث
GTMالمتغيرات
متغيرات طبقة البيانات تقرأ قيم الطلب
GTMالوسم
وسم GA4 أو منصة إعلان يرسل الحدث
وسم
- الدفع (push). تدفع الصفحة كائنًا فيه مفتاح `event` (مثل `purchase`) والبيانات المرتبطة به.
- المشغّل. مشغّل حدث مخصص ينتظر اسم الحدث هذا. الأسماء حساسة لحالة الأحرف، فـ `Purchase` و`purchase` حدثان مختلفان.
- المتغيرات. متغيرات طبقة البيانات تسحب قيمًا مفردة، كمعرّف الطلب أو الإجمالي، من الكائن المدفوع.
- الوسوم. كل وسم يعرف من المشغّل متى يعمل، ومن المتغيرات ماذا يرسل.
ويتناول دليل Google لطبقة البيانات موضع إنشائها فوق مقطع الحاوية كي توجد القيم قبل أن تحتاجها الوسوم. راجع تلك الصفحة للتوصية الحالية بدل الاعتماد على الذاكرة.
طبقة بيانات للتجارة الإلكترونية عمليًا
توثّق Google لأحداث GA4 بنية موصى بها، تشمل كائن `ecommerce` فيه العملة والقيمة وقائمة `items`. إن اتبعت هذه البنية في دفعاتك فبإمكان وسم أحداث GA4 في GTM إرسال البيانات دون إعادة ربط كل حقل. التفاصيل والمعاملات المطلوبة في وثائق Google للتجارة الإلكترونية، فاعتمد تلك الصفحة مرجعًا. ويتابع المقال التالي أحداث التجارة الإلكترونية في GA4: الإعداد وكيف تتحقق منها قائمة الأحداث والفحوص.
عادتان أهم من أي اسم حقل:
- دفعة واحدة لكل إجراء فعلي. دفعة عند تحميل الصفحة وأخرى بعد تحديثها هي طريق تكرار المشتريات. ادفع حدث الشراء مرة واحدة لكل طلب مكتمل.
- امسح كائن التجارة السابق قبل دفعة جديدة. يدفع كثير من الممارسين قيمة فارغة إلى مفتاح `ecommerce` أولًا كي لا تتسرب بيانات حدث سابق إلى اللاحق. جرّب ذلك في متجرك قبل افتراض الحاجة إليه.
مثال محسوب
مصدر القيمة
قراءة الصفحة: عنصر في الصفحة
طبقة البيانات: حقل معرّف
بعد تغيير القالب
قراءة الصفحة: قد تتوقف أو تتغير بصمت
طبقة البيانات: تبقى كما هي ما دامت الدفعة ثابتة
صيغة القيمة
قراءة الصفحة: نص مثل "SAR 1,250.00"
طبقة البيانات: رقم 1250 وعملة SAR
من يصونها
قراءة الصفحة: من يعدّل التصميم
طبقة البيانات: من يملك شيفرة المتجر
افترض طلبًا فيه قطعتان بسعر 450 ريالًا وقطعة بسعر 350 ريالًا. القيمة الصحيحة للطلب 2 × 450 + 350 = 1,250 ريال. النص المقروء "SAR 1,250.00" يحتاج تنظيفًا قبل أن يصير رقمًا. أما في طبقة البيانات فتدفع الرقم 1250 والعملة `SAR` حقلين منفصلين. مثل هذا العيب الصغير، إذا تكرر عبر مئات الطلبات، يحول رقم التقرير إلى تخمين.
المقايضات ومتى تتغير التوصية
- التطبيقات تدفع بيانات أصلًا. كثير من منصات المتاجر وتطبيقاتها يوفر طبقة بيانات جاهزة. افحص ما تدفعه قبل أن تبني طبقتك، وتحقق هل يطابق بنية GA4.
- المتاجر الصغيرة جدًا. إن كنت تعتمد تكاملًا أصليًا من المنصة ومنصة إعلان واحدة فقد تكون طبقة مبنية يدويًا أكثر من حاجتك. أضفها حين تتعدد الوسوم أو تتعارض الأرقام.
- الدفع المخصص. صفحات الدفع المستضافة تحد أحيانًا مما تضيفه. راجع وثائق المنصة الحالية لمعرفة المسموح في صفحة تأكيد الطلب.
- الموافقة. طبقة البيانات تحمل البيانات، وقواعد الموافقة هي التي تقرر أي الوسوم يستخدمها. تأكد مما ينطبق عليك لدى الجهة المختصة أو مستشارك.
قائمة التنفيذ
- افتح الموقع بوضع المعاينة Preview في GTM وراقب الدفعات في صفحة المنتج والسلة وصفحة الشكر.
- دوّن لكل حدث اسمه وحقوله، وقارنها بوثائق Google للتجارة الإلكترونية.
- أنشئ متغيرات طبقة البيانات للحقول التي سترسلها فعلًا فقط.
- أنشئ مشغّلًا واحدًا لكل حدث يطابق اسمه حرفيًا.
- انشر بعد أن يُظهر طلب تجريبي كل حدث مرة واحدة وبالقيم الصحيحة.
ما لا يخبرك به هذا
طبقة بيانات سليمة تضمن مدخلات نظيفة، لا إسنادًا نظيفًا. ما زالت مانعات الإعلانات واختيارات الموافقة وقيود المتصفح تحدد كم حدثًا يستطيع الوسم إرساله. الطبقة تجعل جانبك موثوقًا ولا تجعل عدّ المنصة مكتملًا. وللمطابقة اقرأ لماذا تختلف مبيعات متجرك عن نتائج Meta وGoogle Ads؟، ولجانب الشراء في منصات الإعلان انظر إجراءات التحويل في Google Ads: الأساسي والثانوي وما الذي تعدّه.
الخطوة التالية
قبل إضافة وسم جديد، اكتب قائمة بدفعات طبقة البيانات في متجرك وعلّم الناقص منها وما يعمل مرتين. وإن أردت تصميم هذه البنية وتنفيذها واختبارها من البداية إلى النهاية فخدمة إعداد التتبع مخصصة لذلك.