טעינת נתונים מ-Search Ads 360 ל-BigQuery

אתם יכולים לטעון נתונים מ-Search Ads 360 ל-BigQuery באמצעות המחבר של שירות העברת הנתונים ל-BigQuery ב-Search Ads 360. בעזרת שירות העברת הנתונים ל-BigQuery, אתם יכולים לתזמן משימות העברה חוזרות שמוסיפות את הנתונים העדכניים מ-Search Ads 360 ל-BigQuery.

סקירה כללית על המחבר

שירות העברת הנתונים ל-BigQuery עבור המחבר של Search Ads 360 תומך באפשרויות הבאות להעברת נתונים.

אפשרויות להעברת נתונים תמיכה
דוחות נתמכים המחבר של Search Ads 360 תומך בהעברת נתונים מהדוחות ב-Search Ads 360 v0.

במאמר טרנספורמציה של דוחות Search Ads 360 מוסבר איך הדוחות של Search Ads 360 עוברים טרנספורמציה לטבלאות ב-BigQuery ולתצוגות ב-BigQuery.
תדירות החזרה המחבר של Search Ads 360 תומך בהעברות נתונים יומיות.

כברירת מחדל, העברות הנתונים מתוזמנות למועד שבו הן נוצרות. אפשר להגדיר את מועד העברת הנתונים כשמגדירים את העברת הנתונים.
רענון החלון אתם יכולים לתזמן את העברות הנתונים כדי לאחזר נתונים מ-Search Ads 360 עד 30 יום לפני מועד ההפעלה של העברת הנתונים. אפשר להגדיר את משך הזמן של חלון הרענון כשמגדירים את העברת הנתונים.

כברירת מחדל, חלון הרענון של המחבר של Search Ads 360 הוא 7 ימים.

מידע נוסף זמין במאמר חלונות רענון.

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

מידע על מדיניות שמירת הנתונים של Search Ads 360 זמין במאמר מדיניות שמירת נתוני הדיווח.
מספר מזהי הלקוחות בכל חשבון ניהול שירות העברת הנתונים ל-BigQuery תומך ב-8,000 מספרי לקוח לכל היותר בכל חשבון ניהול ב-Search Ads 360.

כדי לראות את המדריך להעברת נתונים מ-Search Ads 360 שמשתמש ב-Search Ads 360 Reporting API הישן, קראו את המאמר העברות מ-Search Ads 360 (הוצא משימוש).

הטמעת נתונים מהעברות של Search Ads 360

כשמעבירים נתונים מ-Search Ads 360 ל-BigQuery, הנתונים נטענים לטבלאות ב-BigQuery שמחולקות למחיצות לפי תאריך. המחיצה בטבלה שאליה נטענים הנתונים תואמת לתאריך ממקור הנתונים. אם תזמנתם כמה העברות לאותו תאריך, שירות העברת הנתונים ל-BigQuery יחליף את המחיצה של התאריך הספציפי הזה בנתונים העדכניים ביותר. אם מבצעים כמה העברות באותו יום או מפעילים מילויים חוזרים, הנתונים לא משוכפלים והמחיצות של תאריכים אחרים לא מושפעות.

רענון החלונות

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

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

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

מגבלות

  • התדירות המקסימלית שאפשר להגדיר להעברת נתונים מ-Search Ads 360 היא פעם אחת בכל 24 שעות. כברירת מחדל, ההעברה מתחילה בזמן שבו יוצרים אותה. עם זאת, אתם יכולים להגדיר את שעת ההתחלה של העברת הנתונים כשאתם יוצרים את ההעברה.
  • שירות העברת הנתונים ל-BigQuery לא תומך בהעברות נתונים מצטברות במהלך העברה מ-Search Ads 360. כשמציינים תאריך להעברת נתונים, כל הנתונים שזמינים לתאריך הזה מועברים.

לפני שמתחילים

לפני שיוצרים העברת נתונים מ-Search Ads 360:

ההרשאות הנדרשות

מוודאים שנתתם את ההרשאות הבאות:

התפקידים הנדרשים ב-BigQuery

כדי לקבל את ההרשאות שנדרשות ליצירת העברת נתונים בשירות העברת הנתונים ל-BigQuery, בקשו מהאדמין להקצות לכם את התפקיד אדמין ב-BigQuery (roles/bigquery.admin) ב-IAM בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

ההרשאות הנדרשות

כדי ליצור העברת נתונים בשירות העברת הנתונים ל-BigQuery, נדרשות ההרשאות הבאות:

  • הרשאות לשירות העברת נתונים ל-BigQuery:
    • bigquery.transfers.update
    • bigquery.transfers.get
  • הרשאות ב-BigQuery:
    • bigquery.datasets.get
    • bigquery.datasets.getIamPolicy
    • bigquery.datasets.update
    • bigquery.datasets.setIamPolicy
    • bigquery.jobs.create

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

