लिंक ट्रैकिंग प्लेटफ़ॉर्म दर्ज करता है कि आपके लिंक के साथ क्या हुआ। वेबहुक के ज़रिए प्लेटफ़ॉर्म यही बात उसी समय आपके दूसरे सिस्टम को बता देता है, ताकि किसी के डैशबोर्ड खोलने का इंतज़ार न करना पड़े। इन दोनों के मेल से नया कैंपेन लिंक बनते ही आपके CRM में दिख जाता है, या सीक्रेट लिंक खुलते ही कोई टिकट अपडेट हो जाता है।
वेबहुक इंटीग्रेशन वाला लिंक ट्रैकिंग प्लेटफ़ॉर्म चुनते समय “वेबहुक हैं” से आगे देखना होता है: वह कौन-से इवेंट भेजता है, उन्हें कैसे सुरक्षित रखता है, और क्या नहीं भेजता। यह गाइड ये सब बातें बताती है, साथ ही भरोसेमंद रिसीवर बनाने का तरीका, और यह भी कि कब API बेहतर टूल है।
लिंक प्लेटफ़ॉर्म के वेबहुक किस काम आते हैं
तीन काम बार-बार सामने आते हैं।
- सिस्टम को सिंक में रखना। प्लेटफ़ॉर्म में बना लिंक अपने स्लग और मंज़िल के साथ आपके CRM या प्रोजेक्ट टूल के कैंपेन रिकॉर्ड में दिख जाता है, किसी को उसे कॉपी नहीं करना पड़ता।
- वर्कफ़्लो शुरू करना। खोला गया सीक्रेट लिंक हैंडओवर को पूरा मार्क कर देता है, और जो लिंक प्राप्तकर्ता की पुष्टि के बिना मिट गया, वह एक इंसिडेंट खोल देता है।
- वेयरहाउस में डेटा भेजना। इवेंट पहले एक कतार में और फिर एक टेबल में पहुंचते हैं, जहां वे आपके बाकी डेटा से जुड़ जाते हैं।
गिनती के लिए वेबहुक ठीक नहीं हैं। जो डैशबोर्ड हर वेबहुक पर एक संख्या बढ़ाता है, वह पहली बार किसी डिलीवरी के दोबारा भेजे जाने या देर से पहुंचने पर प्लेटफ़ॉर्म की अपनी रिपोर्ट से अलग हो जाएगा। संख्याओं के लिए API या एक्सपोर्ट इस्तेमाल करें, और कार्रवाई के लिए वेबहुक।
किन इवेंट को देखें
हर प्लेटफ़ॉर्म अलग इवेंट भेजता है। सिर्फ़ फ़ीचर का नाम नहीं, इवेंट की पूरी सूची मांगें।
| इवेंट का समूह | आम इवेंट | किस काम का |
|---|---|---|
| लिंक लाइफ़साइकल | बनाया गया, अपडेट हुआ, डिलीट हुआ | CRM में सिंक, ऑडिट ट्रेल, गलती से हुए बदलाव पकड़ना |
| सीक्रेट लाइफ़साइकल | बनाया गया, देखा गया, मिट गया | हैंडओवर की पुष्टि, इंसिडेंट ट्रिगर |
| क्लिक इवेंट | हर क्लिक पर या बैच में | रियल-टाइम ऑटोमेशन, ज़्यादा वॉल्यूम पर |
| डोमेन इवेंट | वेरिफ़ाई हुआ, सर्टिफ़िकेट जारी हुआ | ऑप्स अलर्ट |
LinkPilot के वेबहुक लिंक लाइफ़साइकल (link.created, link.updated, link.deleted) और सीक्रेट लाइफ़साइकल (secret.created, secret.viewed, secret.burned) को कवर करते हैं। क्लिक डेटा हर क्लिक के वेबहुक के रूप में नहीं, बल्कि एनालिटिक्स API और CSV एक्सपोर्ट से मिलता है। ज़्यादातर टीमों के लिए यही सही बंटवारा है: क्लिक बड़ी मात्रा में आने वाला रिपोर्टिंग डेटा हैं, जबकि लाइफ़साइकल इवेंट वे हैं जिनसे कुछ शुरू होना चाहिए।
अगर आपके वर्कफ़्लो को सच में हर क्लिक पर कुछ करना है, तो पक्का कर लें कि प्लेटफ़ॉर्म उन्हें बैच में भेजता है या उनकी रेट लिमिट तय करता है। वरना आपका बनाया रिसीवर किसी पोस्ट के पहली बार वायरल होते ही ठप हो जाएगा।
और क्या परखें
- साइनिंग। हर डिलीवरी पर एक सिग्नेचर होना चाहिए जो आपके पास रखे सीक्रेट से बना हो, ताकि आपका एंडपॉइंट नकली रिक्वेस्ट को ठुकरा सके। बिना सिग्नेचर के वेबहुक भेजने वाला प्लेटफ़ॉर्म आपसे हर POST रिक्वेस्ट पर भरोसा करने को कह रहा है।
- रीट्राई और क्रम। पता करें कि फ़ेल हुई डिलीवरी कितनी बार और कितने समय तक दोबारा भेजी जाती है, और मानकर चलें कि इवेंट गलत क्रम में भी पहुंच सकते हैं।
- इवेंट ID। हर इवेंट की एक यूनीक ID से ही आइडेम्पोटेंसी मुमकिन होती है।
- एंडपॉइंट मैनेजमेंट। हर वर्कस्पेस में कई एंडपॉइंट, हर इवेंट के लिए अलग सब्सक्रिप्शन, और एक डिलीवरी लॉग जिसे कुछ गड़बड़ होने पर पढ़ा जा सके।
- साथ में API। ट्रिगर के लिए वेबहुक, बाकी सब के लिए API। जांचें कि लिंक बनाना, एनालिटिक्स और एक्सपोर्ट, तीनों कोड से किए जा सकते हैं और keys का दायरा सीमित किया जा सकता है। LinkPilot का API
lp_live_बेयरर keys इस्तेमाल करता है और हर प्लान में है। - टीम का ऐक्सेस। वेबहुक एंडपॉइंट कौन जोड़ सकता है, यह मायने रखता है, क्योंकि एंडपॉइंट तक डेटा पहुंचता है। रोल ऐसे हों कि “admin” रोल वाला व्यक्ति एंडपॉइंट मैनेज कर सके और बाकी सब इससे दूर रहें।
ऐसा रिसीवर बनाएं जो ठप न हो
- सबसे पहले सिग्नेचर जांचें। रॉ बॉडी और अपने सीक्रेट से अपेक्षित सिग्नेचर निकालें, कॉन्स्टेंट टाइम में तुलना करें, और जो जांच में फ़ेल हो, उसे पार्स करने से पहले ही ठुकरा दें।
- जल्दी जवाब दें। एक-दो सेकंड में 2xx लौटाएं। असली काम एक कतार से करें, ताकि धीमे CRM की वजह से रीट्राई न हों।
- इवेंट ID सेव करें और जो पहले देख चुके हैं, उन्हें छोड़ दें। रीट्राई आम बात है; एक ही इवेंट को दो बार प्रोसेस करना आपका बग है।
- फ़ील्ड साफ़-साफ़ मैप करें। जिस स्लग, मंज़िल, टैग और टाइमस्टैम्प की ज़रूरत है, उन्हें अपनी स्कीमा में निकाल लें। पूरे पेलोड को सच का स्रोत मानकर स्टोर न करें। यह एक सूचना है, रिकॉर्ड नहीं।
- हर डिलीवरी को लॉग करें, उसकी ID और नतीजे के साथ। तब अगर प्लेटफ़ॉर्म का लॉग कहे कि डिलीवरी हो गई और आपका सिस्टम कहे कि कुछ नहीं हुआ, तो आप पता कर सकेंगे कि वह कहां गई।
- खामोशी पर अलर्ट लगाएं। अगर जिस एंडपॉइंट पर आम तौर पर हर घंटे इवेंट आते हैं, वह एक दिन चुप रहे, तो किसी एक तरफ़ कुछ टूटा है।
पहला असली कैंपेन शुरू करने से पहले स्टेजिंग एंडपॉइंट और प्लेटफ़ॉर्म की टेस्ट डिलीवरी से जांच करें। एक लिंक बनाएं, उसे बदलें, डिलीट करें, और तीनों इवेंट आते हुए देखें।
डेटा को सुरक्षित रखें
वेबहुक पेलोड लिंक और सीक्रेट के बारे में होते हैं, लोगों के बारे में नहीं। उन्हें ऐसा ही रहने दें।
- लिंक के स्लग या टैग में कभी निजी डेटा न डालें, क्योंकि वे उस लिंक के हर पेलोड में साथ जाएंगे।
- एंडपॉइंट को सीमित करें ताकि सिर्फ़ प्लेटफ़ॉर्म का ट्रैफ़िक पहुंचे: सिग्नेचर से, और जहां मुमकिन हो, सोर्स एड्रेस से भी।
- साइनिंग सीक्रेट को सीक्रेट मैनेजर में रखें, रिसीवर की कॉन्फ़िग फ़ाइल में नहीं, और तय समय पर उसे रोटेट करें। अगर रिसीवर बनाने वाले किसी कॉन्ट्रैक्टर को सीक्रेट देना पड़े, तो उसे वन-टाइम सीक्रेट लिंक से भेजें। वेबहुक साइनिंग सीक्रेट की गाइड में यह हैंडओवर समझाया गया है।
- जब क्लिक डेटा CRM में जाए, तो सहमति का ध्यान रखें। किसी ग्राहक से जुड़ा क्लिक रिकॉर्ड ज़्यादातर प्राइवेसी नियमों में निजी डेटा है।
इंटीग्रेशन को भी मापें
- प्लेटफ़ॉर्म के लॉग से डिलीवरी सफलता दर।
- इवेंट के टाइमस्टैम्प से आपके सिस्टम के रिकॉर्ड तक की प्रोसेसिंग में देरी।
- डुप्लिकेट दर, जो कम होनी चाहिए, पर कभी शून्य नहीं होगी।
- मिलान: हफ़्ते में एक बार API से मिली लिंक की संख्या और कुल क्लिक की तुलना अपने सिस्टम के डेटा से करें। फ़र्क का मतलब है कोई डिलीवरी छूट गई या रिसीवर में बग है।
वेबहुक वाला लिंक ट्रैकिंग प्लेटफ़ॉर्म आपके लिंक को बाकी सिस्टम से जोड़ देता है। ऐसा प्लेटफ़ॉर्म चुनें जो भेजी गई हर चीज़ पर सिग्नेचर करे, साफ़ बताए कि कौन-से इवेंट मौजूद हैं, और संख्याओं के लिए API दे। फिर रिसीवर यह मानकर बनाएं कि रीट्राई आम बात है, क्योंकि वे सच में आम हैं।