كيف تُفعّل Google Consent Mode v2 في متجرك السعودي وفق نظام حماية البيانات الشخصيّة

Google Consent Mode v2 هو الطريقة التي يُبلغ بها الموقع علامات Google بما وافق عليه كلّ زائر. ومنذ مارس 2024 تشترطه Google على المعلنين الذين يريدون الاحتفاظ بإعادة الاستهداف، وميزات الجماهير، وقياس التحويلات للمستخدمين في المنطقة الاقتصاديّة الأوروبيّة (EEA)، وتشمل سياستها لموافقة مستخدمي الاتّحاد الأوروبي بريطانيا وسويسرا أيضًا. أمّا للمتاجر في السعوديّة فالدافع مختلف: اشتراط الموافقة في نظام حماية البيانات الشخصيّة (PDPL). ويتناول هذا الدليل الجانبين.

وضع الموافقة ينقل قرار الزائر، أمّا متى يلزمك طلب القرار فيحدّده النظام. والقواعد نفسها في دليلنا لموافقة ملفات تعريف الارتباط في نظام حماية البيانات الشخصيّة.

ما هو Google Consent Mode v2؟

Google Consent Mode v2 واجهة برمجيّة من Google تنقل اختيارات الزائر بشأن الموافقة إلى علامات Google مثل GA4 و Google Ads و Floodlight. يعتمد على أربع إشارات: analytics_storage، و ad_storage، و ad_user_data، و ad_personalization، وتُضبط كلّ منها على «granted» أو «denied»، فتُغيّر علامات Google ما تحفظه وما ترسله بناءً عليها.

ما المختلف بين الإصدار v1 و v2

احتوى Consent Mode v1 على معاملَين فقط: analytics_storage و ad_storage. أمّا v2 فيُضيف معاملَين جوهريَّين: ad_user_data (يتحكّم في إمكانيّة إرسال بيانات المستخدم إلى Google لأغراض الإعلان) و ad_personalization (يتحكّم في عرض الإعلانات المخصّصة). هذان المعاملان إلزاميّان — لن تعمل Google Ads بصورة صحيحة بدونهما. منصّة CMP لديك يجب أن تُرسل المعاملات الأربعة كلّها مع كلّ تحميل صفحة.

معاملات الموافقة الأربعة

يستخدم Google Consent Mode v2 أربعة معاملات للتحكّم في سلوك علامات Google. يجب ضبط كلٍّ منها على «granted» أو «denied». عند التحميل الأوّل للصفحة، يجب أن تكون قيمها الافتراضيّة «denied» حتّى يختار الزائر:

• analytics_storage — يتحكّم في ملفات تعريف ارتباط Google Analytics (يقابل فئة موافقة «التحليلات»)
• ad_storage — يتحكّم في ملفات تعريف الارتباط (الكوكيز) والمعرّفات الإعلانيّة (يقابل فئة «التسويق»)
• ad_user_data — يتحكّم في إرسال بيانات المستخدم على مستوى الأفراد (البريد، الهاتف) إلى Google للمطابقة الإعلانيّة
• ad_personalization — يتحكّم في استخدام Google للبيانات لتخصيص الإعلانات وإعادة الاستهداف

يُطلق شريط أرقام٣٦٠ القيم الافتراضيّة المرفوضة قبل أن يختار الزائر، ثمّ يرسل تحديثًا واحدًا عند اختياره: فئة «التحليلات» تمنح analytics_storage، وفئة «التسويق» تمنح الإشارات الإعلانيّة الثلاث معًا. أمّا functionality_storage و security_storage فتُرسَلان دائمًا بقيمة «granted»، لأنّهما تغطّيان التخزين الذي يحتاجه الموقع ليعمل.

هل Google Consent Mode v2 إلزامي؟

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

