لافتة ملفات تعريف الارتباط أمام الوسم من جانب الخادم: ما الذي يتغيّر، وما الذي لا يتغيّر

اسم المضيف من الطرف الأول خاصية تقنية للطلب. ليس إذنًا. إن كنت تحتاج بالأمس إلى موافقة لوضع ملف تعريف ارتباط تحليلي، فأنت تحتاجها اليوم، وكون الملف يُوضع الآن من metrics.yoursite.com بدلًا من google-analytics.com لا يدخل في الحساب. سؤال الجهة الرقابية هو ما الذي تجمعه ولماذا، لا أي خادم مرّت به الحزمة في الطريق.

ما يتغيّر هو وجهة الطلب المحجوب. حاجبات الإعلانات وميزات الخصوصية في المتصفحات تحجب بحسب اسم المضيف ونمط العنوان، وهي تحجب googletagmanager.com. ولا تحجب نطاقك أنت. فالزائر الذي وافق وكانت قائمة مرشّحات ستسقطه بصمت يُحتسب الآن. هذه هي الفائدة كلها، وهي فائدة فقط للزوار الذين وافقوا.

تقرأ وسوم Google حالة موافقة مكوّنة من بضعة أذونات مسمّاة — analytics_storage و ad_storage و ad_user_data و ad_personalization — وتعدّل ما ترسله تبعًا لها. قبل أن يقرر الزائر، يدفع مدير الموافقة قيمة افتراضية denied؛ وعندما يختار، يدفع تحديثًا. في حالة denied يُطلَق وسم Google على أي حال، لكنه يرسل إشارة بلا ملفات تعريف ارتباط: لا معرّف عميل، لا ملف تعريف ارتباط، مجرد إشارة إلى أن صفحة شوهدت ولا أكثر. وما إن يصبح analytics_storage في حالة granted، يرسل النقرة الكاملة. يتلقى حاوي الخادم أيًا مما أُرسل، وتسافر إشارات الموافقة مع النقرة، فيسلك وسم GA4 في جانب الخادم السلوك نفسه.

يجب أن يُحمَّل مدير الموافقة قبل وسم Google، حتى تكون قيمته الافتراضية في مكانها عندما يقيّم الوسم للمرة الأولى. معظم مديري الموافقة يوفرون قيمة wait_for_update لهذا بالضبط — بضع مئات من الملّي ثانية ينتظر فيها الوسم حالة موافقة قبل أن يفترض denied.

الكيانات التي تنشئها SignalHost في حاويك لا تحمل شروط موافقة. هذا مقصود. وسوم Google نفسها تحترم Consent Mode؛ وفحص موافقة مضاف يدويًا على وسم Google دون فحص على وسوم أحداث GA4 التي تحته هو أول الخطأين أدناه.

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

إما ألا تقيّد شيئًا يدويًا وتترك Consent Mode يقوم بذلك، وإما أن تقيّد كل وسم قادر على الإرسال. لا وسط متسق بينهما.

بعض مديري الموافقة يعملون بحجب السكربتات حتى تُمنح الموافقة — يعترضون وسوم script بحسب العنوان ويحتجزونها. قوائمهم تعرف googletagmanager.com. ولا تعرف exxz2gdaz1jz.yoursite.com، لأن قائمة أحد لا تستطيع: اسم مضيف المحمّل واسم ملفه فريدان لحاويك. فقد يُمرَّر المحمّل في وضع الحجب دون شرط، وإن كنت تعتمد على الحجب لا على Consent Mode، فهذا وسم يُطلَق قبل الموافقة.

طريقان. أضف عنوان المحمّل يدويًا إلى قواعد الحجب في مدير الموافقة، في الفئة التي تنتمي إليها تحليلاتك. أو — وهذا أفضل، لأنه يتعامل أيضًا مع الإشارة بلا ملفات تعريف ارتباط على نحو صحيح — اعتمد على Consent Mode لوسوم Google واستخدم الحجب فقط للسكربتات التي لا تدعمه. موقعنا نحن يشغّل مدير موافقة في وضع الحجب التلقائي مع Consent Mode إلى جانبه؛ وسم Google موضوع بعد سكربت مدير الموافقة، واختبار في المستودع يفشل إذا أعاد أحد ترتيبهما.

تصل حالة الموافقة إلى حاوي الخادم داخل كل نقرة، ويقرؤها وسم GA4 في جانب الخادم كما يقرؤها وسم المتصفح. لا شيء في جانبنا يمنح موافقة أو يوسّعها؛ الإشارة بلا ملفات تعريف ارتباط تبقى إشارة بلا ملفات تعريف ارتباط.

إن ربطت وجهة Meta أو TikTok، فالنقرات نفسها تغذّيهما. أما ما إذا كان رفض الزائر للموافقة التسويقية ينبغي أن يوقف تلك التمريرات، فذلك قرار يعبّر عنه مدير الموافقة لديك — عبر الفئة التي يقع فيها المحمّل، وما إذا كان إعدادك يحترم ad_storage في Consent Mode. تحقق منه كما تتحقق من أي شيء هنا: افتح الموقع واللافتة بلا إجابة، راقب تبويب الشبكة، وانظر ما الذي يخرج.

• سكربت مدير الموافقة يقع في الصفحة فوق وسم Google.
• تُدفع حالة موافقة افتراضية denied قبل تحميل الوسم، مع wait_for_update.
• لا يوجد وسم في الحاوي بشرط موافقة مضاف يدويًا — أو أن كل وسم قادر على الإرسال يحمل شرطًا.
• مع لافتة بلا إجابة، يُظهر تبويب الشبكة إشارة بلا ملفات تعريف ارتباط (gcs=G100 في الطلب) ولا نقرة كاملة.
• بعد القبول، تُظهر الصفحة نفسها نقرة كاملة وتعدّها صفحة الحاوي.
• إذا كان مدير الموافقة يحجب بحسب العنوان، فعنوان المحمّل موجود في قواعده.