מידע נוסף זמין במאמר מתן גישה ל-bigquery.admin.

התפקידים הנדרשים ב- Google Cloud

כדי להוריד נתונים מ-Search Ads 360, צריכה להיות לכם ההרשאה serviceusage.services.use. ההרשאה הזו כלולה בתפקיד ה-IAM המוגדר מראש Service Usage Consumer (roles/serviceusage.serviceUsageConsumer).

התפקידים הנדרשים ב-Search Ads 360

מעניקים גישת קריאה למספר הלקוח ב-Search Ads 360 או לחשבון הניהול שמשמש בהגדרת ההעברה. כדי להגדיר גישת קריאה לחשבונות שירות, אפשר לפנות לתמיכה של Search Ads 360.

יצירת העברת נתונים מ-Search Ads 360

כדי ליצור העברת נתונים לדיווח ב-Search Ads 360, אתם צריכים את מספר הלקוח ב-Search Ads 360 או את חשבון הניהול. בוחרים באחת מהאפשרויות הבאות:

המסוף

  1. נכנסים לדף Data transfers במסוף Google Cloud .

    מעבר אל "העברות נתונים"

  2. ‫לוחצים על Create transfer.

  3. בקטע Source type, בוחרים באפשרות Search Ads 360 בשדה Source.

  4. בקטע Transfer config name, בשדה השם המוצג מזינים שם להעברת הנתונים, למשל My Transfer. שם ההעברה יכול להיות כל ערך שמאפשר לזהות את ההעברה אם צריך לשנות אותה מאוחר יותר.

  5. בקטע אפשרויות תזמון:

    • בקטע Repeat frequency, בוחרים באיזו תדירות להפעיל את העברת הנתונים. אם בוחרים באפשרות ימים, צריך לציין שעה תקינה ב-UTC.
    • אם רלוונטי, בוחרים באפשרות Start now או באפשרות Start at set time, ומציינים תאריך התחלה וזמן ריצה.

  6. בקטע Destination settings, בשדה Dataset בוחרים את מערך הנתונים שיצרתם כדי לאחסן את הנתונים.

  7. בקטע פרטי מקור הנתונים:

    1. בשדה מספר לקוח, מזינים את מספר הלקוח ב-Search Ads 360.
    2. אופציונלי: מזינים גם מזהה סוכנות וגם מזהה מפרסם כדי לאחזר טבלאות מיפוי מזהים.

    3. אופציונלי: בשדה Custom Floodlight Variables, מזינים את המשתנים המותאמים אישית של Floodlight שרוצים לכלול בהעברת הנתונים. המשתנים המותאמים אישית של Floodlight צריכים להיות בבעלות של חשבון Search Ads 360 שצוין על ידי מספר הלקוח בהגדרות ההעברה. הפרמטר הזה מקבל קלט של מחרוזות בפורמט של מערך JSON, והוא יכול לתמוך בכמה משתנים מותאמים אישית של Floodlight. בכל פריט במערך ה-JSON, הפרמטרים הבאים נדרשים:

      • ‫id: המזהה המספרי של משתנה Floodlight המותאם אישית. המזהה הזה מוקצה כשיוצרים משתנה מותאם אישית של Floodlight ב-Search Ads 360. אם ציינתם id, לא צריך לציין name.
      • name: השם שהמשתמש הגדיר למשתנים המותאמים אישית של Floodlight ב-Search Ads 360. אם ציינתם name, לא צריך לציין id.
      • ‫cfv_field_name: השם המדויק של השדה של משתנה Floodlight המותאם אישית, בהתאם לתרחיש לדוגמה. הערכים הנתמכים הם conversion_custom_metrics,‏ conversion_custom_dimensions,‏ raw_event_conversion_metrics ו-raw_event_conversion_dimensions.
      • ‫destination_table_name: רשימה של טבלאות ב-BigQuery שבהן רוצים לכלול את המשתנים המותאמים אישית של Floodlight. כששירות העברת הנתונים ל-BigQuery מאחזר נתונים לטבלאות האלה, ההעברה כוללת את המשתנים המותאמים אישית של Floodlight בשאילתה.
      • ‫bigquery_column_name_suffix: השם הידידותי של העמודה שהוגדר על ידי המשתמש. שירות העברת הנתונים ל-BigQuery מוסיף את הסיומת אחרי שם השדה הרגיל כדי להבדיל בין משתני Floodlight מותאמים אישית שונים. בהתאם לתרחיש לדוגמה, שירות העברת הנתונים ל-BigQuery יוצר שם עמודה ב-BigQuery באופן הבא:
      משתני Floodlight מותאמים אישית כמדדים ופלחים משתנים מותאמים אישית של Floodlight כמאפייני אירועים גולמיים במשאב ההמרות
      metrics metrics_conversion_custom_metrics_bigquery_column_name_suffix metrics_raw_event_conversion_metrics_bigquery_column_name_suffix
      dimension segments_conversion_custom_dimensions_bigquery_column_name_suffix segments_raw_event_conversion_dimensions_bigquery_column_name_suffix

      הדוגמה הבאה היא רשומה של משתנה Floodlight מותאם אישית שמציינת שני משתנים מותאמים אישית של Floodlight:

      [{
"id": "1234",
"cfv_field_name": "raw_event_conversion_metrics",
"destination_table_name": ["Conversion"],
"bigquery_column_name_suffix": "suffix1"
},{
"name": "example name",
"cfv_field_name": "conversion_custom_metrics",
"destination_table_name": ["AdGroupConversionActionAndDeviceStats","CampaignConversionActionAndDeviceStats"],
"bigquery_column_name_suffix": "suffix2"
}]

    4. אופציונלי: בשדה Custom Columns, מזינים את העמודות בהתאמה אישית שרוצים לכלול בהעברת הנתונים. העמודות בהתאמה אישית צריכות להיות בבעלות של חשבון Search Ads 360 שצוין על ידי מספר הלקוח בהגדרות ההעברה. השדה הזה מקבל קלט של מחרוזות בפורמט של מערך JSON ויכול לתמוך בכמה עמודות. בכל פריט במערך ה-JSON, הפרמטרים הבאים נדרשים:

      • ‫id: המזהה המספרי של העמודה בהתאמה אישית. המזהה הזה מוקצה כשיוצרים עמודה בהתאמה אישית. אם ציינתם id, לא צריך לציין name.
      • ‫name: השם שהמשתמש הגדיר לעמודה בהתאמה אישית ב-Search Ads 360. אם ציינתם name, לא צריך לציין id.
      • ‫destination_table_name: רשימה של טבלאות ב-BigQuery שבהן רוצים לכלול את העמודה בהתאמה אישית. כששירות העברת הנתונים ל-BigQuery מאחזר נתונים לטבלאות האלה, ההעברה כוללת את שדה העמודה בהתאמה אישית בשאילתה.
      • ‫bigquery_column_name: שם העמודה הידידותי שהמשתמש הגדיר. זהו שם השדה של העמודה בהתאמה אישית בטבלאות היעד שצוינו ב-destination_table_name. שם העמודה חייב לעמוד בדרישות הפורמט של שמות עמודות ב-BigQuery, והוא צריך להיות ייחודי ושונה משמות של שדות אחרים בסכימה הרגילה של הטבלה או משמות של עמודות בהתאמה אישית.

      הדוגמה הבאה היא רשומה של עמודות בהתאמה אישית שמציינת שתי עמודות בהתאמה אישית:

      [{
  "id": "1234",
  "destination_table_name": ["Conversion"],
  "bigquery_column_name": "column1"
},{
  "name": "example name",
  "destination_table_name": ["AdGroupStats","CampaignStats"],
  "bigquery_column_name": "column2"
}]

    5. אופציונלי: בשדה Table Filter, מזינים רשימה מופרדת בפסיקים של טבלאות שרוצים לכלול, לדוגמה Campaign, AdGroup. כדי להחריג טבלאות מסוימות, מוסיפים בתחילת הרשימה את התו -, לדוגמה -Campaign, AdGroup. כברירת מחדל, כל הטבלאות נכללות.

    6. אופציונלי: בוחרים באפשרות Include PMax Campaign Data כדי לכלול נתונים של קמפיינים למיקסום הביצועים ולהחריג שדות של ad_group מטבלאות מסוימות. למידע נוסף, ראו קמפיינים של מיקסום ביצועים (PMax)

    7. אופציונלי: בוחרים באפשרות Use Client Account Currency כדי להשתמש במטבע של חשבון הלקוח לטעינת נתוני העלות, במקום במטבע של החשבון שמשמש להעברת הנתונים.

    8. אופציונלי: בשדה חלון הרענון, מזינים ערך בין 1 ל-30. אם המדיניות לא מוגדרת, חלון הרענון מוגדר כברירת מחדל ל-7 ימים. מידע נוסף זמין במאמר חלונות רענון.

  8. בתפריט Service Account, בוחרים חשבון שירות מתוך חשבונות השירות שמשויכים לפרויקט ב- Google Cloud . אתם יכולים לשייך חשבון שירות להעברה במקום להשתמש בפרטי הכניסה של המשתמש. מידע נוסף על השימוש בחשבונות שירות להעברות נתונים זמין במאמר שימוש בחשבונות שירות.

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

  9. אופציונלי: בקטע אפשרויות להתראות:

    • לוחצים על המתג כדי להפעיל את ההתראות באימייל. כשמפעילים את האפשרות הזו, האדמין של ההעברה מקבל התראה באימייל כשהרצת ההעברה נכשלת.
    • לוחצים על המתג כדי להפעיל את ההתראות של Pub/Sub. בקטע Select a Cloud Pub/Sub topic, בוחרים את שם הנושא או לוחצים על Create a topic. האפשרות הזו מגדירה התראות על הפעלת Pub/Sub להעברה.

  10. לוחצים על Save.

