الإصدار المختصر

يُعد TCF v2.3 تطورًا لإصدار v2.2 وليس إعادة تصميم من الصفر. صيغة TC String متوافقة، والأغراض والميزات الحالية محفوظة، ومعظم متطلبات واجهة المستخدم الموجهة للناشر تنتقل كما هي دون تغيير يُذكر. تتركز التغييرات الجوهرية في أربعة مجالات:

• قواعد أوضح حول كيفية وجوب عرض CMPs لمعلومات البائعين وفترات الاحتفاظ.
• متطلبات جديدة لـضوابط الطبقة الثانية التفصيلية التي يطالب بها المنظمون منذ قرار هيئة حماية البيانات البلجيكية (DPA) في عام 2022.
• تشديد إنفاذ السياسات حول أنماط التصميم المضلِّلة (dark patterns)، وتكافؤ البروز، والخيارات ال��حددة مسبقًا.
• تعديلات على مخطط Global Vendor List (GVL) وتدفّق الإفصاح عن البائعين.

لماذا وُجد الإصدار v2.3

كل إصدار من TCF هو عملية توازن بين ثلاثة أطراف: الناشرون الذين يحتاجون إلى الاستمرار في تحقيق الدخل، والبائعون الذين يحتاجون إلى واجهة تقنية مستقرة، والهيئات التنظيمية التي تستمر في اكتشاف ثغرات امتثال محددة. الإصدار v2.3 هو استجابة مباشرة لثلاثة ضغوط:

1. إجراءات الإنفاذ ضد الإفراط في استخدام "المصلحة المشروعة" في إطار v2.2. إذ رأت عدة DPAs أوروبية أن عددًا كبيرًا من البائعين كانوا يعلنون الاعتماد على LI لأغراض لا يكون فيها إلا الحصول على الموافقة هو الأساس القانوني المشروع. يُحكم v2.3 الإفصاحات التي يقدّمها البائعون عن الأساس القانوني ويُظهرها في وقت أبكر ضمن واجهة الموافقة.
2. الشكاوى المستمرة بشأن أنماط التصميم المضلِّلة (dark patterns). تجعل السياسات المحدّثة قاعدة تكافؤ البروز أكثر وضوحًا وتغلق الثغرات المتعلقة بالمفاتيح أو الأزرار المفعّلة مسبقًا في الطبقة الثانية.
3. التغذية الراجعة التشغيلية من CMPs والناشرين الكبار. فقد أدخل الإصدار v2.2 عدة إفصاحات إلزامية كان من الصعب تنفيذها بسلاسة على الهاتف المحمول و CTV. يعمل v2.3 على تبسيط مجموعة الإفصاحات الإلزامية ويسمح بنقل المزيد منها إلى عرض طبقي (layered view).

توافق TC String

يبقى TC String نفسه متوافقًا مع الإصدارات السابقة. يُنتج CMP يعمل وفق v2.3 سلاسل يمكن للبائعين العاملين على v2.2 قراءتها، ويمكن لبائع يعمل وفق v2.3 استهلاك سلاسل v2.2 خلال فترة الانتقال. يحدد مؤشر الإصدار في المقطع الأساسي للسلسلة أي إصدار من السياسات يزعم الـ CMP الامتثال له، بينما يتحرك مؤشر إصدار GVL للأمام بشكل مس��قل.

ما يعنيه ذلك عمليًا: لست مضطرًا إلى ترقية جميع البائعين في الوقت نفسه، ولا إلى فرض حدث موافقة جديد على كل مستخدم في اليوم الذي تنشر فيه v2.3. فنهج الإطلاق المرحلي مدعوم صراحةً.

أهم التغييرات التقنية

1. الإفصاح عن البائعين وفترات الاحتفاظ

يُلزم v2.3 CMPs بعرض فترة الاحتفاظ بالبيانات المعلن عنها من كل بائع في واجهة المستخدم الطبقية، لا في قائمة بائعين منفصلة فقط. كانت قيمة الاحتفاظ جزءًا من GVL دائمًا، لكن v2.2 لم يفرض أن يراها المستخدمون بجانب الأغراض. يغلق v2.3 هذه الفجوة لأن الهيئات التنظيمية قالت إن المستخدمين لا يستطيعون اتخاذ قرار مستنير دون معرفة مدة احتفاظ الأطراف ببياناتهم.

