تتبع التحويلات لعملاء شركات التسويق لا يبدأ بوضع كود على الموقع، بل بسؤالين: من يملك حسابات القياس؟ وما الواقعة التي سنسميها «طلبًا» عندما يقرأ العميل التقرير؟ في نموذج وايت ليبل قد تنفذ جهة متخصصة الإعداد باسم وكالة التسويق، لكن ذلك لا يجعل حساب Google Analytics 4 أو حاوية Google Tag Manager ملكًا للمنفذ تلقائيًا. الأفضل أن تبقى أصول العميل قابلة للإدارة والتسليم، وأن يحصل كل طرف على الصلاحية التي يحتاجها فقط. في هذا الدليل نشرح ترتيب الحسابات، ووثيقة الأحداث، واختبار طلب التواصل المقبول، وتسليم العمل دون تكرار وسوم أو تضخيم نتائج. وهو دليل تشغيلي لفرق الوكالات، لا وعد بأن كل نموذج أو زر واتساب يمثل عميلًا أو عملية بيع
قرار الملكية يسبق إنشاء GA4 وتاج مانجر
تخيل وكالة تسويق في جدة تعاقدت مع شركة على إدارة حملاتها، وتستعين بشريك تنفيذ خلف الكواليس لضبط القياس. إذا أنشأ الشريك حساب التحليلات بحسابه الشخصي، ثم أرسل للوكالة لقطة شاشة كل شهر، تصبح العلاقة رهينة توفر شخص واحد. وإذا أنشأت الوكالة كل أصول العملاء تحت بريد موظف واحد، تنتقل المشكلة إليها بدل أن تختفي. النموذج العملي يبدأ بتحديد الجهة التي تملك الموقع والعلاقة التجارية مع العميل، والحساب المؤسسي الذي سيدير الخاصية، ومن يوافق على دعوات الشركاء، وكيف يُسحب الوصول عند انتهاء المشروع. لا تحتاج الوكالة إلى كلمة مرور العميل؛ تحتاج إلى تفويض واضح قابل للتغيير
افصل بين خمسة أشياء تبدو متشابهة في المحادثات السريعة: حساب Google Analytics، وخاصية GA4 داخله، وتدفق بيانات الموقع، وحساب Google Tag Manager، والحاوية التي تحمل الوسوم والمحفزات. ثم أضف ملكية الدومين والموقع ونظام استقبال الطلبات. صلاحية مشاهدة تقارير GA4 لا تمنح حق نشر حاوية الوسوم، وصلاحية تحرير الحاوية لا تجعل صاحبها مالكًا للعلاقة مع العميل. عند كتابة عقد التنفيذ من الباطن، اذكر أسماء الأصول ونوع الوصول ومسؤولية كل تغيير بدل عبارة عامة مثل «الشريك مسؤول عن التتبع»
توضح وثائق Google Analytics لإدارة الصلاحيات أن الأدوار تُمنح على مستوى الحساب أو الخاصية مع قيود بيانات عند الحاجة. وتوضح وثائق Tag Manager أن وصول المستخدم إلى الحساب يختلف عن أذونات الحاوية، وأن القراءة والتحرير والموافقة والنشر ليست حقًا واحدًا. استخدم هذه الطبقات لإعطاء شريك وايت ليبل وصولًا فنيًا محددًا بدل منحه بريد المدير أو صلاحية النشر الدائم لمجرد أنه سينفذ إعدادًا أوليًا
من الأنسب أن يحتفظ بصلاحية الإدارة؟
لا توجد صيغة واحدة صالحة لكل عميل، لكن توجد قاعدة قابلة للدفاع عنها: لا تجعل الطرف الخارجي وحده قادرًا على استعادة أصول القياس. إذا كان العميل يمتلك فريقًا تقنيًا وحسابات مؤسسية منظمة، فليحتفظ بإدارة الأصول ويمنح الوكالة والشريك أدوارًا متناسبة. وإذا كانت الوكالة تدير البنية بموجب اتفاق واضح، فاحفظ وصولًا إداريًا مؤسسيًا وآلية تسليم عند انتهاء العقد. المهم ألا تعتمد الخطة على حساب موظف قد يغادر أو شريك قد يتغير. راجع الأذونات دوريًا، واحتفظ بسجل للسبب الذي منح كل مستخدم دوره وللموعد الذي يجب إعادة مراجعته
اكتب تعريف التحويل قبل وضع أي وسم
تبدو كلمة «تحويل» واضحة حتى يختلف الطرفان على الرقم. قد يحسب فريق الإعلانات ضغط زر الاتصال، بينما يعد فريق المبيعات المكالمة التي استمرت وقتًا كافيًا، ويعد المدير الفرصة التي وصلت إلى عرض سعر. هذه ثلاث وقائع مختلفة، ولا يصح جمعها في صف واحد باسم «العملاء». لذلك يبدأ بريف القياس بسؤال العميل: ما الطلب الذي يستطيع فريقه استقباله والرد عليه؟ وما البيانات التي تثبت حدوثه؟ وما الإشارة الأقرب إلى قيمة العمل فعلًا؟ بعد ذلك يمكن للوكالة أن تربط المرحلة الأولى بالتحليلات، وأن تترك التأهيل والبيع لسجل التشغيل أو CRM دون ادعاء دقة غير موجودة
اكتب لكل حدث بطاقة من ست خانات: الاسم، والواقعة المسببة، ومصدر الإثبات، والحالات المستبعدة، والجهة المسؤولة عن الفحص، والهدف الذي يخدمه في التقرير. مثال: «إرسال نموذج التواصل المقبول» يحدث بعد قبول الخادم للطلب وإرجاع تأكيد صحيح؛ لا يحدث عند فتح النموذج أو محاولة الإرسال أو ظهور رسالة خطأ. أما الضغط على واتساب فهو نية انتقال إلى التطبيق، وقد لا يتحول إلى محادثة مكتملة. وحدث بدء ملء النموذج مفيد لفهم الاحتكاك، لكنه ليس طلبًا. إذا احتاج العميل عدّ المبيعات، فلا تستنتجها من GA4 وحده دون ربط موثوق بسجل المبيعات وتعريف فرصة البيع؛ يشرح دليل ربط طلبات التواصل بالمبيعات هذا المستوى التالي بصورة مستقلة
إذا أردت توسيع زاوية التحليل بعد ضبط الحدث، راجع دليل تحليل سلوك العملاء في GA4. تسمي وثائق Google الحدث الموصى به للحصول على عميل محتمل أولي generate_lead، بينما تشير إلى أحداث أخرى لمراحل لاحقة مثل التأهيل أو إغلاق البيع. راجع مرجع الأحداث الموصى بها في GA4 قبل تسمية الأحداث. لا تضع قيمة مالية افتراضية لكل نموذج لتبدو لوحة الأداء أجمل؛ وإذا استخدمت قيمة، فحدد من أين جاءت وكيف تُراجع. الأهم أن يكون وقوع الحدث قابلًا للاختبار ولا يتكرر مرتين للطلب الواحد بسبب تحميل صفحة الشكر أو إعادة إرسال النموذج
جدول قرارات بسيط بدل قائمة وسوم مبهمة
يمكنك شرح خطة القياس للفريق دون إغراقه في أسماء الأدوات: الظهور يخبرك أن الإعلان أو النتيجة ظهر، والنقرة تخبرك أن المستخدم اختار الانتقال، والجلسة تخبرك أن أداة التحليل سجلت زيارة وفق شروطها، وطلب التواصل المقبول يخبرك أن النظام استقبل رسالة أو اتصالًا قابلًا للمتابعة، والبيع يحتاج تأكيدًا من نظام المبيعات. هذه السلسلة لا تعني أن كل مستخدم يعبر المراحل كلها أو أن الأعداد يجب أن تتطابق. لكل أداة سياسة جمع وتوقيت ونطاق مختلف. إذا طلب العميل «عدد عملاء الإعلانات» فاسأله أولًا: هل يقصد محاولات النموذج، أم الطلبات المقبولة، أم الفرص المؤهلة، أم العقود؟
افحص الموقع أولًا: أين تُرسل الأحداث الآن؟
أكثر أخطاء تتبع التحويلات تكلفة ليس غياب الوسم، بل إضافة وسم ثانٍ إلى موقع يعمل بالفعل. قد يكون GA4 مثبتًا مباشرة في القالب، وقد تضعه إضافة ووردبريس، وقد ينشره Tag Manager، وربما تعمل منصات الإعلانات بوسوم منفصلة. إذا بدأ شريك التنفيذ بإنشاء حاوية جديدة قبل جرد ما يعمل، فسيرى الفريق ارتفاعًا ظاهريًا في الزيارات أو الأحداث لا يرتبط بتغير حقيقي في الجمهور. اطلب من مسؤول الموقع قائمة الإضافات المتصلة بالقياس، ومصادر أكواد الرأس والذيل، والحاويات القائمة، وروابط صفحات الشكر، وطريقة عمل النموذج. لا تُزل كودًا قديمًا لمجرد أنه غير مفهوم؛ أثبت أولًا وظيفته ومالكَه ومصير البيانات المترتبة عليه
في ووردبريس قد تتداخل وظيفة Site Kit مع إعداد منفصل لـ Tag Manager أو قالب مخصص. الخطر هنا ليس في أسماء الأدوات، بل في تكرار إرسال الحدث نفسه إلى الخاصية نفسها. قبل التنفيذ، وثّق معرف تدفق GA4، ومعرف الحاوية، والصفحات التي يُحمّل فيها كل منهما، وما إذا كانت هناك بيئة معاينة أو نسخة اختبار. إذا كان الموقع يعرض نسخة عربية وأخرى إنجليزية، فلا تفترض أن كود القياس أو الموافقة يظهر في اللغتين بالطريقة نفسها. وإذا كانت صفحة الطلب تُحمّل عبر نافذة منبثقة أو طلب AJAX، فلا تبنِ خطة القياس على انتقال إلى عنوان URL جديد لم تختبره
خريطة الأصول التي تستلمها وكالة التسويق
اطلب سجلًا مختصرًا يبدأ بالدومين والإصدار الفعلي للموقع، ثم خاصية GA4 وتدفق الويب، وحساب Tag Manager وحاويته، وربط Google Ads إن وجد، وأداة إدارة الموافقة، ووجهة الطلبات، وطريقة نسخ الإعدادات. لا تضع رموز الدخول أو كلمات المرور في المستند؛ يكفي تعريف الأصل وصاحب الصلاحية ومسار طلب الوصول. أضف اسم الشخص الذي يوافق على النشر ومتى يجوز لشريك وايت ليبل تعديل حاوية موجودة. إذا كان أكثر من منفذ يعمل في الوقت نفسه، افصل مساحة العمل والتغيير المطلوب عن التعديلات التي قد ينشرها فريق آخر قبل اكتمال الاختبار
هذا الجرد ليس بيروقراطية؛ هو ما يحدد نطاق السعر والوقت والمخاطر. عندما يقول العميل «تتبع جميع التحويلات»، قد يعني نماذج متعددة، أو مكالمات، أو محادثات واتساب، أو حجوزات من نظام خارجي. لكل قناة إثبات مختلف وقدرة مختلفة على إرجاع معلومة إلى GA4. اسأل عن الحالات الاستثنائية: ماذا لو رفض الخادم المرفق؟ ماذا لو ضغط الزائر الزر مرتين؟ ماذا لو ظهرت رسالة نجاح قبل تخزين الطلب؟ ماذا لو عاد الزائر من تطبيق الهاتف؟ إذا لم تُعرف الإجابات، اكتب «يتطلب تحققًا» بدل وعد عام بالدقة الكاملة
إعداد GA4 وGTM باسم العميل دون خلط الأدوار
بعد الجرد، حدد موضعًا واحدًا لإرسال البيانات إلى كل وجهة. لا يعني ذلك أن كل شيء يجب أن يمر عبر Tag Manager؛ بعض المواقع تُرسل أحداثًا من الخادم عند قبول الطلب، وبعضها يحتاج رسالة من الواجهة بعد استجابة صحيحة. القرار يعتمد على بنية الموقع وصلاحيات الفريق وخصوصية البيانات، لا على رغبة المنفذ في استخدام أداة بعينها. إذا اخترت GTM، فحدد من يُنشئ الوسم الأساسي، ومن يراجع المحفز، ومن ينشر الإصدار. إذا كان GA4 موجودًا مسبقًا، اختبر ما يصل إلى الخاصية قبل إضافة أي وسم جديد. وإذا كنت ستنقل طريقة التثبيت، خطط لفترة تحقق قصيرة تمنع الفجوة والتكرار
لا تجعل الوكالة توقع عقد قياس على صورة شاشة فقط. اطلب قائمة بأسماء الأحداث وتعريفها، ومصفوفة تبين أين يبدأ الحدث وأين ينتهي، وروابط الصفحات المعنية، وطريقة الاختبار في الهاتف والكمبيوتر، واسم الإصدار المنشور من الحاوية. يمكن للشريك أن يكتب هذا تحت اسم الوكالة، لكن يجب أن يتمكن فريقها من شرحه للعميل. عندما تعيد بيع خدمة القياس، فأنت تبيع نظامًا قابلًا للفحص والتسليم، لا حق الوصول الحصري إلى لوحة يصعب فهمها بعد خروج المنفذ
الأذونات الدنيا ومسار الموافقة
من الخطأ منح كل شريك دور المدير العام بدافع السرعة. قد يكفيه دور قراءة أثناء التدقيق، ثم صلاحية تحرير على الحاوية في التنفيذ، مع بقاء قرار النشر لدى شخص مسؤول في الوكالة أو العميل. وقد يحتاج حق نشر مؤقتًا إذا نص الاتفاق على ذلك. توضح مساعدة Tag Manager الرسمية الفروق بين Read وEdit وApprove وPublish، وتوصي بعدم ترك إدارة الحساب لشخص واحد فقط. أما في GA4 فراجع دور المستخدم وقيود البيانات على مستوى الخاصية؛ من يحلل النتائج ليس بالضرورة من يغير إدارة المستخدمين أو إعدادات الجمع. وثّق كل استثناء ومن وافق عليه وموعد مراجعته
إذا كان العميل يطلب أن تختفي هوية شريك وايت ليبل عن تقريره، فهذا لا يبرر استخدام حسابات مشتركة أو إخفاء الصلاحيات عن مالك الأصل. الفصل بين هوية العلامة التي يرى بها العميل الخدمة وبين حقه في أصوله الرقمية أساسي. يمكن للمنفذ العمل خلف واجهة الوكالة عبر وصول محدد ورسائل مهنية، بينما يظل سجل الأذونات واضحًا للمسؤولين المخولين. لا ترسل دعوات إلى بريد شخصي دون موافقة صاحب الحساب، ولا تحتفظ بصلاحيات لم تعد مطلوبة بعد التسليم بحجة أن المشروع قد يعود لاحقًا
كيف تختبر طلب تواصل حقيقيًا بدل الضغط على زر؟
ابدأ بمسار واحد واضح: افتح صفحة نموذج التواصل في بيئة تسمح بالاختبار، املأ بيانات اختبار مصرّحًا بها، أرسل الطلب مرة واحدة، وتحقق أولًا من استجابة الخادم أو سجل الطلب المعتمد. بعد قبول الطلب، راقب ظهور إشارة النجاح في واجهة الموقع، ثم ظهور حدث القياس في أداة التصحيح. لا تكرر إرسال النموذج إلى بريد الإدارة لأجل تحسين التقرير؛ استخدم اختبارًا محددًا يميز نفسه ويُنسق مسبقًا مع المسؤول. وإذا كان الموقع الحقيقي لا يسمح باختبار دون إنشاء طلب، فلا تستنتج نجاح التتبع من مجرد رؤية الكود؛ سجّل أن التحقق النهائي ينتظر طلبًا حقيقيًا مقبولًا
في GTM يتيح وضع Preview وTag Assistant رؤية المحفزات والوسوم التي أطلقتها نسخة العمل قبل نشرها. استخدمه لفهم ترتيب الأحداث والتأكد من أن المحفز لا يعمل عند فشل الإرسال. وفي GA4 يمكن استخدام DebugView لمتابعة أحداث جهاز اختبار عندما يكون وضع التصحيح مفعّلًا. وصول الحدث إلى DebugView يثبت مرحلة من الاختبار، لكنه لا يثبت أن تقارير الإنتاج ستسجل كل الطلبات أو أن قسم المبيعات عالجها. افصل في التقرير بين «مر الحدث من المتصفح»، و«استُقبل في التحليلات»، و«خُزن الطلب فعليًا»
اختبر الحالات السلبية كما تختبر النجاح. اترك حقلًا إلزاميًا فارغًا، وأرسل ملفًا غير مقبول إذا كان النموذج يدعم المرفقات في بيئة آمنة، وافصل الاتصال أثناء العملية إن أمكن دون إيذاء الموقع، ثم راقب ألا يظهر حدث generate_lead لمجرد محاولة الإرسال. أعد تحميل صفحة الشكر وتحقق من أن العد لا يتكرر. افتح النموذج على هاتف صغير وتأكد من أن الرسالة المرئية للمستخدم تعكس الحالة الحقيقية. عندما تكون استجابة النظام مجهولة، لا تطلب من الزائر أن يعيد الإرسال بلا تحقق؛ فقد يكون الطلب حُفظ بينما فشل إشعار البريد أو الرد المرئي
الفارق بين حدث يصل وبيانات تصلح للقرار
قد ينجح الوسم تقنيًا ويفشل القرار التجاري. مثال ذلك نموذج يرسل الحدث بعد كل ضغطة على «إرسال» حتى عند ظهور رسالة تحقق، أو خاصية تجمع زيارات موظفي الوكالة وكأنهم جمهور الحملة. وقد يكون الحدث صحيحًا لكن التقرير يخلط جلسات أسبوع بنقرات إعلان من أسبوع آخر. لهذا راجع سلسلة البيانات كاملة: تعريف الحدث، وطريقة إطلاقه، ووجهته، والمنطقة الزمنية، واستثناءات الموظفين والاختبارات، وطريقة قراءة الرقم في التقرير. سجّل ما الذي اختبرته بنفسك وما الذي لم تستطع إثباته. لا تستخدم عبارة «التتبع مضبوط 100%» لأن أدوات القياس تتأثر بالموافقات وحظر المتصفح وإعدادات الموقع والتغييرات التقنية المستمرة
تحتاج الوكالة إلى قاموس صغير للمقاييس تحمله في كل تسليم. «نقرات الإعلانات» تأتي من منصة الإعلان وفق قواعدها، و«الزيارات» من التحليلات وفق إعدادها، و«الطلبات المقبولة» من نظام استقبال الطلبات أو حدث تم التحقق من مطابقته له، و«العملاء المؤهلون» من تقييم فريق المبيعات. قد تختلف هذه الأرقام دون خطأ في أي نظام، بسبب اختلاف الفترة الزمنية أو طريقة الإسناد أو رفض ملفات الارتباط أو تكرار الطلب. عندما يُكتب الفرق بوضوح في التقرير، لا يضطر مدير الحساب إلى اختراع تفسير كل شهر. ويمكن الرجوع إلى مقالنا عن تقارير وايت ليبل لشرح فصل طبقات الأرقام قبل تقديمها للعميل
إذا ركّبت الأداة على موقع عربي وإنجليزي، لا يكفي اختبار اللغة الافتراضية. تأكد من أن كل نموذج يرسل إشارة النجاح نفسها عند قبول الطلب، وأن هوية الصفحة أو الخدمة واضحة دون إرسال نص الرسالة أو رقم الهاتف داخل بارامترات التحليلات. افحص روابط إعادة التوجيه بين اللغتين، وأحداث الأزرار التي قد تنشئها إضافات مختلفة، وحالات الهاتف التي تفتح تطبيقًا خارجيًا. لا تتعامل مع اختلاف عدد الأحداث بين اللغتين تلقائيًا بوصفه خطأ؛ ربما يختلف عدد الزوار، لكن اختلاف بنية الإرسال نفسه يتطلب فحصًا
الخصوصية: اجمع ما يخدم القياس فقط
رغبة العميل في معرفة مصدر الطلب لا تبرر نسخ كل بيانات النموذج إلى Google Analytics. تجنب إرسال الاسم أو الهاتف أو البريد أو نص الرسالة أو معرفات حساسة في أسماء الأحداث أو مسارات URL أو المعلمات؛ يكفي غالبًا نوع الطلب والقناة والصفحة أو فئة الخدمة بعد مراجعة ما هو مناسب. إذا كان هناك ربط بخادم أو أداة CRM، فحدد أين تُخزن البيانات، ومن يصل إليها، ومدة الاحتفاظ، وآلية حذف وصول الشريك عند انتهاء التعاقد. لا تقدم هذا الدليل بوصفه فتوى قانونية؛ راجع مسؤول الخصوصية والقواعد السارية على نشاط العميل وبلده قبل تشغيل جمع جديد أو مشاركة بيانات مع طرف ثالث
قد تجعل أداة الموافقة بعض الأحداث لا تُرسل إلا بعد قرار المستخدم، وقد تمنع سياسات المتصفح أو إضافاته أجزاء من القياس. لذلك لا تقارن رقم GA4 بسجل الطلبات وكأنهما نسختان من قاعدة واحدة. إذا ظهرت فجوة، ابدأ بتحديد مقدارها ونوعها والبيئة التي تحدث فيها، ثم تحقق من السلوك الفعلي بدل أن توقف الموافقة لتجعل التقرير يبدو مكتملًا. شريك وايت ليبل المهني يشرح للوكالة القيود بوضوح؛ إخفاء الفجوات عن العميل لا يحسّن جودة الخدمة
ملف تسليم يمكن لوكالتك استخدامه بعد رحيل المنفذ
لا تنتهي خدمة تتبع التحويلات عند نشر الحاوية. سلّم الوكالة وصفًا للأصول والصلاحيات، وخريطة الأحداث وأسباب إطلاقها، ونسخة من أسماء الوسوم والمحفزات والإصدارات المنشورة، ونتائج الاختبارات الإيجابية والسلبية، والقيود المعروفة، ومن يراجع البيانات بعد تغيير الموقع. اذكر تاريخ الاختبار وبيئته، لا عبارة عامة مثل «تم الفحص». وإذا غيّر فريق تطوير العميل النموذج بعد شهر، يجب أن يعرف مدير الحساب أي نقطة في السلسلة يعيد اختبارها أولًا. هذا يمنع أن تصبح الوثائق مجرد لقطة من لوحة جميلة لا تساعد في إصلاح عطل
اتفق على يوم انتقال الصلاحيات قبل بدء العمل. في هذا اليوم يتحقق صاحب الأصل من وجود وصول إداري مستقل، ثم يراجع المستخدمين الخارجيين، ويؤكد بقاء الوسوم الضرورية منشورة، ويختبر حدثًا معتمدًا إن كان الاختبار مسموحًا. لا تحذف حاوية كاملة أو خاصية GA4 لمجرد تغيير الشريك؛ قد تحتوي على سجل تاريخي أو وسوم لخدمات أخرى. ولا تُبقِ حساب الشريك السابق بنشر دائم بلا سبب. إذا كانت الوكالة تريد تشغيل مزود جديد، فالتسليم المنظم يقلل الخلاف حول ما يجب أن ينتقل وما يجب أن يبقى لدى العميل
كيف توزّع المسؤوليات في مشروع وايت ليبل؟
العميل يقرر ما يعدّ طلبًا صالحًا ويملك موقعه وبيانات عملائه وفق الاتفاق. الوكالة تترجم هذا القرار إلى نطاق خدمة وسعر وتقرير ومسار موافقات. شريك التنفيذ يضبط الوسوم أو التكاملات ويقدم دليل اختبار وحدود القياس. فريق التطوير يغير النموذج أو نقطة حفظ الطلب عند الحاجة، وفريق المبيعات يحدد لاحقًا إن صار الطلب فرصة أو صفقة. قد تتداخل الأدوار في شركة صغيرة، لكن لا يجوز أن تختفي المسؤولية. اكتب اسم الدور بدل شخص بعينه حتى لا تنهار العملية إذا غاب موظف أو انتقل الحساب إلى مدير آخر
عندما يطلب العميل تعديلًا، مرره عبر سؤالين: هل تغيّر تعريف الحدث، أم تغيّرت طريقة تنفيذه؟ تغيير لون زر لا يحتاج بالضرورة إلى إعادة تصميم القياس، أما تغيير النموذج من إرسال عادي إلى AJAX أو نقل الاستقبال إلى نظام خارجي فقد يقطع الإشارة القديمة. أرسل للشريك وصف التغيير ومثالًا على الطلب المقبول وموعد النشر. بعد التطبيق، اختبر المسار المتأثر فقط ثم حدث وثيقة التسليم. هذه الطريقة أسرع وأكثر أمانًا من تعديل جميع الوسوم كلما تغيّر شكل صفحة
مثال افتراضي: طلبات خدمة صيانة تصل بطرق مختلفة
لنفترض أن وكالة تسويق تدير حملة لشركة صيانة في السعودية، وتتلقى الشركة الطلبات عبر نموذج الموقع ومكالمة وزر واتساب. هذا مثال تدريبي لا يصف عميلًا فعليًا لإنجاز. اتفقت الوكالة مع العميل على أن الطلب المقبول من النموذج هو رسالة محفوظة تحتوي على وسيلة تواصل ونوع خدمة، بينما الضغط على واتساب مجرد فتح قناة محادثة، والمكالمة تحتاج سجلًا من مزود اتصال أو تأكيدًا من الموظف. عند بناء لوحة القياس، تُعرض الأفعال الثلاثة في صفوف منفصلة. لا تسمي الوكالة مجموعها «عملاء جدد»، ولا تُرسل قيمة بيع تلقائية إلى GA4 عند كل ضغط
في الأسبوع الأول يرى الفريق خمسين بدءًا للنموذج وعشرين محاولة إرسال، لكن نظام الطلبات يسجل اثني عشر طلبًا مقبولًا بعد استبعاد رسائل فاشلة ومكررة. إذا أظهر GA4 عشرين حدث generate_lead، فالمشكلة ليست «أن النظام رفض ثمانية عملاء»، بل أن تعريف الحدث لا يطابق واقعة القبول. يعود شريك التنفيذ إلى نقطة إطلاق الوسم: هل تعمل عند الضغط بدل استجابة الخادم؟ هل تكرر الإرسال عند تحديث الصفحة؟ بعد التصحيح لا يعيد كتابة أرقام الماضي كما لو كانت صحيحة؛ يضع تاريخ الإصلاح ويشرح للعميل أي مقارنة صارت غير عادلة. هذه الشفافية أهم من تقرير متصل لا يكشف تغير القاعدة
في الأسبوع الثاني تصل عشرة طلبات مقبولة من النموذج، ويصنف فريق المبيعات أربعة منها فرصًا مناسبة، ثم تُغلق صفقة واحدة بعد متابعة قد تمتد أسابيع. لا يجوز أن يقول التقرير إن «معدل التحويل من الإعلان إلى بيع 10%» لمجرد قسمة واحد على عشرة؛ قد تكون بعض الطلبات من بحث عضوي أو إحالات، وقد تقع الصفقة خارج فترة الإعلانات، وقد لا يكتمل الإسناد. ابدأ بتقرير ما ثبت: عشرة طلبات مقبولة في النظام، أربعة مؤهلة في سجل المبيعات، وصفقة مؤكدة بتوقيت مستقل. ثم ناقش ما يمكن نسبته للقنوات وفق البيانات والموافقات المتاحة
أخطاء تكشف أن خدمة القياس لم تُسلّم بعد
أول خطأ أن يحمل تقرير الوكالة شعارها بينما تبقى الحسابات عند شريك لا يستطيع العميل أو الوكالة الوصول إليه. ثانيها نشر وسم جديد قبل فحص الموجود، فتتضاعف الأحداث بصمت. ثالثها استخدام حدث form_start أو نقرة واتساب بوصفهما طلبًا ناجحًا، ورابعها اختبار المتصفح فقط دون التأكد من حفظ الطلب. خامسها نسيان اللغة الثانية أو نسخة الجوال، وسادسها إعطاء الشريك دور النشر الدائم دون مراجعة. هذه الأخطاء ليست مجرد تفاصيل تقنية؛ تؤثر في قرار الميزانية ووضوح المسؤولية عندما يتغير الفريق
من الأخطاء أيضًا أن يوضع اسم عميل حقيقي أو رقم هاتفه في معلمة الحدث لأن الفريق أراد مطابقة الطلبات بسهولة. المطابقة يجب أن تُصمم بما يراعي الخصوصية وسياسة الأداة والاتفاق مع العميل، لا عبر إرسال بيانات شخصية مكشوفة إلى كل لوحة. وقد يكون العيب في التقرير لا في الكود: جمع نقرات Google Ads مع جلسات GA4 وطلبات النموذج في «إجمالي تفاعل» يوحي برقم ضخم بلا معنى. إذا احتاج المدير ملخصًا، فليعرض سلسلة منفصلة مع تعريف كل مرحلة وحدودها، ثم يربطها بقرار قابل للتنفيذ
أسئلة يطرحها أصحاب شركات التسويق قبل التعاقد
هل يجب أن يكون حساب GA4 باسم العميل أم باسم الوكالة؟
الأصل أن يُحدد الاتفاق مالك الحساب والخاصية وطريقة تسليمها منذ البداية. عندما يكون العميل صاحب الموقع والبيانات، يكون احتفاظه بوصول إداري مؤسسي خيارًا يقلل الارتهان، مع منح الوكالة والشريك أذونات عمل مناسبة. توجد ترتيبات تشغيل أخرى، لكن لا تجعل المنفذ الخارجي المالك الوحيد بحكم أنه أنشأ الحساب أولًا. وثّق القرار ومن يستطيع استعادة الوصول عند تبديل الوكالة
هل تكفي إضافة Site Kit لتتبع كل الطلبات؟
لا. قد تساعد Site Kit في ربط خدمات جوجل ووضع وسوم معينة، لكنها لا تعرّف وحدها ما هو الطلب المقبول في نظامك، ولا تضمن أن كل نموذج أو مكالمة وصلت إلى فريق المبيعات. افحص ما تجمعه فعليًا، وحدد الحدث المطلوب واختبره من المصدر إلى التقرير. إذا كان الموقع يستخدم إضافة أخرى أو كودًا خاصًا، راجع التداخل قبل إضافة شيء جديد
متى أعتبر generate_lead حدثًا ناجحًا؟
عندما يرتبط بواقعة محددة اتفق عليها الفريق، مثل قبول الخادم لطلب تواصل صالح، ويظهر في أداة القياس دون تكرار ملحوظ بعد اختبار الحالات الناجحة والفاشلة. مجرد ظهور الاسم في إعدادات الحاوية لا يكفي. وإذا لم يكن لديك حق اختبار طلب حقيقي، صرّح بأن النشر الفني تم لكن تحقق القبول النهائي لم يكتمل
هل تستطيع وكالة وايت ليبل إخفاء اسم الشريك عن العميل؟
يمكن تقديم الخدمة والتقرير بهوية الوكالة وفق اتفاقها مع العميل وشريك التنفيذ، لكن ذلك لا يبرر إخفاء حق العميل في أصوله أو منح صلاحيات غير مصرح بها. رتب التفويضات والعقود والخصوصية بوضوح بين الأطراف المخولة. الفرق بين العلامة الظاهرة في التقرير وبين ملكية البيانات يجب أن يكون معروفًا لمن يملك القرار
لماذا يختلف عدد الطلبات بين GA4 ونظام النماذج؟
قد يعود الفرق إلى الموافقة على التتبع أو حظر المتصفح أو توقيت تسجيل الحدث أو تكراره أو اختلاف تعريف الطلب نفسه. ابدأ بمقارنة طلبات معروفة وتواريخها وحالات قبولها، ثم افحص الحدث في Tag Assistant وDebugView إذا كان ذلك متاحًا. لا تعدّل الأرقام يدويًا لمجرد مساواتها، ولا تفترض أن إحدى الأداتين «معطلة» من فرق إجمالي واحد
هل الضغط على زر الهاتف أو واتساب تحويل نهائي؟
هو إشارة نية اتصال أو انتقال، لكنه لا يثبت مكالمة متصلة أو محادثة مفيدة أو صفقة. اعرضه كمؤشر مستقل، واستخدم سجل اتصال أو نظام محادثات أو متابعة بشرية إذا أردت قياس المرحلة التالية. لا تسوّق للعميل عدد الضغطات على أنه عدد العملاء الذين اشتروا
ماذا أطلب من شريك التنفيذ عند انتهاء المشروع؟
اطلب خريطة الأصول والأذونات، وتعريف الأحداث، وقائمة الإصدارات المنشورة، ونتائج الاختبارات، والقيود، وخطة إعادة الاختبار بعد تغييرات الموقع، وتاريخ سحب الصلاحيات غير اللازمة. اختبر وصول الوكالة أو العميل إلى الحسابات قبل إنهاء التعاقد، ولا تعتمد على ملف PDF لا يستطيع أحد تنفيذ ما فيه
ابدأ من الواقعة التي يريدها العميل، ثم ابنِ القياس حولها
إذا كانت وكالتك تحتاج شريكًا ينفذ إعداد قياس قابلًا للفحص والتسليم باسمك، فابدأ بتحديد القنوات والنماذج ومالك الحسابات وتعريف الطلب المقبول. ستتمكن عندها من مقارنة عروض التنفيذ على نتيجة محددة بدل قائمة أدوات عامة. تعرّف على خدمات وايت ليبل لشركات التسويق، أو تواصل مع إنجاز لعرض نطاق المشروع وما لديك من حسابات حالية. لا نعدك بأن وسمًا واحدًا يضمن مبيعات؛ نبدأ بوضوح الملكية وصحة الحدث وحدود التقرير حتى يكون القرار التالي مبنيًا على ما حدث فعلًا