BQ

מזינים את הפקודה bq mk ומציינים את הדגל ליצירת העברה – --transfer_config. צריך גם את הדגלים הבאים:

  • --data_source
  • --target_dataset
  • --display_name
  • --params

הדגלים הבאים הם אופציונליים:

  • ‫--project_id: מציין באיזה פרויקט להשתמש. אם לא מציינים את הדגל, המערכת משתמשת בפרויקט שמוגדר כברירת מחדל.
  • ‫--service_account_name: מציין חשבון שירות שישמש לאימות ההעברה של Search Ads 360 במקום חשבון המשתמש שלכם.
bq mk \
--transfer_config \
--project_id=PROJECT_ID \
--target_dataset=DATASET \
--display_name=NAME \
--data_source=DATA_SOURCE \
--service_account_name=SERVICE_ACCOUNT_NAME \
--params='{PARAMETERS,"custom_columns":"[{\"id\": \"CC_ID\",\"destination_table_name\": [\"CC_DESTINATION_TABLE\"],\"bigquery_column_name\": \"CC_COLUMN\"}]","custom_floodlight_variables":"[{\"id\": \"CFV_ID\",\"cfv_field_name\": [\"CFV_FIELD_NAME\"],\"destination_table_name\": [\"CFV_DESTINATION_TABLE\"],\"bigquery_column_name_suffix\": \"CFV_COLUMN_SUFFIX\"}]"}'

