מעקב המרות

סיכום

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

• ייצור: 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 יום כדי לבצע הזמנה אצל אותו מוכר. (Merchant Change Value = 2 )
• משתמש עוקב אחרי קישור לפעולה במקום מסוים, ולאחר מכן מבצע הזמנה בחנות אחרת, באותו סשן או בסשן אחר בחלון זמן של 30 יום. ( ערך השינוי של Merchant = 1)

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

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

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

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