CRM ब्रिज
सत्राची ओळख मिळताच रेकॉर्डिंग CRM मधील त्या व्यक्तीवर टीप म्हणून येते — विद्यमान संपर्कावर, नव्या नाही.
1. एका वाक्यात काम
सत्र ओळखताच दिलेल्या ID ने CRM मध्ये व्यक्ती शोधून रेकॉर्डिंग दुव्याची टीप जोडतो.
एवढेच. नवीन संपर्क, व्यवहार किंवा पाइपलाइन बदल नाहीत. किंमत पृष्ठाच्या प्रत्येक भेटीवर दुहेरी नोंद वाढवणारा CRM नसलेल्या एकत्रीकरणापेक्षा वाईट.
व्यक्ती सापडली नाही तर काही होत नाही. ब्राउझर सत्रावरून CRM नोंद तयार करणे म्हणजे अविश्वसनीय ओळख वापरणे — सत्रे ग्राहक कोण आहेत याचा अधिकृत आधार नाहीत.
2. जुळवणी की: व्यक्ती कशी शोधतो
दहा मिनिटे लक्ष द्यावा असा भाग; CRM एकत्रीकरण सहसा इथेच शांतपणे चुकते.
साइटने दिलेल्या माहितीनुसार अभ्यागत ओळखतो — MousePlayer.setUserId(), विश्लेषण साधनातून मिळालेला वेगळा ID किंवा सर्व्हर identify कॉल. CRM कडेही ओळख असते. दोन्ही सारखी हवी.
| शोधतो | बदलता येते | |
|---|---|---|
| HubSpot | संपर्काचा ईमेल | नाही — शोध एंडपॉइंट त्यावरच आधारित |
| Pipedrive | शब्दावरून व्यक्ती; आधी ईमेल | नाही |
| Salesforce | एक फील्ड तुम्ही नाव देता, डीफॉल्ट Email | होय |
Salesforce का विचारते
Salesforce क्वचित ईमेलवर आधारित असते. तुमचे कदाचित Customer_Number__c किंवा बिलिंग प्रणालीच्या बाह्य ID वर. तरीही ईमेलने शोधल्यास काहीच सापडणार नाही आणि यश कळवेल — एकत्रीकरण चालू दिसते म्हणून सर्वात वाईट अपयश.
म्हणून फॉर्म विचारतो: पाठवत असलेले मूल्य Contact च्या कोणत्या फील्डमध्ये आहे? API नाव द्या; सानुकूल फील्ड असल्यास पुढील भागासह: __c .
क्वेरीपूर्वी नाव कडक नमुन्याने तपासतो. CRM फील्ड नावात अक्षरे, अंक, अंडरस्कोर; बाकी एस्केप करण्याऐवजी नाकारतो, कारण एस्केपमध्ये सूक्ष्म चूक शक्य, नकारात नाही.
3. केव्हा चालते आणि केव्हा मुद्दाम नाही
ओळख पटताना: साइटचा पुढील कॉल: MousePlayer.setUserId(), PostHog, Mixpanel किंवा Amplitude मधून ब्रिजने वाचलेला वेगळा ID किंवा सर्व्हरचा identify एंडपॉइंट कॉल.
प्रत्येक सत्रात एकदा, पृष्ठागणिक नाही
लॉगिननंतर अकरा पृष्ठे पाहणाऱ्यासाठी एक टीप, अकरा नाही. CRM टाइमलाइन लोक वाचतात.
ID शिवाय नाही
अनामिक सत्राशी जुळवायला काही नसते. IP वरून अंदाज नाही; तोच पत्ता असणाऱ्या व्यक्तीला रेकॉर्डिंग जोडत नाही.
CRM ला व्यक्ती अज्ञात असल्यास नाही
पूर्ण मानतो, अयशस्वी नाही — संभाव्य ग्राहक CRM मध्ये नसणे सामान्य; उद्या पुन्हा प्रयत्न करून फरक पडणार नाही.
4. टीप कशी दिसते आणि टोकन कुठे
संपर्क टाइमलाइनवर एक टीप: सत्र रेकॉर्ड झाल्याची ओळ आणि दुवा. विक्रेता क्लिक करून संपर्कापूर्वी व्यक्तीने काय केले ते पाहतो.
प्रवेशमाहिती
AES-256-GCM एन्क्रिप्टेड. जतन केल्यावर पुन्हा दिसत नाही — तारका दिसतात; तारकांसह फॉर्म जतन केल्यास मूळ मूल्य बदलत नाही. कामाच्या अंतर्गत रांगेत मुद्दाम नसते: सामायिक स्थिती की ठेवण्याची जागा नाही.
Salesforce ला तीन गोष्टी, इतरांना दोन
Salesforce Connected App आणि रिफ्रेश टोकनने प्रमाणीकरण करते; consumer key, secret, refresh token आणि इन्स्टन्स URL लागते. HubSpot/Pipedrive ला एक API टोकन. तिन्ही ठिकाणी अॅप तुमचे — MousePlayer वर विश्वास ठेवावे लागणारे मार्केटप्लेस अॅप चालवत नाही.
5. Zoho CRM आणि Freshsales
आणखी दोन CRM; सेटअपच्या कामात अगदी विरुद्ध टोके.
| Zoho CRM | Freshsales | |
|---|---|---|
| तुम्ही देता | डेटा केंद्र, क्लायंट ID, क्लायंट सीक्रेट, रिफ्रेश टोकन | API की आणि Freshworks डोमेन |
| शोधतो | दिलेले फील्ड; डीफॉल्ट Email | दिलेले फील्ड; डीफॉल्ट email |
| टीप येते | संपर्कावर Note नोंद म्हणून | संपर्कावर टीप म्हणून |
Zoho सहापैकी एका डेटा केंद्रात
खाते येथे असते: com, eu, in, com.au, jp किंवा com.cn; कीवरून ठरत नाही. चुकल्यास Zoho पुढील उत्तर देते: INVALID_TOKEN — की चुकीची वाटून चुकीच्या ठिकाणी शोधाल. म्हणून ड्रॉपडाउन आहे.
एकदा Self Client
Zoho API कन्सोलमध्ये Self Client तयार करा, पुढीलसाठी grant टोकन: ZohoCRM.modules.ALL आणि ZohoSearch.securesearch.READ; एकदा बदलून रिफ्रेश टोकन मिळवा. त्याची मुदत संपत नाही; तासाभराची अॅक्सेस टोकन त्यातून मिळतात, साठवत नाही.
नकार देतानाही Zoho चे 200
टोकन बदल आणि नोंदी लिहिताना HTTP 200 सोबत त्रुटी किंवा नोंदनिहाय स्थिती मजकुरात येऊ शकते. मजकूर वाचतो — फक्त स्थितीवर विश्वास ठेवणारा ब्रिज न बनलेल्या टीपेसाठी यश सांगेल.
सर्व ट्रेडमार्क संबंधित मालकांचे आहेत. MousePlayer चे या प्रदात्यांशी व्यावसायिक संबंध नाहीत.