المواصفات الفنية لـ "الموافقة الإضافية" من Google

على الناشرين العمل مباشرةً مع منصّات إدارة الموافقة إذا أرادوا العمل مع مزوّدي تقنية الإعلان (ATP) الذين لا ينطبق عليهم إطار الشفافية والموافقة.

يحدّد هذا المستند المواصفات الفنية (التي يُطلق عليها اسم "الموافقة الإضافية") المخصّصة فقط للاستخدام مع الإصدار 2 من إطار الشفافية والموافقة (TCF) الصادر عن مكتب IAB في أوروبا من أجل إرسال إشارات الشفافية و/أو الموافقة إلى المورّدين الذين لم يُسجّلوا إلى الآن في قائمة المورّدين العالميين (GVL) التابعة لمكتب IAB في أوروبا. وتتيح هذه المواصفات للناشرِين ومنصّات إدارة الموافقة (CMP) والشركاء إمكانية جمع الموافقات الإضافية ونشرها، إلى جانب تنفيذ إطار الشفافية والموافقة، وذلك بالنسبة إلى الشركات التي لم تُسجَّل بعد في قائمة المورّدين العالميين الصادرة عن مكتب IAB في أوروبا ولكنّها مدرَجة في قائمة مزوّدي تقنية الإعلان (ATP) الصادرة عن Google.

التغييرات المتعلّقة بالإصدار 2 من "الموافقة الإضافية"

منذ ديسمبر 2023، أصبحت Google توفّر الإصدار 2 من مواصفات "الموافقة الإضافية". وفي ما يلي التغييرات الأساسية:

• تعديل على سلسلة "الموافقة الإضافية" لمساعدة المورّدين المُفصح عنهم في منصّة إدارة الموافقة
• تعديل على واجهة برمجة التطبيقات CMP API لإتاحة التشغيل التفاعلي لمنصّات إدارة الموافقة التي تتيح كلّاً من إطار الشفافية والموافقة ووضع موافقة المعلِن

ستبقى سلاسل "الموافقة الإضافية" التي أُنشئت استنادًا إلى مواصفات الإصدار 1 متاحة.

مكوّنات "الموافقة الإضافية"

نُتيح كلاً مما يلي ضمن "الموافقة الإضافية":

• سلسلة الشفافية والموافقة (TC) على النحو المحدّد في مواصفات الإصدار 2.2 من إطار الشفافية والموافقة الصادر عن مكتب IAB، والذي يتضمّن الشفافية والموافقة الممنوحة للمورّدين في قائمة المورّدين العالميين الصادرة عن مكتب IAB
• سلسلة addtl_consent خفيفة (سلسلة "موافقة إضافية") تحتوي على قائمة بمزوّدي تقنية الإعلان من Google المعتمدين و/أو المُفصَح عنهم الذين لم يُسجلوا بعد لدى مكتب الإعلانات التفاعلية

تحدد هذه المواصفات ما يلي:

1. تنسيق سلسلة "الموافقة الإضافية"

2. الإضافة إلى واجهة برمجة التطبيقات TCF v2.2 CMP API لإتاحة سلسلة "الموافقة الإضافية" وعناصر التحكّم عند توفُّر كلٍّ من وضع موافقة المعلِن وإطار الشفافية والموافقة

3. كيفية تخزين سلسلة "الموافقة الإضافية"

4. كيفية تمرير سلسلة الموافقة الإضافية من خلال سلسلة الإعلانات الرقمية

تنسيق سلسلة "الموافقة الإضافية"

ما هي المعلومات المخزّنة في سلسلة "موافقة إضافية"؟

تحتوي سلسلة "موافقة إضافية" على المكوّنات التالية:

• الجزء 1: رقم لإصدار المواصفات، مثل 2

• الجزء 2: رمز الفاصل "~"

• الجزء 3: قائمة بمعرِّفات مزوّدي تقنية "إعلانات Google" التي وافق عليها المستخدم والمفصولة بالنقاط. مثال: "1.35.41.101"

• الجزء 4: رمز الفاصل "~"

• الجزء 5: "dv." تليها قائمة بأرقام تعريف مزوّدي تقنية "إعلانات Google" المُفصَح عنهم والمفصولة بالنقاط مثال: "dv.9.21.81"

  لا يجب إدراج المورّدين ضمن الجزء 5 إذا كانوا مدرَجين في الجزء 3، وذلك لتقليل طول السلسلة.

