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

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

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

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

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

קוד שגיאה
QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION או QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION בהתאם למשך הזמן של השימוש הגבוה במשאבים.

אם נתקלתם בשגיאות האלה, המתינו 5 דקות לפני שתנסו שוב לשלוח בקשות שנכשלו עם QuotaError.EXCESSIVE_SHORT_TERM_QUERY_RESOURCE_CONSUMPTION, ו-30 דקות לבקשות שנכשלו עם QuotaError.EXCESSIVE_LONG_TERM_QUERY_RESOURCE_CONSUMPTION.

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

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

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

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

בטבלה הבאה מפורטים נתונים סטטיסטיים מצטברים על צריכת המשאבים של מבני שאילתות שונים בשרתי 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	3000
לטווח ארוך (24 שעות)	26	150	14000

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

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

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

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

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

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

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

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

  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(customerId, query);

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

    if (adGroupIds.Contains(adGroupId))
    {
      CheckAndAddRowIntoMemoryMap(row, adGroupId, memoryMap);
    }
  }
  foreach (KeyValuePair<long, List<GoogleAdsRow>> entry in memoryMap)
  {
    InsertRowsIntoStatsTable(entry.Key, entry.Value);
  }

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