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

ברמה הכללית, התאמה של קובצי cookie היא התהליך שבו מפרסם או ספק משייכים קובצי cookie בדומיין שלהם לקובצי cookie בדומיין של Google. התאמה של קובצי ה-cookie האלה מאפשרת לכם לחבר לאותו המשתמש נתונים מאינטראקציה ישירה (First-Party) שנמצאים בבעלותכם אל נתוני מודעות Google (המעקב אחר הנתונים מתבצע באמצעות Display & Video 360 ו-Campaign Manager 360) באותו משתמש. כך תוכלו לשלב נתונים ממערכת ניהול קשרי הלקוחות (CRM) ולהבין טוב יותר את התנהגות המשתמשים. בעזרת שילוב של הנתונים האלה בעזרת שאילתות איחוד (join) שמתמקדות בפרטיות, תוכלו:

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

מגבלות ופרטיות משתמשי הקצה

למרות שהתאמה של קובצי cookie היא יעילה, יש כמה מגבלות:

  • אין לצרף בין טבלאות *_match לבין טבלאות שאינן *_match.
  • נדרשת עבודת הנדסה גם מכם וגם מ-Google.
  • סביר להניח שלא תוכלו להתאים את כל הנתונים של מודעות Google שלכם. שיעורי ההתאמה כפופים למספר גורמים, ומשתנים בהתאם לתרחיש לדוגמה ולהגדרה בצד הלקוח. לרוב, אחוזי הלקוחות לטירגוט נמוכים מהצפוי. המשתמשים יכולים לבצע התאמות של קובצי Cookie רק אם הם קיימו אינטראקציה עם הדומיין שלכם ועם המודעות שלכם.
  • Google תתחיל לאכלס את טבלאות ההתאמות אחרי שהן יהיו מוכנות. בהתאם לתדירות שבה משתמשים נכנסים לאתר ומקבלים את הפיקסל התואם, יכול להיות שיחלפו כמה חודשים עד שטבלאות ההתאמות יכללו נתונים מקיפים ויציבים על המשתמשים.
  • לא תהיה לך אפשרות לשייך משתמשים ספציפיים למספר מכשירים, אלא אם יש לך דרך כלשהי לחבר משתמשים בין מכשירים.
  • אי אפשר לבצע התאמה למשתמש יחיד באמצעות מספר קובצי cookie, כפי שקורה כשמשתמש מוחק את קובצי ה-cookie שלו.
  • משימות שפועלות בטבלאות של התאמות כפופות לאותן דרישות צבירה כמו משימות אחרות ב-Ads Data Hub. שיעור נמוך של בקשות שמולאו, בשילוב עם ביקורים לא תכופים בדומיין שלכם, עלול להוביל לקשיים בהשגת נתונים. הסיבה לכך היא ההשפעה המשולבת של אחוזי הלקוחות לטירגוט ודרישות הצבירה1.
  • בהתאם למדיניות של Google בנושא פרטיות משתמשי הקצה:
    • נאסר להתאים בין נתונים של משתמשים מחוברים ולא מחוברים.
    • לא יכולים להתאים נתונים למשתמשים שביטלו את הסכמתם להתאמה אישית של מודעות.
  • לגבי אירועים ב-iOS, אפשר להתאים רק נתונים שמקורם באפליקציות ב-iOS 14.5 ואילך רק ממשתמשים שהעניקו הרשאה במסגרת App Tracking Transparency של Apple.

כדי שתהיה לכם אפשרות להשתמש בנתונים מאינטראקציה ישירה (First-Party) ב-Ads Data Hub, אתם צריכים לאשר שקיבלתם את ההסכמה המתאימה לשיתוף נתונים ממשתמשי קצה באזור הכלכלי האירופי עם Google, בהתאם למדיניות Google בנושא הסכמת משתמשים באיחוד האירופי ולמדיניות של Ads Data Hub. הדרישה הזו חלה על כל חשבון Ads Data Hub, וצריך לעדכן אותה בכל פעם שמעלים נתונים חדשים מאינטראקציה ישירה (First-Party). כל משתמש יכול לאשר את ההודעה בשם החשבון כולו.

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

