התאמות של קובצי Cookie

'התאמת קובצי cookie' היא תכונה שמאפשרת לך להתאים את קובץ ה-cookie — לדוגמה, מזהה של משתמש שגלש באתר שלכם — עם מזהה תואם User ID ספציפי למגיש הצעות מחיר, וליצור רשימות משתמשים שיעזרו לכם לבצע בחירות יעילות יותר של הגשת הצעות מחיר. במדריך הזה מתוארים המושגים שאפשר להשתמש בהם בקובצי Cookie התאמות, וגם תהליכי עבודה שונים של התאמות קובצי cookie, וכל וריאציה שיש להם במקרים מסוימים.

מושגים

בעלי דומיינים בדרך כלל מגדירים את התוכן של קובצי ה-cookie עבור משתמשים שגולשים של האתר שלו, שמשמש לזיהוי משתמשים בדומיין זה. גם אם שניים בעלי הדומיינים היו מסכימים להעביר את הנתונים האלה באופן אחר, מודל האבטחה מדפדפני האינטרנט מגבילים את הקריאה של קובץ cookie שהוגדר על ידי דפדפן אחר דומיין.

בהקשר של פרסום בדיגיטל, Google מזהה משתמשים עם קובצי Cookie ששייכים לדומיין doubleclick.net ועם מגישי הצעות המחיר המשתתפים בתוכנית 'בידינג בזמן אמת' עשויים להחזיק בדומיין משלהם, לזהות כמה משתמשים שהם מעוניינים להציג מודעות. התאמות של קובצי cookie שמאפשר למגיש הצעות המחיר להתאים את קובצי ה-Cookie שלו לקובצי Google, כדי שהוא לקבוע אם חשיפה שנשלחה בבקשה להצעת מחיר משויכת לאחד של המשתמשים המטורגטים, הם יקבלו נתוני קובצי Cookie משלהם או User-ID שספציפי למגיש הצעות המחיר, שהוא צורה מוצפנת קובץ Cookie אחד (doubleclick.net) בבקשה להצעת המחיר.

שירות התאמת קובצי ה-cookie שמתואר במדריך הזה מאפשר את היצירה ותחזוקה של הקשר בין קובץ cookie של מגיש הצעות מחיר לבין מזהה משתמש, ומאפשר גם לאכלס רשימות משתמשים.

טבלאות של התאמות

אפשר להשתמש בטבלת התאמות כדי למפות מזהה או נתונים אחרים מדומיין אחד אחר. מגישי הצעות המחיר יכולים להשתמש בשירות ההתאמות של קובצי cookie כדי לאכלס משלהם טבלאות של התאמות על ידי מיפוי קובץ ה-cookie של משתמש נתון לקובץ Google של המשתמש User ID, או כדי לאכלס טבלת התאמות שמתארחת ב-Google. טבלאות ההתאמות הן שנדרשים לאפליקציה של מגיש הצעות המחיר כדי לגשת לנתוני קובצי Cookie של המשתמש שמוצגת להם החשיפה.

טבלאות התאמות שמתארחות ב-Google

לצורך תחזוקה קלה יותר, שיפורים בזמן האחזור וגישה לנתונים של התאמות באזורים מסוימים, מומלץ לאפשר ל-Google לארח טבלת התאמות. כך אפשר לציין מחרוזת בקידוד base64 שמתאימה לאינטרנט – נקראים בהמשך כנתוני התאמה מתארחים, והם ימופו מזהה המשתמש של Google עבור משתמש נתון. לאחר יצירת התאמה, ניתן: נעשה בו שימוש בדרכים הבאות:

  • בידינג בזמן אמת: בבקשות הבאות להצעות מחיר על חשיפות שמשויכים למשתמש, Google תשלח לך את נתוני ההתאמה המתארחים תואם למזהה המשתמש שלהם ב-Google. אם נקודת הקצה לבידינג מוגדרת כדי להשתמש בפרוטוקול RTB של Google, מקבלים אותו כבייטים מפוענחים דרך השדה BidRequest.hosted_match_data. ב-OpenRTB של Google BidRequest.user.buyeruid יחזיר את התוצאה הזו כמחרוזת בקידוד base64 לבטוח באינטרנט.

  • רשימות משתמשים: ניתן לאכלס רשימות משתמשים באמצעות מזהי משתמשים של Google או נתוני התאמה מתארחים.

  • טירגוט מראש: אפשר להגדיר טירגוט מראש כך שתקבלו רק בקשות להצעות מחיר שמכיל נתוני התאמה מתארחים. אפשר להשתמש כך כדי למנוע פחות רלוונטיות חשיפות למשתמשים מחוץ למרחב קובצי ה-Cookie.

רשימות משתמשים

אפשר ליצור ולנהל רשימות משתמשים באמצעות Real-Time Bidding API. אחרי שיוצרים את הרשימות האלה, אפשר לאכלס את הרשימות האלה בתהליכי העבודה של התאמות קובצי Cookie שמתואר בהמשך, או באמצעות השירות להעלאת נתונים בכמות גדולה.

תחילת העבודה

כדי להתחיל לעבוד עם התאמות של קובצי cookie, עליך לפנות אל מנהל חשבונות טכני שיכול להפעיל תהליכי עבודה ספציפיים ולעזור לכם להגדיר את הדברים הבאים:

  • Cookie matching Network ID (NID): מזהה מחרוזת שמזהה באופן ייחודי חשבון של מגיש הצעות מחיר לצורך התאמות של קובצי Cookie ופעולות קשורות אחרות.
  • Cookie matching URL (כתובת URL תואמת): כתובת ה-URL הבסיסית של נקודת הקצה שאפשר לקבל ולטפל בבקשות נכנסות כחלק מתהליכי העבודה של התאמות קובצי cookie. מגישי הצעות המחיר יכולים להטמיע פקודות מאקרו בכתובת ה-URL הזו כדי לשלוט בסדר הפרמטרים שמועברים אליה בתהליכי העבודה של התאמות של קובצי cookie.
  • תג התאמה: התג שצריך להציב בדפדפן של המשתמש לצורך תהליך עבודה של התאמת קובצי cookie ביוזמת מגיש הצעות המחיר. אפשר להציג את המידע הזה לצד מודעות, או יוצבו בנכסי אינטרנט מחוץ למודעות.
  • כתובת URL של הדוח 'התאמה של קובצי cookie' (אופציונלי): בדוח החד-כיווני תהליך עבודה של התאמת קובצי cookie, זוהי כתובת URL אופציונלית שניתן לספק לציין נקודת קצה (endpoint) תקבל פרטי שגיאה במקרה שקובץ ה-Cookie התאמה נכשלת דרך הפניה אוטומטית מסוג HTTP 302. כברירת מחדל, התשובות יהיו נשלחו לכתובת האתר הזו אם אירעה שגיאה בפעולת ההתאמה של קובצי cookie, אבל מגיש הצעות המחיר עשוי לבקש שההפניה האוטומטית תישלח תמיד.
  • Cookie Match Assist URL: להמרות שמטמיעות את תהליך העבודה של Cookie Match Assist, זו כתובת ה-URL הבסיסית של נקודת הקצה שנועדה להגיב לבקשות נכנסות.
  • מכסה של Cookie Match Assist: להמרות שמטמיעות את תהליך העבודה של Cookie Match Assist, זו המספר המקסימלי של בקשות שכתובת ה-URL של התאמת קובצי ה-Cookie יכולה לקבל כל שנייה. המטרה היא למנוע עומס יתר של בקשות CMA של Exchange עם בקשות.