أطلقت Google تحديث Consent Mode v2 استجابةً لقانون الأسواق الرقميّة الأوروبي (DMA)، الذي يصنّف Google بوصفها «بوّابة» (gatekeeper) ويشترط الموافقة الصريحة من المستخدم قبل معالجة بياناته الشخصيّة لأغراض الإعلان. وبدون إشارات Consent Mode v2 من موقعك، لا تستطيع Google تحديد ما إذا كان الزائر قد وافق — فتُعامل البيانات كلّها كغير مُوافَق عليها. هذا يعني لا جمهور إعادة استهداف، ولا نمذجة تحويلات، وأداء حملات أضعف بكثير.

الأثر العملي يقع على القياس. فدون إشارات Consent Mode v2 لا تستطيع Google التمييز بين زائر وافق وآخر رفض، لذا تُقيّد جماهير إعادة الاستهداف للزيارات المعنيّة، ولا تستطيع تطبيق نمذجة التحويلات، ويعمل Smart Bidding ببيانات أقلّ. وبالنسبة للمتاجر التي تُنفق بجدّيّة على Google Ads، يظهر ذلك إسنادًا أضعف ومزايدة أقلّ كفاءة.

هل تحتاج المتاجر السعوديّة إلى Google Consent Mode v2؟

اشتراط Google الخاصّ بـ Consent Mode v2 يستهدف الزيارات من المنطقة الاقتصاديّة الأوروبيّة وبريطانيا، لا من السعوديّة. أمّا الدافع في السعوديّة فهو نظام حماية البيانات الشخصيّة: فالتتبّع الذي يجمع بيانات شخصيّة يحتاج إلى أساس صحيح، هو الموافقة عادةً، قبل أن يعمل. وإن كان المتجر يستخدم Google Analytics أو Google Ads، فـ Consent Mode v2 هو وسيلة إيصال هذه الموافقة إلى علامات Google.

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

بُني Consent Mode v2 في الأساس لقانون الأسواق الرقميّة الأوروبي (DMA) ولائحة GDPR، لكنّ تصميم إشاراته يناسب نظام حماية البيانات الشخصيّة جيّدًا. فبموجب النظام، يجب أن يمنح الزائر إذنه صراحةً قبل كتابة أيّ ملف تعريف ارتباط للتتبّع، وقبل انطلاق أيّ بيكسل تتبّع، وقبل إنشاء أيّ معرّف تحليلي. أمّا نموذج الانسحاب، الذي يعمل فيه التتبّع حتّى يعترض أحد، فلا يستوفي هذا المعيار.