במאמר הדרישות לקבלת הסכמה באזור הכלכלי האירופי מוסבר איך מאשרים את ההסכמה ב-Ads Data Hub.

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

תג ההתאמה הוא פיקסל 1x1 שקוף שמכיל את מזהה הפרופיל התואם של קובץ ה-cookie ומזהה מקודד של משתמש או קובץ cookie:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm=Q29va2llIG51bWJlciAxIQ" />

תג ההתאמה הזה הוא שיוצר תקשורת בינך לבין שירותי התאמת קובצי ה-cookie של Google.

סקירה כללית מפורטת

  1. משתמש מבקר בדף עם תג התאמה.
  2. תג ההתאמה מפעיל סדרה של הפניות אוטומטיות לשירותי ההתאמה של Google Marketing Platform, Google Ads ו-YouTube. הבקשות כוללות את המזהה של המשתמש הזה או את קובץ ה-cookie מהאתר שלכם, וגם את קובץ ה-Cookie של Google בכל אחד מהמרחבי המזהים של השירות התואם.
  3. פיקסל 1x1 שקוף מוחזר לדפדפן כדי לאשר שהבקשה מולאה.

התהליך הזה מוצג בתרשים הבא:

תמונה שמתארת סדרה של הפניות מחדש בין הדפדפן לשירותים תואמים

הגדרה

כך מגדירים התאמות של קובצי cookie ב-Ads Data Hub:

  1. פנו לאיש הקשר האחראי לחשבון שלכם ודווחו על העניין שלכם בהתאמת קובצי cookie. הם ידונו ביעדים שלכם ויספקו לכם מידע נוסף על פריסת הפיקסל למעקב בדומיין שלכם.
  2. מומחי Ads Data Hub יפתחו שיחה נוספת כדי לדון בדרישות הטכניות ובתרחישי השימוש.
  3. בזמן שאתם פורסים את פיקסל המעקב ואת נקודת הקצה של השגיאות, Google תיצור את טבלאות ההתאמות שלכם.

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

שליחת שאילתה על טבלאות ההתאמות

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

הטבלה המקורית של נתונים מאינטראקציה ישירה (1PD) מיוצגת על ידי my_data. המידע הזה כולל פרטים אישיים מזהים (PII) וגם נתונים שאינם פרטים אישיים מזהים (PII). השימוש בטבלה המקורית יכול לשפר את הדוחות בעזרת יותר תובנות, כי היא מייצגת את כל הנתונים מאינטראקציה ישירה (First-Party) בהיקף, בהשוואה לטבלה של _match.

לכל טבלה בסכימת Ads Data Hub שמכילה את השדה user_id יש טבלה *_match. לדוגמה, לטבלה adh.google_ads_impressions, מערכת Ads Data Hub יוצרת גם טבלת התאמות בשם adh.google_ads_impressions_match שמכילה את מזהי המשתמשים. טבלאות התאמה נפרדות נוצרות לטבלאות מבודדות מדיניות. לדוגמה, לטבלה adh.google_ads_impressions_policy_isolated_youtube, מערכת Ads Data Hub תיצור גם טבלת התאמות בשם adh.google_ads_impressions_policy_isolated_youtube_match שמכילה את מזהי המשתמשים.

הטבלאות האלה מכילות קבוצת משנה של המשתמשים שזמינים בטבלאות המקוריות, שבהן יש התאמה ב-user_id. לדוגמה, אם הטבלה המקורית מכילה נתונים לגבי משתמש א' ומשתמש ב', אבל יש התאמה רק למשתמש א', משתמש ב' לא יופיע בטבלת ההתאמות.

