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

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

סקירה כללית של מחברים

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

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

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

רענון חלונות

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

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

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

מגבלות

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

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

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

• מוודאים שביצעתם את כל הפעולות שנדרשות כדי להפעיל את שירות העברת נתונים ל-BigQuery.
• יוצרים מערך נתונים בשירות העברת הנתונים ל-BigQuery כדי לאחסן את נתוני הדיווח של Search Ads 360.
• אם אתם רוצים להגדיר התראות על הפעלת העברה ב-Pub/Sub, אתם צריכים הרשאות pubsub.topics.setIamPolicy. אם מגדירים רק התראות באימייל, לא צריך הרשאות Pub/Sub. מידע נוסף זמין במאמר בנושא התראות על הפעלת שירות העברת נתונים ל-BigQuery.
• מאפשרים גישה ל-Search Ads 360 Reporting API בפרויקט.

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

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

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

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

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

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

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

Cloud de Confiance by S3NS תפקידים נדרשים

כדי להוריד נתונים מ-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 או חשבון ניהול. בוחרים באחת מהאפשרויות הבאות:

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\"}]"}'

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\" }]"}'

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