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

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

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

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

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

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

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