בכל אחד מתהליכי העבודה הנתמכים של התאמת קובצי cookie, לכתובת URL של התאמת קובצי Cookie של מגיש הצעות מחיר בדרך כלל מצורפים פרמטרים הזמנה ללא אחריות. מגישי הצעות מחיר עם שילובים שמחייבים שימוש עקבי סדר הפרמטרים יכול להציב פקודות מאקרו בכתובת האתר של התאמת קובצי ה-Cookie ל להבטיח את מיקומם.

פקודות מאקרו נתמכות

מגישי הצעות המחיר יכולים באופן אופציונלי להגדיר את כתובת ה-URL שלהם להתאמת קובצי cookie כך שתכלול אחת או יותר יותר פקודות מאקרו בצורת %%GOOGLE_<PARAM_NAME>%% או %%GOOGLE_<PARAM_NAME>_PAIR%%. רכיבי המאקרו הנתמכים הערכים המורחבים הם:

Macro ערך מורחב
GOOGLE_GID GOOGLE_USER_ID
GOOGLE_GID_PAIR &amp;google_gid=GOOGLE_USER_ID
GOOGLE_CVER COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR &amp;cver=COOKIE_VERSION_NUMBER
GOOGLE_ERROR ERROR_ID
GOOGLE_ERROR_PAIR &amp;google_error=ERROR_ID
GOOGLE_PUSH PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR &amp;google_push=PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS google_gid=GOOGLE_USER_ID&amp;cver=COOKIE_VERSION_NUMBER&amp;google_error=ERROR_ID

דוגמה למאקרו

למגיש הצעות מחיר יש שילוב של התאמות קובצי cookie עם נקודת קצה שמתארחת בכתובת https://user.bidder.com.cookies, וההטמעה שלהם מחייבת פרמטרים שהוגדרו מראש על ידי מגישי הצעות המחיר בנוסף להתאמת Pixel פרמטרים בסדר הבא: google_push, google_gid, google_cver וגם google_error. מגיש הצעות המחיר יכול לעשות זאת על ידי הגדרת כתובת URL תואמת של קובץ cookie ל:

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

כש-Google תשלח מאוחר יותר בקשת התאמה למגיש הצעות המחיר הזה, הבקשה תורחב משהו כזה:

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

שירות התאמת קובצי ה-Cookie של Google תומך כרגע בשלושה תהליכי עבודה במקרים שונים שמתוארים בהמשך.

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

שלב 1: ממקמים את תג ההתאמה

כדי להתחיל בתהליך הזה, מגיש הצעות המחיר חייב להציב את תג ההתאמה שלו. שהיא מעבדת בדפדפן של המשתמש. תג התאמה פשוט שמחזיר רק מזהה המשתמש ב-Google של מגיש הצעות המחיר יכול להיות בנוי באופן הבא:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

יש פרמטרים נוספים שאפשר לכלול בתג ההתאמה כדי למלא במקרים שונים. למידע נוסף על הפרמטרים האלה, אפשר לעיין במאמר התאמה לפרמטרים של כתובת ה-URL של התג.

שלב 2: Google מגיבה עם הפניה לכתובת אחרת שכוללת את נתוני ההתאמה

תג ההתאמה יגרום לשירות התאמת קובצי ה-Cookie של Google לקבל בקשה מהדפדפן של המשתמש, שינפיק HTTP 302 להפנות באופן אוטומטי לכתובת ה-URL של 'התאמת קובצי cookie' של מגיש הצעות המחיר. כתובת האתר להפניה מחדש תכלול את השאילתה שמציינים את ה-User-ID של Google ואת מספר הגרסה שלו בכתובת ה-URL, מגיש הצעות המחיר יקבל גם את קובץ ה-cookie שלו בכותרות של הבקשות. לחשבון לתרגול, עבור כתובת URL תואמת לקובצי cookie שצוינה כ-https://ad.network.com/pixel, כתובת האתר להפניה מחדש עבור תג ההתאמה הפשוט כפי שנראה למעלה, עשויה להיראות כך הבאים:

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

מזהה המשתמש ב-Google שמועבר דרך הפרמטר google_gid הוא קובץ בקידוד base64 ללא ריפוד String. למגישי הצעות מחיר שבוחרים לארח טבלת התאמות, מומלץ לאחסן את המחרוזת המדויקת שהוחזרה על ידי שירות התאמת קובצי ה-Cookie. בפעימות הבאות בקשות להצעות מחיר, שיתאימו לערכים שצוינו עד BidRequest.google_user_id בפרוטוקול RTB של Google, או BidRequest.user.id הטמעת OpenRTB.

הגרסה שצוינה ב-google_cver מציינת את הערך של מספר הגרסה של Google User ID. מזהה המשתמש ב-Google של משתמש נתון משתנה לעתים רחוקות, ולאחר מכן הערך יגדל.

אם Google נתקלת בשגיאה במהלך העיבוד של בקשת ההתאמה, במקום זאת יופיע הפרמטר google_error.

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

מגיש הצעות המחיר מקבל הפניה אוטומטית לכתובת ה-URL התואמת לקובצי Cookie, כולל שהם ציינו בשלב הראשון, ואלו ש-Google סיפקה השלב השני. בנוסף, הם יקבלו גם את קובץ ה-cookie ב-HTTP כותרות עליונות. אם הפעולה הצליחה, מגיש הצעות המחיר מארח טבלת התאמות משלו. יכולים להתאים את קובץ ה-cookie שלהם למזהה המשתמש ב-Google שנכלל בתשובה. זה כן מומלץ למגישי הצעות המחיר לאחסן את המחרוזת המדויקת שהוחזרה על ידי התאמת קובצי cookie שירות.

אם הפעולה לא תושלם, מגיש הצעות המחיר יקבל google_error בהפניה האוטומטית. זהו ערך מספרי שתואם את הערכים של שגיאה שמזהה את השגיאה הספציפית שאירעה. אפשר ללמוד מידע נוסף על ערכי השגיאה האפשריים כאן. אם קיבלת שגיאה, אפשר לנסות לבצע שוב התאמה עבור המשתמש הזה על ידי להוסיף תג התאמה חדש.

מגיש הצעות המחיר חייב תמיד להגיב על ידי הצגת תמונת פיקסל בלתי נראית בגודל 1x1, או או להחזיר תשובה של HTTP 204 ללא תוכן.

תהליך העבודה הזה מאויר באמצעות התרשים הבא, שבו בקשות תשובות מיוצגות בחץ, ופריטי הנתונים הנלווים אליהן מופיעות בסוגריים.

התאמת פרמטרים של כתובת אתר של תג

