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

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

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

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

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

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

לכל טבלה בסכימה של Ads Data Hub שמכילה את השדה user_id מצורפת טבלת התאמות. לדוגמה, לטבלה 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, שבה מאוחסן מזהה המשתמש כבייט.

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

דוגמה 1

ערך User‑ID תמיד יהיה קצר מ-24 בייטים. מומלץ לשלוח את מזהה המשתמש ישירות ל-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, '-', ''))

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