כאשר:

  • ‫PROJECT_ID (אופציונלי): מציין באיזה פרויקט להשתמש. אם לא מציינים את הדגל, המערכת משתמשת בפרויקט שמוגדר כברירת מחדל.
  • DATASET: קבוצת הנתונים של היעד להגדרות ההעברה.

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

  • DATA_SOURCE: מקור הנתונים – search_ads.

  • ‫SERVICE_ACCOUNT_NAME (אופציונלי): שם חשבון השירות שמשמש לאימות של העברת הנתונים. חשבון השירות צריך להיות בבעלות של אותו project_id ששימש ליצירת ההעברה, וצריכות להיות לו כל ההרשאות הנדרשות.

  • ‫PARAMETERS: הפרמטרים של הגדרות ההעברה שנוצרו, בפורמט JSON. לדוגמה: --params='{"param":"param_value"}'. חובה לציין את הפרמטר customer_id.

    • ‫table_filter: מציין אילו טבלאות לכלול בהעברת הנתונים. אם לא מציינים את הדגל, כל הטבלאות נכללות. כדי לכלול רק טבלאות ספציפיות, משתמשים ברשימת ערכים שמופרדים בפסיקים (לדוגמה, Ad, Campaign, AdGroup). כדי להחריג טבלאות ספציפיות, מוסיפים מקף (-) לפני הערכים שרוצים להחריג (לדוגמה, שימוש ב--Ad, Campaign, AdGroup מחריג את כל שלושת הערכים).
    • ‫custom_columns: מציין עמודות בהתאמה אישית בדוחות. הפרמטר הזה מקבל קלט של מחרוזות בפורמט של מערך JSON ויכול לתמוך בכמה עמודות. בכל פריט במערך ה-JSON, צריך לציין את הפרמטרים הבאים:
      • ‫CC_ID: המזהה המספרי של העמודה בהתאמה אישית. המזהה הזה מוקצה כשיוצרים עמודה בהתאמה אישית.
      • ‫CC_DESTINATION_TABLE: רשימה של טבלאות ב-BigQuery שבהן רוצים לכלול את העמודה בהתאמה אישית. כששירות העברת הנתונים ל-BigQuery מאחזר נתונים לטבלאות האלה, העברת הנתונים כוללת את השדה של העמודה בהתאמה אישית בשאילתה.
      • ‫CC_COLUMN: שם העמודה הידידותי שהמשתמש הגדיר. זהו שם השדה של העמודה בהתאמה אישית בטבלאות היעד שצוינו ב-destination_table_name. שם העמודה צריך לעמוד בדרישות הפורמט של שמות עמודות ב-BigQuery, והוא חייב להיות ייחודי לשדות אחרים בסכימה הרגילה של הטבלה או לעמודות בהתאמה אישית אחרות.
    • ‫custom_floodlight_variables: מציין משתנים מותאמים אישית של Floodlight בהעברה. הפרמטר הזה מקבל קלט של מחרוזות בפורמט של מערך JSON, והוא יכול לתמוך בכמה משתנים מותאמים אישית של Floodlight. בכל פריט במערך ה-JSON, צריך לציין את הפרמטרים הבאים:
      • ‫CFV_ID: המזהה המספרי של משתנה Floodlight המותאם אישית. המזהה הזה מוקצה כשיוצרים משתנה מותאם אישית של Floodlight ב-Search Ads 360.
      • ‫CFV_FIELD_NAME: השם המדויק של השדה של משתנה Floodlight המותאם אישית, בהתאם לתרחיש לדוגמה. הערכים הנתמכים הם conversion_custom_metrics,‏ conversion_custom_dimensions,‏ raw_event_conversion_metrics ו-raw_event_conversion_dimensions. מידע נוסף זמין במאמר מדדי Floodlight בהתאמה אישית.
      • ‫CFV_DESTINATION_TABLE: רשימה של טבלאות ב-BigQuery שבהן ייכללו המשתנים המותאמים אישית של Floodlight. כששירות העברת הנתונים ל-BigQuery מאחזר נתונים לטבלאות האלה, העברת הנתונים כוללת את המשתנים המותאמים אישית של Floodlight בשאילתה.
      • ‫CFV_COLUMN_SUFFIX: שם העמודה הידידותי שהמשתמש הגדיר. שירות העברת הנתונים ל-BigQuery מוסיף את הסיומת אחרי שם השדה הרגיל כדי להבדיל בין משתני Floodlight שונים בהתאמה אישית. בהתאם לתרחיש לדוגמה, שירות העברת הנתונים ל-BigQuery יוצר שם עמודה ב-BigQuery באופן הבא:
    • ‫use_client_account_currency: מציינים את הערך TRUE כדי להשתמש במטבע של חשבון הלקוח לטעינת נתוני העלות, במקום במטבע של החשבון שבו משתמשים בהעברת הנתונים הזו.
    משתני Floodlight מותאמים אישית כמדדים ופלחים משתנים מותאמים אישית של Floodlight כמאפייני אירועים גולמיים במשאב ההמרות
    metrics metrics_conversion_custom_metrics_bigquery_column_name_suffix metrics_raw_event_conversion_metrics_bigquery_column_name_suffix
    dimension segments_conversion_custom_dimensions_bigquery_column_name_suffix segments_raw_event_conversion_dimensions_bigquery_column_name_suffix