פרמטר תיאור
google_nid מזהה הרשת (NID) של החשבון של מגיש הצעות המחיר. אפשר לאחזר את המזהה הזה דרך מגישי הצעות המחיר משאב.
google_cm מציינת לשירות התאמת קובצי ה-Cookie של Google שצריך לבצע התאמות של קובצי Cookie. המערכת מתעלמת מערך הפרמטר, והוא יכול להיות שהושמט.
google_sc הפרמטר הזה הוצא משימוש. מגדיר את קובץ ה-Cookie של Google עבור משתמש אם אין מזהה. המערכת מתעלמת מערך הפרמטר, והוא עלול חייב להשמיט. אם לא כוללים קובץ cookie, הדבר יגרום לשגיאה קיים.
google_no_sc הפרמטר הזה הוצא משימוש. זה מצביע על שירות התאמת קובצי cookie לא אמור להגדיר קובץ cookie למשתמש אם אחד מהם לא קיים. המערכת מתעלמת מערך הפרמטר, והוא יכול להיות שהושמט.
google_hm

נתונים שמגיש הצעות המחיר רוצה לאחסן בטבלת התאמות שמתארחת ב-Google.

הערך הוא מחרוזת בקידוד base64 שמתאימה לאינטרנט (אופציונלי). כמות הנתונים הגולמיים צריכה להיות 40 בייטים או פחות. לדוגמה, Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u.

google_redir מחרוזת בקידוד כתובת URL שמגיש הצעות המחיר יכול לציין אם הוא רוצה להפנות Google תשלח את ההפניה האוטומטית של HTTP 302 לכתובת ה-URL המקודדת עבור תג ההתאמה הזה. כך Google יכולה להיות מוצבת בחלק הקדמי בתוך רשת להתקשר לשותפים. אם לא תציינו את הסיבה, תתקבל שגיאה google_hm, או באמצעות google_cm.
google_ula מחרוזת שמשמשת להוספת המשתמש לרשימת משתמשים קיימת. הערך הפורמט הצפוי הוא userlistid[,timestamp]:
  • userlistid: מזהה של רשימת משתמשים מספרית אחת.
  • timestamp: חותמת זמן אופציונלית בפורמט POSIX. מציין מתי המשתמש נוסף לרשימת המשתמשים.

ניתן לחזור על הפרמטר הזה של כתובת אתר כדי להוסיף את המשתמש לכמה רשימות.
gdpr מציין שהבקשה כפופה להגבלות של GDPR על נתונים בשימוש. פרטים נוספים זמינים במאמר הדרישות בנושא הסכמת משתמשים באיחוד האירופי שמפורטות בהמשך, או ההשפעה על התאמה של קובצי cookie זכאות בתנאים מסמכי תיעוד בנושא TCF גרסה 2.0 של Authorized Buyers.

לדוגמה: gdpr=1
gdpr_consent מחרוזת נתוני שקיפות והסכמה שמייצגת את ההסכמה ממשתמשי הקצה. לפרטים נוספים, אפשר לקרוא את הדרישות לקבלת הסכמת משתמשים באיחוד האירופי. למטה, או איך המחרוזת של נתוני השקיפות וההסכמה תועבר? בקטע מסמכי תיעוד בנושא TCF גרסה 2.0 של Authorized Buyers.
process_consent מציין שמגיש הצעות המחיר קיבל הסכמה ממשתמשי הקצה לשימוש בנתונים שצוינו ב מדיניות Google בנושא הסכמת משתמשים באיחוד האירופי.

אם הבקשה לא כפופה למדיניות Google בנושא הסכמת משתמשים באיחוד האירופי, או אם יש האם פרמטרים אחרים של הסכמה זמינים בבקשה? (gdpr_consent), המערכת תתעלם מהפרמטר הזה.

לדוגמה: process_consent=T

בנוסף לפרמטרים שלמעלה, מגישי הצעות המחיר יכולים לציין מגישי הצעות מחיר משלהם. יצורפו כפרמטרים לכתובת ה-URL להפניה אוטומטית. שימו לב שההגדרות של מגיש הצעות המחיר המערכת תתעלם מפרמטרים ששמם עם הקידומת google_ כי אלה שמורים ל-Google לפיתוח עתידי ולשימור 'פרמטרים' ההזמנה אינה מובטחת. תג התאמה שכולל את ההגדרות של מגיש הצעות המחיר פרמטרים שונים עשויים להיראות כך:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

פרמטרים של כתובת אתר להפניה מחדש

כתובת ה-URL להפניה אוטומטית נוצרה מכתובת ה-URL הבסיסית להתאמת קובצי cookie שהוגדרה עבור לחשבון של מגיש הצעות המחיר, כולל google_ ופרמטרים שהוגדרו על ידי מגיש הצעות המחיר בהתאם לאלה שצוינו בתג ההתאמה. google_ הבאים מוגדרים פרמטרים של תגובה:

פרמטר תיאור
google_gid מזהה משתמש של Google. קובעים אם צוין google_cm בבקשה והבקשה הושלמה בהצלחה.
google_cver גרסת קובץ ה-Cookie. קובעים אם צוין google_cm בבקשה והבקשה הושלמה בהצלחה.
google_error

ערך מסוג מספר שלם שמציין את השגיאה הכוללת בבקשה. מתי הוא מציין שלא בוצעו פעולות יוגדרו google_ פרמטרים של תשובות. השגיאה הנתמכת כוללים את הערכים הבאים:

  • 1: למשתמש יש קובץ Cookie של Google, אבל הוא ביטל את ההסכמה לשימוש בקובצי Cookie מעקב באמצעות קובץ ה-Cookie הזה.
  • 2: לא צוינו פעולות חוקיות. לדוגמה, אפשרות התקבלה בקשה.
  • 3: למשתמש אין קובץ Cookie של Google. Google לא להגדיר את קובץ ה-Cookie דרך שירות התאמת קובצי ה-Cookie.
  • 4: צוינו פעולות מתנגשות. אינך מורשה לציין גם את google_push וגם את google_cm דיווחים על אותה בקשה כי יש להם מטרות מתנגשות.
  • 5: פרמטר google_push לא חוקי היה מועברת בהפניה אוטומטית לשרת Google כחלק ממעבר דו-כיווני בקשה להתאמת פיקסלים. ההפניה האוטומטית חייבת להגדיר google_push לאותו ערך שהועבר אליכם בבקשת הפיקסל הראשונית.
  • 6: בתג ההתאמה צוין NID לא חוקי.
  • 7: זוהה קובץ Cookie לא חוקי.
  • 8: הוצא משימוש. לא נמצא קובץ Cookie.
  • 9: לא נמצא קובץ cookie. בוצע ניסיון להגדיר קובץ cookie לבדיקה.
  • 10: נעשה שימוש בפרמטר google_redir ללא ציון google_hm, או שנעשה בו שימוש בנוסף אל google_cm.
  • 15: הבקשה מגיעה מאזור שבו Google ההגדרה הזו מחייבת ש-Google תארח את טבלת ההתאמות. כתוצאה מכך, התגובה לא מכילה מזהה משתמש ב-Google. האפשרות הזו מופעלת כרגע עבור רק אחוז קטן מהתנועה, אבל הוא מתוכנן להפעלה מלאה של יוני 2020.
