מעקב המרות

סיכום

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

כדי להשלים את השילוב, צריך לבצע את הפעולות הבאות:

1. איסוף ואחסון של rwg_token.
2. איסוף ואחסון של המוכר.
3. החזרת הערכים rwg_token ו-merchant_change.
4. בודקים ומאמתים את מעקב ההמרות.

איסוף ואחסון של rwg_token.

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

איסוף אסימונים

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

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

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

AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==

אחסון אסימונים

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

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

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

כדאי להביא בחשבון את הנקודות הבאות כשמחליטים איפה לאחסן את rwg_token.

אחסון ברמת המכשיר

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

אחסון ברמת המשתמש

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

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

רענון הטוקן

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

פרטים נוספים זמינים בדרישות בנוגע לשיוך המרות.

איסוף ואחסון של המוכר.

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

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

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

מחזירה את הערכים rwg_token ו-merchant_change.

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

• ייצור: https://www.google.com/maps/conversion/collect
• Sandbox: https://www.google.com/maps/conversion/debug/collect

כששולחים אירוע המרה, חובה לכלול את הערך השמור של rwg_token וגם ערך merchant_change של 1 או 2. פרטים נוספים על merchant_change זמינים במאמר החזרת הערך של שינוי המוכר.

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

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

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

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

החזרת הערך של שינוי המוכר

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

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

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

בודקים ומאמתים את מעקב ההמרות.

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

1. ביצוע הזמנה באמצעות קישור לפעולה
   • הזמנות ישירות ללא הפניה או אסימונים שנשמרו בעבר לא אמורות לגרום לשליחת בקשה ל-Google.
2. השלמת הזמנה באמצעות קישור עם rwg_token מצורף.
   • מוודאים שהבקשה נשלחה בהצלחה עם הערך rwg_token ו-merchant_change של 2
   • חשוב לוודא שאתם שומרים את rwg_token למשך 30 יום
3. השלמת הזמנה חדשה אצל אותו מוכר באמצעות מחיר חדש של rwg_token.
   • מוודאים שהבקשה נשלחה בהצלחה עם הערכים החדשים של rwg_token ו-merchant_change ב-2
   • מוודאים שחלון האחסון של השיוך של האסימון מתעדכן למשך 30 יום
4. עוברים ישירות לדף ההזמנות של המוכר שבדקתם, ומבצעים הזמנה חדשה בלי הוספת rwg_token.
   • חשוב לוודא שהבקשה נשלחת עם הערך של rwg_token ששמור קודם לכן והערך של merchant_change הוא 2

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

1. עוברים לדף ההזמנות של המוֹכר באמצעות קישור עם הסיומת rwg_token, ואז עוברים למוֹכר אחר ומבצעים הזמנה.
   • מוודאים שהבקשה נשלחת עם הערך rwg_token ו-merchant_change של 1

בזמן הבדיקה, שולחים את בקשת ה-HTTP POST לנקודת הקצה של ההמרה. יש שתי נקודות קצה, אחת לסביבת הייצור ואחת לסביבת ארגז החול.

• ייצור: https://www.google.com/maps/conversion/collect
• Sandbox: https://www.google.com/maps/conversion/debug/collect

צריך לצרף את האסימון הבא לקישור או לכתובת ה-URL של הפעולה:

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

צריך להשתמש באסימון הבא לבדיקות שמחייבות אסימונים נוספים.

rwg_token=AJKvS9U2QfiQanHFQrlJxBjD0AyFany3qpaJVEWOcY4nHqY_UkLYFFDj6RIa-EXS1iEmV8gtFPG6v1cU1jnusJK66ijXXnaqkQ%3D%3D

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

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

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

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

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

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

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

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

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