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

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

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

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

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

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

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

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

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

טבלאות ההתאמה מכילות עמודה נוספת בשם external_cookie, שבה מאוחסן מזהה המשתמש כ-BYTES.

כשכותבים שאילתות, חשוב להביא בחשבון את סוג השדה. אופרטורים להשוואה ב-SQL מצפים שהליטרלים שמשווים יהיו מאותו סוג. בהתאם לאופן שבו user_id מאוחסן בטבלה של נתונים מאינטראקציה ישירה, יכול להיות שתצטרכו לקודד את הערכים בטבלה לפני שתתאימו את הנתונים. כדי שההתאמות יתבצעו בהצלחה, צריך להמיר את מפתח ההצטרפות ל-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 קבוצת משנה (או גיבוב) של המזהה שלכם. חשוב לזכור שבכל מקרה, תצטרכו לוודא שתוכלו לכתוב SQL JOIN שימיר את המזהה בטבלה של האינטראקציה הישירה באותו אופן.

דוגמה 1

ערך User ID תמיד יהיה קצר ממגבלת האורך של 24 בייט. ב-Ads Data Hub מומלץ פשוט לשלוח את מזהה המשתמש ישירות אל 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 בשדה בנתונים מאינטראקציה ישירה, תצטרכו להמיר אותה לבייטים, כמו בדוגמה שלמעלה, כדי שהנתונים יצורפו בהצלחה.

בדוגמה הבאה מוצג אופן הקידוד של ה-UUID והוספתו לשדה של קובץ ה-Cookie החיצוני:

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

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

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. הפעולה הזו מוסיפה לתוצאות נתונים על קמפיינים עם 0 חשיפות.

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 חלקי 0.2 שווה ל-250. ↩

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