מעקב המרות

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

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

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

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

אסימון א':

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

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