שלב 3: מעקב המרות

הטמעה

סיכום

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

1. איסוף הערך של rwg_token מדף הנחיתה או מנקודת הכניסה לאפליקציה.
2. שמירה של rwg_token בחלון השיוך המתאים
3. שליחת אירוע המרה בקופה

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

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

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

איסוף ה-rwg_token

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

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

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

<script>
  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;
    }
  }
</script>

שמירת rwg_token

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

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

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

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

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

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

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

כשמשתמש משלים עסקה שאפשר לשייך לקישור של פעולה ב-Google Places, צריך לשלוח בקשת HTTP POST לנקודת הקצה של ההמרה. יש שתי נקודות קצה, אחת לסביבת הייצור ואחת לסביבת Sandbox.

• ייצור: https://www.google.com/maps/conversion/collect
• ארגז חול: https://www.google.com/maps/conversion/debug/collect

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

{
  'conversion_partner_id': partnerId,
  'rwg_token': <rwg_token_val>
}

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

AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==

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

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
    })
  });
}

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

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

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

חלון השיוך הזה אומר שאנחנו מצפים שאירוע המרה יישלח בכל אחד מהתרחישים הבאים:

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

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

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

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

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