2. ضوابط أكثر صرامة في الطبقة الثانية

في الطبقة الثانية — عرض "إدارة التفضيلات" — يؤكد v2.3 بوضوح أن المفاتيح (toggles) الخاصة بالأغرا�� والبائعين غير الضروريين يجب أن تكون في وضع الإيقاف افتراضيًا. تُعد المربعات المحددة مسبقًا أو أشرطة التمرير المفعّلة مسبقًا مخالفة للسياسة حتى لو لم ينقر المستخدم صراحةً على "قبول". CMPs التي كانت تعتمد سابقًا على نمط "الاشتراك الضمني" (soft opt-in) ستحتاج إلى إعادة عرض الطبقة الثانية.

3. إنفاذ قاعدة تكافؤ البروز

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

4. الإشارة إلى المصلحة المشروعة

يجب على البائعين الذين يعلنون الاعتم��د على المصلحة المشروعة كأساس قانوني في v2.3 أن يعلنوا أيضًا عن الأغراض التي أجروا لها تقييم مصلحة مشروعة (Legitimate Interests Assessment) ولأي منها أكملوا هذا التقييم. تُلزم CMPs بتمرير هذا الإعلان إلى واجهة المستخدم حتى يتمكّن المستخدمون من الاعتراض استنادًا إلى معلومات كاملة. عمليًا، يعني هذا أن تدفّق "الاعتراض" سيعرض الآن حالة LIA الخاصة بالبائع بدلًا من مفتاح عام.

5. تحديثات مخطط GVL

يضيف مخطط Global Vendor List حقولًا لدقة الاحتفاظ، وحالة LIA، ورابطًا قابلًا للقراءة آليًا إلى قسم سياسة الخصوصية لكل بائع والمتعلق بالأغراض المعلَن عنها. يجب على CMPs التي تخزّن GVL مؤقتًا تحديث محلّل مخططها لفهم الحقول الجديدة قبل الإشارة إلى GVL خاصة بـ v2.3.

تغييرات السياسات التي تؤثر في تجربة المستخدم (UX)

يمثل TCF كلاً من مواصفة تقنية ومجموعة من السياسات. يصل عدد من تغييرات سياسات v2.3 مباشرة إلى واجهة الموافقة:

• لا مزيد من استخدام "المتابعة دون قبول" كمعادل للرفض ما لم يكن مطابقًا بصريًا لزر القبول وينتج TC String نفسه الذي سينتج عن رفض كامل.
• تكافؤ اللغة — يجب أن تكون إشعارات الموافقة متاحة بكل لغة يتوفر بها الموقع نفسه، لا بلغة متصفح المستخدم فحسب. يجب على CMPs دعم تجاوز الإعداد المحلي (locale override).
• إمكانية الوصول الدائمة — يجب أن يكون المستخدمون قادرين على الوصول إلى مركز التفضيلات من كل صفحة في الموقع، لا من صفحة الهبوط فقط، ويجب تسمية رابط الوصول بطريقة يفهمها المستخدم غير المتخصص على أنها متعلقة بالموافقة.

ما الذي يجب على الناشرين فعله

