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

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

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

הערה: הקטע הזה מתייחס לשינוי שיחול בקרוב ב-Google Ads API. מידע נוסף זמין בפוסט הזה בבלוג.

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

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

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

שיטה	שדה Cost
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	3000
לטווח ארוך (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, וכתוצאה מכך להגבלת קצב שליחת הבקשות ולצמצום הקצב.

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

  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 של הלקוח.