מעקב המרות

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

הבא
עדכון בזמן אמת