התאמות של קובצי 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 ואילך ממשתמשים שהעניקו הרשאה במסגרת השקיפות בנושא מעקב (ATT) של Apple.

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

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

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

ערך מזהה המשתמש שלך תמיד יהיה מתחת למגבלת האורך של 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 שעות בהצגת התאמות שבוצעו ביום מסוים בטבלאות. ↩