מעקב המרות

איור 2: סקירה כללית על מעקב המרות

סקירה כללית

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

כדי להשלים את השילוב:

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

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

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

ניתוח הטוקן

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

בדוגמה הבאה מוסבר איך מתבצע הניתוח של 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;
  }
}

האסימון שמצורף לכתובת ה-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=/";
}

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

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

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

  • משנים את המכשיר שבו הם משתמשים.
  • ניקוי האחסון המקומי או קובצי ה-cookie.
  • משתמשים בדפדפן פרטי או בדפדפן אנונימי.

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

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

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

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

רענון הטוקן

כש-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_changed

כשמשתמש משלים הזמנה שהתחילה בהפניה action_link, צריך לשלוח בקשת HTTP POST לנקודת הקצה של ההמרה. יש שתי נקודות קצה:

  • סביבת ייצור: https://www.google.com/maps/conversion/collect
  • סביבה ב-Sandbox: https://www.google.com/maps/conversion/debug/collect

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

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

  • דרישה: כשמשתמש יוצא מהאתר המקורי של המוכר ומשלים רכישה דרך הפלטפורמה שלכם עם מוכר אחר.
    • Merchant change value: ‏ 1
  • דרישה: כשהמשתמש משלים עסקה דרך המוֹכר המקורי.
    • Merchant change value: ‏ 2

בדיקה ואימות של מעקב ההמרות

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

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

מקרה בדיקה תיאור הבדיקה User Flow התוצאה הצפויה
1 משתמש משלים הזמנה שלא התבצעה דרך Google. משתמש עובר ישירות לדף ההזמנה בלי הפניה מ-Google או בלי הפניה קיימת. הפעולה הזו לא אמורה לגרום ליצירת אירוע המרה כלשהו. אין אירוע המרה כי המשתמש לא ביקר בעבר בדף ההזמנות או לא הועבר על ידי Google.
2 משתמש משלים הזמנה שהתקבלה מ-Google. משתמש מוצא את המוכר שלכם דרך Google, מופנה לדף ההזמנות שלכם ומבצע הזמנה. אירוע המרה יישלח עם אסימון א' ועם הערך merchant changed (המוכר שינה) של 2, כי Google הפנתה את המשתמש לדף ההזמנה.
3 משתמש (מ-Google) מתחיל בתהליך ההזמנה, אבל עוזב את הסשן לפני שההזמנה הושלמה.

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

הערה: כתובת ה-URL של תהליך ההזמנה לא יכולה לכלול את האסימון rwg_token.
משתמש חוזר לדף ההזמנה אחרי בדיקה מס' 4. אסימון ב צריך להישמר למשך 30 יום, וכל המרה במהלך 30 הימים האלה אמורה להחזיר אירוע המרה. אירוע המרה יישלח עם אסימון B ועם הערך merchant changed (המוכר השתנה) של 2, כי המשתמש חוזר לדף ההזמנה אחרי הפניה קודמת מ-Google.
5 משתמש משלים הזמנה חדשה שמקורה ב-Google אחרי בדיקה מס' 4. אם משתמש חוזר לדף ההזמנות באמצעות הפניה מ-Google אחרי הפניה קודמת מ-Google, חלון האחסון של 30 הימים שלו מתאפס ואסימון חדש אסימון ג' מחליף את האסימון הישן אסימון ב'. לאחר מכן, כל ההמרות העתידיות ישויכו ל-אסימון C. אירוע המרה יישלח עם אסימון C ועם הערך merchant changed (המוכר שינה) של 2, כי המשתמש השלים את ההזמנה והאסימון החדש החליף את האסימון שנשמר קודם.

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

מקרה בדיקה תיאור הבדיקה User Flow התוצאה הצפויה
6 משתמש הגיע לדף לקביעת פגישות שלכם דרך Google והשלים הזמנה אצל מוכר אחר. משתמש הגיע לדף לקביעת פגישות שלכם דרך Google, נעשה שימוש ב-אסימון א', אבל לפני השלמת ההזמנה הוא מנווט לדף אחר ומבצע את ההזמנה אצל מוכר שונה מהמוכר שהפנה אותו במקור. אירוע המרה יישלח כי המשתמש השלים הזמנה שהתקבלה מהפניה מ-Google עם אסימון א' ועם הערך merchant changed (המוכר השתנה) שווה ל-1 כי המשתמש השלים את ההזמנה אצל מוכר אחר מזה שדרכו קיבל את ההפניה.

במהלך הבדיקה, שולחים את בקשת ה-HTTP POST לנקודת הקצה של ההמרה. יש שתי נקודות קצה:

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

טוקנים לבדיקה

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

אסימון א':

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

אסימון ב':

rwg_token=AJKvS9U2QfiQanHFQrlJxBjD0AyFany3qpaJVEWOcY4nHqY_UkLYFFDj6RIa-EXS1iEmV8gtFPG6v1cU1jnusJK66ijXXnaqkQ%3D%3D

אסימון C:

rwg_token=AJKvS9VwInjZ_hGZPvBz0COVWJ5oFDzocFt9hGi7TMurlo2l71uiXP48PspPUMmRnqCUDE1mF_A5H_dMV78cBTF8jIfSQK6lEA%3D%3D

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

conversion-tracking-dashboard

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

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

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

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

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

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

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

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