לדוגמה, הפקודה הבאה יוצרת העברת נתונים של Search Ads 360 בשם My Transfer באמצעות מספר הלקוח 6828088731 ומערך הנתונים mydataset כיעד. ההעברה גם מציינת משתנה מותאם אישית של Floodlight. העברת הנתונים נוצרת בפרויקט ברירת המחדל:

bq mk \
--transfer_config \
--target_dataset=mydataset \
--display_name='My Transfer' \
--data_source=search_ads \
--params='{"customer_id":"6828088731", "custom_floodlight_variables":"[{\"id\": \"9876\", \"cfv_field_name\": \"raw_event_conversion_metrics\", \"destination_table_name\": [\"Conversion\"],\"bigquery_column_name_suffix\": \"suffix1\" }]"}'

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

[URL omitted] Please copy and paste the above URL into your web browser and follow the instructions to retrieve an authentication code.

פועלים לפי ההוראות שבהודעה ומדביקים את קוד האימות בשורת הפקודה.

API

משתמשים ב-method‏ projects.locations.transferConfigs.create ומספקים מופע של המשאב TransferConfig.

הפעלה ידנית של העברה מ-Search Ads 360

כשמפעילים העברה באופן ידני ב-Search Ads 360, המערכת יוצרת תמונות מצב של טבלאות התאמה פעם ביום ושומרת אותן במחיצה של תאריך ההרצה האחרון. כשמפעילים העברה ידנית, תמונות המצב של טבלאות ההתאמה הבאות לא מתעדכנות:

  • חשבון
  • מודעה
  • AdGroup
  • AdGroupCriterion
  • כל טבלת מיפוי מזהים
  • נכס
  • BidStrategy
  • מסע פרסום
  • CampaignCriterion
  • ConversionAction
  • מילת מפתח
  • NegativeAdGroupKeyword
  • NegativeAdGroupCriterion
  • NegativeCampaignKeyword
  • NegativeCampaignCriterion
  • ProductGroup

קמפיינים למיקסום הביצועים (PMax)

המחבר של Search Ads 360 מאפשר לייצא נתונים של קמפיינים למיקסום הביצועים. כשיוצרים העברת נתונים, צריך לסמן את התיבה Include PMax Campaign Data, כי נתוני הקמפיינים למיקסום הביצועים לא מיוצאים כברירת מחדל.

