מעקב המרות

הטמעה

סיכום

ההטמעה של מעקב המרות מורכבת משלושה חלקים:

  • איסוף של rwg_token ו-merchant_id מדף הנחיתה או מנקודת הכניסה לאפליקציה.
  • שימוש קבוע ב-rwg_token וב-merchant_id בשביל חלון השיוך (Attribution) המתאים.
  • ההשוואה בין merchant_id לבין merchant_id במועד ההמרה (ההזמנה הושלמה).
  • שליחת אירוע המרה בזמן ההמרה (ההזמנה הושלמה).

כדי להטמיע את מעקב ההמרות הזה, לא צריך להשתמש ב-Google Analytics או בכל JavaScript אחר של צד שלישי.

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

  • ברמת המכשיר נכללים שימוש בקובצי cookie של הדפדפן, באחסון מקומי, באחסון מקומי של אפליקציה או בכל שיטה אחרת שיכולה לשמור את האסימון למשך חלון השיוך (Attribution) למשך 30 יום. מכיוון שהאסימון יאוחסן באופן מקומי במכשיר של המשתמש, אם המשתמש משנה את המכשיר שבו הוא משתמש, מנקה את האחסון המקומי או את קובצי ה-Cookie או משתמש בגלישה פרטית או במצב פרטי, יכול להיות שאירוע ההמרה לא משויך כראוי. כשמשתמשים במעקב המרות ברמת המכשיר, צריך להטמיע אותו מחדש בכל פלטפורמה נתמכת (כולל בנייד).
  • ברמת המשתמש תוכלו לשמור את הנתונים במסד הנתונים של האפליקציות, דרך מערכת ניתוח נתונים בצד השרת או מערכות אחרות בצד השרת. מכיוון שהאסימון יאוחסן בצד השרת, אם המשתמש משנה את המכשיר שבו הוא משתמש, מוחק את האחסון המקומי או את קובצי ה-cookie או משתמש במצב גלישה פרטית או במצב פרטי, אירוע ההמרה עדיין ישויך ברגע שהמשתמש יתחבר שוב. כשמשתמשים במעקב המרות ברמת המשתמש, בהתאם לארכיטקטורה של המערכת, אפשר להטמיע אותו פעם אחת בצד השרת ולעשות בו שימוש חוזר בכל הפלטפורמות הנתמכות.

מתבצע איסוף של rwg_token

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

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

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

var query = location.search.substring(1);
var params = query.split('&');
var rwgToken = undefined;
for (var i = 0; i < params.length; ++i) {
  var pair = params[i].split('=');
  if (pair[0] == 'rwg_token') {
    rwgToken = decodeURIComponent(pair[1]);
    break;
  }
}

מתבצע איסוף של merchant_id

אם מטמיעים את הלוגיקה של מעקב ההמרות בקצה הקדמי, צריך להטמיע בדף הנחיתה סקריפט בהתאמה אישית שימצא ויתעד את merchant_id. בדרך כלל, merchant_id כבר מופיע בדף הנחיתה או בכתובת ה-URL, כך שאפשר לצלם אותו משם. אם לא, צריך למצוא דרך לחשוף אותו במקום כלשהו כדי שניתן יהיה להשתמש בו, וסביר להניח שהדבר יגרום לשינויים בקצה העורפי.

אם מטמיעים את הלוגיקה של מעקב ההמרות בקצה העורפי, יכול להיות שה-merchant_id יופיע לצד הנתונים שמריצים שאילתות במערכת הפנימית כדי ליצור את דף הקצה הקדמי.

ה-merchant_id הזה חייב להיות זהה לזה ששיתפתם עם Google בפיד.

שימוש קבוע ב-rwg_token וב-merchant_id

תצטרכו לשמור את הפרמטר rwg_token של כתובת ה-URL, שיצורף לכל קישורי הפעולות שסיפקתם, למשך תקופה כוללת של 30 יום. יש לשמור ולהחזיר את הערך של rwg_token ללא עריכות.

בנוסף ל-rwg_token, צריך לאחסן את גם merchant_id שמשויך לקישור לפעולה.

אם קיים אסימון קיים מביקור קודם, צריך להחליף את rwg_token ואת merchant_id הקודמים, ולאפס את חלון 30 הימים לאחסון.

