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

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

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

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

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

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

• שדות להכללה:

  • 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
  

עיבוד לאחר מכן וחילוץ נתונים

• מיפוי של פלחים גיאוגרפיים: ממשק ה-API לא מחזיר שמות בטקסט פשוט (כמו 'ניו יורק') או קודים קצרים (כמו '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 גולמיים.

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

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