1. تأكيد دعم مزوّد الـ CMP لديك لإصدار v2.3. اطلب معرفة التاريخ الدقيق الذي سيكون فيه إصدارهم المعتمد على v2.3 متاحًا وسلسلة الإصدار التي سيبلّغ عنها.
2. تحديث منطق التخزين المؤقت لـ GVL. إذا كنت تستضيف ��ي نسخة معكوسة (mirror) من GVL ذاتيًا، فحدّث محلّل المخطط قبل نشر GVL الخاصة بـ v2.3، وإلا سيفشل CMP لديك في التحقق من البائعين الجدد.
3. أعد كتابة واجهة الطبقة الثانية بحيث تكون جميع المفاتيح في وضع الإيقاف افتراضيًا، ويتم فرض تكافؤ البروز بصريًا، وتُعرض فترات الاحتفاظ بجانب الأغراض.
4. أعد تشغيل تدقيق الامتثال. أسهل مكاسب الجهات التنظيمية هي مخالفات أنماط التصميم المضلِّلة التي يشير إليها v2.3 الآن صراحةً. عالجها قبل مراجعة الإنفاذ التالية.
5. خطّط لاستراتيجية إعادة طلب الموافقة (re-prompt). رغم أن TC String متوافق مع الإصدارات السابقة، تشجّع السياسات الناشرين على إعادة طلب الموافقة عندما تتغير نطاقات المعالجة أو الإفصاحات عنها بشكل جوهري. حدّد ما إذا كان نشر v2.3 لديك يرقى إلى تغيير "جوهري" لجمهورك.

ما الذي يجب ع��ى البائعين فعله

1. إكمال Legitimate Interests Assessment لكل غرض تعلن فيه الاعتماد على LI، وتقديم نتيجة التقييم إلى GVL.
2. تحديث مدخلتك في GVL لتضمين حقول مخطط v2.3: دقة الاحتفاظ، إعلان LIA، ورابطًا عميقًا إلى سياسة الخصوصية.
3. التحقق من صحة محلّل TC String لديك بمقارنته مع سلاسل مرجعية لـ v2.3 توفرها IAB Europe.
4. التنسيق مع شركائك من CMP على تاريخ انتقال مشترك، حتى لا تكون أول طلبات الشراء التي تحمل سلسلة v2.3 متجهة إلى بائع يدعم v2.2 فقط.

أخطاء شائعة في الترحيل

• التعامل مع v2.3 كفرصة لإعادة تصميم واجهة المستخدم. من المغري دمج تحديثات الهوية البصرية مع نشر v2.3، لكن ذلك يعقّد اختبارات الامتثال. أطلق أولاً إصدارًا يركّز فقط على الامتثال لـ v2.3، ثم طوّر التصميم لاحقًا.
• تجاهل متطلب عرض فترات الا��تفاظ. غالبًا ما تقوم الفرق بتحديث عرض قائمة البائعين لكنها تنسى أن فترات الاحتفاظ يجب أن تظهر الآن أيضًا في العرض الطبقي غرضًا بغرض.
• الافتراض بأن TC String وحده كافٍ. فالسلسلة المتوافقة الناتجة عن واجهة مستخدم غير متوافقة تظل غير متوافقة. لقد غرّمت الجهات التنظيمية مرارًا مشغّلين بدت سلاسلهم جيدة بينما كانت لافتاتهم تخفي زر الرفض.
• استبعاد CTV والهاتف المحمول من النطاق. ينطبق v2.3 على كل واجهة يُنتج فيها TCF signals. الناشرون الذين ينشرون تحديث الويب ويتجاهلون تطبيقات CTV أو تطبيقات الهاتف المحمول يخلقون بيئة هجينة غير متوافقة.

الخلاصة

لا يُعد TCF v2.3 قطيعة مزعزِعة مع v2.2، لكنه يشكّل تشديدًا ملموسًا للقواعد التي تُمسك منظومة الإعلانات البرمجية الأوروبية معًا. اتجاه التطور واضح: مزيد من الشفافية، وعدد أقل من أنماط التصميم المضلِّلة، وتحكم أكثر تفصيلاً للمستخدم، وتساهل أقل مع الحالات الحدّية التي كانت تمر سابقًا. CMPs والناشرون الذين يتعاملون مع v2.3 كرقعة سريعة سيجدون أنفسهم سريعًا أمام الجهة التنظيمية مجددًا. أما من يستغلون الترحيل لتنظيف تجربة الطبقة الثانية، والتخلي عن التحايلات على المصلحة المشروعة، وبناء تدفّق موافقة حقيقي يقوم على تكافؤ البروز، فسيخرجون من مرحلة الانتقال بمخزون يُباع فعلًا في عصر v2.3 — وبوضعية موافقة قادرة على الصمود أمام أي شيء قد يأتي به الإصدار v2.4 لاحقًا.