google_hm

מופיעה רק אם הניסיון לכתוב לטבלת ההתאמות שמתארחת ב-Google נכשל. במקרה כזה, הערך שלו הוא אחד מקודי הסטטוס הבאים:

  • 1 – אסור: הלקוח עדיין לא נכלל ברשימת ההיתרים של כתיבת רשומות של טבלת התאמות מתארחות.
  • 2 – שגיאת פענוח: ערך הפרמטר לא יכול להיות מפוענח.
  • 3 – המטען הייעודי (Payload) ארוך מדי: ערך הפרמטר מפוענח ל יותר מ-24 בייטים של נתונים.
  • 4 - שגיאה פנימית: אירעה שגיאה פנימית באחסון של הנתונים.
  • 5 – ויסות נתונים: הכתיבה הזו לא עברה עיבוד עקב ויסות נתונים (throttle).
google_ula

סטטוס פעולת הוספה של רשימת משתמשים, שחוזרת אם היא כוללת google_ula צוינו בבקשה. הפורמט הוא:
userlistid,status code

דוגמה: google_ula=1234567890,0

הפעולה google_ula יכולה להחזיר כל אחד מקודי הסטטוס הבאים:

  • 0 – אין שגיאה. המשתמש נוסף לרשימת המשתמשים.
  • 2 – ההרשאה נדחתה. אין לך הרשאה להוסיף משתמשים לרשימת המשתמשים הנתונה.
  • 5 – מזהה רשימת משתמשים שגוי. המזהה של רשימת המשתמשים שצוינה אינו חוקי.
  • 6 – מזהה המאפיין סגור. המזהה של רשימת המשתמשים שסופקה סגור.
  • 10 – שגיאה פנימית. שירות 'התאמת קובצי cookie' כולל אירעה שגיאה פנימית, אפשר לנסות להתאים שוב את המשתמש.

התרחישים הבאים מתארים איך התאמות של קובצי cookie עשויה להיראות עבור משתמש טיפוסי שגולש בדף אינטרנט.

תרחיש 1: משתמש מנקה את קובצי ה-Cookie וגולש באתר

דנה מנקה את המטמון של כל קובצי ה-Cookie. לאחר מכן הם נכנסים לדף הבית של ExampleNews.com.

הנה תיאור של התהליך:

  1. מערכת ExampleNews.com מבצעת רינדור וקוראת מודעות מ-Google (Ad Manager).
  2. מאחר שיחידת המודעות כשירה להקצאה דינמית, Google שולחת הצעת מחיר בקשות ל-FinestDSP ולמגישי הצעות מחיר אחרים דרך השירות 'בידינג בזמן אמת'.
  3. האפליקציה של מגיש הצעות המחיר ב-FinestDSP מקבלת ומעבדת את הבקשה להצעת מחיר. ושולח את התגובה שלו להצעת המחיר.
  4. Google מקבלת תגובות להצעות מחיר ממגישי הצעות המחיר, כולל התגובה של FinestDSP. מציין מודעה עם תג התאמה (פיקסל).
  5. FinestDSP זוכה במכרז. Google מציגה את המודעה והתג של FinestDSP רחל.
  6. תג ההתאמה קורא ל-Cookie Match Service של Google, ומציין את google_nid ו-google_cm.
  7. שירות התאמת קובצי ה-Cookie קורא את קובץ ה-Cookie של Google של דנה, ושולח את הפניה מחדש של הדפדפן לכתובת ה-URL של התאמת קובצי ה-Cookie של FinestDSP עם הוגדרו הפרמטרים google_user_id ו-google_cver.
  8. הדפדפן של דנה טוען את ההפניה האוטומטית לכתובת ה-URL של Cookie Match של FinestDSP.
  9. נקודת הקצה (endpoint) שתואמת לקובצי cookie של FinestDSP מעבדת את הבקשה להפניה אוטומטית, שכולל פרמטרים של כתובות אתרים שהוגדרו על ידי Google, ואת קובץ ה-cookie שלהם עבור דורית כותרות HTTP. FinestDSP יכול עכשיו לשמור את המיפוי של קובץ ה-cookie שלו google_user_id בטבלת ההתאמות שלהם.
  10. FinestDSP מגיב להפניה מחדש באמצעות פיקסל 1x1 בלתי נראה.
תרחיש 2: משתמש עם מיפוי קיים

שבוע אחרי תרחיש 1, דנה מבקרת שוב ב-ExampleNews.com. עכשיו, וג'יין כולל במחשב גם קובצי cookie של מגיש הצעות מחיר וגם קובצי cookie של Ad Manager. כך עובדת.

  1. דף האינטרנט עובר עיבוד, וגורם ל-Google (Ad Manager) לבקש מודעות יוצג בדף.
  2. במהלך המכרז של המודעות, Google שולחת בקשה להצעת מחיר למגישי הצעות המחיר הרלוונטיים, כולל FinestDSP.
  3. FinestDSP מקבל את הבקשה להצעת מחיר, כולל אותות כמו google_user_id
  4. FinestDSP מחפש את google_user_id בטבלת ההתאמות שלו, הוא מוצא את קובץ ה-cookie שמשויך ל'ג'יין' שנוצר שבוע לפני כן (בתרחיש 1).
  5. על סמך מידע המשויך לקובץ ה-cookie, הבידינג של FinestDSP לוגיקה מאפשרת להגיש הצעת מחיר לחשיפה, וזוכה במכרז.
  6. דנה עשויה לראות מודעה שמותאמת לתחומי העניין שלה, על סמך מידע שיש ב-FinestDSP.

התאמה חד-כיוונית של קובצי cookie דומה לתהליך העבודה הדו-כיווני, חוץ מזה, הוא משתנה כך שרק Google מארחת ומאכלסת התאמה טבלה. אפשר להשתמש באפשרות הזו במקרים שבהם מגיש הצעות המחיר לא מורשה לארח מזהי משתמשים של Google בטבלת התאמות משלהם. כדי להשתמש בתהליך הזה, מגישי הצעות המחיר חייב לאפשר ל-Google לארח את טבלת ההתאמות, לא יכול יותר לציין google_cm בבקשות לשירות התאמת קובצי ה-Cookie של Google, וגם כתוצאה מכך, לא יקבלו google_gid כדי לאכלס טבלת התאמות. לאחר ש-Google קובעת התאמה למשתמש, מגישי הצעות המחיר יכולים להוסיף אותם לרשימות משתמשים באמצעות נתוני קובצי cookie משלהם. באופן דומה, בקשות להצעות מחיר משתמשים אלה לא יכללו את מזהה המשתמש של Google, אבל יכללו נתוני התאמה מתארחים. א' דוגמה פשוטה של תהליך העבודה המתוקן מוצג סיכום בשלבים הבאים.

כדי להתחיל את התהליך הזה, מגיש הצעות המחיר חייב להציב תג התאמה. עוברים עיבוד בדפדפן של המשתמש. בניגוד לתהליך העבודה של משתמשים שלא מגיעים ממדינה בארה"ב שיש בה הגבלות על פרטיות, תג ההתאמה חייב להפנות את הדפדפן של המשתמש אל קובץ ה-Cookie כתובת URL תואמת. לדוגמה, באמצעות כתובת URL שתואמת לקובצי Cookie, שהוגדרה כך: https://ad.network.com/pixel, נראה כך:

<img src="https://ad.network.com/pixel" />

במהלך הטעינה בדפדפן של המשתמש, תישלח בקשה לפיקסל כתובת URL תואמת של קובצי Cookie. הבקשה הזו תכיל את קובץ ה-cookie בכותרת ה-HTTP, שיש לחלץ בשלב הבא.

נקודת הקצה (endpoint) התואמת לקובצי cookie של מגיש הצעות המחיר חייבת להפנות מחדש לקובץ cookie של Google שירות תואם, כולל הפרמטר google_hm שאוכלס ב- את נתוני קובצי ה-cookie שלהם בקידוד base64, הבטוחים באינטרנט. כתובת ה-URL להפניה אוטומטית עשויה להיראות כך הבאים:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

Google תקבל כתובת אתר להפניה מחדש שמכילה את הפרמטרים שציינת, נוסף ל-cookie של Google בכותרות ה-HTTP.

שלב 4: Google מציגה פיקסל להצלחה או הפניה אוטומטית לשגיאה אם צוינה כתובת ה-URL של הדוח

אם פעולת ההתאמה של קובצי cookie מצליחה, או אם לא, קובצי cookie צוינה כתובת URL תואמת של הדוח עבור החשבון של מגיש הצעות המחיר – Google כברירת מחדל יוצג פיקסל שקוף בגודל 1x1, ותהליך העבודה יסתיים כאן. החשיפות שיוצגו למשתמש הזה בבקשות הבאות להצעות מחיר יכללו את נתוני משחק מתארחים ב-BidRequest.hosted_match_data עבור Google פרוטוקול, או BidRequest.user.buyeruid ל-OpenRTB של Google יישום בפועל. מגישי הצעות המחיר יכולים גם לאכלס רשימות משתמשים באמצעות נתוני ההתאמה המתארחים. שהם ציינו.

אחרת, במקרה של שגיאה, Google תשלח כתובת אתר להפניה מחדש של מגיש הצעות המחיר כתובת האתר של הדוח 'התאמה של קובץ cookie' עם הסיבה לשגיאה שצוינה הפרמטר google_error. אם כתובת ה-URL של דוח התאמת קובצי Cookie למגיש הצעות המחיר היו https://ad.network.com/report, כתובת ה-URL להפניה אוטומטית תיראה כמו:

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

הדפדפן של המשתמש יפנה לכתובת ה-URL של 'דוח התאמת קובצי Cookie' של מגיש הצעות המחיר. כולל סיבת השגיאה (אם קיימת) שצוינה על ידי Google הפרמטר google_error. מידע נוסף על פירוש השגיאה את התג, ראו את תיאור הפרמטר.

שלב 6: מגיש הצעות המחיר מציג פיקסל שקוף בגודל 1x1

מגיש הצעות המחיר חייב להגיב על ידי הצגת פיקסל שקוף בגודל 1x1 בדפדפן.

תהליך העבודה שמוגדר כברירת מחדל למשתמשים במדינות בארה"ב עם הגבלות על פרטיות מודגם בתרשים שבה הבקשות והתשובות מיוצגות על ידי חץ, והנתונים פריטים שנלווים אליהם מופיעים בסוגריים.

פרמטר תיאור
google_nid מזהה הרשת (NID) של החשבון של מגיש הצעות המחיר. אפשר לאחזר את המזהה הזה דרך מגישי הצעות המחיר משאב.
google_sc הפרמטר הזה הוצא משימוש. מגדיר את קובץ ה-Cookie של Google עבור משתמש אם אין מזהה. המערכת מתעלמת מערך הפרמטר, והוא עלול חייב להשמיט. אם לא כוללים קובץ cookie, הדבר יגרום לשגיאה קיים.
google_no_sc הפרמטר הזה הוצא משימוש. זה מצביע על שירות התאמת קובצי cookie לא אמור להגדיר קובץ cookie למשתמש אם אחד מהם לא קיים. המערכת מתעלמת מערך הפרמטר, והוא יכול להיות שהושמט.
google_hm

מכיל נתונים שמגיש הצעות המחיר רוצה לשמור בהתאמה שמתארחת ב-Google טבלה.
google_redir כתובת URL מקודדת שרוצים ש-Google תשלח לה הפניה אוטומטית מסוג HTTP 302. כתובת ה-URL שצוינה תקבל הפניות אוטומטיות עם המאפיין google_error גם לשגיאות וגם לפעולות מוצלחות.
google_ula מחרוזת שמשמשת להוספת המשתמש לרשימת משתמשים קיימת. הערך הפורמט הצפוי הוא userlistid[,timestamp]:
  • userlistid: מזהה של רשימת משתמשים מספרית אחת.
  • timestamp: חותמת זמן אופציונלית בפורמט POSIX. מציין מתי המשתמש נוסף לרשימת המשתמשים.

ניתן לחזור על הפרמטר הזה של כתובת אתר כדי להוסיף את המשתמש לכמה רשימות.
gdpr מציין שהבקשה כפופה להגבלות של GDPR על נתונים בשימוש. פרטים נוספים זמינים במאמר הדרישות בנושא הסכמת משתמשים באיחוד האירופי שמפורטות בהמשך, או ההשפעה על התאמה של קובצי cookie זכאות בתנאים מסמכי תיעוד בנושא TCF גרסה 2.0 של Authorized Buyers.

לדוגמה: gdpr=1
gdpr_consent מחרוזת נתוני שקיפות והסכמה שמייצגת את ההסכמה ממשתמשי הקצה. לפרטים נוספים, אפשר לקרוא את הדרישות לקבלת הסכמת משתמשים באיחוד האירופי. למטה, או איך המחרוזת של נתוני השקיפות וההסכמה תועבר? בקטע מסמכי תיעוד בנושא TCF גרסה 2.0 של Authorized Buyers.
process_consent מציין שמגיש הצעות המחיר קיבל הסכמה ממשתמשי הקצה לשימוש בנתונים שצוינו ב מדיניות Google בנושא הסכמת משתמשים באיחוד האירופי.

אם הבקשה לא כפופה למדיניות Google בנושא הסכמת משתמשים באיחוד האירופי, או אם יש האם פרמטרים אחרים של הסכמה זמינים בבקשה? (gdpr_consent), המערכת תתעלם מהפרמטר הזה.

לדוגמה: process_consent=T
פרמטר תיאור
google_error

