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

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

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

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

גרסת ממשק API	קוד שגיאה
<= גרסה 17	QuotaError.RESOURCE_EXHAUSTED
>= v18	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	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, מה שמוביל להגבלת קצב של יצירת הבקשות ולויסות נתונים (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. כל שאר העמודות מתעדכנות בתדירות נמוכה או לא מתעדכנת ב- הכול, לכן מאוד לא יעיל לאחזר אותם כל שעה. אפשר לאחסן את התמונות האלה במסד נתונים מקומי ולהריץ אירוע שינוי, שינוי סטטוס כדי להוריד שינויים פעם או פעמיים ביום.

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

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

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

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