הכללת נתונים מקמפיינים למיקסום הביצועים מסירה ad_group שדות מטבלאות מסוימות וכוללת טבלאות חדשות. אי אפשר לכלול שדות של ad_group כי Search Ads 360 API מסנן את הנתונים של הקמפיינים למיקסום הביצועים.

הטבלאות הבאות לא כוללות עמודות שקשורות ל-ad_group כשתיבת הסימון Include PMax Campaign Tables מסומנת:

  • CartDataSalesStats
  • ProductAdvertised
  • ProductAdvertisedDeviceStats
  • ProductAdvertisedConversionActionAndDeviceStats

תמיכה בחשבונות ניהול ב-Search Ads 360

לשימוש בחשבונות ניהול ב-Search Ads 360 יש כמה יתרונות על פני שימוש במספרי לקוח נפרדים:

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

ללקוחות קיימים שיש להם כמה העברות נתונים של Search Ads 360 שספציפיות למספר לקוח, מומלץ לעבור במקום זאת לחשבון ניהול ב-Search Ads 360. כדי לעשות את זה:

  1. מגדירים העברת נתונים אחת של Search Ads 360 ברמת חשבון הניהול או חשבון הניהול המשני.
  2. תזמון מילוי חוסרים.
  3. משביתים העברות ספציפיות של Search Ads 360 לפי מספר לקוח.

מידע נוסף על חשבונות ניהול ב-Search Ads 360 זמין במאמרים מידע על חשבונות ניהול בממשק החדש של Search Ads 360 ואיך החשבונות מקושרים לחשבון הניהול.

דוגמה

ברשימה הבאה מוצגים מספרי הלקוחות שמקושרים לחשבונות ניהול מסוימים ב-Search Ads 360:

  • ‫1234567890 – חשבון הניהול הראשי
    • ‫1234 – חשבון ניהול משני
      • ‫1111 — מספר לקוח
      • ‫2222 — מספר לקוח
      • ‫3333 — מספר לקוח
      • ‫4444 – מספר לקוח
      • ‫567 – חשבון ניהול משני
        • ‫5555 — מספר לקוח
        • ‫6666 — מספר לקוח
        • ‫7777 — מספר לקוח
    • ‫89 — חשבון ניהול משני
      • ‫8888 — מספר לקוח
      • 9999 — מספר לקוח
    • 0000 — מספר לקוח

כל מספר לקוח שמקושר לחשבון ניהול מופיע בכל דוח. מידע נוסף על מבנה הדיווח של Search Ads 360 בשירות העברת הנתונים ל-BigQuery זמין במאמר טרנספורמציה של דוחות Search Ads 360.

הגדרות העברה למספר לקוח 1234567890

הגדרת העברה לחשבון הניהול ברמה הבסיסית (מספר לקוח 1234567890) יוצרת הפעלות של העברת נתונים שכוללות את מספרי הלקוחות הבאים:

  • ‫1111 (דרך חשבון ניהול משני 1234)
  • ‫2222 (דרך חשבון הניהול המשני 1234)
  • ‫3333 (דרך חשבון ניהול משני 1234)
  • ‫4444 (דרך חשבון הניהול המשני 1234)
  • ‫5555 (דרך חשבון ניהול משני 567 וחשבון ניהול משני 1234)
  • ‫6666 (דרך חשבון ניהול משני 567 וחשבון ניהול משני 1234)
  • ‫7777 (דרך חשבון ניהול משני 567 וחשבון ניהול משני 1234)
  • ‫8888 (דרך חשבון ניהול משני 89)
  • ‫9999 (דרך חשבון ניהול משני 89)
  • 0000 (מספר לקוח פרטי)

הגדרות העברה למספר לקוח 1234

הגדרת העברה לחשבון ניהול משני 123 (מספר לקוח 1234) יוצרת הפעלות של העברת נתונים שכוללות את מספרי הלקוחות הבאים:

  • 1111
  • 2222
  • 3333
  • 4444
  • ‫5555 (דרך חשבון הניהול המשני 567)
  • ‫6666 (דרך חשבון הניהול המשני 567)
  • 7777 (דרך חשבון הניהול המשני 567)

הגדרות העברה למספר לקוח 567

הגדרת העברה לחשבון ניהול משני 567 (מספר לקוח 567) יוצרת הפעלות של העברת נתונים שכוללות את מספרי הלקוחות הבאים:

  • 5555
  • 6666
  • 7777

הגדרות העברה למספר לקוח 89

הגדרת העברה לחשבון ניהול משני 89 (מספר לקוח 89) יוצרת הפעלות של העברת נתונים שכוללות את מספרי הלקוחות הבאים:

  • 8888
  • 9999

הגדרות העברה למספר לקוח 0000

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

  • 0000

