התאמה לפרטים שהמשתמשים סיפקו (UPDM)

התכונה "התאמה לפרטים שהמשתמשים סיפקו" (UPDM) מאפשרת לצרף את הנתונים מאינטראקציה ישירה (First-Party) שנאספו לגבי משתמש – כמו מידע מהאתרים, מהאפליקציות או מהחנויות הפיזיות – לפעילות של אותו המשתמש המחובר, שנאספה בנתוני מודעות ממוצרי Google, כולל נתונים ממוצרים שבבעלות ובהפעלת Google. הנתונים האלה כוללים נתונים שנרכשו דרך מוצרי Google Marketing Platform ‏ (GMP), למשל, YouTube שנרכש באמצעות Display & Video 360. אין תמיכה במוצרים אחרים של GMP שלא נמצאים בבעלות ובהפעלה של Google.

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

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

סקירה כללית של הכרטיסייה "חיבורים"

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

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

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

לומדים את המונחים

• חיבור לפרטים שהמשתמשים סיפקו: אתם יכולים להגדיר חיבור לפרטים שהמשתמשים סיפקו כדי לייבא ולהתאים את הנתונים, לתזמן ייבוא נתונים, לשנות את הנתונים ולהתאים את נתוני המודעות באמצעות מזהה משתמש. אירוע המודעה חייב להיות מקושר למשתמש מחובר בנתוני מודעות ממוצרי Google. נדרשים כמה פרויקטים ב-Google Cloud.
• חיבור לנתונים מאינטראקציה ישירה: הגדירו חיבור לנתונים מאינטראקציה ישירה ככלי להכנת נתונים, כדי לתזמן ייבוא נתונים ולשנות נתונים בלי התכונות המתקדמות של UPDM. בסוג החיבור הזה צריך רק פרויקט אחד ב-Google Cloud.
• מקור נתונים: מוצר מקושר, קובץ מיובא או שילוב עם צד שלישי. למשל: BigQuery.
• יעד: תרחיש שימוש, בדרך כלל מוצר או תכונה במוצר של Google שמופעלים בהם נתונים מיובאים. למשל: התאמה לפרטים שהמשתמשים סיפקו ב-Ads Data Hub.
• פרויקט אדמין: הפרויקט ב-Google Cloud שמכיל את נתוני הפרסום הקנייניים שלכם בפורמט הגולמי שלהם.
• מערך נתוני הפלט: מערך הנתונים ב-BigQuery שאליו Ads Data Hub כותב. כברירת מחדל, זהו מערך נתונים בפרויקט הניהול שלכם. כדי לשנות אותו לפרויקט אחר ב-Google Cloud, קראו את המאמר הגדרת חשבונות שירות.

סיכום התהליך

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

מידע על הדרישות בנושא פרטיות

איסוף נתוני לקוחות

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

פעולות שצריך לבצע:

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

אישור הסכמה מאינטראקציה ישירה (First-Party)

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

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

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

גודל הנתונים

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

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

הגדרת הטמעת נתונים

לפני שמתחילים, צריך להגדיר את חשבון Ads Data Hub כדי ליצור חיבורי נתונים, שבאמצעותם תגדירו את צינור עיבוד הנתונים להתאמת נתונים. צריך לבצע את השלבים פעם אחת בלבד.

בדף חיבורים, לוחצים על התחלת ההגדרה כדי לפתוח את אשף הגדרת החשבון בשלב ההפעלה של UPDM.

נכנסים לדף Connections.

הטמעה והתאמה של נתונים מאינטראקציה ישירה (First-Party)

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

בקישורים של Ads Data Hub נעשה שימוש בחשבון השירות שמוצג בקטע Settings > Details > Service account (בדרך כלל service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com). צריך להקצות לו את התפקידים הבאים:

