המפרט הטכני 'מצב הסכמה נוספת' ב-Google

המסמך הזה מגדיר מפרט טכני (שנקרא 'מצב הסכמה נוספת') שמיועד רק לשימוש במקביל לגרסה 2.0 של Transparency & Consent Framework (‏TCF - מסגרת השקיפות וההסכמה) של IAB Europe, כפתרון זמני עבור ספקים שעדיין לא נכללים ברשימת הספקים הגלובלית (GVL) של IAB Europe. המפרט הזה מאפשר לבעלי תוכן דיגיטלי, לספקי פתרונות לקבלת הסכמה (CMP) ולשותפים לאסוף ולהפיץ את ההסכמה הנוספת – לצד הטמעת גרסה 2.0 של TCF – לחברות שעדיין לא נכללות ברשימת הספקים הגלובלית של IAB Europe, אבל מופיעות ברשימת ספקי טכנולוגיות הפרסום (ATP) של Google.

מקורות מידע שקשורים לנושא

• המשפט לגבי נתוני השקיפות וההסכמה בגרסה 2.0 לפורמט של רשימת הספקים הגלובלית
• גרסה 2.0 של Consent Management Platform API
• המדיניות של Transparency & Consent Framework (‏TCF - מסגרת השקיפות וההסכמה) של IAB Europe
• מדיניות Google בנושא הסכמת משתמשים באיחוד האירופי

הרכיבים של 'מצב הסכמה נוספת'

ב'מצב הסכמה נוספת', אנחנו תומכים בשני הרכיבים הבאים:

• המחרוזת לגבי נתוני השקיפות וההסכמה (מחרוזת TC), כפי שהוגדרה במפרט של גרסה 2.0 של IAB TCF. המחרוזת הזו כוללת את נתוני השקיפות וההסכמה שנקבעו לספקים ברשימת הספקים הגלובלית (GVL) של IAB. וגם
• מחרוזת addtl_consent פשוטה (מחרוזת AC), הכוללת רשימה של ספקי טכנולוגיות הפרסום של Google שהמשתמשים הביעו הסכמה עבורם, אבל הם אינם רשומים ב-IAB.

המפרט הזה מגדיר את הרכיבים הבאים:

1. הפורמט של מחרוזת AC (הסכמה נוספת)
2. התוסף ל-CMP API עבור גרסה 2.0 של TCF המספק תמיכה במחרוזת AC
3. אופן האחסון של מחרוזת AC
4. אופן ההעברה של מחרוזת AC דרך שרשרת הפרסום הדיגיטלי

פורמט המחרוזת של 'הסכמה נוספת' (AC)

איזה מידע מאוחסן במחרוזת AC?

מחרוזת AC כוללת את שלושת הרכיבים הבאים:

• חלק 1: מספר הגרסה של המפרט, למשל "1"
• חלק 2: סמל מפריד "~"
• חלק 3: רשימה של מזהים המופרדים באמצעות נקודות, המשויכים לספקי טכנולוגיות הפרסום (ATP) של Google שהמשתמשים הביעו הסכמה עבורם. דוגמה: "1.35.41.101"

לדוגמה, אם מחרוזת AC היא ‎1~1.35.41.101, פירוש הדבר הוא שהמשתמש הביע הסכמה לספקי טכנולוגיות הפרסום עם המזהים 1, 35, 41 ו-101, והמחרוזת נוצרת על סמך הפורמט המוגדר במפרט של גרסה 1.0.

מי צריך ליצור מחרוזת AC?

רק ספק פתרונות לקבלת הסכמה (CMP) הרשום ב-TCF של IAB Europe רשאי ליצור מחרוזת AC על סמך מספר מזהה ה-CMP שהוקצה לו, בהתאם למדיניות של IAB. ספקי שירות אחרים של צד שלישי לא רשאים ליצור מחרוזות AC בעצמם.

איפה יפורסמו ספקי טכנולוגיות הפרסום של Google?

Google תפרסם את הרשימה של ספקי טכנולוגיות הפרסום שלא רשומים ב-IAB ואת המזהים שלהם במיקום הבא:

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

מתי צריך ליצור מחרוזת AC?

בכל המקרים, אפשר ליצור מחרוזת AC רק כאשר בעל התוכן הדיגיטלי מציית למדיניות Google בנושא הסכמת משתמשים באיחוד האירופי. באופן ספציפי, אסור ליצור מחרוזת AC לפני שהמשתמש נותן הסכמה תקפה מבחינה משפטית לפעולות הבאות: 1) שימוש בקובצי cookie או באחסון מקומי אחר, היכן שהדבר נדרש על פי חוק, וגם 2) איסוף ושיתוף של מידע אישי ושימוש בו לצורך התאמה אישית של מודעות על ידי ספק טכנולוגיית פרסום, בהתאם למדיניות Google בנושא הסכמת משתמשים באיחוד האירופי.

