راهنمای مهاجرت از IAB TCF v2.2 به v2.3: چه چیزهایی عوض شد و CMPها چطور باید ارتقا بدهند
چارچوب شفافیت و رضایت IAB Europe (TCF) پرکاربردترین سیگنال رضایت در تبلیغات برنامهریزیشده اروپاست. نسخههای مختلف این چارچوب هرگز صرفاً بهروزرسانی ظاهری نیستند — هر نسخه بازتاب بازخورد ناظران، اقدامات اجرایی، و درسهایی است که از نحوه کار واقعی ناشران و فروشندگان گرفته شده است. حرکت از TCF v2.2 به v2.3 هم از این قاعده مستثنا نیست.
این راهنما بهصورت گامبهگام توضیح میدهد v2.3 دقیقاً چه چیزهایی را عوض میکند، چرا این تغییرات اعمال شدهاند، و چگونه میتوان یک CMP در محیط عملیاتی را طوری مهاجرت داد که نه موجودی مبتنی بر رضایت از دست برود و نه در طول دوره گذار، نقض Policies رخ دهد.
خلاصه ماجرا
TCF v2.3 یک تکامل نسبت به v2.2 است، نه بازطراحی کامل. فرمت TC String سازگار باقی مانده، مقاصد (purposes) و قابلیتهای موجود حفظ شدهاند، و بیشتر الزامات رابط کاربری سمت ناشر بدون تغییر منتقل میشوند. تغییرات معنادار در چهار حوزه متمرکز شدهاند:
- قوانین شفافتر درباره اینکه CMPها چطور باید اطلاعات فروشنده و دورههای نگهداری داده را نمایش دهند.
- الزامات جدید برای کنترلهای لایه دومِ جزئیتر (granular) که ناظران از زمان تصمیم DPA بلژیک در سال ۲۰۲۲ روی آن فشار میآوردند.
- سختگیرانهتر شدن اجرای سیاستها در زمینه الگوهای فریبنده (dark patterns)، برابری در برجستهسازی گزینهها، و ممنوعیت پیشفرضهای فعال (pre-ticked).
- تنظیمات در طرحواره (schema) Global Vendor List (GVL) و جریان افشای اطلاعات فروشنده.
چرا v2.3 به وجود آمد
هر نسخه TCF نتیجه نوعی چانهزنی میان سه گروه است: ناشرانی که باید درآمدزایی را حفظ کنند، فروشندگانی که به یک اینترفیس فنی پایدار نیاز دارند، و ناظمانی که مدام شکافهای مشخص در انطباق را پیدا میکنند. v2.3 پاسخ مستقیم به سه فشار است:
- اقدامات اجرایی علیه استفاده بیشازحد از «منافع مشروع» (legitimate interest) در v2.2. چندین DPA اروپایی تشخیص دادند که تعداد زیادی از فروشندگان برای مقاصدی ادعای LI میکنند که در آنها در عمل فقط رضایت میتواند مبنای قانونی باشد. v2.3 افشای مبنای حقوقی اعلامشده توسط فروشنده را سختگیرانهتر میکند و آن را زودتر در رابط کاربری رضایت به کاربر نشان میدهد.
- شکایتهای مستمر درباره ا��گوهای فریبنده (dark patterns). Policies بهروزشده، قاعده «برابری در برجستهسازی» را صریحتر کرده و منافذ مربوط به گزینههای از پیش فعالشده در لایه دوم را میبندند.
- بازخورد عملیاتی از CMPها و ناشران بزرگ. v2.2 چند افشای اجباری معرفی کرد که پیادهسازی تمیز آنها روی موبایل و CTV دشوار بود. v2.3 مجموعه افشاهای اجباری را کمی سادهتر کرده و اجازه میدهد بخش بزرگتری از آنها در یک نمای لایهای (layered) ارائه شود.
سازگاری TC String
خود TC String همچنان بهصورت عقبسازگار باقی مانده است. یک CMP مبتنی بر v2.3 رشتههایی تولید میکند که فروشندگان v2.2 میتوانند بخوانند، و یک فروشنده v2.3 نیز میتواند در دوره گذار، رشتههای v2.2 را مصرف کند. نشانگر نسخه در بخش اصلی رشته مشخص میکند CMP ادعای انطباق با کدام نسخه سیاستی را دارد، و اشاره به نسخه GVL بهصورت مستقل بهروزرسانی میشود.
نتیجه عملی این است: لازم نیست همه فروشندگان را همزمان ارتقا دهید، و لازم نیست در روز استقرار v2.3 همه کاربران را مجبور به ایجاد یک رویداد رضایت جدید کنید. TCF بهطور صریح از استقرار مرحلهای پشتیبانی میکند.
تغییرات فنی کلیدی
۱. افشای فروشنده و دوره نگهداری
در v2.3، CMPها موظفاند دوره نگهداری داده اعلامشده هر فروشنده را در رابط کاربری لایهای نمایش دهند، نه فقط در یک فهرست فروشندگان جداگانه. مقدار نگهداری همیشه در GVL وجود داشته، اما v2.2 الزام نکرده بود که کاربر آن را کنار مقاصد ببیند. v2.3 این شکاف را میبندد چون ناظران استدلال کردند کاربر بدون دانستن مدت ماندگاری داده، نمیتواند تصمیم آگاهانهای بگیرد.
۲. سختگیری بیشتر روی کنترلهای لایه دوم
در لایه دوم — نمای «مدیریت ترجیحات» — v2.3 بهصراحت میگوید که وضعیت پیشفرض برای سوئیچهای مربوط به مقاصد و فروشندگان غیرضروری باید خاموش باشد. جعبههای تیکخورده از قبل یا اسلایدرهای از پیش فعالشده، حتی اگر کاربر روی «accept» کلیک نکند، نقض Policy محسوب میشوند. CMPهایی که قبلاً بر الگوی «soft opt-in» تکیه داشتند، باید رندر لایه دوم را بازطراحی کنند.
۳. اجرای قاعده برابری در برجستهسازی
قاعده برابری در برجستهسازی از v2.1 وجود داشته، اما v2.3 آن را با امکان تفسیر کمتر تعریف میکند: کنترل «رد همه» باید در همان لایه، با همان وزن بصری، همان کلاس کنتراست رنگ، و همان فاصله تعاملی با «accept all» ارائه شود. مخفی کردن گزینه رد پشت یک لینک، دکمه کوچکتر یا صفحه ثانویه، اکنون بهطور صریح یک عدم انطباق است و نه موضوع قضاوت سلیقهای.
۴. سیگنالدهی درباره منافع مشروع
فروشندگانی که در v2.3 منافع مشروع را بهعنوان مبنای قانونی اعلام میکنند، اکنون باید مشخص کنند برای کدام مقاصد ارزیابی انجام دادهاند و برای کدامیک Legitimate Interests Assessment را کامل کردهاند. CMPها موظفاند این اعلام را به رابط کاربری منتقل کنند تا کاربر بتواند با اطلاعات کامل، مخالفت کند. در عمل، این یعنی جریان «objection» اکنون وضعیت LIA هر فروشنده را بهصورت جداگانه نشان میدهد، نه صرفاً یک سوئیچ کلی.
۵. بهروزرسانیهای طرحواره GVL
طرحواره Global Vendor List فیلدهایی برای سطح جزئیات دوره نگهداری، وضعیت LIA و یک لینک ماشینی (machine-readable) به بخش مربوطه از سیاست حریم خصوصی هر فروشنده برای مقاصد اعلامشده اضافه میکند. CMPهایی که GVL را کش میکنند، باید پیش از اشاره به GVL مبتنی بر v2.3، مفسر طرحواره خود را برای درک این فیلدهای جدید بهروزرسانی کنند.
تغییرات سیاستیِ مؤثر بر UX
TCF هم یک مشخصات فنی است و هم مجموعهای از Policies. چند مورد از تغییرات سیاستی v2.3 مستقیماً روی رابط کاربری رضایت اثر میگذارند:
- پایان استفاده از «ادامه بدون پذیرش» بهعنوان معادل رد کردن مگر آنکه از نظر بصری با دکمه پذیرش مطابقت داشته باشد و دقیقاً همان TC String را تولید کند که یک «رد کامل» ایجاد میکند.
- برابری زبانی — اعلان رضایت باید در همه زبانهایی که خود سایت در آنها عرضه میشود در دسترس باشد، نه فقط زبان مرورگر کاربر. CMPها باید امکان override کردن locale را پشتیبانی کنند.
- دسترسی دائمی — کاربر باید بتواند از هر صفحه سایت، به مرکز ترجیحات دسترسی پیدا کند، نه فقط صفحه فرود، و لینک دسترسی باید طوری برچسبگذاری شود که یک کاربر غیرمتخصص هم متوجه شود به رضایت و حریم خصوصی مربوط است.
ناشران چه کارهایی باید انجام دهند
- پشتیبانی v2.3 توسط تأمینکننده CMP خود را تأیید کنید. تاریخ دقیق در دسترسبودن نسخه v2.3-certified و رشته نسخهای را که گزارش خواهد کرد، بپرسید.
- منطق کش GVL خود را بهروزرسانی کنید. اگر هر نوع آینه GVL را خودتان میزبانی میکنید، پیش از عرضه GVL مبتنی بر v2.3 مفسر طرحواره را بهروزرسانی کنید، وگرنه CMP شما در اعتبارسنجی فروشندگان جدید شکست میخورد.
- رابط کاربری لایه دوم را بازنویسی کنید تا همه سوئیچها در حالت پیشفرض خاموش باشند، برابری در برجستهسازی بهصورت بصری رعایت شود، و دورههای نگهداری کنار هر مقصد نمایش داده شود.
- ممیزی انطباق خود را دوباره اجرا کنید. آسانترین شکارهای ناظران، الگوهای فریبندهای هستند که v2.3 حالا صریحاً آنها را هدف گرفته است. پیش از بررسی اجرایی بعدی، این موارد را اصلاح کنید.
- برای re-prompt برنامهریزی کنید. با اینکه TC String عقبسازگار است، Policies ناشران را تشویق میکند وقتی دامنه یا افشای پردازش بهشکل معناداری عوض میشود، دوباره از کاربر رضایت بگیرند. تصمیم بگیرید که آیا استقرار v2.3 برای مخاطبان شما مصداق «تغییر معنادار» هست یا نه.
فروشندگان چه کارهایی باید انجام دهند
- برای هر مقصدی که در آن LI اعلام میکنید، Legitimate Interests Assessment را تکمیل کنید و نتیجه را به GVL ارسال کنید.
- ورودی خود در GVL را بهروزرسانی کنید و فیلدهای طرحواره v2.3 شامل سطح جزئیات دوره نگهداری، اعلامیه LIA و لینک عمیق (deep link) به سیاست حریم خصوصی را اضافه کنید.
- تحلیلگر TC String خود را با رشتههای مرجع v2.3 که توسط IAB Europe ارائه شده، اعتبارسنجی کنید.
- با شرکای CMP خود هماهنگ شوید و یک تاریخ مشترک برای cutover تعیین کنید تا اولین درخواست خریدی که یک رشته v2.3 را حمل میکند، روی فروشندهای که فقط v2.2 را میفهمد فرود نیاید.
دامهای رایج در مهاجرت
- نگاه کردن به v2.3 بهعنوان فرصت بازطراحی UI. وسوسهانگیز است که بهروزرسانیهای برند را با استقرار v2.3 ادغام کنید، اما این کار تست انطباق را پیچیده میکند. ابتدا یک نسخه v2.3 فقط برای انطباق عرضه کنید، بعد روی طراحی تکرار کنید.
- نادیده گرفتن الزام نمایش دوره نگهداری. تیمها اغلب نمای فهرست فروشندگان را بهروزرسانی میکنند، اما فراموش میکنند که حالا باید دوره نگهداری در نمای لایهایِ مقصدبهمقصد هم نمایش داده شود.
- فرض اینکه TC String بهتنهایی کافی است. یک رشته بهظاهر سازگار که از یک رابط کاربریِ ناسازگار تولید شده، همچنان ناسازگار است. ناظران بارها اپراتورهایی را جریمه کردهاند که رشتههایشان بیعیب به نظر میرسید، اما بنرهایشان دکمه رد را پنهان میکرد.
- بیرون گذاشتن CTV و موبایل از دامنه کار. v2.3 برای هر سطحی که در آن سیگنالهای TCF تولید میشود، لازمالاجراست. ناشرانی که فقط وب را بهروزرسانی میکنند و اپلیکیشنهای CTV یا موبایل خود را نادیده میگیرند، در عمل یک محیط ترکیبیِ ناسازگار ایجاد میکنند.
جمعبندی
TCF v2.3 یک گسست رادیکال از v2.2 نیست، اما سفت و سختتر شدن معنادار قواعدی است که اکوسیستم برنامهریزیشده اروپا را کنار هم نگه میدارد. جهتگیری روشن است: شفافیت بیشتر، الگوهای فریبنده کمتر، کنترل جزئیتر برای کاربر، و تحمل پایینتر برای سناریوهای مرزی که قبلاً از زیر رادار عبور میکردند. CMPها و ناشرانی که با v2.3 مثل یک وصله سریع برخورد کنند، دوباره پایشان به اتاق ناظر باز خواهد شد. کسانی که از این مهاجرت برای تمیز کردن UX لایه دوم، کنار گذاشتن میانبُرهای مبتنی بر منافع مشروع، و بازسازی یک جریان رضایت واقعاً مبتنی بر برابری در برجستهسازی استفاده کنند، در پایان دوره گذار، موجودیای خواهند داشت که در عصر v2.3 واقعاً معامله میشود — و وضعیت رضایتی که احتمالاً از هر چیزی که v2.4 در آینده بیاورد هم جان سالم بهدر خواهد برد.