מעבר למעקב המרות גרסה 2

סקירה כללית

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

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

שינויים בשמירת האסימון

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

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

<script>
  if (typeof rwg_token !== 'undefined') {
    merchant_id = // Write your own logic here assigning the merchant id value
    document.cookie =
    "_rwg_token=" + rwg_token + ";_merchant_id=" + merchantid + ";max-age=2592000;domain=rootdomain.com;path=/";
  }
</script>

שינויים בשליחת נתוני המרות

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

{
  "conversion_partner_id": <partnerId>,
  "rwg_token": <rwg_token_val>
  "merchant_changed": 1|2
}

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

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

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

AJKvS9WeONmWKEwjG0--HdpzMq0yAVNL8KMxbb44QtbcxMhSx_NUud5b8PLUBFehAIxOBO-iYRIJOknEFkIJmdsofdVJ6uOweQ==

בעת שליחת הבקשה, השתמש בנקודות הקצה הבאות שתואמות לסביבה שלך:

• הפקה: https://www.google.com/maps/conversion/collect
• Sandbox: https://www.google.com/maps/conversion/debug/collect

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

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

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

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

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

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

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

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

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