כיצד לקרוא מחרוזת הסכמה של TCF: מדריך שטח למפתחים

מהי בעצם ה-TC string

ה-IAB Transparency & Consent Framework מייצר אסימון קומפקטי יחיד — ה-TC string — שנוסע עם כל בקשת פרסום ומספר לספקים בדיוק עם מה משתמש הסכים ועם מה לא. הוא מקודד ב-Base64-URL וארוז ברמת הסיביות, כך שהוא נראה כמו ג׳יבריש (CPxy...AAA) אך מקודד רשומה מדויקת וניתנת לביקורת.

המקטעים

TC string מלא הוא מספר מקטעים מופרדים בנקודות. הראשון הוא ה-core string; האחרים הם אופציונליים:

שדות הביטים הם הלב של העניין: סיבית N שמוגדרת ל-1 משמעה הסכמה למטרה N או לספק N. מטרה 1 היא “אחסון/גישה למידע במכשיר,” מטרות 3 ו-4 מכסות פרסומות מותאמות אישית, וכן הלאה.

פענוח אחת בפועל

נדיר שתפענח ביטים ביד. השתמש בספריות שמספק IAB או במפענח ציבורי:

ב-JavaScript הקריאה __tcfapi('getTCData', 2, cb) מחזירה את האובייקט שכבר נותח — tcData.purpose.consents ו-tcData.vendor.consents הם מפות של id → בוליאני. זוהי אמת היסוד שלך בזמן ריצה.

השגיאות שהורגות הכנסות

כשביקוש מותאם אישית נעלם בשקט, ה-TC string הוא בדרך כלל הסיבה:

תהליך עבודה לאיתור תקלות

שחזר את ההסכמה של המשתמש, תפוס את ה-TC string החי מ-__tcfapi או מבקשת הפרסום, העבר אותו דרך מאמת, והשווה את המטרות/ספקים המפוענחים למה שהשותפים שלך דורשים. תשע מתוך עשר פעמים הפער הוא סיבית ספק יחידה או מטרה 1 חסרה.

היכן FlexyConsent משתלב

FlexyConsent מייצר TC strings תקפים לפי המפרט עם CMP ID רשום, שומר עליהם טריים, חושף את המצב המפוענח לאיתור תקלות, ומדווח אילו מטרות וספקים אכן ניתנים ברחבי התעבורה שלך — כך שתוכל לראות, לא לנחש, היכן הסכמה (והכנסות) דולפות.

נקודות מפתח

← בdelays delays קרא הכל →