טעינת נתונים מ-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 reports.

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

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

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

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

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

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

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

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

מגבלות

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

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

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

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

ודאו שהענקתם את ההרשאות הבאות.

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

כדי לקבל את ההרשאות שנדרשות ליצירת העברת נתונים באמצעות שירות העברת נתונים ל-BigQuery, צריך לבקש מהאדמין להקצות לכם את תפקיד BigQuery Admin ‏ (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. עוברים לדף 'העברות נתונים' במסוף Google Cloud .

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

  2. לוחצים על Create transfer (יצירת העברה).

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

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

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

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

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

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

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

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

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

    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: מציינים 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

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

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

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

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

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

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

אתם יכולים להשתמש בשאילתות לדוגמה הבאות של Search Ads 360 כדי לנתח את הנתונים שהועברו. אפשר גם להציג את השאילתות בכלי להמחשה חזותית כמו Looker 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 ומבקשים להגדיל את המכסה.