בטבלאות ההתאמות יש עמודה נוספת בשם external_cookie, שמאחסנת את קובץ ה-cookie כ-ONIX.

חשוב לקחת בחשבון את סוג השדה כשכותבים את השאילתות. אופרטורים להשוואה של SQL מצפים שהליטרליות שאתם משווים יהיו מאותו הסוג. בהתאם לאופן שבו user_id מאוחסן בטבלת הנתונים מאינטראקציה ישירה, יכול להיות שתצטרכו לקודד את הערכים בטבלה לפני התאמת הנתונים. כדי שההתאמות יהיו מוצלחות, צריך להעביר (cast) את מפתח ההצטרפות אל BYTES:

JOIN ON
  adh.google_ads_impressions_match.external_cookie = CAST(my_data.user_id AS BYTES)

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

מזהי משתמשים בקידוד

קידוד מזהי משתמשים בצד הלקוח

כדי להבטיח שניתן להעביר פורמטים שונים של מזהים באופן בטוח באמצעות כתובת URL, כל המזהים צריכים להיות בקידוד Base64 שבטוח לכתובות URL לפני שהם נשלחים. המזהה המפוענח מסוג Base64, הבטוח לשימוש בכתובות URL, יהיה זמין ב-Ads Data Hub בשדה external_cookie, כך שצריך לבטל את הטרנספורמציות שהחלת לפני הקידוד כדי להסיק את המזהה המקורי.

אם המזהה הוא תמיד באורך 24 תווים (או בייטים) או פחות, ניתן לכלול בפיקסל את המזהה בקידוד Base64, הבטוח לשימוש בכתובת ה-URL, כפי שמוצג בדוגמה 1. אם המזהה ארוך מ-24 תווים (או בייטים), תצטרכו להמיר אותו לייצוג שגודלו 24 בייטים או פחות. במקרים מסוימים (כמו ב-GUID בדוגמה 2), מדובר בהמרה לייצוג בבייטים. במקרים אחרים, יכול להיות שתצטרכו לשלוח ל-Google קבוצת משנה (או גיבוב) של המזהה. שימו לב שבכל מקרה, צריך לוודא שאפשר לכתוב join של SQL שימיר את המזהה בטבלת הצד הראשון באותו אופן.

דוגמה 1

ערך User ID שלך תמיד יהיה נמוך ממגבלת האורך של 24 בייטים. ההמלצה של Ads Data Hub היא לשלוח את ה-User-ID ישירות אל ADH (אחרי שמקודדים אותו ל-Base64 שהוא בטוח לכתובת URL, למטרות העברה של כתובות URL).

var userId = 'abcdef123456789';
// Encode the string (or number) in normal base64.
var userIdBase64 = btoa(userId);