ערך מסוג מספר שלם שמציין את השגיאה הכוללת בבקשה. מתי הוא מציין שלא בוצעו פעולות יוגדרו google_ פרמטרים של תשובות. השגיאה הנתמכת כוללים את הערכים הבאים:

  • 1: למשתמש יש קובץ Cookie של Google, אבל הוא ביטל את ההסכמה לשימוש בקובצי Cookie מעקב באמצעות קובץ ה-Cookie הזה.
  • 2: לא צוינו פעולות חוקיות. לדוגמה, אפשרות התקבלה בקשה.
  • 3: למשתמש אין קובץ Cookie של Google. Google לא להגדיר את קובץ ה-Cookie דרך שירות התאמת קובצי ה-Cookie.
  • 4: צוינו פעולות מתנגשות. אינך מורשה לציין גם את google_push וגם את google_cm דיווחים על אותה בקשה כי יש להם מטרות מתנגשות.
  • 5: פרמטר google_push לא חוקי היה מועברת בהפניה אוטומטית לשרת Google כחלק ממעבר דו-כיווני בקשה להתאמת פיקסלים. ההפניה האוטומטית חייבת להגדיר google_push לאותו ערך שהועבר אליכם בבקשת הפיקסל הראשונית.
  • 6: בתג ההתאמה צוין NID לא חוקי.
  • 7: זוהה קובץ Cookie לא חוקי.
  • 8: הוצא משימוש. לא נמצא קובץ Cookie.
  • 9: לא נמצא קובץ cookie. בוצע ניסיון להגדיר קובץ cookie לבדיקה.
  • 10: נעשה שימוש בפרמטר google_redir ללא ציון google_hm, או שנעשה בו שימוש בנוסף אל google_cm.
  • 15: הבקשה מגיעה מאזור שבו Google ההגדרה הזו מחייבת ש-Google תארח את טבלת ההתאמות. כתוצאה מכך, התגובה לא מכילה מזהה משתמש ב-Google. האפשרות הזו מופעלת כרגע עבור רק אחוז קטן מהתנועה, אבל הוא מתוכנן להפעלה מלאה של יוני 2020.

ביוזמת Google: התאמת Pixel דו-כיוונית

התאמת Pixel דו-כיוונית היא תהליך עבודה להתאמת קובצי cookie של Google שירות שבו Google מנסה להתאים בין מזהה המשתמש של Google לבין מזהה אלגוריתמי מגיש הצעות המחיר שנבחר מלבד הזוכה במכרז 'בידינג בזמן אמת'. כאשר מודעה הוצב, Google תציב תג התאמה שינחה את הדפדפן של המשתמש לטעון פיקסל שקוף מכתובת ה-URL של התאמת קובצי Cookie של מגיש הצעות המחיר שנבחר. הפעולה הזו תאפשר גם Google וגם מגיש הצעות המחיר כדי לאכלס טבלת התאמות במשתמש נתון. בהמשך מופיע דוגמה פשוטה לתהליך העבודה הזה.

שלב 1: Google מציבה תג התאמה

כשדף של בעל אתר שמשתתף בתוכנית נטען בדפדפן של המשתמש, מיקום המודעה בדף זה ממלא על ידי Google, ניתן להציב תג התאמה מבקש פיקסל ממגיש הצעות מחיר שנבחר באמצעות אלגוריתם. התאמת ה-Pixel שהוצב על ידי Google משלב את כתובת האתר של 'התאמת קובצי cookie' של מגיש הצעות המחיר עם פרמטרים נוספים מגיש הצעות המחיר יכול להשתמש בו כדי לאכלס את טבלת ההתאמות שלו. עבור כתובת URL תואמת של קובצי cookie צוין כ-https://ad.network.com/pixel, המבנה שלו הוא ככה:

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

מגישי הצעות מחיר שמקבלים בקשות להתאמת פיקסלים נדרשים להשיב עם הפניה אוטומטית לשירות התאמת קובצי ה-Cookie של Google, שבנוי באופן הבא:

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

שימו לב שכתובת ה-URL להפניה אוטומטית שלמעלה דומה לכתובת ה-URL שבה אתם משתמשים להתאים את התג לתהליך העבודה של התאמת קובצי cookie שמופעלת על ידי מגיש הצעות המחיר. בהתאמת Pixel, הפרמטר google_cm מוחלף ב- הפרמטר google_push, והערך שלו חייב להיות שווה לערך. שסופקה על ידי Google בבקשה. דומה גם לשיטה של מגיש הצעות המחיר תהליך עבודה, פרמטרים נוספים כדי למלא תרחישים לדוגמה נוספים.

שלב 3: Google מעבדת את ההפניה האוטומטית ומגיבה עם פיקסל

Google מתעדת שנוצרה התאמה למשתמש, ומטפלת בכל פעולות נוספות המבוקשות באמצעות פרמטרים של שאילתה. לבסוף, Google מגיבה עם פיקסל שקוף בגודל 1x1.

תרשים תהליך עבודה של התאמת Pixel

תהליך העבודה הזה מאויר באמצעות התרשים הבא, שבו בקשות תשובות מיוצגות בחץ, ופריטי הנתונים הנלווים אליהן מופיעים בסוגריים.

פרמטרים של בקשות ל-Google Match Tag

פרמטר תיאור
google_gid מזהה משתמש של Google. עבור משתמשים שלא נמצאים במדינה בארה"ב שיש בה הגבלות על פרטיות, ההגדרה תהיה תמיד מצוין בתג ההתאמה של Google.
google_cver גרסת קובץ ה-cookie. זה תמיד יצוין בהתאמה של Google התיוג.
google_push מציין שהבקשה הזו מתחילה את תהליך העבודה של התאמת Pixel. הערך חייב להיות מוחזר דרך הפרמטר התואם של מגיש הצעות המחיר עם הפניה אוטומטית.

פרמטרים של הפניה אוטומטית לפיקסלים של מגיש הצעות המחיר

פרמטר תיאור
google_nid מזהה הרשת (NID) של החשבון של מגיש הצעות המחיר. אפשר לאחזר את המזהה הזה דרך מגישי הצעות המחיר משאב.
google_push מציין שההפניה הזו משלימה את התאמת ה-Pixel בתהליך העבודה. הערך מתג ההתאמה של Google התואם חייב להיות שצוינו כאן.
google_hm

מכיל נתונים שמגיש הצעות המחיר רוצה לשמור בהתאמה שמתארחת ב-Google טבלה.
google_ula מחרוזת שמשמשת להוספת המשתמש לרשימת משתמשים קיימת. הערך הפורמט הצפוי הוא userlistid[,timestamp]:
  • userlistid: מזהה של רשימת משתמשים מספרית אחת.
  • timestamp: חותמת זמן אופציונלית בפורמט POSIX. מציין מתי המשתמש נוסף לרשימת המשתמשים.

ניתן לחזור על הפרמטר הזה של כתובת אתר כדי להוסיף את המשתמש לכמה רשימות.

ביוזמת Google: התאמת פיקסלים חד-כיוונית

התאמת Pixel חד-כיוונית שונה מתהליך העבודה הדו-כיווני תג ההתאמה של Google לא כולל פרמטר שמציין את משתמש Google מזהה, אבל ימשיך לאכלס טבלת התאמות שמתארחת ב-Google. אפשר להשתמש בערך הזה במקרים שבהם מגיש הצעות המחיר לא מורשה לארח מזהי משתמשים של Google טבלת התאמות משלו. דוגמה פשוטה לתהליך העבודה המתוקן מופיעה סיכום בשלבים הבאים.

שלב 1: Google מציבה תג התאמה