مثال على سلسلة "الموافقة الإضافية"

تعني سلسلة "الموافقة الإضافية" ‎2~1.35.41.101~dv.9.21.81 أنّ المستخدم قد وافق على مزوّدي تقنية الإعلان الذين يحملون أرقام التعريف 1 و35 و41 و101، وأنّه تم الإفصاح للمستخدم عن مزوّدي تقنية الإعلان الذين يحملون أرقام التعريف 9 و21 و81، ويتم إنشاء السلسلة باستخدام التنسيق المحدّد في مواصفات الإصدار 2.

مَن الذي عليه إنشاء سلسلة "الموافقة الإضافية"؟

لا يمكن إنشاء سلسلة "الموافقة الإضافية" إلّا من خلال منصّة إدارة موافقة مسجّلة ضمن إطار الشفافية والموافقة الصادر عن مكتب IAB في أوروبا، وذلك باستخدام رقم تعريف منصّة إدارة الموافقة المخصّص لهذه السلسلة وفقًا لسياسات مكتب IAB. على المورّدين أو أي مقدّمي خدمات آخرين تابعين لجهة خارجية عدم إنشاء سلاسل "موافقة إضافية" بأنفسهم.

أين سيتم نشر بيانات مزوّدي تقنية الإعلان من Google؟

ستنشر Google قائمة مزوّدي تقنية الإعلان غير المسجَّلين لدى مكتب الإعلانات التفاعلية (IAB) وأرقام تعريفهم في الموقع التالي:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

متى يجب إنشاء سلسلة "الموافقة الإضافية"؟

في جميع الحالات، لا يجوز إنشاء سلسلة "الموافقة الإضافية" إلّا إذا كان الناشر يمتثل إلى سياسة موافقة المستخدِم في الاتّحاد الأوروبي المتّبعة في Google.

يجب عدم تضمين المورّدين المعتمدين إلّا عندما يمنح المستخدِم موافقة صالحة قانونيًا على:

1. استخدام ملفّات تعريف الارتباط أو غيرها من مساحات التخزين المحلّية عندما يكون ذلك مطلوبًا بموجب القانون

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

المورّدون المُفصَح عنهم الذين ليس لديهم موافقة من أجل

1. استخدام ملفّات تعريف الارتباط أو غيرها من مساحات التخزين المحلّية عندما يكون ذلك مطلوبًا بموجب القانون

2. جمع البيانات الشخصية ومشاركتها واستخدامها لتخصيص الإعلانات، ولا يجب إدراجهم إلّا عند توفير الشفافية الملائمة للمستخدِمين في ما يتعلّق بهوية كلّ مزوّد تقنية إعلان، بما في ذلك الربط بسياسة خصوصية مزوّد تقنية الإعلان على النحو الوارد في قائمة مزوّدي تقنية الإعلان الصادرة عن Google.

يجب إنشاء سلسلة "الموافقة الإضافية" فقط كسلسلة تكميلية لسلسلة الموافقة والشفافية، وليس بدلاً منها. لن تعالج Google الطلب، وستتجاهل سلسلة "الموافقة الإضافية" في طلب تمّ استلامه من خلال Google، وذلك إذا لم تتوفّر سلسلة الموافقة والشفافية للطلب نفسه.

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

مراجع ذات صلة

• سلسلة الموافقة والشفافية مع الإصدار 2.2 من قائمة المورّدين العالميين

• الإصدار 2.2 من Consent Management Platform API

• سياسات "إطار الشفافية والموافقة" الصادر عن مكتب الإعلانات التفاعلية في أوروبا

• سياسة موافقة المستخدم في الاتحاد الأوروبي المتّبعة في Google

إضافة إلى واجهة برمجة تطبيقات CMP API

نقترح توسيع واجهة برمجة تطبيقات TCF v2.2 CMP JavaScript API للسماح بعرض سلسلة "الموافقة الإضافية". ونقترح على وجه التحديد توسيع عنصرَي JSON وهما TCData وInAppTCData لعرض هذه البيانات.

TCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

 

InAppTCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

كيف يجب تخزين سلسلة "الموافقة الإضافية"؟

الويب

تعتمد آلية التخزين على خيار منصّة إدارة الموافقة.

