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

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

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

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

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

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

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

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

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

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

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

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

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