Google מציבה תג התאמה למגיש הצעות מחיר שנבחר באמצעות אלגוריתם. תג ההתאמה כולל את הקטע הפרמטר google_push. לדוגמה:

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

שלב 2: הדפדפן של המשתמש מבקש פיקסל מכתובת ה-URL של מגיש הצעות המחיר להתאמת בישול

הדפדפן של המשתמש מבקש פיקסל מכתובת ה-URL של התאמת קובצי Cookie של מגיש הצעות המחיר. כולל קובץ ה-cookie של מגיש הצעות המחיר בכותרות ה-HTTP.

נקודת הקצה (endpoint) התואמת לקובצי cookie של מגיש הצעות המחיר חייבת להפנות מחדש לקובץ cookie של Google שירות תואם, כולל הפרמטר google_hm שאוכלס ב- את נתוני קובצי ה-cookie שלהם בקידוד base64, הבטוחים באינטרנט. כתובת ה-URL להפניה אוטומטית עשויה להיראות כך הבאים:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

Google תקבל כתובת אתר להפניה מחדש שמכילה את הפרמטרים שציינת, נוסף ל-cookie של Google בכותרות ה-HTTP. אם הפעולה הייתה החשיפות של משתמש זה בבקשות הבאות להצעות מחיר יכללו נתוני ההתאמה המתארחת של מגיש הצעות המחיר בBidRequest.hosted_match_data למשך לפרוטוקול Google, או BidRequest.user.buyeruid עבור הטמעת OpenRTB. מגישי הצעות המחיר יכולים גם לאכלס רשימות משתמשים באמצעות להתאים נתונים שהם ציינו.

לבסוף, Google מחזירה פיקסל שקוף בגודל 1x1 לדפדפן של המשתמש.

התכונה Open Bidding מאפשרת לשותפי פרסום להשתמש ביוזמת מגיש הצעות מחיר וביוזמת Google תהליכי עבודה להתאמת קובצי cookie, כדי להתאים בין ה-User-ID של Google לקובץ ה-cookie שלהם. קובץ Cookie Match Assist (CMA) הוא תכונה נוספת שמיועדת לרשתות Exchange, שמאפשרת להן ליצור טבלאות של התאמות עם מגישי הצעות מחיר משלהם.

  1. כשמציבים מודעה, Google בוחרת באמצעות אלגוריתם Exchange ומציב תג Cookie Match Assist שמכיל את מבנה:

    <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>

  2. תג ההתאמה של CMA של Google גורם לכתובת ה-URL של התאמת קובצי cookie של פלטפורמת ה-Exchange לקבל בקשה לפיקסל.

  3. נקודת הקצה של 'התאמת קובצי cookie' של ה-Exchange מקבלת את הבקשה, כאשר שירות התאמת קובצי Cookie משלו אחראי להתאמה של מזהה המשתמש עם אחד ממגישי הצעות המחיר. בתרשים הבא, התאמות קובצי ה-Cookie של הבורסה מגיב לדפדפן של המשתמש בהפנייה מחדש לאחד נקודות קצה (endpoints).
  4. מגיש הצעות המחיר מקבל את הבקשה, יחד עם כל הפרמטרים שצוינו על ידי פלטפורמת ה-Exchange להתאים בין מזהה המשתמש לקובץ ה-cookie שלו.

הגבלות

מכסת התדירות של הבקשות להתאמות חדשות

מגישי הצעות המחיר אחראים להגביל את מספר הקריאות לקובץ ה-cookie שירות התאמה למשתמשים שיש להם רשומה חדשה בהתאמה שמתארחת ב-Google טבלה. רשומה בטבלת ההתאמות המתארחת עשויה להיחשב כפג תוקף בעוד 14 יום, ולאחר מכן אפשר לרענן אותו.

תגובה לכל הבקשות להתאמת פיקסלים

מגישי הצעות מחיר שמשתמשים בתהליך העבודה של התאמת Pixel צפויים להגיב לכל בקשות נכנסות של Pixel Match עם תשובה, כולל google_push הפרמטר. כך Google יכולה לאכוף את המדיניות על ידי מעקב אחר השימוש. אם שיעור התגובה של מגיש הצעות המחיר יורד מתחת ל-90%, Google תצמצם את מספר בקשות Pixel Match נשלחו לחשבון שלהם.

שימוש בנקודות קצה (endpoint) HTTPS

צריך להגדיר נקודות קצה (endpoints) שבהן נעשה שימוש בכל תהליכי העבודה של התאמות קובצי cookie HTTPS.

כשמשיבים לבקשת Pixel Match שנשלחה אליך באמצעות HTTPS, נדרש להפנות מחדש לשירות התאמת קובצי cookie ב-HTTPS. באופן דומה, נקודת קצה של Cookie Match Assist שמפנה למגישי הצעות מחיר גם כן חייבת להשתמש ב-HTTPS. אם שולחים ל-Google בקשות ב-HTTP בתדירות גבוהה יותר מפעם ב-2 דקות, מספר בקשות ההתאמה שנשלחות לחשבון שלכם יוגבל.

הבקשות להתאמות של קובצי Cookie כפופות ל- משתמש Google באיחוד האירופי המדיניות בנושא הסכמה צריכה לכלול מידע על הסכמה של משתמשי קצה. בקשות כאלה נדרשות מציין שקיבלתם הסכמה באחת מהדרכים הבאות:

דוגמאות

הדוגמאות הבאות ממחישות איך להשתמש בשירות התאמות של קובצי cookie כדי להשיג יעדים ספציפיים. לתשומת ליבך, אלא אם צוין אחרת, להניח שהמשתמש שעליו מבוצעת פעולה הוא לא מדינה בארה"ב עם הגבלות על פרטיות.

אכלוס טבלת התאמות שמתארחת אצל מגיש הצעות המחיר

מגיש הצעות מחיר יכול להשתמש בתהליך העבודה של התאמת קובצי cookie כדי לאכלס את ההתאמה שלו הטבלה באמצעות לספק רק את הערכים google_nid ו-google_cm בפרמטרים בתג ההתאמה שלהם. הדוגמה הזו יכולה להיראות כך:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

אם כתובת ה-URL של התאמת קובצי Cookie של מגיש הצעות המחיר מוגדרת ל-https://ad.network.com/pixel?id=1, ופעולת ההתאמה של קובצי ה-cookie בוצעה בהצלחה, ההפניה האוטומטית ש-Google שולחת התגובה לתג ההתאמה של מגיש הצעות המחיר עשויה להיראות כך:

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

אם פעולת ההתאמה של קובצי cookie נכשלת מכיוון שלמשתמש אין קובץ ה-Cookie של Google, התגובה תהיה:

https://ad.network.com/pixel?id=1&google_error=3

קוד השגיאה תלוי בסיבה הבסיסית לשגיאה. למידה לקבלת מידע נוסף על קודי שגיאה אפשריים בתהליך העבודה של התאמת קובצי cookie, אפשר לעיין במאמר פרמטרים של כתובות URL להפניה אוטומטית.

הוספה לרשימת משתמשים יחידה