• מקור BigQuery: התפקיד roles/bigquery.dataViewer (צפייה בנתוני BigQuery) במערך הנתונים או בטבלה של המקור.
• מקור ב-Cloud Storage: התפקיד roles/storage.objectViewer (Storage Object Viewer) בקטגוריה או באובייקט של המקור.
• יעד ייבוא נתונים מאינטראקציה ישירה (First-Party): roles/bigquery.dataEditor (עריכת נתונים ב-BigQuery) במערך הנתונים של היעד, אם הטבלה לא נמצאת במערך הנתונים שמוגדר כברירת מחדל.

דרישות לגבי שדות וסוגי נתונים

1. התאמה לפרטים שהמשתמשים סיפקו (UPDM):
   • ממפים את השדה user_id ועוד שדה אחד לפחות של פרטים אישיים מזהים (email,‏ phone או כתובת מלאה: first_name,‏ last_name,‏ country,‏ zip_code).
   • ‫user_id,‏ country ו-zip_code: STRING בטקסט פשוט (ללא גיבוב). במקור של BigQuery, העמודות האלה כבר צריכות להיות מסוג STRING. סוגים אחרים (למשל INT64) נכשלים כשהחיבור נוצר. החיבורים ממירים את user_id ל-BYTES בטבלת ההתאמה. country צריך להיות קוד בן 2 אותיות לפי תקן ISO 3166-1 alpha-2.
   • ‫email,‏ phone,‏ first_name ו-last_name: HASH – צריך לבצע גיבוב באמצעות SHA-256 וקידוד באמצעות Base64 (אפשר גם להשתמש בערך SHA-256 הקסדצימלי של 64 תווים). הכלי "חיבורים" לא מגבב נתונים. ערכי טקסט פשוט לא נתפסים כשהחיבור נוצר, וכל הפעלה נכשלת עם ... must be encoded using TO_BASE64(SHA256(...)).
   • לחיבורים של התאמה לפרטים שהמשתמשים סיפקו אין טבלת יעד. כל השאילתות בחשבון, ושאילתות UPDM שמופעלות באופן ידני, כותבות לאותם נתוני התאמה, כך שכל הפעלה מחליפה את הקודמת. מספיק חיבור אחד של UPDM לכל חשבון.
   • במאמר הכנת הנתונים להזנה מפורטים הכללים לכל שדה.
2. ייבוא נתונים מאינטראקציה ישירה (First-Party):
   • צריך להשתמש רק בסוגי הנתונים שמוצעים בממשק המשתמש: INTEGER,‏ STRING,‏ HASH,‏ DOUBLE,‏ DATE ו-TIMESTAMP. אין תמיכה בסוגים אחרים של BigQuery.
   • מקור BigQuery: הסוג הממופה לא מוחל. כל עמודת יעד שומרת על הסוג של עמודת המקור שלה.
   • מקור Cloud Storage: העמודות נקראות כ-STRING ומומרות לסוג הממופה. ערכים שלא ניתן להמיר הופכים ל-NULL בלי שההרצה תיכשל.
   • כל הפעלה מחליפה את כל טבלת היעד, ולא מוסיפה לה. אם במקור אין שורות, היעד יהיה ריק. אל תשתמשו בטבלת המקור או בטבלה שאתם צריכים לשמור את הנתונים שלה בתור טבלת היעד.

דרישות לגבי עמודות בקובץ CSV ב-Cloud Storage

• מוסיפים שורת כותרת. המערכת מדלגת על השורה הראשונה, ולא משתמשת בשמות העמודות שבה.
• הקובץ חייב להכיל בדיוק את עמודות המקור הממופות, לא יותר ולא פחות. עמודות מיותרות גורמות לכישלון ההפעלה.
• ייבוא נתונים מאינטראקציה ישירה (First-Party): העמודות צריכות להיות באותו סדר כמו מיפוי השדות.
• התאמה לפרטים שהמשתמשים סיפקו: העמודות צריכות להיות בסדר הזה, וצריך להשאיר רק את השדות שאתם ממפים: user_id, ‏ email, ‏ phone, ‏ first_name,‏ last_name, ‏ country, ‏ zip_code. אין חשיבות לסדר של שורות המיפוי.
• אם סדר העמודות שונה, המערכת לא תזהה את זה: הערכים ייטענו בשדות הלא נכונים (או ששיעור הנתונים הזהים ירד) בלי שתוצג שגיאה.