שליחת שאילתות לגבי הנתונים

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

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

שאילתות לדוגמה ב-Search Ads 360

אתם יכולים להשתמש בשאילתות הבאות לדוגמה ב-Search Ads 360 כדי לנתח את הנתונים שהועברו. אפשר גם להציג את השאילתות בכלי להמחשה חזותית כמו Data Studio.

השאילתות הבאות הן דוגמאות לתחילת העבודה עם שאילתות על נתוני Search Ads 360 באמצעות שירות העברת נתונים ל-BigQuery. אם יש לכם שאלות נוספות לגבי מה שאפשר לעשות עם הדוחות האלה, פנו לנציג הטכני של Search Ads 360.

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

ביצועים ברמת הקמפיין

השאילתה לדוגמה הבאה מנתחת את ביצועים ברמת הקמפיין של Search Ads 360 ב-30 הימים האחרונים.

SELECT
  c.customer_id,
  c.campaign_name,
  c.campaign_status,
  SUM(cs.metrics_clicks) AS Clicks,
  (SUM(cs.metrics_cost_micros) / 1000000) AS Cost,
  SUM(cs.metrics_impressions) AS Impressions
FROM
  `DATASET.sa_Campaign_CUSTOMER_ID` c
LEFT JOIN
  `DATASET.sa_CampaignStats_CUSTOMER_ID` cs
ON
  (c.campaign_id = cs.campaign_id
  AND cs._DATA_DATE BETWEEN
  DATE_ADD(CURRENT_DATE(), INTERVAL -31 DAY) AND DATE_ADD(CURRENT_DATE(), INTERVAL -1 DAY))
WHERE
  c._DATA_DATE = c._LATEST_DATE
GROUP BY
  1, 2, 3
ORDER BY
  Impressions DESC

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DATASET: שם מערך הנתונים
  • ‫CUSTOMER_ID: מספר הלקוח ב-Search Ads 360

מספר מילות המפתח

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

  SELECT
    c.campaign_status AS CampaignStatus,
    a.ad_group_status AS AdGroupStatus,
    k.ad_group_criterion_status AS KeywordStatus,
    k.ad_group_criterion_keyword_match_type AS KeywordMatchType,
    COUNT(*) AS count
  FROM
    `DATASET.sa_Keyword_CUSTOMER_ID` k
    JOIN
    `DATASET.sa_Campaign_CUSTOMER_ID` c
  ON
    (k.campaign_id = c.campaign_id AND k._DATA_DATE = c._DATA_DATE)
  JOIN
    `DATASET.sa_AdGroup_CUSTOMER_ID` a
  ON
    (k.ad_group_id = a.ad_group_id AND k._DATA_DATE = a._DATA_DATE)
  WHERE
    k._DATA_DATE = k._LATEST_DATE
  GROUP BY
    1, 2, 3, 4

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DATASET: שם מערך הנתונים
  • ‫CUSTOMER_ID: מספר הלקוח ב-Search Ads 360

טבלאות מיפוי מזהים

לישויות בממשק החדש של Search Ads 360, כמו לקוחות, קמפיינים וקבוצות של מודעות, יש מרחב מזהים שונה מזה שבממשק הקודם של Search Ads 360. משתמשים קיימים של העברת נתונים מ-Search Ads 360 שרוצים לשלב נתונים מהממשק הישן של Search Ads 360 עם ה-Search Ads 360 API החדש, יכולים להשתמש בשירות העברת הנתונים ל-BigQuery כדי להעביר טבלאות מיפוי של מזהים. לשם כך, צריך לספק מזהה סוכנות ומזהה מפרסם תקינים בהגדרות ההעברה.

ישויות נתמכות מכילות שתי עמודות, legacy_id ו-new_id, שמציינות את מיפוי המזהים של ישויות בגרסאות הישנות והחדשות של Search Ads 360, בהתאמה. בישויות AD,‏ CAMPAIGN_CRITERION ו-CRITERION, מסופק גם new_secondary_id כי אין להן מזהים ייחודיים גלובליים בממשק החדש של Search Ads 360. הרשימה הבאה כוללת טבלאות של מיפוי מזהים.

  • IdMapping_AD
  • IdMapping_AD_GROUP
  • IdMapping_CAMPAIGN
  • IdMapping_CAMPAIGN_CRITERION
  • IdMapping_CAMPAIGN_GROUP
  • IdMapping_CAMPAIGN_GROUP_PERFORMANCE_TARGET
  • IdMapping_CRITERION
  • IdMapping_CUSTOMER
  • IdMapping_FEED_ITEM
  • IdMapping_FEED_TABLE

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

השאילתה הבאה משתמשת בטבלאות מיפוי מזהים כדי לצבור מדדים לכל קמפיין בטבלאות מהעברות נתונים קודמות וחדשות של Search Ads 360 במרחב המזהים החדש.

