Chrome Privacy Sandbox وواجهة Topics API: دليل الناشر لعام 2026 حول الموافقة والاستهداف والقياس
على مدى معظم العقد الماضي، اعتمد الإعلان الرقمي على افتراض بسيط: ستكون ملفات تعريف الارتباط التابعة لجهات خارجية موجودة دائمًا، تحمل بصمت معرّفات المستخدمين عبر الويب. هذا الافتراض انهار الآن. تغيّر مسار إيقاف Chrome عدة مرات، لكن اتجاه التحوّل لم يتغير: تنتهي إمكانية التتبع عبر المواقع بواسطة ملفات تعريف الارتباط التابعة لجهات خارجية، وPrivacy Sandbox من Google هو البديل الذي تريد Chrome أن يعتمده الناشرون والمعلنون. Sandbox ليس منتجًا واحدًا، بل هو مجموعة من واجهات API للمتصفح — Topics وProtected Audience وAttribution Reporting وFenced Frames وShared Storage وغيرها — يحل كل منها محل حالة استخدام محددة كانت ملفات تعريف الارتباط تغطيها. بالنسبة للناشر، لا يكمن التحدي في فهم واجهات API بشكل فردي، بل في بناء طبقة موافقة ومسار تحقيق دخل يحافظ على توافق تدفقات Privacy Sandbox مع امتثال GDPR وقوانين الخصوصية الحكومية في آنٍ واحد. يستعرض هذا الدليل العناصر المتحركة في عام 2026 وما يجب أن تبدو عليه منظومة موافقتك.
ما الذي يحل محله Privacy Sandbox فعلًا
حملت ملفات تعريف الارتباط التابعة لجهات خارجية أربع وظائف إعلانية مميزة: الاستهداف القائم على الاهتمامات، وإعادة الاستهداف، وقياس التحويل، وتحديد تكرار الإعلانات. يقسّم Privacy Sandbox هذه الوظائف إلى واجهات API منفصلة، لكل منها ملف موافقة خاص بها.
Topics API — الاستهداف القائم على الاهتمامات
تُعيّن Topics API لكل متصفح مجموعة صغيرة من موضوعات الاهتمام ذات الطابع العام — حوالي خمسة موضوعات أسبوعيًا، مستمدة من تصنيف منسّق يضم بضع مئات من الفئات. عندما يستدعي الناشر document.browsingTopics()، يعيد المتصفح ما يصل إلى ثلاثة موضوعات يمكن لمنظومة تقنية الإعلانات استخدامها للتخصيص السياقي دون أي معرّف عبر المواقع. تُحسب الموضوعات محليًا وتُخزَّن على الجهاز وتتناوب أسبوعيًا وتخضع لضوابط المستخدم في chrome://settings/adPrivacy.
Protected Audience API — إعادة الاستهداف والتسويق المعاد
تُبقي Protected Audience، المعروفة سابقًا بـ FLEDGE، على إعادة الاستهداف دون معرّف مشترك عبر المواقع. ينضم المعلنون بالمستخدم إلى مجموعة اهتمام على موقعهم؛ وعندما يزور المستخدم ناشرًا مشاركًا، تُجرى مزادة على الجهاز داخل Fenced Frame لاختيار الإعلان المناسب. يُعرض الإعلان الفائز دون أن يعرف الناشر مجموعة الاهتمام التي تطابقت.
Attribution Reporting API — قياس التحويل
تحل Attribution Reporting محل بكسلات التحويل لمجموعة فرعية من حالات استخدام القياس. وتدعم تقارير مستوى الأحداث (المشوّشة والناقصة لكل تحويل) وتقارير الملخص التجميعية (ملخصات مُزالة التحيز إحصائيًا). على عكس بكسل الإرث، لا تكشف عن الارتباط الفردي بين المستخدم والتحويل.
Shared Storage وFenced Frames
Shared Storage هو مخزن قيم مفتاحية يمكن الكتابة إليه من أي مكان وقراءته داخل بيئة محمية، مخصص لحالات الاستخدام عبر المواقع مثل تحديد تكرار الإعلانات واتساق تجارب A/B. أما Fenced Frames فهي iframes معزولة تمنع الصفحة المحيطة من قراءة الإعلان المعروض أو بيانات تفاعله.
هل يتطلب Privacy Sandbox موافقة؟
هذا هو السؤال الأكثر سوء فهمًا في مشهد تقنية الإعلانات عام 2026، والإجابة تختلف باختلاف الولاية القضائية.
بموجب GDPR وePrivacy
لم تصدر هيئة حماية البيانات الأوروبية EDPB موقفًا شاملًا، لكن السلطات الوطنية كانت أكثر صراحة. اعتبرت كل من ICO البريطانية وهيئة Garante الإيطالية وCNIL الفرنسية أن Topics وProtected Audience تستلزمان موافقة مسبقة (opt-in) حيث تعالجان بيانات شخصية، بما في ذلك أي معالجة تكتب أو تقرأ الحالة على جهاز المستخدم. المنطق: يظل المتصفح يخزن موضوعات الاهتمام ومجموعات الاهتمام محليًا، واستدعاء document.browsingTopics() ينقل بيانات شخصية مستنتجة إلى طرف ثالث. هذا منظّم بموجب المادة 5(3) من توجيهية ePrivacy، التي تستلزم الموافقة على أي وصول إلى معدات المستخدم أو تخزين عليها بما يتجاوز الضروري للخدمة المطلوبة.
موقف Google أكثر تساهلًا — يجادلون بأن واجهات API مُصممة بما يحفظ الخصوصية وأن متطلبات الموافقة قد لا تنطبق في جميع السياقات. هذا ليس موقف الجهات التنظيمية. التعامل مع Privacy Sandbox باعتباره معفيًا من الموافقة في أوروبا ينطوي على مخاطر عالية.
بموجب CCPA وCPRA وقوانين الولايات الأمريكية
في الولايات المتحدة، تُعامَل تدفقات Privacy Sandbox عمومًا على أنها مشاركة لمعلومات شخصية للإعلانات السلوكية السياقية المتقاطعة بموجب CPRA. وهذا يعني أنها تُشغّل حق الانسحاب ويجب مراعاتها من خلال إشارات Global Privacy Control وآليات الانسحاب الشامل الأخرى. لا يُعفيها حقيقة أن بيانات Topics مشتقة من المتصفح وليست مُباعة من وسيط خارجي.
ضوابط Chrome الخاصة
يوفر Chrome تبديلات للمستخدمين في chrome://settings/adPrivacy لـ Topics وProtected Audience وAttribution Reporting. تقف خيارات المستخدم هذه جنبًا إلى جنب — وليس بدلًا من — حالة موافقة CMP الخاص بك. المستخدم الذي رفض ملفات تعريف الارتباط الإعلانية في بانرك لكنه قبل Topics في إعدادات Chrome الشاملة لا يزال يقول لك لا من خلال البانر. يجب أن تراعي منظومتك الأشد من الإشارتين.
طبقة الموافقة التي تحتاجها فعلًا
تعامل منظومة موافقة 2026 الاحترافية واجهات Privacy Sandbox API باعتبارها أنشطة معالجة متمايزة، يتم بوابتها من خلال أغراض IAB TCF أو الفئات المكافئة لقوانين الولايات.
ربط Sandbox APIs بأغراض TCF
- Topics API — IAB TCF Purpose 2 (اختيار إعلانات أساسية) وPurpose 3 (إنشاء ملف إعلانات مخصص) كحد أدنى؛ Purpose 4 (اختيار إعلانات مخصصة) إذا كانت الموضوعات تغذّي الاستهداف.
- Protected Audience — Purpose 3 و4، بالإضافة إلى Purpose 7 (قياس أداء الإعلان) إذا استخدم المزاد بيانات النتائج.
- Attribution Reporting — Purpose 7 (قياس أداء الإعلان) وPurpose 9 (فهم الجماهير من خلال الإحصاءات).
- Shared Storage لتحديد التكرار — Purpose 3 حيث يغذّي التخصيص، أو على أساس المصلحة المشروعة حيث يقتصر على ضبط التكرار.
الربط بـ Google Consent Mode v2
تُعيّن إشارات Google Consent Mode v2 على سلوك Privacy Sandbox:
- ad_storage مرفوض — تعطيل استدعاءات Topics وProtected Audience API بالكامل
- ad_user_data مرفوض — منع Attribution Reporting من إرسال بيانات نطاق المستخدم
- ad_personalization مرفوض — تخطي مدخلات Topics في منطق الاستهداف
التعامل مع إشارات الولايات الأمريكية
بالنسبة لحركة المرور الأمريكية، يجب على طبقة الموافقة فحص Global Privacy Control وإشارات الانسحاب المعمول بها للولايات. عندما انسحب مستخدم أمريكي من المشاركة، أوقف document.browsingTopics()، ولا تستدعِ joinAdInterestGroup، واحذف رؤوس تسجيل Attribution Reporting.
أنماط التنفيذ العملية
يتبع الناشرون الذين طرحوا بالفعل Privacy Sandbox بشكل عام أحد نمطين معماريين.
النمط الأول: التنسيق من جانب الخادم
يجمع مدير وسوم من المصدر الأول على أصلك حالة الموافقة والولاية القضائية للمستخدم وأي تجاوزات للإشارات، ثم يُدرج مشروطًا خطاطيف Privacy Sandbox في الصفحة. يتلقى خادم الإعلانات وSSP علامات الموافقة عبر طلب العطاء، ويقرران ما إذا كانا سيستدعيان Topics أو Protected Audience أو لا شيء. يُمركز هذا النمط المنطق ويجعل حالة الموافقة محورية.
النمط الثاني: دمج غلاف تقديم العطاءات في الرأس
تدعم Prebid.js وأغلفة تقديم العطاءات الأخرى الآن وحدات Privacy Sandbox. يقرأ الغلاف إشارة الموافقة، ويُعدّل سلوك استدعاء Topics، ويوجّه نتيجة المزاد عبر Protected Audience عند السماح. هذا النهج أخف في النشر لكنه يدفع المزيد من المنطق إلى جانب العميل ويشدّ تبعيتك على إيقاع إصدارات الغلاف.
ما يجب مراجعته
- تأكد من أن
document.browsingTopics()لا يُستدعى إلا إذا كانت موافقة الإعلانات من CMP مؤكدة ولا توجد إشارة انسحاب - تأكد من أن
joinAdInterestGroupوrunAdAuctionخاضعان لنفس الشروط - تأكد من أن رؤوس تسجيل Attribution Reporting تُرسَل فقط في ردود المستخدمين الذين تسمح حالة موافقتهم بالقياس
- تأكد من أن قائمة البائعين في سلسلة TCF لا تزال تتطابق مع SSPs وDSPs التي تستخدم Sandbox APIs على مخزونك
- تأكد من أن سياسة الخصوصية الخاصة بك تصف Topics وProtected Audience وAttribution Reporting باعتبارها أنشطة معالجة متمايزة مع الأساس القانوني فترة الاحتفاظ
ما لا يفعله Privacy Sandbox
عدة مفاهيم خاطئة شائعة بحاجة إلى الزوال قبل أن تبني ميزانيتك عليها.
ليس حلًا للتحايل على الموافقة
تقلل واجهات API من البيانات الشخصية المكشوفة للمعلنين، لكنها لا تجعل المعالجة الأساسية معفاة من الموافقة بموجب القانون الأوروبي. نظرية الامتثال القائلة بأن اعتماد Sandbox يتيح لك تخطي CMP غير صحيحة في كل ولاية قضائية داخل EU/EEA.
ليس بديلًا كاملًا لملفات تعريف الارتباط اليوم
تقدم Topics إشارة استهداف خشنة وناقصة أضعف عادةً من الجماهير القائمة على ملفات تعريف الارتباط. نطاقات إعادة استهداف Protected Audience لا تزال في طور النضج. يمتلك Attribution Reporting حدودًا للتشويش في القياس يمكن أن تخفي ارتفاعات التحويل الصغيرة. يجب على الناشر الذي ينقل كل تحقيق الدخل إلى Sandbox اليوم توقع انخفاض RPM بنسبة 10-30 بالمئة مقارنةً بمنظومة قائمة على ملفات تعريف الارتباط على المخزون النموذجي.
ليس دائمًا بشكله الحالي
مواصفة Privacy Sandbox لا تزال في تطور. يتوسع تصنيف Topics، وحدود مجموعات اهتمام Protected Audience قيد المراجعة، والاستجابة التنظيمية مستمرة. صمّم طبقة موافقتك لتكون قابلة للتهيئة وليست مشفرة بصلابة وفق المواصفة الحالية.
الموقف الصحيح لعام 2026
يُفهم Privacy Sandbox على أفضل وجه باعتباره طبقة واحدة ضمن استراتيجية أشمل بلا ملفات تعريف ارتباط، إلى جانب البيانات من المصدر الأول والجماهير المحددة من البائعين والاستهداف السياقي وتقديم العطاءات في الرأس من جانب الخادم. الناشرون الذين سيفوزون في 2026 هم من يعاملون الموافقة باعتبارها الحَكَم لا العائق — يُغذّون Sandbox APIs فقط حيث يسمح القانون وخيار المستخدم، ويعودون بنعومة إلى السياق في أي مكان آخر، ويقيسون النتائج عبر كلا المسارين بأدوات لا تفترض الهوية.
أسوأ موقف هو الانتظار. الجهات التنظيمية تكتب بالفعل الموجة التالية من القواعد — التزامات Sandbox الخاصة بسلطة المنافسة والأسواق البريطانية، وتوجيهات CNIL الجارية، وأحكام التنميط في قانون الذكاء الاصطناعي الأوروبي، كلها تمس هذا الأرض. الناشرون الذين يُدمجون Privacy Sandbox في منظومة موافقة محكمة الضوابط في 2026 سيكونون مستعدين لتلك القواعد. أما من يضيفونه كبديل طارئ لملفات تعريف الارتباط في اللحظة الأخيرة فسيجدون أنفسهم يُعيدون الكتابة تحت الضغط.