وتصميم الرفض الافتراضي في Consent Mode v2 يتّسق مع ذلك. فحين تُطلق gtag('consent', 'default', {analytics_storage: 'denied', ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied'}) قبل تحميل علامات Google، لا يعالج أيّ منتج من Google في الصفحة البيانات وكأنّ الموافقة ممنوحة. ونداء التحديث بعد النقر على الشريط يسجّل اختيار الزائر الفعلي. ومن يراجع طلبات الشبكة في موقعك من متصفّح جديد سيرى الرفض الافتراضي أوّلًا، ثمّ لا طلبات بيانات إلى Google حتّى ينقر الزائر، وهذا هو الدليل الذي تحتاج إلى عرضه إن وصلت شكوى إلى SDAIA.

كيف تُفعّل Google Consent Mode v2؟

اضبط الإشارات الأربع على الرفض قبل تحميل أيّ علامة من Google، وحدّثها عبر gtag('consent', 'update', …) حين يختار الزائر، واستعِد الاختيار المحفوظ في الزيارات التالية. تستطيع منصّة إدارة الموافقة (CMP) تولّي الخطوات الثلاث عنك، وتوضّح الخطوات أدناه ما يجب أن تفعله.

الخطوة 1: ضبط الحالة الافتراضيّة «مرفوضة»

الخطوة الأهمّ ضمان إطلاق الحالة الافتراضيّة للموافقة قبل تحميل أيّ علامة من Google. أي استدعاء gtag('consent', 'default', { analytics_storage: 'denied', ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied' }) بوصفه أوّل شيء في رأس الصفحة — قبل GTM، وقبل GA4، وقبل أيّ سكربت آخر. إذا أُطلقت الحالة الافتراضيّة بعد علامات Google، فلديك فجوة امتثال.

الخطوة 2: تحديث الموافقة عند اختيار المستخدم

حين يتفاعل الزائر مع شريط الموافقة ويختار خياراته، يجب أن تُطلق منصّة CMP فورًا gtag('consent', 'update', {...}) بقيم المعاملات الجديدة. إذا قَبِل الزائر التحليلات ورفض التسويق، يضبط استدعاء التحديث analytics_storage على «granted» مع إبقاء ad_storage و ad_user_data و ad_personalization على «denied». يجب أن يُطلَق التحديث متزامنًا — فأيّ تأخير يعني أنّ علامات Google قد تُطلَق بحالة موافقة قديمة.

الخطوة 3: التعامل مع الزوّار العائدين

للزوّار العائدين الذين سبق أن وافقوا، يجب أن تقرأ منصّة CMP ملف تعريف الارتباط المخزَّن الذي يحفظ الموافقة وتُطلق الحالة الافتراضيّة الملائمة عند تحميل الصفحة. إذا قَبِل زائرٌ كلّ الفئات بالأمس، يجب أن يُطلق تحميل اليوم الحالةَ الافتراضيّة بالموافقات كلّها ممنوحة. هذا يضمن وصول إشارات الموافقة الصحيحة إلى علامات Google فورًا، دون انتظار ظهور الشريط. يتولّى أرقام٣٦٠ ذلك تلقائيًّا بقراءة ملف تعريف الارتباط consentiq_consent قبل إطلاق أيّ علامة.

ماذا يحدث لبيانات Google حين يرفض الزائر الموافقة؟

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

النمذجة هي حلّ Google لهذه الفجوة. ففي أبريل 2021، وفي معرض عرض نتائجها الأولى، ذكرت Google أنّ نمذجة التحويلات عبر Consent Mode تستعيد في المتوسّط أكثر من 70% من مسارات «النقر على الإعلان ثمّ التحويل» التي تضيع بسبب اختيارات الموافقة، وأضافت أنّ النتائج تتفاوت كثيرًا بحسب معدّلات الموافقة والإعداد. تعامل مع هذا الرقم بوصفه تقديرًا أوّليًّا من Google نفسها، لا توقّعًا لمتجرك. ويستطيع GA4 أيضًا نمذجة سلوك الزوّار الرافضين متى بلغت الزيارات الحدّ المطلوب. ومع إرسال الإشارات الأربع بصورة صحيحة، تحتفظ Google Ads بجماهير إعادة الاستهداف للزوّار الموافقين، وبـ Enhanced Conversions، وبـ Smart Bidding.

كيف تُفعّل Consent Mode v2 على Shopify وسلة وزد و WordPress؟

استخدم مسار الموافقة الخاصّ بكلّ منصّة: على Shopify تطبيق CMP يستدعي Customer Privacy API ويرسل تحديثات gtag أيضًا، وعلى سلة وزد تطبيق موافقة يُضيف نصّ الشريط البرمجي إلى واجهة المتجر، وعلى WordPress إضافة CMP أو قالب موافقة في GTM. وفي كلّ الحالات يجب أن يُطلَق الرفض الافتراضي قبل علاماتك.

طريقة توصيل Consent Mode v2 تتوقّف على منصّة متجرك. كلّ المسارات أدناه تُنتج الحالة النهائيّة ذاتها — رفض افتراضي يُطلَق أوّلًا، ثم تحديث عند الموافقة — لكنّ سطح التنفيذ يختلف.

Shopify

تكشف Shopify عن واجهة Customer Privacy API، وهي نقطة التكامل الرسميّة للموافقة على واجهة Shopify. منصّة إدارة الموافقة (CMP) المثبّتة عبر متجر تطبيقات Shopify تستدعي window.Shopify.customerPrivacy.setTrackingConsent() حين يقبل الزائر أو يرفض. إن استخدمت Google Tag Manager أيضًا على Shopify، فعلى CMP بالإضافة إلى ذلك أن تستدعي gtag('consent', 'update', ...) — Customer Privacy API لا ينتشر تلقائيًّا إلى وسوم GTM. تطبيق أرقام٣٦٠ لـ Shopify يُدير كلا السطحين بنقرة واحدة؛ يُثبّته التاجر من متجر التطبيقات، يظهر الشريط، وترث تحليلات Shopify ووسوم Google المحمَّلة عبر GTM حالة الموافقة تلقائيًّا.

سلة

يُضيف تجّار سلة أدوات الموافقة عبر متجر تطبيقات سلة أو عبر إعدادات الأكواد المخصّصة في المتجر. وفي سلة تفصيل خاصّ: تُحمّل المنصّة حاوية Google Tag Manager الخاصّة بها مبكرًا جدًّا، فلا يستطيع أيّ تطبيق أن يسبقها بإعداد الموافقة الافتراضي. ما يستطيعه تطبيق الموافقة هو ضبط الرفض الافتراضي قبل مشغّلات تحميل الصفحة وعلاماتك أنت، ثمّ تحديثه حين يختار الزائر. ويُجهّز تطبيق أرقام٣٦٠ على سلة الشريط مع إعدادات Consent Mode v2 الافتراضيّة عند التثبيت، دون تعديل كود الثيم أو حاوية GTM. وأيًّا كان التطبيق الذي تستخدمه، تحقّق من الترتيب في Tag Assistant بعد التثبيت.

زد

تتّبع زد نمط تطبيقات مشابهًا لسلة؛ فالنصّ البرمجي الذي يُضيفه تطبيق زد يقع في رأس صفحة المتجر، ويضبط إعدادات Consent Mode v2 الافتراضيّة قبل علامات صفحتك، ويُحدّثها حين يتفاعل الزائر مع الشريط. والمتاجر التي تُشغّل تتبّع تحويلات Google Ads أو Conversions API من Meta تحتاج إلى التحقّق من الترتيب في Tag Assistant بالعناية نفسها: فالإعداد الافتراضي المتأخّر يعني أنّ العلامات عملت قبله.

WordPress

تجّار WordPress أمامهم مساران: إضافة CMP أو ضبط GTM يدويًّا. إضافة أرقام٣٦٠ لـ WordPress (السلة على wordpress.org: arqam360-consent-privacy-pdplgdpr) تُدير GCM v2 تلقائيًّا — ثبّت، فعّل، ألصق مفتاح API من لوحة التحكم، ويُشحَن الشريط مع إعدادات الرفض الافتراضي موصولة. للمواقع التي تملك حاويات GTM مخصّصة، يمكنك استخدام قالب GCM-v2 المدمَج؛ الإعدادات متطابقة، لكنّها تُدار في GTM بدل لوحة WordPress.

المواقع المُخصّصة

للمواقع التي لا تملك إضافة CMP أو تكامل تطبيق، الإعداد اليدوي كالتالي: (1) أضف stub لـ gtag في رأس المستند قبل أيّ سكربت آخر — نداء gtag('consent', 'default', ...) بالعوامل الأربعة كلّها مضبوطة على 'denied'؛ (2) حمّل وسوم Google (gtag.js و GA4 و Google Ads و Floodlight) بعد إطلاق الرفض الافتراضي؛ (3) اربط زرَّي القبول والرفض في شريطك بنداءات gtag('consent', 'update', {...}). الترتيب غير قابل للتفاوض — يجب أن يُطلَق الافتراضي أوّلًا. فوسم Google الذي يُحمَّل قبله يعمل دون أيّ حالة موافقة، ويُرسل عادةً بياناته ويضع ملفات تعريف الارتباط لتلك الزيارة. وتسري التحديثات اللاحقة من تلك اللحظة، لكنّها لا تُلغي ما أُطلق قبلها.

كيف تتحقّق من أنّ Consent Mode v2 يعمل؟

افتح موقعك في نافذة تصفّح خاص واستخدم Google Tag Assistant: يجب أن يظهر إعداد موافقة افتراضي بالإشارات الأربع مرفوضةً قبل أيّ علامة من Google، ثمّ تحديث حين تنقر على الشريط. بعدها راجع لسان Network في المتصفّح: يجب ألّا تخرج أيّ طلبات إلى google-analytics.com أو doubleclick.net قبل أن تختار.

يستغرق كلّ فحص أدناه دقائق. شغّلها في جلسة متصفّح جديدة (نافذة تصفّح خاص أو ملف مستخدم جديد) لمحاكاة زائر للمرّة الأولى؛ فالمتصفّح الذي تستخدمه يوميًّا، بما خزّنه من ملفات تعريف الارتباط سابقًا، يعطي قراءات «الموافقة ممنوحة» مضلّلة.

• Google Tag Assistant Companion (إضافة Chrome): افتح الإضافة، وحدّث الصفحة، وانقر على لسان 'Tags'. يجب أن ترى نداء gtag('consent', 'default') يُطلَق أوّلًا، وكلّ الإشارات تظهر 'denied'. وبعد النقر على زرّ القبول في شريطك، يجب أن يُطلَق نداء gtag('consent', 'update') بالإشارات التي ربطتها بـ 'granted'.
• وضع المعاينة في GTM (Tag Assistant): اتّصل بحاوية GTM في وضع المعاينة. يجب أن ترى حدث الموافقة يُطلَق قبل تنفيذ أيّ علامة، وأن تبقى العلامات المضبوطة على «يلزم موافقة إضافيّة لإطلاق العلامة» متوقّفة حتّى تتحوّل إشارة الموافقة المقابلة إلى 'granted'.
• GA4 DebugView: ادخل خاصّيّة GA4 ← Configure ← DebugView، وزر الموقع مع debug_mode=1 في الرابط. يجب ألّا ترى أحداثًا ما دامت الموافقة مرفوضة، ثمّ تظهر الأحداث بعد القبول. وإن وصلت أحداث إلى DebugView بينما الشريط لا يزال يعرض الرفض، فالإعداد الافتراضي أُطلِق بعد أوّل علامة GA4، فأصلح ترتيب التحميل.
• لسان Network في DevTools: افتح DevTools ← Network، وصفِّ النتائج بـ 'google-analytics' أو 'doubleclick'. في الزيارة الجديدة يجب ألّا ترى أيّ طلب إلى هذين النطاقين قبل التفاعل مع الشريط. وإن رأيت طلبات تنطلق فورًا، فإنّ Consent Mode لا يحجبها: إمّا أنّ الحالة الافتراضيّة غير مضبوطة، أو أنّ العلامات تُحمَّل بمعزل عن gtag.
• من زاوية نظام حماية البيانات الشخصيّة: إن وصلت شكوى إلى SDAIA، فأبسط دليل تستطيع عرضه سجلّ شبكة يخلو من طلبات تتبّع Google قبل الموافقة. واجعل إثبات ذلك سهلًا بالحجب الكامل حتّى الموافقة؛ فالحجب الجزئي، حين تنتظر أغلب العلامات وتنطلق واحدة مبكرًا، أصعب في الدفاع عنه.
• التحقّق من الزائر العائد: في التصفّح الخاص، اقبل الموافقة، ثمّ أغلق النافذة وافتح نافذة تصفّح خاص جديدة وزر الموقع مرّة أخرى. يجب أن تُستعاد موافقتك المحفوظة، ويُطلَق النداء الافتراضي بقيم 'granted'، وتعمل العلامات طبيعيًّا. وإن ظهر الشريط من جديد، فمنصّة الموافقة لا تحفظ سجلّ الموافقة بصورة صحيحة، وهذا خلل امتثال مستقلّ يحتاج إلى إصلاح.

قائمة سريعة: أربعة سيناريوهات للاختبار

التحقّق ضروري. استخدم Google Tag Assistant (إضافة Chrome) لفحص إشارات الموافقة على موقعك الفعلي، واختبر أربعة سيناريوهات:

• زائر جديد: تحقّق من إطلاق الحالة الافتراضيّة «denied» قبل أيّ علامة، ثمّ إطلاق «update» عند التفاعل مع الشريط
• زائر عائد موافِق: تحقّق من إطلاق الحالة الافتراضيّة بـ «granted» فورًا عند تحميل الصفحة
• سحب الموافقة: تحقّق من إطلاق «update» بـ «denied» حين يسحب الزائر موافقته
• تشخيصات Google Ads: راجع Tools > Diagnostics في Google Ads للتأكّد من علامات الصحّ الخضراء على المعاملات الأربعة

خمسة أخطاء شائعة وكيف تتجنّبها

تفشل أغلب تطبيقات GCM v2 المعطوبة بإحدى خمس طرق. إن كنت فعّلت Consent Mode v2 بنفسك، فراجع إعدادك مقابل كلّ منها قبل أن تفترض أنّه يعمل.

الخطأ 1 — إطلاق الافتراضي بعد GA4. الأكثر شيوعًا. يُضيف المطوّرون gtag('consent', 'default', ...) في الكتلة البرمجيّة نفسها مع gtag('config', 'G-XXXXX', ...) أو بعد وسم GA4 في GTM. النتيجة: GA4 يُهيّأ ويُرسل أولى بياناته قبل وجود أيّ حالة موافقة، فتُقاس تلك الزيارة وقد تُوضع ملفات تعريف الارتباط قبل أن يختار الزائر. يحكم الافتراضي المتأخّر ما يأتي بعده، لكنّه لا يسترجع ما أُطلق قبله — بينما تُظهر واجهة الموافقة 'denied'. الإصلاح: يجب أن يكون نداء الموافقة الافتراضي أوّل نداء gtag على الصفحة، قبل أيّ منتج Google آخر.

الخطأ 2 — تفويت العوامل الجديدة الخاصّة بـ v2. أدخل Consent Mode v2 ad_user_data و ad_personalization فوق ad_storage و analytics_storage في v1. هاجرت بعض منصّات CMP من v1 إلى v2 بإعادة التسمية فقط، وتركت العامِلَين الجديدَين دون ضبط (وهو ما يُعامله Google كرفض افتراضي — مرغوب أحيانًا، غير صريح دومًا). الإصلاح: اضبط العوامل الأربعة جميعًا صراحةً في نداءات الافتراضي والتحديث. إن لم تُطلق منصّة CMP لديك ad_user_data و ad_personalization، فهي تنفيذ ما قبل v2 بصرف النظر عمّا تدّعيه وثائقها.

الخطأ 3 — ربط فئة «التسويق» بـ ad_storage فقط. ربط الفئات بالعوامل مصدر متكرّر للموافقة الناقصة الصامتة. يقبل المستخدم «التسويق» على شريطك، لكن إن حدّثت منصّة CMP عاملك ad_storage فقط وتجاهلت ad_user_data و ad_personalization، فأنت تقنيًّا لم تمنح موافقة إعلانيّة كاملة — تنميط Google Ads للتحويلات لن يعمل، Meta CAPI يستلم إشارة جزئيّة، وجمهور إعادة التسويق لن يتعبّأ. اربط «التسويق» بالعوامل الإعلانيّة الثلاثة جميعًا (ad_storage + ad_user_data + ad_personalization) في وقت واحد.

الخطأ 4: إهمال سحب الموافقة. يمنح نظام حماية البيانات الشخصيّة الأفراد حقّ سحب موافقتهم، ويجب أن يكون السحب بسهولة المنح. كثير من منصّات الموافقة تتعامل مع المنح الأوّل، لكنّها لا تُطلق نداء gtag('consent', 'update', ...) حين ينقر المستخدم لاحقًا «رفض الكلّ» أو يغيّر تفضيلاته. والنتيجة: تستمرّ العلامات في العمل مع كلّ تحميل صفحة رغم تغيّر حالة الموافقة في التخزين المحلّي للمنصّة. والإصلاح: يجب أن يُرسل كلّ تغيير في الإعدادات نداء تحديث. اختبر ذلك بالقبول ثمّ الرفض فورًا من لوحة التفضيلات؛ يجب أن تتوقّف طلبات الشبكة إلى google-analytics خلال تنقّل صفحة واحد.

الخطأ 5 — الاعتماد على CMP لا يُطلق تحديثات gtag إطلاقًا. بعض أدوات «شريط الكوكيز» القديمة تُدير الكوكيز عبر كتابات document.cookie، لكنّها لا تتكامل أبدًا مع gtag API الخاصّة بـ Consent Mode v2. بالنسبة لوسوم Google يبدو هذا وكأنّ إدارة الموافقة غير موجودة؛ تبقى الحالة الافتراضيّة على آخر ضبط (غالبًا لا شيء)، وفي ذلك لا يعمل التنميط أو يعمل على خطّ أساس خاطئ. الإصلاح: اختر منصّة موافقة تُطلق نداءات gtag أصلًا لا تكتفي بكتابة الكوكيز. والفحص الذي يهمّ ملحوظ بالعين: افتح Tag Assistant وتأكّد أنّ رفضًا افتراضيًّا ينطلق قبل أيّ وسم من Google، ثمّ تحديثًا عند اختيار الزائر. وهكذا يُطلق أرقام٣٦٠ العوامل الأربعة.

تفعيل Consent Mode v2 عبر أرقام٣٦٠

يتولّى أرقام٣٦٠ تنفيذ Consent Mode v2 تلقائيًّا بالكامل. لا كود تكتبه، ولا متغيّرات GTM تضبطها، ولا تسلسل علامات تديره. أضف سكربت أرقام٣٦٠ إلى موقعك وفعِّل خيار Consent Mode في لوحة التحكّم — يُتولّى ما يلي عنك:

• ضبط القيم الافتراضيّة المرفوضة مبكرًا في الصفحة، قبل علامات Google الخاصّة بك ومشغّلات تحميل الصفحة
• تحديث الإشارات الأربع فور تفاعل الزائر مع الشريط
• قراءة الموافقة المحفوظة تلقائيًّا للزوّار العائدين
• دعم الوضع الأساسي «basic» (حجب العلامات حتّى الموافقة) والوضع المتقدّم «advanced» (إرسال إشارات بلا ملفات تعريف ارتباط)
• متوافق مع GTM و gtag.js المباشر و GA4 وتتبّع تحويلات Google Ads
• يعمل إلى جانب Google Tag Manager من جهة الخادم عبر تكامل أرقام٣٦٠ مع sGTM

أسئلة متكرّرة

مصادر موثوقة

الخطوات التالية

إن كنت تُعدّ Consent Mode v2 من الصفر، فأسرع مسار تثبيت منصّة موافقة تأتي بإعدادات الرفض الافتراضي جاهزة، ثمّ إجراء فحوص التحقّق أعلاه للتأكّد. وانتبه إلى أنّ قائمة Google للمنصّات المعتمدة شرط منفصل، يخصّ عرض الإعلانات في المنطقة الاقتصاديّة الأوروبيّة وبريطانيا وسويسرا فقط، وليست مقياسًا لصحّة تنفيذ Consent Mode v2. وإن كنت تملك منصّة وتشكّ في أنّها لا تعمل، فابدأ بفحوص التحقّق: فمعظم الإخفاقات تقع في الأخطاء 1 و2 و3 أعلاه، ويمكن إصلاحها دون تغيير المزوّد.