چگونه یک رشته رضایت TCF را بخوانیم: راهنمای میدانی توسعه‌دهنده

TC string واقعاً چیست

چارچوب IAB Transparency & Consent Framework یک توکن فشرده واحد تولید می‌کند — TC string — که با هر درخواست تبلیغاتی همراه می‌شود و دقیقاً به فروشندگان می‌گوید کاربر با چه چیزی موافقت کرده و با چه چیزی موافقت نکرده است. با Base64-URL رمزگذاری شده و در سطح بیت بسته‌بندی شده است، بنابراین مانند مهملات به نظر می‌رسد (CPxy...AAA) اما یک سابقه دقیق و قابل‌حسابرسی را رمزگذاری می‌کند.

بخش‌ها

یک TC string کامل چند بخش است که با نقطه جدا شده‌اند. اولی رشته هسته است؛ بقیه اختیاری هستند:

فیلدهای بیتی قلب کار هستند: بیت N که روی 1 تنظیم شده یعنی رضایت برای هدف N یا فروشنده N. هدف ۱ “ذخیره/دسترسی به اطلاعات روی یک دستگاه” است، اهداف ۳ و ۴ تبلیغات شخصی‌سازی‌شده را پوشش می‌دهند و غیره.

رمزگشایی یکی در عمل

شما به‌ندرت بیت‌ها را با دست رمزگشایی می‌کنید. از کتابخانه‌های ارائه‌شده توسط IAB یا یک رمزگشای عمومی استفاده کنید:

در جاوااسکریپت فراخوانی __tcfapi('getTCData', 2, cb) شیء از قبل تجزیه‌شده را برمی‌گرداند — tcData.purpose.consents و tcData.vendor.consents نگاشت‌هایی از id → boolean هستند. این حقیقت پایه شما در زمان اجرا است.

خطاهایی که درآمد را می‌کشند

وقتی تقاضای شخصی‌سازی‌شده بی‌صدا ناپدید می‌شود، معمولاً TC string دلیل آن است:

یک گردش‌کار عیب‌یابی

رضایت کاربر را بازتولید کنید، TC string زنده را از __tcfapi یا درخواست تبلیغاتی بگیرید، آن را از یک اعتبارسنج بگذرانید و اهداف/فروشندگان رمزگشایی‌شده را با آنچه شرکای شما نیاز دارند مقایسه کنید. نه بار از ده بار شکاف یک بیت فروشنده واحد یا یک هدف ۱ گمشده است.

جایگاه FlexyConsent

FlexyConsent رشته‌های TC معتبر از نظر مشخصات را با یک شناسه CMP ثبت‌شده تولید می‌کند، آن‌ها را تازه نگه می‌دارد، وضعیت رمزگشایی‌شده را برای عیب‌یابی نمایش می‌دهد و گزارش می‌دهد که کدام اهداف و فروشندگان در سراسر ترافیک شما واقعاً اعطا می‌شوند — بنابراین می‌توانید ببینید، نه حدس بزنید، که رضایت (و درآمد) کجا نشت می‌کند.

نکات کلیدی

← وبaderegistrdelays delays خواندن همه →