שליפת נתונים גיאוגרפיים לניסויים

כדי לשלוף נתונים באופן אוטומטי או בקנה מידה גדול לצורך ניסויי GeoX, צריך להשתמש ב-Google Ads API כדי לשלוף נתוני עלות והוצאות. לאחר מכן, אתם משלבים את הנתונים האלה עם נתונים גולמיים, לא מסוננים וללא שיוך של המרות או הכנסות ממערכת ה-CRM הפנימית, מנקודת מכירה (POS) או ממסדי נתונים פנימיים של מכירות.

ארכיטקטורה מומלצת לתהליך עבודה של API

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

• שירות: משתמשים ב-GoogleAdsService, באופן ספציפי ב-methods‏ Search או SearchStream.

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

  הערה: אל תשתמשו ב-campaign_location_target_report, כי הדוח הזה של AdWords API מדור קודם הוצא משימוש.

• שדות שצריך לכלול:

  • campaign.id
  • segments.date
  • segments.geo_target_city (או אזור או מדינה, בהתאם לרמת הפירוט של GeoX)
  • metrics.cost_micros

• שאילתת GAQL לדוגמה: כדי להשתמש ב-GeoX, המפרסמים שולפים מדדי עלות באמצעות Google Ads API במקום המרות משויכות (שאמורות להגיע ממערכות CRM פנימיות או ממערכות של צד שלישי). אפשר להשתמש בשאילתה הבאה:

  SELECT
    campaign.id,
    segments.date,
    segments.geo_target_city,
    metrics.cost_micros
  FROM geographic_view
  WHERE segments.date DURING LAST_30_DAYS
  

  הערה: geographic_view מחזיר רק שורות של פלחים גיאוגרפיים שבהם תועדו חשיפות או הוצאות בתאריך נתון. כדי לכלול ימים ואזורים שבהם לא היו הוצאות בסדרת הזמן של GeoX, צריך לבצע צירוף חיצוני שמאלי (left outer join) בפייפליין של הנתונים, מול המכפלה הקרטזית המלאה של התאריכים ואזורי היעד.

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

עיבוד לאחר סריקה וחילוץ נתונים

• מיפוי פלחים גיאוגרפיים: ה-API לא מחזיר שמות בטקסט פשוט (כמו "New York") או קודים קצרים (כמו "501" או "ES") בתצוגות דוחות. שדות כמו segments.geo_target_city או segments.geo_target_country מחזירים מחרוזת של שם משאב שמפנה אל GeoTargetConstant (לדוגמה, geoTargetConstants/1023191). מחלצים את המזהה המספרי (1023191) ושולחים שאילתה למשאב geo_target_constant:

  SELECT
    geo_target_constant.id,
    geo_target_constant.name,
    geo_target_constant.canonical_name
  FROM geo_target_constant
  WHERE geo_target_constant.id = 1023191
  

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

• המרת עלות: ה-API מחזיר ערכי עלות במיקרו-יחידות. צריך לחלק את הערך metrics.cost_micros ב-1,000,000 כדי לקבל את ערך המטבע הסטנדרטי שנדרש בקובץ ההעלאה.

מזהי מיקום גיאוגרפי למוטציות טירגוט

כשמבצעים שינויים בטירגוט למיקום גיאוגרפי ברמת הקמפיין או קבוצת המודעות, המפרסמים צריכים לחפש את המזהה המדויק של GeoTargetConstant (geoTargetConstants/ID) באזורים שנבחרו ולהעביר אותו. אי אפשר להעביר קודי ISO או Nielsen גולמיים.

סוג האזור	מזהה ה-API הנדרש (GeoTargetConstant)	פורמט מדור קודם (אין להשתמש)
אזור DMA (אזור שוק ייעודי)	מזהה 200501 (לניו יורק)	קוד Nielsen (לדוגמה, 501 לניו יורק)
מדינה	מזהה 2724 (לספרד)	קוד ISO (לדוגמה, "ES" לספרד)

שיטות מומלצות ושגיאות עיצוב נפוצות

• פורמט התאריך: השדה segments.date מחזיר מחרוזות תאריכים בפורמט ISO-8601, בפורמט YYYY-MM-DD. בצינור עיבוד הנתונים של ה-ETL, צריך להמיר את שדות התאריכים באופן מפורש למחרוזות YYYY-MM-DD, ולהימנע מפתיחת קובצי CSV שיוצאו באפליקציות של גיליונות אלקטרוניים שמשנות באופן אוטומטי את הפורמט של עמודות התאריכים.
• אפסים בתחילת המיקוד: התייחסו למיקוד (לדוגמה, 01234) כסוגי מחרוזות (VARCHAR או STRING) לאורך כל צינור עיבוד הנתונים, ולא כמספרים שלמים, כדי שהאפסים בתחילת המיקוד לא יוסרו.
• צבירה: אם אתם מפעילים מחקר עם כמה קבוצות, אתם צריכים לספק מדדי הוצאות נפרדים לכל קבוצת ניסוי.
• צירוף נתוני המרות: כשמצרפים נתוני המרות ממערכת CRM פנימית או ממסדי נתונים פנימיים של מכירות, צריך לוודא שלנתוני ההמרות יש את המאפיינים הבאים כדי להבטיח עיבוד חלק של הנתונים עם נתוני Google Ads API ו-GeoX:
  • סדרת זמנים יומית: הנתונים צריכים להיות מקובצים לפי יום.
  • רמה גיאוגרפית: כל המרה צריכה להיות ממופה ליחידות הגיאוגרפיות המדויקות שאתם בודקים (לדוגמה, התאמה בין המיקוד למשלוח של הלקוח לבין אזור השיווק או אשכול המיקודים שבהם השתמשתם בתכנון).
  • ערכי ברוטו: הנתונים חייבים להיות ערכים מוחלטים לא שליליים, כמו הכנסה ברוטו או מספר המרות ברוטו. אם מערכת ה-CRM שלכם עוקבת אחרי הכנסות נטו עם ערכים שליליים להחזרים כספיים, אתם צריכים להשתמש במספרים ברוטו בניסוי ולהחיל יחס החזרים כספיים מאוחר יותר.