יש ליצור מחרוזת AC (הסכמה נוספת) רק כמחרוזת משלימה למחרוזת TC (נתוני השקיפות וההסכמה), ולא במקום מחרוזת TC. Google לא תעבד את הבקשה, והיא תמחק את מחרוזת AC בבקשה שנשלחה אליה אם אין מחרוזת TC זמינה עבור אותה בקשה.

ספקי פתרונות לקבלת הסכמה (CMP) שמטמיעים את המפרט הזה צריכים לוודא שמחרוזת AC שהם יוצרים כוללת רק את המזהים מקובץ ATP של Google שפורסם (כלומר, ספקים שאינם נכללים ברשימת הספקים הגלובלית). כש-Google מקבלת מחרוזת TC, היא בודקת את הגרסה של רשימת הספקים הגלובלית שמופיעה במחרוזת הזו. אם הגרסה של רשימת הספקים הגלובלית (GVL) כוללת רישום של ספק, המערכת תתעלם מפקדי מחרוזת TC של הספק הזה ומכל רשומה במחרוזת AC של הספק הזה. בנסיבות כאלה, Google שומרת לעצמה את הזכות להסיר רשומות "כפולות" כאלה ממחרוזת AC ולהעביר מחרוזת AC מתוקנת לצד מחרוזת TC. ספקים אחרים מלבד Google לא רשאים לשנות את מחרוזת AC.

תוסף ל-CMP API

אנחנו מציעים להרחיב את CMP JavaScript API הקיים של גרסה 2.0 של TCF כדי לאפשר את ההחזרה של מחרוזת AC. באופן ספציפי, אנחנו מציעים להרחיב את האובייקטים של 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’,
}

איך צריך לאחסן את מחרוזת AC?

באתר

מנגנון האחסון נתון לבחירתו של ספק הפתרונות לקבלת הסכמה (CMP).

באפליקציה

NSUserDefaults‏ (iOS) או SharedPreferences‏ (Android) ישמשו לאחסון של מחרוזת AC באמצעות CMP SDK. בעזרת מנגנוני האחסון האלה:

• הספקים יכולים לגשת בקלות למחרוזת AC
• מחרוזת AC יכולה להופיע בעקביות בכל הסשנים באפליקציה
• מחרוזת AC יכולה לעבור בין ספקי פתרונות לקבלת הסכמה (CMP), וכך לאפשר לבעל התוכן הדיגיטלי להחליף CMP SDK אחד ב-CMP SDK אחר.

אם בעל התוכן הדיגיטלי בוחר להסיר CMP SDK מהאפליקציה שלו, באחריותו להסיר את הערכים של AddtlConsent עבור המשתמשים, כדי שהספקים לא ישתמשו יותר במחרוזת AC הכלולה.

מפתח אחסון וחיפוש ב-NSUserDefaults וב-SharedPreferences	ערך
IABTCF_AddtlConsent	מחרוזת: מחרוזת AC עם גרסת מפרט ומזהים של ספקי טכנולוגיות פרסום שהמשתמשים הביעו הסכמה עבורם

אופן ההעברה של מחרוזת AC דרך שרשרת הפרסום הדיגיטלי

בקשה להצעת מחיר

אנחנו נעשה שימוש חוזר ב-ConsentedProvidersSettings כדי להפיץ הלאה את הספקים שלא נכללים ברשימת הספקים הגלובלית (GVL).

• בפרוטוקול התוספים של 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 כדי לקבל את מחרוזת TC. בדומה לתמיכה במחרוזת TC, אנחנו מספקים פרמטר סטנדרטי של כתובת URL ומאקרו בכתובות ה-URL של הפיקסלים שאליהן צריך להוסיף את מחרוזת AC.

פרמטר של כתובת URL	מאקרו תואם	ייצוג בכתובת ה-URL
addtl_consent	ADDTL_CONSENT	&addtl_consent=${ADDTL_CONSENT}

דוגמה 1

כדי שספק א' יקבל מחרוזת AC, כתובת URL של תמונה צריכה לכלול צמד מפתח/ערך עם הפרמטר של כתובת ה-URL ופקודת המאקרו &addtl_consent=${ADDTL_CONSENT}. כתובת ה-URL שתתקבל תהיה:

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

 

דוגמה 2

בבקשה נתונה, אם מחרוזת AC היא: ‎1~1.35.41.101

פונקציית הקריאה החוזרת (caller) או הכלי לעיבוד של הקריאייטיב מחליפים את המאקרו בכתובת ה-URL במחרוזת AC בפועל, כך שהפיקסל המוטמע המקורי שכולל את המאקרו ישתנה באופן הבא בעת ביצוע הקריאה לשרת שצוין:

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