ניתן לציין את הפרמטר google_ula בהתאמה של מגיש הצעות מחיר כדי להוסיף את המשתמש לרשימת משתמשים עם המזהה הנתון. אם Google לטבלת התאמות שמתארחות אצל מגיש הצעות המחיר יש ערך חדש למשתמש, מגיש הצעות המחיר יכול להציב תג התאמה שכולל את google_nid ואת google_ula פרמטרים להוספת המשתמש לרשימה שצוינה בלי להתחיל את התהליך תהליך עבודה של התאמת קובצי Cookie. לעיון בהגבלות בהפעלת שירות התאמת קובצי ה-Cookie לדברים נוספים. הערכים המתאימים תג התאמה עשוי להיראות כך:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

לקבלת תגובה מוצלחת, שבה כתובת ה-URL של 'התאמת קובצי cookie' של מגיש הצעות המחיר היא https://ad.network.com/pixel, כתובת ה-URL להפניה אוטומטית של Google תהיה:

https://ad.network.com/pixel?google_ula=12345,0

אם יש שגיאה כללית – לדוגמה, אין קובץ Cookie של Google למשתמש — כתובת ה-URL להפניה אוטומטית תכלול את הפרמטר google_error:

  • https://ad.network.com/pixel?google_error=3

אם קיימת שגיאה ספציפית בנוגע להוספת המשתמש לרשימה, תקבל את הערך google_ula בהפניה האוטומטית. בניגוד ל- פרמטר תואם של תג התאמה, הוא מחליף את חותמת הזמן בסטטוס כדי לציין את הצלחת הפעולה. לדוגמה, אם הבקשה נכשלה בגלל שלחשבון מגיש הצעות המחיר לא הייתה גישה לרשימת המשתמשים שצוינה, כתובת ה-URL להפניה אוטומטית תהיה:

https://ad.network.com/pixel?google_ula=12345,2

הוספה למספר רשימות משתמשים

מגישי הצעות המחיר יכולים לציין שמשתמש יתווסף לכמה רשימות משתמשים על ידי כולל מספר פרמטרים של google_ula בתג ההתאמה. לחשבון יכול להיראות כך:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

סטטוס הפעולה של כל רשימת משתמשים מדווח באופן דומה באמצעות פרמטרים ייחודיים מסוג google_ula בהפניה האוטומטית:

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

בהפניה מחדש שלמעלה, ניתן לראות שהפעולה הצליחה עבור המשתמש רשימה עם המזהה 45678, אך הפעולה נכשלה עבור מזהה רשימת המשתמשים 12345 כי למגיש הצעות המחיר לא הייתה הרשאה לגשת אליו.

כדי לבצע התאמות של קובצי cookie ולהוסיף את המשתמש לרשימת משתמשים בחשבון אחד בקשה, תג ההתאמה של מגיש הצעות המחיר צריך לכלול google_cm ו- google_ula:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

כתובת ה-URL להפניה אוטומטית שצוינה על ידי Google תכלול את google_gid, google_cver ו-google_ula. כתובת ה-URL הזו עשויה להיראות כמו הבאים:

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

אחסון משחק בטבלת התאמות שמתארחת ב-Google

אם מגיש הצעות מחיר רוצה לאחסן את נתוני קובצי ה-Cookie שלו בטבלת התאמות שמתארחת ב-Google, הוא לא מתכוון לשמור התאמה עם מזהה המשתמש של Google בהתאמה שלו טבלה, תג ההתאמה שלו חייב לכלול את הפרמטר google_hm כאשר הערך שלו חייב להיות מחרוזת בקידוד base64 שמתאימה לאינטרנט. עבור משתמש שבו נתוני קובצי ה-cookie הלא מקודדים של מגיש הצעות המחיר הם Cookie number 1!, הוא Q29va2llIG51bWJlciAxIQ==, וצריך להשתמש בו תואם לתג כמו בדוגמה הבאה:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

לקבלת תגובה מוצלחת, שבה כתובת ה-URL של 'התאמת קובצי cookie' של מגיש הצעות המחיר היא https://cookie-monster.com/pixel, כתובת ה-URL להפניה אוטומטית של Google להיות:

https://cookie-monster.com/pixel

הפרמטר google_gid לא נמצא בהפניה האוטומטית כי תג ההתאמה לא כלל את google_cm, והתג google_hm הוא לא נכלל בתשובות מוצלחות. בבקשות עתידיות להצעות מחיר על חשיפות לגבי משתמש זה, מגיש הצעות המחיר יקבל את נתוני ההתאמה המתארחים שלו BidRequest.hosted_match_data לפרוטוקול RTB של Google, או BidRequest.user.buyeruid להטמעת OpenRTB של Google.

אם מגיש הצעות המחיר השתמש במקום זאת בתג התאמה שבו הערך של google_hm לא היה בקידוד base64 — כמו chocolate_chunk! - כתובת ה-URL להפניה אוטומטית עשויה להיראות כך הבאים:

https://cookie-monster.com/pixel?google_hm=2

כתובת ה-URL להפניה אוטומטית שלמעלה כוללת ערך google_hm של 2, פעולה שמרמזת על כך שהפעולה נכשלה כי הערך לא מפוענח.

טבלאות של התאמות של מגישי הצעות מחיר ושל Google שמתארחות ב-Google, עם רשימות משתמשים

אם מגיש הצעות המחיר מארח רשימת שימוש משלו, בנוסף למשתמש שמתארח ב-Google רוצה תג התאמה יחיד שיתאים לשתי הטבלאות ויוסיף את המשתמש ברשימת משתמשים נתונה, תג ההתאמה שלהם חייב לכלול את הפרמטר google_cm, הפרמטרים google_hm ו-google_ula. אם מגיש הצעות המחיר הנתונים של קובצי ה-cookie הם Cookie number 1!, הערך המקודד יהיה Q29va2llIG51bWJlciAxIQ==, שיפיק תג התאמה כמו הבאים:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

לקבלת תגובה מוצלחת, שבה כתובת ה-URL של 'התאמת קובצי cookie' של מגיש הצעות המחיר היא https://cookie-monster.com/pixel, כתובת ה-URL להפניה אוטומטית של Google ייראה כך:

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

עם קבלת ההפניה האוטומטית, מגיש הצעות המחיר יכול להתאים למזהה המשתמש ב-Google שצוין ב-google_gid ונתוני קובצי ה-cookie שלהם בטבלת ההתאמות. לחשבון בנוסף, הם יכולים לקבוע שטבלת ההתאמות שמתארחת ב-Google ורשימת המשתמשים התפעוליים הצליחו. כתוצאה מכך, כל טירגוט מראש של מגיש הצעות המחיר שהוגדר לטרגט למזהה של רשימת המשתמשים שצוין, יגרום עכשיו למגיש הצעות המחיר לקבל בקשות להצעות מחיר עבור חשיפות מהמשתמש. באופן דומה, בהצעות מחיר כאלה בקשות, מגיש הצעות המחיר יקבל את נתוני ההתאמה המתארחים שלו BidRequest.hosted_match_data לפרוטוקול RTB של Google, או BidRequest.user.buyeruid להטמעת OpenRTB של Google.