SELECT CustomerID, CampaignID, Sum(Clicks), Sum(Cost) FROM
(SELECT
  cs.customer_id AS CustomerID,
  cs.campaign_id AS CampaignID,
  cs.metrics_clicks AS Clicks,
  cs.metrics_cost_micros / 1000000 AS Cost
FROM
  `DATASET.sa_CampaignStats_CUSTOMER_ID` cs
WHERE cs._DATA_DATE = 'NEW_DATA_DATE'
UNION ALL
SELECT
  customer_id_mapping.new_id AS CustomerID,
  campaign_id_mapping.new_id AS CampaignID,
  cs.clicks AS Clicks,
  cs.cost AS Cost
FROM
  `DATASET.CampaignStats_ADVERTISER_ID` cs
LEFT JOIN
  `DATASET.IdMapping_CUSTOMER_ADVERTISER_ID` customer_id_mapping
ON cs.accountId = customer_id_mapping.legacy_id
LEFT JOIN
  `DATASET.IdMapping_CAMPAIGN_ADVERTISER_ID` campaign_id_mapping
ON cs.campaignId = campaign_id_mapping.legacy_id
WHERE cs._DATA_DATE = 'OLD_DATA_DATE')
GROUP BY
1, 2
ORDER BY
1, 2

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DATASET: שם מערך הנתונים
  • ‫CUSTOMER_ID: מספר הלקוח ב-Search Ads 360
  • ‫ADVERTISER_ID: מזהה המפרסם ב-Search Ads 360
  • NEW_DATA_DATE: תאריך הנתונים בטבלה של הממשק החדש של Search Ads 360
  • OLD_DATA_DATE: תאריך הנתונים בטבלה של הממשק הקודם של Search Ads 360

השאילתה הבאה משתמשת בטבלאות מיפוי מזהים כדי לצבור מדדים לכל קמפיין בטבלאות מהעברות נתונים קודמות וחדשות של Search Ads 360 במרחב המזהים הישן.

SELECT CustomerID, CampaignID, Sum(Clicks), Sum(Cost) FROM
(SELECT
  customer_id_mapping.legacy_id AS CustomerID,
  campaign_id_mapping.legacy_id AS CampaignID,
  cs.metrics_clicks AS Clicks,
  cs.metrics_cost_micros / 1000000 AS Cost
FROM
  `DATASET.sa_CampaignStats_CUSTOMER_ID` cs
LEFT JOIN
  `DATASET.IdMapping_CUSTOMER_ADVERTISER_ID` customer_id_mapping
ON cs.customer_id = customer_id_mapping.new_id
LEFT JOIN
  `DATASET.IdMapping_CAMPAIGN_ADVERTISER_ID` campaign_id_mapping
ON cs.campaign_id = campaign_id_mapping.new_id
WHERE cs._DATA_DATE = 'NEW_DATA_DATE'
UNION ALL
SELECT
  CAST(accountId AS INT) AS CustomerID,
  CAST(campaignId AS INT) AS CampaignID,
  cs.clicks AS Clicks,
  cs.cost AS Cost
FROM
  `DATASET.CampaignStats_ADVERTISER_ID` cs
WHERE cs._DATA_DATE = 'OLD_DATA_DATE')
GROUP BY
1, 2
ORDER BY
1, 2

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DATASET: שם מערך הנתונים
  • ‫CUSTOMER_ID: מספר הלקוח ב-Search Ads 360
  • ‫ADVERTISER_ID: מזהה המפרסם ב-Search Ads 360
  • NEW_DATA_DATE: תאריך הנתונים בטבלה של הממשק החדש של Search Ads 360
  • OLD_DATA_DATE: תאריך הנתונים בטבלה של הממשק הקודם של Search Ads 360

בעיות אפשריות במכסות

‫Search Ads 360 Reporting API מקצה מכסה למספר הבקשות שהפרויקט ב-Google יכול לשלוח. אם אתם משתמשים בפרויקט אחד לשירות העברת הנתונים ל-BigQuery ולשירותים אחרים, כל השירותים חולקים את אותה מכסה ויכולים להגיע למגבלת המכסה בכל שירות.

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

  • משתמשים בפרמטר table_filter כדי לטעון רק את הטבלאות שצריך.

  • מגדירים פרויקט נפרד לשירות העברת הנתונים ל-BigQuery. צירוף טבלאות בין פרויקטים יכול להיראות כך: 

      #standardSQL
  select count(a.item1)
  from (select item1, item2 from project-A.data_set_a.table_name_a) a
  inner join
  (select item3, item4 from project-B.data_set_b.table_name_b) b
  on a.item1 = b.item3

  • פונים אל התמיכה של Search Ads 360 ומבקשים להגדיל את המכסה.