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

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

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

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

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

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

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

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