מעקב המרות

איור 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 כדי לעקוב אחרי נתונים ברמת המכשיר דרך דפדפן.

const rwgToken = new URLSearchParams(location.search).get('rwg_token') || undefined;

שמירת הטוקן

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

  • ברמת המכשיר
  • ברמת המשתמש

אפשר לאחסן את האסימון בכל רמה, אבל חובה לאחסן את האסימון למשך 30 ימים אחרי ההפניה הראשונית.

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

if (rwgToken !== undefined) {
  document.cookie =
  "_rwgToken=" + rwgToken + "; 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 קיים.

// Store the rwgToken and merchantId in your cookie and set the cookie
// expiration date to 30 days.
if (typeof rwgToken !== 'undefined') {
  document.cookie =
  "_rwgToken=" + rwgToken + "; _merchantId=" + 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`;

// Retrieve the value of the rwgToken stored in the browser's cookie
const match = document.cookie.match(new RegExp('(?:^| )_rwgToken=([^;]+)'));
const storedRwgToken = match ? match[1] : undefined;

// Send Conversion event with decoded token, verify any special characters
// are sent properly.
if (storedRwgToken !== undefined) {
  fetch(endpoint, {
    method: "POST",
    body: JSON.stringify({
      conversion_partner_id: partnerId,
      rwg_token: decodeURIComponent(storedRwgToken),
      merchant_changed: merchantChanged
    })
  });
}

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

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

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

  • דרישה: כשמשתמש עוזב את האתר המקורי של המוכר ומשלים רכישה דרך הפלטפורמה שלכם אצל מוכר אחר.
    • ערך שינוי המוכר: 1
  • דרישה: כשמשתמש משלים עסקה דרך המוכר המקורי.
    • ערך שינוי המוכר: 2

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

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

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

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

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

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

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

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

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

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

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

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

Token A:

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

טוקן ב':

rwg_token=AJKvS9U2QfiQanHFQrlJxBjD0AyFany3qpaJVEWOcY4nHqY_UkLYFFDj6RIa-EXS1iEmV8gtFPG6v1cU1jnusJK66ijXXnaqkQ%3D%3D

טוקן ג':

rwg_token=AJKvS9VwInjZ_hGZPvBz0COVWJ5oFDzocFt9hGi7TMurlo2l71uiXP48PspPUMmRnqCUDE1mF_A5H_dMV78cBTF8jIfSQK6lEA%3D%3D

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

conversion-tracking-dashboard

דרישות לשימוש בתכונה 'שיוך המרות'

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

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

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

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

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

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

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