מקורות נתונים נתמכים ומגבלות חיבור

• מקורות נתונים: אפשר להשתמש רק במקורות מ-BigQuery ומ-Cloud Storage.
• שמות של טבלאות ב-BigQuery: בטבלאות המקור והיעד ב-BigQuery צריך לציין את השם המלא של project.dataset.table.
• נתיבי קבצים ב-Cloud Storage: צריך לספק URI של קובץ אחד (כמו gs://bucket/path/file.csv). אין תמיכה בנתיבים עם התווים הכלליים לחיפוש * או ?.
• שמות החיבורים: לכל חיבור בחשבון צריך להיות שם ייחודי.

הכנת הנתונים להזנה

כדי שהנתונים יותאמו בצורה נכונה, הם צריכים לעמוד בדרישות הפורמט הבאות:

• במקרים שבהם מצוין בתיאורים של שדות להזנת קלט הבאים, צריך להעלות באמצעות גיבוב SHA256.
• UPDM תומך בקידוד Base64. מידע נוסף זמין במאמר TO_BASE64.
• השדות להזנת קלט צריכים להיות בפורמט של מחרוזות. לדוגמה, אם אתם משתמשים בפונקציית הגיבוב SHA256 של BigQuery, השתמשו בטרנספורמציה הבאה: TO_BASE64(SHA256(user_data)).

אימות גיבוב (hash) וקידוד נתונים

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

  /**
   * @fileoverview Provides the hashing algorithm, as well as some valid hashes of
   * sample data for testing.
  */

  async function hash(token) {
    // Removes leading or trailing spaces and converts all characters to lowercase.
    const formattedToken = token.trim().toLowerCase();
    // Hashes the formatted string using the SHA-256 hashing algorithm.
    const hashBuffer = await crypto.subtle.digest(
        'SHA-256', (new TextEncoder()).encode(formattedToken));
    // Converts the hash buffer to a base64-encoded string and returns it.
    const base64Str = btoa(String.fromCharCode(...new Uint8Array(hashBuffer)));
    return base64Str;
  }

  function main() {
    // Expected hash for test@gmail.com:
    // h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    hash('test@gmail.com').then(result => console.log(result));

    // Expected hash for +18005551212:
    // YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    hash('+18005551212').then(result => console.log(result));

    // Expected hash for John: ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
    hash('John').then(result => console.log(result));

    // Expected hash for Doe: eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=
    hash('Doe').then(result => console.log(result));
  }

  main()

  """Provides the hashing algorithm, as well as some valid hashes of sample data for testing.

  Supports: Python 2, Python 3

  Sample hashes:

    - Email 'test@gmail.com': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '+18005551212':   YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    - First name 'John':      ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
    - Last name 'Doe':        eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=
  """

  import base64
  import hashlib

  def hash(token):
  # Generates a base64-encoded SHA-256 hash of a normalized input string.
    return base64.b64encode(
        hashlib.sha256(
            token.strip().lower().encode('utf-8')).digest()).decode('utf-8')

  def print_hash(token, expected=None):
  # Computes and displays the hash of a token, with optional validation.
    hashed = hash(token)

    if expected is not None and hashed != expected:
      print(
          'ERROR: Incorrect hash for token "{}". Expected "{}", got "{}"'.format(
              token, expected, hashed))
      return

    print('Hash: "{}"\t(Token: {})'.format(hashed, token))

  def main():
  # Tests the hash function with sample tokens and expected results.
    print_hash(
        'test@gmail.com', expected='h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=')
    print_hash(
        '+18005551212', expected='YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=')
    print_hash('John', expected='ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=')
    print_hash('Doe', expected='eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=')

  if __name__ == '__main__':
    main()

  /*
  Provides the hashing algorithm, as well as some valid hashes of sample data for testing.

  Sample hashes:

    - Email 'test@gmail.com': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '+18005551212':   YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    - First name 'John':      ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
    - Last name 'Doe':        eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=
  */
  package main

  import (
    "crypto/sha256"
    "encoding/base64"
    "fmt"
    "strings"
  )

  // Hash hashes an email, phone, first name, or last name into the correct format.
  func Hash(token string) string {
    formatted := strings.TrimSpace(strings.ToLower(token))
    hashed := sha256.Sum256([]byte(formatted))
    encoded := base64.StdEncoding.EncodeToString(hashed[:])
    return encoded
  }

  // PrintHash prints the hash for a token.
  func PrintHash(token string) {
    fmt.Printf("Hash: \"%s\"\t(Token: %s)\n", Hash(token), token)

  }

  func main() {
    PrintHash("test@gmail.com")
    PrintHash("+18005551212")
    PrintHash("John")
    PrintHash("Doe")
  }

  package updm.hashing;

  import static java.nio.charset.StandardCharsets.UTF_8;

  import java.security.MessageDigest;
  import java.security.NoSuchAlgorithmException;
  import java.util.Base64;

  /**
  * Example of the hashing algorithm.
  *
  * <p>Sample hashes:
  *
  * <ul>
  *   <li>Email 'test@gmail.com': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
  *   <li>Phone '+18005551212': YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
  *   <li>First name 'John': ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
  *   <li>Last name 'Doe': eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=
  * </ul>
  */
  public final class HashExample {

  private HashExample() {}

  public static String hash(String token) {
    // Normalizes and hashes the input token using SHA-256 and Base64 encoding.
    String formattedToken = token.toLowerCase().strip();

    byte[] hash;
    try {
      hash = MessageDigest.getInstance("SHA-256").digest(formattedToken.getBytes(UTF_8));
    } catch (NoSuchAlgorithmException e) {
      throw new IllegalStateException("SHA-256 not supported", e);
    }

    return Base64.getEncoder().encodeToString(hash);
  }

  public static void printHash(String token) {
    // Calculates and prints the hash for the given token.
    System.out.printf("Hash: \"%s\"\t(Token: %s)\n", hash(token), token);
  }

  public static void main(String[] args) {
    // Executes hash calculations and prints results for sample tokens.
    printHash("test@gmail.com");
    printHash("+18005551212");
    printHash("John");
    printHash("Doe");
  }
  }

  /*
  Provides the hashing algorithm, as well as some valid hashes of sample data for testing.

  The following code uses Google Standard SQL and can be run on BigQuery to generate match tables from unhashed data.

  Sample hashes:

    - Email 'test@gmail.com': h5JGBrQTGorO7q6IaFMfu5cSqqB6XTp1aybOD11spnQ=
    - Phone '+18005551212':   YdkRG+0+bZz8G8O1yzWkAmh8TxVGvuBhor1ET73WTEQ=
    - First name 'John':      ltljLzY1ZMwwMlIUCc8iqFLyAy7sCZ7VlnwNAAzsYHo=
    - Last name 'Doe':        eZ75KhGvkY4/t0HfQpNPO1aO0tk6wd908bjUGieTKm8=

  The unhashed input table schema is assumed to be:

  - Column name: UserID, Type: String
  - Column name: Email, Type: String
  - Column name: Phone, Type: String
  - Column name: FirstName, Type: String
  - Column name: LastName, Type: String
  - Column name: PostalCode, Type: String
  - Column name: CountryCode, Type: String
  */

  -- Creates a new table with Base64-encoded SHA-256 hashes of specified columns.
  CREATE TABLE `your_project_name.your_dataset_name.output_hashed_table_name`
  AS
  SELECT
    UserID,
    TO_BASE64(SHA256(LOWER(Email))) AS Email,
    TO_BASE64(SHA256(Phone)) AS Phone,
    TO_BASE64(SHA256(LOWER(FirstName))) AS FirstName,
    TO_BASE64(SHA256(LOWER(LastName))) AS LastName,
    PostalCode,
    CountryCode,
  FROM
    `your_project_name.your_dataset_name.input_unhashed_table_name`;

מפתחות איחוד (join)

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

1. כתובת אימייל, מספר טלפון, כתובת (הכי חזק)
2. טלפון, כתובת
3. כתובת אימייל, כתובת
4. אימייל, טלפון
5. כתובת
6. טלפון
7. אימייל (הכי פחות חזק)

יצירת טבלת התאמות

1. לוחצים על Connections (קישורים) > Create connection (יצירת קישור) > User-provided data matching (התאמה לפרטים שהמשתמשים סיפקו).
2. בוחרים מקור נתונים ולוחצים על קישור.
3. אם מוצגת בקשה לאימות, מאמתים את החשבון ולוחצים על הבא:

   BigQuery

   לוחצים על "אישור" כדי לתת גישה ל-BigQuery.

   Cloud Storage

   לוחצים על "אישור" כדי להעניק גישה ל-Cloud Storage.

   MySQL

   מזינים את המיקום של מסד הנתונים, היציאה, שם המשתמש והסיסמה ב-MySQL.

   S3

   ממלאים את מפתח הגישה הסודי של Amazon S3.

   PostgreSQL

   מזינים את המיקום של מסד הנתונים, היציאה, שם המשתמש, הסיסמה ומסד הנתונים ב-PostgreSQL.

   Redshift

   מזינים את המיקום של מסד הנתונים, היציאה, שם המשתמש, הסיסמה ומסד הנתונים ב-Redshift.

   sFTP

   מזינים את המיקום, שם המשתמש והסיסמה של שרת ה-SFTP.

   פתית שלג

   מזינים את שם המשתמש, הסיסמה ומזהה החשבון ב-Snowflake.

4. מגדירים את מקור הנתונים ולוחצים על הבא:

   BigQuery

   בוחרים את הטבלה ב-BigQuery שרוצים לייבא.

   Cloud Storage

   מזינים את הנתיב של gsutil, למשל gs://my-bucket/folder/, ובוחרים את הפורמט של הקובץ.

   בפעם הראשונה שמקשרים את מקור המידע, מופיעה התראה. לוחצים על 'אישור' כדי להעניק גישה, ולוחצים על 'הבא'. הערה: צריכה להיות לכם הרשאה לתת גישה ל-storage.buckets.setIamPolicy בקטגוריה הרלוונטית.

   MySQL

   בוחרים את הטבלה ומסד הנתונים מ-MySQL שבהם רוצים להשתמש.

   S3

   מציינים את ה-URI לקובץ שרוצים להעלות, ביחס לכתובת המארח.

   PostgreSQL

   מזינים את שם הסכימה והטבלה (או התצוגה) ב-PostgreSQL.

   Redshift

   מזינים את השם של הסכימה והטבלה (או התצוגה) ב-Redshift. כברירת מחדל, כתובות URL של מיקום מסד נתונים ב-Redshift בנויות כך: cluster-identifier.account-number.aws-region.redshift.amazonaws.com.

   sFTP

   מזינים את הנתיב והשם של הקובץ בפורמט הבא: /PATH/FILENAME.csv

   פתית שלג

   מזינים את מסד הנתונים, הסכימה והטבלה (או התצוגה) שרוצים להשתמש בהם מ-Snowflake.

5. בוחרים מערך נתונים ב-BigQuery שישמש כיעד ביניים ולוחצים על הבא. השלב הזה עוזר לוודא שהפורמט של הנתונים נכון.
6. אופציונלי: משנים את הפורמט של הנתונים. הטרנספורמציות כוללות חישוב גיבוב (hash), עיצוב של אותיות רישיות/קטנות ומיזוג/פיצול של שדות.
   1. לוחצים על Action‏ > more_vert > Transform.
   2. בחלונית שקופצת, לוחצים על הוספת טרנספורמציה או על הוספת טרנספורמציה נוספת.
   3. בוחרים סוג טרנספורמציה מהתפריט הנפתח ומזינים את הדרישות.
   4. לוחצים על שמירה.
7. בוחרים לפחות מפתח איחוד אחד וממפים את השדות שבהם תשתמשו. מערכת Ads Data Hub תמפה באופן אוטומטי שדות עם שמות זהים, שמסומנים בסמל auto_fix_high. עורכים את השינויים הנדרשים ולוחצים על הבא.
8. הגדרת לוח זמנים:
   1. נותנים שם לחיבור.
   2. מגדירים תדירות, שקובעת באיזו תדירות הנתונים ייובאו לקבוצת הנתונים שבחרתם בשלב הקודם. כל הפעלה תחליף את הנתונים בטבלת היעד.
   3. צריך לציין איך לטפל בהתנגשויות בין מזהי משתמשים. אתם יכולים לבחור אם להשאיר את ההתאמה הקיימת או להחליף אותה בנתונים חדשים.
9. לוחצים על סיום. בדרך כלל אפשר לשלוח שאילתות לטבלאות התאמה 12 שעות אחרי שהן נוצרות.

הצגת פרטי החיבור

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

1. לוחצים על חיבורים.
2. לוחצים על שם החיבור כדי לראות את הפרטים שלו.
3. עכשיו אפשר לראות את פרטי החיבור ואת ההפעלות האחרונות. בכל אחד מהם מוצגים שני סוגים אפשריים של שגיאות: שגיאות ברמת החיבור (החיבור לא פעל) ושגיאות ברמת השורה (שורה לא יובאה).
   1. הסטטוס Failed מציין שהחיבור כולו נכשל (למשל, בעיה בהרשאות של חשבון השירות). לוחצים על סטטוס השגיאה כדי לראות אילו שגיאות השפיעו על החיבור.
   2. הסטטוס Completed מציין שהחיבור פעל בהצלחה. עם זאת, עדיין יכולות להיות שגיאות ברמת השורה, שמסומנות בערך שאינו אפס בעמודה "שורות עם שגיאות". כדי לראות אילו רשומות נכשלו, לוחצים על הערך.

עריכת חיבור

אפשר לערוך את הפרטים הבאים:

• שם החיבור
• תזמון
• טבלת היעד
• מיפוי שדות

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

כדי לערוך את פרטי החיבור:

1. לוחצים על חיבורים.
2. לוחצים על שם החיבור שרוצים לערוך.
3. עורכים את הפרטים שרוצים לשנות:
   • שם החיבור: לוחצים על עריכה, מזינים את השם החדש ולוחצים על Enter.
   • לוח זמנים: לוחצים על עריכה, מגדירים את לוח הזמנים החדש ולוחצים על שמירה.
   • ‫טבלת יעדים: לוחצים על Edit, מזינים את שם היעד החדש ולוחצים על Save.
   • מיפוי שדות: לוחצים על navigate_next, משנים את השדות ולוחצים על שמירה.
4. לוחצים על close.

העברת קישורים קיימים

הקישורים הקיימים בכרטיסייה Connections (קישורים) עוברים לממשק קישורים מעודכן, שמוטמע ישירות ב-Ads Data Hub. החיבורים המעודכנים קוראים מקורות וכותבים יעדים באמצעות חשבון השירות שמוצג בקטע Settings > Details > Service account (בדרך כלל service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com), במקום חשבונות השירות הקודמים של Data Fusion, ‏ Dataproc ו-UPDM.

לפני שהחיבורים שלכם יועברו, השלימו את הפעולות לביצוע הבאות:

1. הענקת הרשאות לחשבון השירות: מעניקים לחשבון השירות שמופיע בקטע Settings > Details > Service account (בדרך כלל service-<number>@gcp-sa-adsdatahub.iam.gserviceaccount.com) את התפקידים הנדרשים במקור וביעד (roles/bigquery.dataViewer,‏ roles/storage.objectViewer ו-roles/bigquery.dataEditor בקבוצות נתונים ביעד שהן לא ברירת המחדל). יכול להיות שקישורים עם מקורות לא קריאים, שנמחקו או שהשתנו עדיין יועברו (במיוחד מקורות ב-Cloud Storage, שלא מאומתים בזמן ההעברה), אבל ההפעלות ייכשלו עד שתעניקו גישה או תתקנו את המקור.
2. המרת חיבורים לא נתמכים: חיבורים עם ההגדרות הבאות לא יועברו. צריך להמיר אותם לחיבורים נתמכים של BigQuery או Cloud Storage:
   • מקורות נתונים אחרים (Amazon S3,‏ Snowflake,‏ MySQL,‏ PostgreSQL,‏ Amazon Redshift,‏ sFTP או Salesforce): קודם מעבירים את הנתונים ל-BigQuery או ל-Cloud Storage, ואז יוצרים חיבור ל-BigQuery או ל-Cloud Storage.
   • מיפויי שדות או סוגי נתונים שלא נתמכים: מעדכנים או יוצרים מחדש את החיבור כדי לעמוד בדרישות לגבי השדות וסוגי הנתונים.
   • נתיבים עם תווים כלליים לחיפוש ב-Cloud Storage (* או ?): מחליפים את ה-URI של התו הכללי לחיפוש ב-URI של קובץ יחיד, או טוענים קודם את הקבצים ל-BigQuery.
   • שמות חיבורים כפולים: משנים את השם של החיבורים הכפולים או מוחקים אותם, כדי שלכל חיבור בחשבון יהיה שם ייחודי.
3. מחיקת חיבורים שלא בשימוש: מחקו חיבורים מיושנים שאתם לא צריכים יותר.

נתונים תואמים לשאילתה

הרצת שאילתות על טבלאות ההתאמות

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

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

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

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

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

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

JOIN ON
  adh.google_ads_impressions_updm.customer_data_user_id = CAST(my_data.user_id AS BYTES)

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

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

ספירת משתמשים תואמים

השאילתה הזו סופרת את מספר המשתמשים התואמים בטבלת החשיפות של מודעות Google Ads.

/* Count matched users in Google Ads impressions table */

SELECT COUNT(DISTINCT user_id)
FROM adh.google_ads_impressions_updm

חישוב אחוז הלקוחות לטירגוט

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

/* Calculate the UPDM match rate */

CREATE TEMP TABLE total_events OPTIONS(privacy_checked_export=TRUE) AS
SELECT
  customer_id,
  COUNT(*) AS n
FROM adh.google_ads_impressions
WHERE is_updm_eligible
GROUP BY 1;

CREATE TEMP TABLE matched_events OPTIONS(privacy_checked_export=TRUE) AS
SELECT
  customer_id,
  COUNT(*) AS n
FROM adh.google_ads_impressions_updm
GROUP BY 1;

SELECT
  customer_id,
  SAFE_DIVIDE(matched_events.n, total_events.n) AS match_rate
FROM total_events
LEFT JOIN matched_events
  USING (customer_id)

איחוד נתונים מאינטראקציה ישירה (First-Party) עם נתוני מודעות מ-Google Ads

השאילתה הזו מדגימה איך לאחד נתונים מאינטראקציה ישירה (First-Party) עם נתוני Google Ads:

/* Join first-party data with Google Ads data. The customer_data_user_id field
contains your ID as BYTES. You need to cast your join key into BYTES for
successful matches. */

SELECT
  inventory_type,
  COUNT(*) AS impressions
FROM
  adh.yt_reserve_impressions_updm AS google_data_imp
LEFT JOIN
  `my_data`
ON
  google_data_imp.customer_data_user_id = CAST(my_data.user_id AS BYTES)
GROUP BY
  inventory_type

שאלות נפוצות בנושא UPDM

שאלות נפוצות בנושא UPDM