גשר CRM
כשסשן מקבל זהות, ההקלטה מתווספת כהערה לאותו אדם ב-CRM — לאיש קשר שכבר קיים, ולא לחדש.
1. מה הוא עושה, במשפט אחד
ברגע שסשן מזוהה, אנו מחפשים את האדם ב-CRM שלך לפי המזהה שנשלח אלינו, ומצרפים הערה עם קישור להקלטה.
זה הכול. ללא אנשי קשר חדשים, ללא עסקאות חדשות, ללא שינוי בצינור המכירות. CRM שמייצר כפילות בכל ביקור בדף המחירים גרוע מהיעדר שילוב.
אם האדם לא נמצא, לא קורה דבר. יצירתו הייתה כתיבת רשומה ל-CRM מתוך סשן דפדפן — וסשני דפדפן אינם מקור אמת לגבי זהות הלקוחות שלך.
2. מפתח ההתאמה: איך האדם מאותר
לחלק זה כדאי להקדיש עשר דקות, כי כאן שילוב CRM בדרך כלל משתבש בשקט.
אנו מכירים את המבקר לפי מה שהאתר מסר לנו — MousePlayer.setUserId(), מזהה ייחודי שנקרא מכלי הניתוח או קריאת identify בצד השרת. גם ה-CRM מכיר אותו לפי נתון כלשהו. שני הנתונים חייבים להיות זהים.
| מה מחפשים | אפשר לשנות | |
|---|---|---|
| HubSpot | כתובת הדוא״ל של איש הקשר | לא — נקודת הקצה לחיפוש בנויה סביבה |
| Pipedrive | אנשים לפי מונח, קודם דוא״ל | לא |
| Salesforce | שדה שנבחר על ידך, ברירת מחדל Email | כן |
מדוע Salesforce היא זו ששואלת
התקנות Salesforce ממעטות להשתמש בדוא״ל כמפתח. אצלך המפתח עשוי להיות Customer_Number__c, או מזהה חיצוני ממערכת החיוב. אם בכל זאת היינו מחפשים לפי דוא״ל, לא היינו מוצאים דבר אך מדווחים על הצלחה — הכשל הגרוע ביותר, כי השילוב נראה פעיל.
לכן הטופס שואל: איזה שדה ב-Contact מכיל את הערך שנשלח? יש להזין את שם ה-API, כולל __c אם זה שדה מותאם.
שם השדה נבדק מול תבנית מחמירה לפני שהוא מגיע לשאילתה. שם שדה CRM מורכב מאותיות, ספרות וקווים תחתונים — כל דבר אחר נדחה במקום לעבור escaping, כי ב-escaping אפשר לטעות באופן עדין, ואילו דחייה אינה משאירה מקום לטעות כזו.
3. מתי הוא מופעל, ומתי נמנע מכך במכוון
בעת הזיהוי: כשהאתר קורא לפונקציה MousePlayer.setUserId(), כשגשר הניתוח קורא בחזרה מזהה ייחודי מ-PostHog, מ-Mixpanel או מ-Amplitude, או כשהשרת שלך קורא לנקודת הקצה identify.
פעם אחת לסשן, לא לכל דף
אדם שנכנס ואז גולש באחד עשר דפים מייצר הערה אחת, לא אחת עשרה. ציר הזמן של ה-CRM נועד לקריאה בידי אנשים.
לא ללא מזהה
לסשן אנונימי אין נתון להתאמה. איננו מנחשים לפי כתובת IP, ואיננו מצרפים את ההקלטה למי שבמקרה חולק את אותה כתובת.
לא כשהאדם אינו מוכר ל-CRM
נחשב כהושלם, ולא ככשל — לקוח פוטנציאלי שעדיין אינו ב-CRM הוא מצב רגיל, וניסיון חוזר מחר לא ישנה זאת.
4. איך נראית ההערה והיכן נשמר האסימון
הערה אחת בציר הזמן של איש הקשר: שורה המציינת שהוקלט סשן וקישור. נציג המכירות לוחץ וצופה במה שהאדם עשה בפועל לפני שפנה.
פרטי הגישה
נשמרים בהצפנת AES-256-GCM. לעולם אינם מוצגים שוב לאחר השמירה — השדה מציג כוכביות, ושמירת הטופס עם הכוכביות משאירה את הערך השמור ללא שינוי. במכוון הם גם אינם נכללים בתור הפנימי שנושא את המשימה: התור הוא מצב משותף, ומצב משותף אינו מקום מתאים למפתח.
Salesforce דורשת שלושה דברים, האחרות שניים
Salesforce מזדהה דרך Connected App עם אסימון רענון, ולכן מבקשת consumer key, סוד ואסימון רענון, וכן את ה-URL של המופע. HubSpot ו-Pipedrive מקבלות אסימון API יחיד. בכל שלושת המקרים האפליקציה שלך — MousePlayer אינו מפעיל אפליקציית marketplace שצריך לתת בה אמון.
5. Zoho CRM ו-Freshsales
שתי מערכות CRM נוספות, שנמצאות בקצוות מנוגדים מבחינת מאמץ ההגדרה.
| Zoho CRM | Freshsales | |
|---|---|---|
| מה מספקים | מרכז נתונים, מזהה לקוח, סוד לקוח ואסימון רענון | מפתח API ודומיין Freshworks שלך |
| מה מחפשים | שדה לבחירתך, ברירת מחדל Email | שדה לבחירתך, ברירת מחדל email |
| היכן מתווספת ההערה | באיש הקשר, כרשומת Note | באיש הקשר, כהערה |
Zoho נמצאת באחד משישה מרכזי נתונים
החשבון נמצא באזור com, eu, in, com.au, jp או com.cn, ושום דבר במפתח אינו מציין באיזה. בחירה שגויה גורמת ל-Zoho להשיב INVALID_TOKEN — תשובה שנראית כמו מפתח שגוי ומובילה לחיפוש במקום הלא נכון. בדיוק לשם כך השדה הוא רשימה נפתחת.
Self Client, פעם אחת
יש ליצור Self Client במסוף Zoho API ולהפיק grant token עבור ZohoCRM.modules.ALL וגם ZohoSearch.securesearch.READ, ואז להחליף אותו פעם אחת באסימון רענון. תוקף אסימון הרענון אינו פג; אסימוני הגישה השעתיים נשלפים באמצעותו ולעולם אינם נשמרים.
Zoho משיבה 200 כשהכוונה היא לא
גם החלפת האסימון וגם כתיבת הרשומות יכולות להחזיר HTTP 200 עם שגיאה או מצב לכל רשומה בגוף התשובה. אנו קוראים את הגוף — גשר שסומך על קוד הסטטוס היה מדווח על הצלחה בהערה שמעולם לא נוצרה.
כל הסימנים המסחריים המוזכרים כאן שייכים לבעליהם בהתאמה. ל-MousePlayer אין קשר עסקי עם ספקים אלה.