CRM ब्रिज
सत्र को नाम मिलते ही CRM में उसी व्यक्ति पर रिकॉर्डिंग का नोट आता है — पहले से मौजूद संपर्क पर, नए पर नहीं।
1. एक वाक्य में काम
सत्र पहचाने जाते ही भेजे पहचानकर्ता से 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 टाइमलाइन लोग पढ़ते हैं।
पहचानकर्ता बिना नहीं
गुमनाम सत्र में मिलान का आधार नहीं। 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 | |
|---|---|---|
| आप देते हैं | डेटा केंद्र, क्लाइंट ID, क्लाइंट सीक्रेट, रीफ़्रेश टोकन | API कुंजी और Freshworks डोमेन |
| हम खोजते हैं | आपकी बताई फ़ील्ड, डिफ़ॉल्ट Email | आपकी बताई फ़ील्ड, डिफ़ॉल्ट email |
| नोट आता है | संपर्क पर, Note रिकॉर्ड के रूप में | संपर्क पर, नोट के रूप में |
Zoho छह डेटा केंद्रों में से एक में है
खाता इसमें होता है: com, eu, in, com.au, jp या com.cn, और कुंजी कुछ नहीं बताती कौन-सा। ग़लत चुनने पर Zoho यह देता है: INVALID_TOKEN — खराब कुंजी जैसा लगता है और गलत जगह खोजने लगते हैं। इसलिए फ़ील्ड ड्रॉपडाउन है।
Self Client, एक बार
Zoho API कंसोल में Self Client बनाकर इस स्कोप का ग्रांट टोकन बनाएँ: ZohoCRM.modules.ALL और ZohoSearch.securesearch.READ, फिर एक बार रीफ़्रेश टोकन लें। यह समाप्त नहीं होता; इससे हर घंटे एक्सेस टोकन लिए जाते हैं और कभी सहेजते नहीं।
Zoho का 200 अस्वीकृति भी हो सकता है
टोकन विनिमय और रिकॉर्ड लिखना दोनों HTTP 200 के साथ बॉडी में त्रुटि या प्रति रिकॉर्ड स्थिति दे सकते हैं। हम बॉडी पढ़ते हैं — केवल स्थिति मानने वाला ब्रिज कभी न बने नोट को सफल बताएगा।
यहाँ बताए ट्रेडमार्क संबंधित स्वामियों के हैं। MousePlayer का इन प्रदाताओं से व्यावसायिक संबंध नहीं।