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

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

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

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

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

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

  • שאילתת 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 גולמיים.

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