// Ensure that the uploaded user IDs use web-safe Base64 encoding.
userIdBase64 = userIdBase64.replace(/\+/g, '-').replace(/\//g, '_')
    .replace(/=+$/, '');

// After encoding the UUID correctly, you can create the request tag and
// insert it into the DOM.
var imgElement = Document.createElement('img');
imgElement.src =
    'https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm='
    + userIdBase64;
document.body.appendChild(imgElement);
דוגמה 2

צריך להקצות ערך של מזהה ייחודי אוניברסלי (UUID) בתור מזהה משתמש, כמו: 123e4567-e89b-12d3-a456-426655440000.

אם יש התאמה, מומלץ לבצע את השינויים הבאים ב-Ads Data Hub:

  1. UUID מעוצב כמחרוזת בת 36 תווים.
  2. פענוח הקסדצימלי של UUID.
  3. UUID מעוצב כבייטים.
  4. קידוד בייטים מסוג Base64 שבטוח לכתובות URL.
  5. UUID מעוצב כמחרוזת.

אפשר ליישם את זה באמצעות הקוד הבא:

JavaScript

var userId = '123e4567-e89b-12d3-a456-426655440000';

// A helper function for converting a hex string to a byte array.
function strToBytes(str) {
        for (var bytes = [], i = 0; i < str.length; i += 2) {
          bytes.push(parseInt(str.substr(i, 2), 16));
        }
        return bytes;
}

// Remove the formatting dashes from the UUID.
userId = userId.replace(/-/g, '');

// Encode the hex string as a byte array.
var userIdBytes = strToBytes(userId);

// Encode the byte array in normal base64.
var userIdBase64 = btoa(String.fromCharCode(...new Uint8Array(userIdBytes)));

// Ensure that the uploaded user IDs use web-safe Base64 encoding.
userIdBase64 = userIdBase64.replace(/\+/g, '-').replace(/\//g, '_').replace(
    /=+$/, '');

// After encoding the UUID correctly, you can create the request tag and
// insert it into the DOM.
var imgElement = Document.createElement('img');
imgElement.src =
    'https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm='
    + userIdBase64;
document.body.appendChild(imgElement);

Python

import base64

user_id = '123e4567-e89b-12d3-a456-426655440000'
user_id_as_bytes = bytes.fromhex(user_id.replace('-', ''))
base64.urlsafe_b64encode(user_id_as_bytes)

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

  1. הפורמט של external_cookie הוא בייטים.
  2. קידוד הקסדצימלי external_cookie.
  3. external_cookie בפורמט של מחרוזת.

קידוד מזהי משתמשים ב-Ads Data Hub

אם שומרים את מחרוזת ה-UUID בשדה בנתונים מאינטראקציה ישירה (First-Party), צריך להמיר אותה לבייטים, כמו בדוגמה שלמעלה, כדי לאחד את הנתונים.

הדוגמה הבאה מראה איך לקודד את ה-UUID ולחבר אותו בשדה החיצוני של קובץ ה-cookie:

JOIN my_data ON imp.external_cookie = FROM_HEX(REPLACE(my_data.uuid, '-', ''))

שים לב שאי אפשר להעביר מספר שלם לבייטים. אם מזהה המשתמש שלכם הוא מספר שלם (כמו בדוגמה 1 למעלה), תצטרכו לבצע העברה (cast) קודם כמחרוזת:

JOIN my_data ON imp.external_cookie = CAST(CAST(my_data.user_id AS STRING) AS BYTES)

חשוב לזכור שהקידוד הנדרש כדי להתאים לנתונים יהיה ספציפי לאופן שבו אתם מאחסנים אותם ולאופן שבו מקודדת אותם לפני שליחתם אל Ads Data Hub.

מידע נוסף על פונקציות מחרוזת ב-BigQuery SQL

שאילתה לדוגמה

בדוגמה הבאה מתבצעת איחוד של נתונים מאינטראקציה ישירה (First-Party) עם google_ads_impressions_match, ולאחר מכן מצרפת את התוצאות האלה עם adh_google_ads_impressions בשאילתה שנייה.

SELECT
  imp.campaign_id as campaign_id,
  sum(my_data.recent_orders) as orders,
  average(my_data.lifetime_value) as ltv
FROM
  adh.google_ads_impressions_match as imp
LEFT JOIN
  my_data ON imp.external_cookie = my_data.company_guest_id_bytes
GROUP BY
  campaign_id

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

SELECT
  campaign_id,
  COALESCE(orders, 0) as orders,
  COALESCE(ltv, 0) as ltv,
FROM (SELECT DISTINCT campaign_id
   FROM adh.google_ads_impressions)
LEFT JOIN previous_results USING (campaign_id)

  1. לדוגמה: כאשר שיעור הבקשות שמולאו הוא 20%, בפועל צריכים להיות 250 משתמשים בכל שורה כדי לעמוד בסף הצבירה של 50 משתמשים, כלומר 50 / .2 = 250.↩

  2. ייתכן עיכוב של עד 48 שעות לפני שהתאמות שבוצעו ביום מסוים יופיעו בטבלאות.↩