ניהול יעיל של נתונים

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

הסבר על מדיניות השימוש של Google במשאבים בדוחות

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

גרסת ממשק API	קוד שגיאה
<= v16	QuotaError.RESOURCE_EXHAUSTED
>= v17	QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION או QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION, בהתאם למשך הזמן של שימוש ארוך במשאבים.

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

שיטה	שדה עלות
GoogleAdsService.Search	SearchGoogleAdsResponse.query_resource_consumption
GoogleAdsService.SearchStream	SearchGoogleAdsStreamResponse.query_resource_consumption

מדד העלות שמוחזר מהשדות האלה תלוי בגורמים שונים, כמו

• גודל החשבונות
• התצוגות והעמודות שמאחזרים בדוחות
• העומס על שרתי Google Ads API.

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

חלון זמן	ממוצעת (p50).	P70 (גבוה למדי)	P95 (גבוה מאוד)
תקופה קצרה (5 דקות)	6000	30000	1800000
טווח ארוך (24 שעות).	16000	90000	8400000

לדוגמה, נניח שאתם מריצים דפוס שאילתה באופן הבא, שצורכת 600 יחידות של משאבים לכל דוח.

SELECT campaign.id, campaign.name, metrics.cost_micros FROM campaign WHERE
    segments.date = "YYYY-MM-DD"

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

חלון זמן	ממוצעת	די גבוהה	גבוה מאוד
תקופה קצרה (5 דקות)	10	50	3,000
טווח ארוך (24 שעות).	26	150	14000

הרצת דפוס השאילתה 10 פעמים ב-5 דקות תיחשב לשימוש ממוצע, והרצת 3,000 דוחות ב-5 דקות תיחשב כשימוש גבוה מאוד.

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

שמירת הנתונים במטמון

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

ביצוע אופטימיזציה לתדירות של הרצת דוחות

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

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

אופטימיזציה של גודל הדוחות

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

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

  List<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  foreach (long adGroupId in adGroupIds)
  {
    string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
        "metrics.cost_micros, metrics.impressions, segments.date FROM " +
        "ad_group WHERE segments.date DURING LAST_7_DAYS AND " +
        "ad_group.id = ${adGroupId}";
    List<GoogleAdsRow> rows = RunGoogleAdsReport(customerId, query);
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

הקוד הזה פועל היטב בחשבון בדיקה קטן. עם זאת, Google Ads תומכת ב-20,000 קבוצות של מודעות לכל היותר בכל קמפיין וב-10,000 קמפיינים בכל חשבון. לכן, אם הקוד הזה פועל בחשבון Google Ads גדול, הוא עלול לגרום לעומס יתר על השרתים של Google Ads API, דבר שמוביל להגבלת קצב של יצירת בקשות ולויסות נתונים (throttle).

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

  Hashset<long> adGroupIds = FetchAdGroupIdsFromLocalDatabase();

  string query = "SELECT ad_group.id, ad_group.name, metrics.clicks, " +
      "metrics.cost_micros, metrics.impressions, segments.date FROM " +
      "ad_group WHERE segments.date DURING LAST_7_DAYS";
  List<GoogleAdsRow> rows = RunGoogleAdsReport(customer_id, query);

  var memoryMap = new Dictionary<long, List<GoogleAdsRow>>();
  for each (GoogleAdsRow row in rows)
  {
    var adGroupId = row.AdGroup.Id;

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (long adGroupId in memoryMap.Keys())
  {
    InsertRowsIntoStatsTable(adGroupId, rows);
  }

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

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

SELECT
  ad_group.id,
  ad_group.name,
  metrics.clicks,
  metrics.cost_micros,
  metrics.impressions,
  segments.date
FROM ad_group
WHERE segments.date DURING LAST_7_DAYS
  AND ad_group.id IN (id1, id2, ...)
LIMIT 100000

תוויות הן דרך נוספת לקבץ ישויות ולהפחית את מספר השאילתות לדיווח. למידע נוסף, אפשר לעיין במדריך התוויות.

אופטימיזציה של מה שמאחזרים

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

SELECT
  customer.id,
  customer.currency_code,
  campaign.id,
  campaign.name,
  ad_group.id,
  ad_group.name,
  ad_group_criterion.keyword.match_type,
  ad_group_criterion.keyword.text,
  ad_group_criterion.criterion_id,
  ad_group_criterion.quality_info.creative_quality_score,
  ad_group_criterion.system_serving_status,
  ad_group_criterion.negative,
  ad_group_criterion.quality_info.quality_score,
  ad_group_criterion.quality_info.search_predicted_ctr,
  ad_group_criterion.quality_info.post_click_quality_score,
  metrics.historical_landing_page_quality_score,
  metrics.search_click_share,
  metrics.historical_creative_quality_score,
  metrics.clicks,
  metrics.impressions
FROM keyword_view
WHERE segments.date DURING LAST_7_DAYS

העמודות היחידות שעשויות להשתנות בכל שעה הן metrics.clicks ו-metrics.impressions. כל העמודות האחרות מתעדכנות לעתים רחוקות או כלל לא, ולכן מאוד לא יעיל לאחזר אותן מדי שעה. תוכלו לאחסן את הערכים האלה במסד נתונים מקומי ולהריץ דוח change-event או change-status כדי להוריד שינויים פעם או פעמיים ביום.

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

ניקוי חשבונות שלא נמצאים בשימוש

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

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