داخل التطبيق

سيتمّ استخدام NSUserDefaults‏ (iOS) أو SharedPreferences (لنظام التشغيل Android) لتخزين سلسلة "الموافقة الإضافية" من خلال حزمة تطوير البرامج في منصّة إدارة الموافقة (CMP). تسمح هذه الخدمة بما يلي:

• وصول المورّدين إلى سلسلة "الموافقة الإضافية" بسهولة

• استمرار سلسلة "الموافقة الإضافية" في جميع جلسات التطبيق

• قابلية نقل سلسلة "الموافقة الإضافية" بين منصّات إدارة الموافقة لتوفير المرونة للناشرين من أجل استبدال حزمة تطوير البرامج لمنصّة إدارة موافقة بحزمة أخرى

إذا اختار الناشر إزالة حزمة تطوير البرامج CPM SDK من تطبيقه، يكون مسؤولاً عن محو قيم AddtlConsent للمستخدمين، حتى لا يستمر المورّدون في استخدام سلسلة "الموافقة الإضافية" المضمّنة.

مفتاح البحث والتخزين في NSUserDefaults وSharedPreferences	القيمة
IABTCF_AddtlConsent	سلسلة: سلسلة "الموافقة الإضافية" مع إصدار المواصفات وأرقام تعريف مزوّدي تقنية الإعلان المعتمدين

كيفية تمرير سلسلة "الموافقة الإضافية" من خلال سلسلة الإعلانات الرقمية

طلب عرض السعر

سنُعيد استخدام ConsentedProvidersSettings لنشر المراحل المتقدمة للموردين الذين لا يتبعون قائمة المورّدين العالميين.

• نموذج إضافات في OpenRTB
• إصدار Protobuf القديم

message ConsentedProvidersSettings {
 // Set of IDs corresponding to providers for whom the publisher has told
 // Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local  
 // storage where legally required; and 2) the collection, sharing, and use of personal data for 
 // personalization of ads by an ATP in accordance with Google’s EU User Consent Policy.
 // A mapping of provider ID to provider name is posted at providers.csv.
 repeated int64 consented_providers = 2 [packed = true];
}

 // Information about the providers for whom the publisher has told Google
 // that its EEA users have consented to the use of their personal data for
 // ads personalization in accordance with Google's EU User Consent Policy.
 // This field will only be populated when regs_gdpr is true.
 optional ConsentedProvidersSettings consented_providers_settings = 42;

الخدمات المستندة إلى عناوين URL

عند عرض تصميم إعلان، يمكن أن يحتوي على عدد من وحدات البكسل ضمن علامات <img>. على سبيل المثال، <img src="http://vendor-a.com/key1=val1&key2=val2">، الذي يرسل طلب HTTP GET من المتصفح إلى نطاق المورِّد.

بما أن وحدة البكسل هي علامة <img> بدون إمكانية تنفيذ JavaScript، لا يمكن استخدام واجهة برمجة التطبيقات CMP API للحصول على سلسلة الموافقة والشفافية. على غرار إتاحة سلسلة الشفافية والموافقة، نوفّر معلَمة عنوان URL عادية ووحدة ماكرو في عناوين URL لوحدات البكسل التي يجب إدراج سلسلة "الموافقة الإضافية" فيها.

مَعلمة عنوان URL	ماكرو مطابق	التمثيل الفعلي في عنوان URL
addtl_consent	ADDTL_CONSENT	&addtl_consent=${ADDTL_CONSENT}

مثال 1

لكي يتلقى المورّد سلسلة "موافقة إضافية"، يجب أن يتضمّن عنوان URL الخاص بالصورة زوجًا من المفاتيح والقيم مع معلَمة عنوان URL ووحدة الماكرو &addtl_consent=${ADDTL_CONSENT}. عنوان URL الناتج هو:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

 

مثال 2

في طلب معيّن، إذا كانت سلسلة "الموافقة الإضافية" هي: ‎1~1.35.41.101

يستبدل المتصل أو عارض تصميم الإعلان وحدة الماكرو في عنوان URL بسلسلة "الموافقة الإضافية" الفعلية لكي يتم تعديل وحدة البكسل الموضوعة في الأصل والتي تحتوي على وحدة الماكرو على النحو التالي عند إجراء الاستدعاء للخادم المحدد:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101