מעקב המרות

איור 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": "AFd1xnHrJWKcjtriCyB5j3QL0bzbmLdcg1N1f5cJuSNVhteYjuOJz18Au6GIAT0tjHkw6fkUJKcarafV45b3c_gl7uT_o8HMcg==",
  "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, צריך לקחת בחשבון את המוכר המקורי שנשמר ב-Parse and Store the Merchant Information. בודקים אם המוכר השתנה ומקצים את הערך בהתאם לדרישות.

  • דרישה: כשמשתמש עוזב את האתר של המוכר המקורי ומשלים רכישה דרך הפלטפורמה שלכם אצל מוכר אחר.
    • ערך שינוי המוכר: 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
  • סביבת Sandbox: ‏ https://www.google.com/maps/conversion/debug/collect

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

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

Token A:

rwg_token=AFd1xnHrJWKcjtriCyB5j3QL0bzbmLdcg1N1f5cJuSNVhteYjuOJz18Au6GIAT0tjHkw6fkUJKcarafV45b3c_gl7uT_o8HMcg%3D%3D

טוקן ב':

rwg_token=AE37R_gte8WCEaytMalsIr9agWQRLuN8199RsVhU2WoRKRvcZ0eBTD8cFvnfUZh-GY0IvY-zjS3W9KWAmy3WDiWXbVvQRZyzMQ%3D%3D

טוקן ג':

rwg_token=AE37R_jmAP-UgWNApkxwdlX5M2z1UBGuUzHZ63YWmRWeTjRJKxfSD1mzJ4joLnB11MHrBULuisjP-9I64LnBJDXyCc_CIJSCPg%3D%3D

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

conversion-tracking-dashboard

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

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

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

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

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

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

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

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