מעקב המרות

אזהרה: יש לוודא שכחלק מנתוני ההמרות, פרטי הזיהוי האישי של המשתמש מידע (PII) לא נשלח ל-Google.

הטמעה

סיכום

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

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

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

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

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

בהמשך מוצגת דוגמה למעקב המרות ברמת המכשיר, שבו הערכים האלה נשמרים בדפדפן אינטרנט באמצעות קובץ 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 קישור לפעולה, צריך לשלוח בקשת HTTP POST לנקודת הקצה של ההמרה. יש שתי נקודות קצה, אחת לסביבת הייצור ואחת בסביבת Sandbox.

  • הפקה: 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==

כדי לבצע בדיקה ב-Sandbox, עליך להוסיף ידנית את הפרמטר הבא של כתובת אתר ל- קישורי Sandbox שלך:

rwg_token=AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ%3D%3D

דוגמה מלאה למעקב המרות ברמת המכשיר (באמצעות קובץ 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
    })
  });
}

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

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

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

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

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

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

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

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

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