אם שומרים את הצמדה שלמעלה, אפשר לאחסן את הערכים ברמת המכשיר או ברמת המשתמש:

  • ברמת המכשיר נכללים שימוש בקובצי cookie של הדפדפן, באחסון מקומי, באחסון מקומי של אפליקציה או בכל שיטה אחרת שיכולה לשמור את האסימון למשך חלון השיוך (Attribution) למשך 30 יום.
  • ברמת המשתמש תוכלו לשמור את הנתונים במסד הנתונים של האפליקציות, דרך מערכת ניתוח נתונים בצד השרת או מערכות אחרות בצד השרת.

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

if (typeof rwg_token !== 'undefined') {
  document.cookie =
  "_rwg_token=" + rwg_token + ";_merchant_id=" + merchantid + ";max-age=2592000;domain=rootdomain.com;path=/";
}

כשמשתמשים במעקב המרות ברמת המשתמש, צריך לאחסן את rwg_token + merchant_id בשרת ולשייך אותו למשתמש.

שליחת נתוני המרות

כשמשתמש משלים עסקה שאפשר לשייך לקישור של Google Place Action צריך לשלוח בקשת HTTP POST לנקודת הקצה של ההמרה. יש שתי נקודות קצה, אחת לסביבת הייצור ואחת לסביבת ארגז החול.

  • הפקה: https://www.google.com/maps/conversion/collect
  • Sandbox: https://www.google.com/maps/conversion/debug/collect

גוף הפוסט צריך להיות אובייקט בקידוד JSON בפורמט:

{
  "conversion_partner_id": <partnerId>,
  "rwg_token": <rwg_token_val>,
  "merchant_changed": 1|2
}

דוגמה (מוכר שלא השתנה עם אסימון הבדיקה של השותף 20123456):

{
  "conversion_partner_id": 20123456,
  "rwg_token": "AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==",
  "merchant_changed": 2
}

הערך merchant_Change משמש כדי לקבוע אם המוכר השתנה מהמוכר הראשוני להפניה אוטומטית. יש שני ערכים שאפשר להעביר

ערך שינוי במוֹכר דרישה
1 צריך להשתמש בערך הזה כשמשתמש עזב את האתר של המוכר המקורי והשלים רכישה דרך הפלטפורמה דרך מוכר אחר
2 צריך להשתמש בערך הזה כשהלקוח השלים עסקה דרך הישות המקורית (מוכר).

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

AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==

בהמשך מוצגת דוגמה מלאה למעקב המרות ברמת המכשיר (באמצעות קובץ cookie במכשיר של המשתמש) ב-JavaScript, שממחיש איך ליצור את בקשת הפרסום:

const partnerId = XXXXXXXXXX;

const endpoint = `https://www.google.com/maps/conversion/collect`;

const rwgTokenCookie = document.cookie
  .split('; ')
  .find(row => row.startsWith('_rwg_token='));

if (typeof rwgTokenCookie !== 'undefined') {
  const rwgTokenVal = rwgTokenCookie.split('=')[1];
  fetch(endpoint, {
    method: "POST",
    body: JSON.stringify({
      conversion_partner_id: partnerId,
      rwg_token: rwgTokenVal,
      merchant_changed: merchantChanged
    })
  });
}

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

דרישות לשיוך המרות

ברירת המחדל של Google לשיוך המרות היא חלון שיוך (Attribution) של 30 יום לכל אינטראקציה עם קישור למקום, בכל חנות.

המשמעות של חלון השיוך (Attribution) היא ש-Google תצפה שאירוע המרה יישלח בכל אחד מהתרחישים הבאים:

  • משתמש לוחץ על קישור לפעולה לגבי מקום ומבצע הזמנה לאותו מוכר באותו סשן. (ערך השינוי של המוכר = 2 )
  • משתמש לוחץ על קישור לפעולה לגבי מקום, ואז חוזר מערוץ אחר בתוך 30 יום כדי לבצע הזמנה לאותו מוכר. (ערך השינוי של מוכר = 2 )
  • משתמש לוחץ על קישור לפעולה לגבי מקום ואז מבצע הזמנה בחנות אחרת, באותו סשן או בסשן אחר בחלון זמן של 30 יום. ( ערך השינוי במוכר = 1 )

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

  • אפליקציות אינטרנט למחשב או לנייד
  • אפליקציות לנייד, באמצעות קישור עומק לאפליקציה או באמצעות כוונה רשומה של האפליקציה בדומיין

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

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

הקודם
פידים
הבא
בדיקת השילוב