אני הולך להציג לכם פתרון יצירתי לבעיה נפוצה יחסית, אז גם אצלכם זה קצת שונה – אני ממליץ לקרוא עד הסוף כדי לקבל השראה.
סיפור
הכל התחיל מלקוח שמשתמש בצ׳אט של אינטרקום באתר.
הלקוח מוכר high-ticket products, כלומר מוצרים במחיר גבוה מאוד יחסית למתחרים באותו שוק (כמובן שגם איכות המוצרים נמצאת בקצה העליון של הסקאלה), ולכן לוקח יחסית הרבה זמן לסגור עסקה.
המסלול הרגיל הוא שגולש מגיע לאתר, משאיר פרטים בטופס או בצ׳אט, נציג חוזר אליו תוך זמן קצר ואז מתחיל תהליך שיכול לקחת אפילו כמה חודשים.
הלקוח רוצה לדווח על המרות לגוגל אנליטיקס כדי לראות את כל הפאנל – כמה הגיעו מכל מקור תנועה, כמה השאירו פרטים בטופס או בצ׳אט, כמה לידים היו איכותיים ורלוונטיים, וכמה באמת סגרו עסקה.
מכיוון שיכולים לעבור כמה חודשים ואפילו שנה עד שהעסקה נסגרת, הלקוח רצה להתבסס על כמות הלידים האיכותיים בתור מדד ההצלחה (KPI) שיעזור לו באופטימיזציה של הקמפיינים.
אבל מכיוון שהסימון של ״ליד איכותי״ מתבצע מחוץ לאתר על ידי הנציג הטלפוני, צריך להשתמש ב-Measurement Protocol כדי לשלוח איוונטים אופליין לגוגל אנליטיקס כאשר הנציג מגדיר את הליד כ״איכותי״.
אז הוספנו לטופס הלידים כמה hidden fields שכוללים את ה-client id וה-session id מתוך הקוקיז, והגדרנו שהשדות הללו ישלחו ל-CRM ביחד עם פרטי הליד (שם, מייל, טלפון וכד׳).
כאשר נציג המכירות מסמן את הליד כאיכותי, המתכנת שולח איוונט לגוגל אנליטיקס 4 באמצעות ה-Measurement Protocol, וביחד עם האיוונט הוא מכניס את ה-client id וה-session id שהגיעו עם הטופס, כדי שגוגל אנליטיקס יוכל לשייך את האיוונט לגולש ולסשן המתאים.
עד כאן הכל רגיל.
איפה הבעיה
הבעיה התחילה עם הצ׳אט של אינטרקום, מכיוון שבכל פעם שמישהו משאיר את המייל שלו בצ׳אט מתבצעות 2 פעולות:
1. נשלח איוונט לגוגל אנליטיקס בשם ״Provided Email Address״. האיוונט הזה נשלח על ידי התג מנג׳ר, אבל הוא לא מכיל שום פרט מזהה אודות הגולש.
2. במקביל, נוצר contact חדש באינטרקום שמכיל את פרטי הגולש.
הבעיה היא שאין שום דרך לקשר בין שתי הפעולות.
האיוונט שנשלח לאנליטיקס לא מכיל שום פרטים על הגולש, ואיש הקשר שנוצר באינטרקום לא מכיל שום מידע שיכול לעזור לנו בדיווח לאנליטיקס.
זה יוצר מצב שגם אם נשלח איוונט באמצעות ה-Measurement Protocol כאשר נציג המכירות יסמן את אותו איש קשר בתור ״ליד איכותי״, לא יהיה לנו את ה-client id ו-session id כדי שהאיוונט ישוייך לסשן המקורי, וזה יגרום לנו לאבד את מקור התנועה של הליד.
אגב, מסיבה כלשהיא, אינטרקום לא שומרים בקוקי את ה-UTM שאיתו הגולש הגיע, ולכן אם הגולש יוצר קשר דרך הצ׳אט אחרי שיטוט קצר באתר (כלומר לא מהעמוד הראשון של הביקור) – הוא מאבד את ה-UTM ואין שום אינדיקציה למקור התנועה.
הפתרון
ברמת העקרון, הפתרון שחשבנו עליו עובד ככה:
אנחנו יודעים שכאשר גולש משאיר פרטים, נשלח לאנליטיקס איוונט בשם ״Provided Email Address״.
כשהאיוונט נכנס לאנליטיקס, הוא נכנס גם לטבלת ה-intraday ב-BigQuery, בדרך כלל תוך כמה שניות.
אם נדע לתשאל את ה-BigQuery ולקחת משם את ה-client id (שנקרא user_pseudo_id) ואת ga_session_id ולהוסיף אותם בתור custom fields לאיש הקשר באינטרקום – יהיה לנו כל מה שאנחנו צריכים כדי לשלוח את ה-Measurement Protocol בצורה שתאפשר שיוך לסשן הנכון.
אבל כמו שאתם רואים יש הרבה איוונטים בשם Provided Email Address, ולכל אחד יש client_id ו-session_id שונים. אז איך נדע איזה איוונט לקחת?
ההגיון אומר לקחת בכל פעם את האיוונט האחרון שהגיע, אבל מה קורה אם שני גולשים השאירו פרטים ביחד?
אז הורדנו את כל הלידים שהגיעו בשנה האחרונה כולל חותמת הזמן שמציינת מתי הליד נכנס למערכת, ונתנו ל-ChatGPT לבדוק מה הפערים הכי קטנים, וגילינו שמתוך מאות לידים – רק 2 לידים (או 4 ליתר דיוק) היו בפער של פחות מחצי דקה אחד מהשני:
זה גרם לנו להניח שאם נתשאל את ה-BigQuery ברגע שהליד מגיע (או 15 שניות אחרי, כדי לתת קצת זמן למידע להכנס), ונבקש את ה-client id ו-session id של האיוונט ״Provided Email Address״ האחרון שהגיע, יש סיכוי של 99.99% שנקבל את הערכים הנכונים.
(אם הפערים בין הלידים נמוכים יותר אצלכם, תמיד אפשר להוסיף תנאים נוספים לשאילתה כמו מדינה, דפדפן, ואפילו גרסת דפדפן כדי לצמצם את הבדיקה. הפרמטרים הללו זמינים גם בגוגל אנליטיקס/BigQuery וגם באינטרקום).
לאחר התשאול אנחנו מעדכנים את איש הקשר שנוצר באינטרקום ומוסיפים לו את הערכים של client id ו-session id שקיבלנו מ-BigQuery, וככה המתכנת יכול לשלוח Measurement Protocol מלא שמכיל את כל מה שצריך כדי שהאיוונט ישויך לסשן הנכון.
את האוטומציה בנינו במייק, וככה היא נראית:
שלב ראשון – האזנה ללידים חדשים שנוצריך באינטרקום:
שלב שני – המתנה של 10 שניות (אפשר גם 15 אם מרגיש לכם יותר בטוח):
שלב שלישי – תשאול BigQuery:
שלב רביעי – שימוש בנתונים שהגיעו מ-BigQuery כדי לעדכן את איש הקשר הרלוונטי באינטרקום:
QA אחרי כמה ימים
אחרי כמה ימים שזה רץ אני יכול להגיד שזה עובד ממש טוב.
כפי שתוכלו לראות בצילום המסך מאינטרקום, יש כמה חוסרים אבל כ-95% מהלידים מקבלים את הערכים בצורה מושלמת:
מה שכן, שמתי לב שאותם לידים גם לא קיימים בביג קוורי, כלומר בזמן שהליד נכנס לאינטרקום, גם לא נשלח איוונט לאנליטיקס וגם הטריגר לא הופעל, ולכן אני חושד שמדובר בלידים שמגיעים ממקום אחר שהוא לא הצ׳אט.
אני ממשיך לחקור את זה אבל מבחינתי זה הרבה יותר מ-good enough, כי לפני שבניתי את האוטומציה לא היה לי כלום…
כמו כן, כמו שכתבתי קודם הפתרון הזה עובד בתצורה הנוכחית כי המרווחים בין הלידים מספיק גדולים, ולכן התשאול של BigQuery נותן את התוצאה הנכונה, אבל גם אם המרווחים אצלכם קטנים יותר – תוכלו להוסיף תנאי כדי לצמצם את הבחירה.
למשל במקום להגיד לו ״תביא לי את הליד האחרון״, תוכלו לקחת את המדינה + דפדפן מאינטרקום ולבקש מ-BigQuery להביא לכם את ״הליד האחרון שהגיע ממדינה X ודפדפן Y״, ואז גם אם המרווחים בין הלידים קטנים יותר, יש סיכוי גבוה יותר שתקבלו את האיוונט הנכון.
זהו חברים 🙂
מקווה שנהניתם.
כמובן שהפוסט התייחס לאינטרקום, אבל תוכלו ליישם את זה בכל מערכת צ׳אט אחרת שמאפשרת לבצע את הפעולות שהצגתי (חיבור למייק, עריכת פרטי הליד וכו׳).
אם עדיין לא נרשמתם לניוזלטר שלי תוכלו לעשות את זה כאן >>