आपकी landing pages पर Webhook
ज़्यादातर lead gen स्टैक में बीच में एक टैक्स होता है: एक Zap या scenario, जिसका इकलौता काम lead को पेज से ऐसे endpoint तक ले जाना है जो उसे सीधे भी ले लेता। हर lead उस पड़ाव की क़ीमत टास्क या क्रेडिट में चुकाता है, और हर पड़ाव एक और जगह है जहां lead अटक सकता है, जबकि बायर इंतज़ार करता है।
LanderLab का Webhook इंटीग्रेशन इसे हटा देता है। हर पेज अपने leads सीधे किसी भी HTTPS endpoint पर भेजता है: बायर का posting URL, आपका अपना lead API, किसी CRM का endpoint, किसी ट्रैकर का postback। Method, फ़ॉर्मेट, headers और ठीक-ठीक body आप तय करते हैं, ताकि दूसरी तरफ़ lead वैसे ही पहुंचे जैसे उसके docs मांगते हैं।
इस साइट पर जिन टूल्स की अपनी एंट्री नहीं है, उनमें से ज़्यादातर के पीछे यही इंटीग्रेशन है, और जब कोई बायर आपको spec sheet भेजे, तो यही काम आता है।
Middleware के पैसे देने से सीधा webhook बेहतर क्यों है
जो lead पहले पेज, फिर Zap, फिर बायर तक जाता है, वह दो सिस्टम पर निर्भर रहता है और उनमें से एक उसका बिल बनाता है। हाई-वॉल्यूम ऑफ़र पर ऑटोमेशन प्लान आपके leads की गिनती के साथ बढ़ता जाता है, जबकि बीच में कुछ ख़ास नहीं होता: Zap एक lead लेता है और उसे कहीं और पोस्ट कर देता है।
सीधा webhook वही पोस्ट है, बिना बीच के पड़ाव के। सबमिट होते ही lead पेज से endpoint तक जाता है, आपके कंट्रोल में, और बीच में ऐसा कुछ नहीं होता जो रुक जाए, जिसके टास्क ख़त्म हो जाएं या जिसकी प्राइसिंग बदल जाए। कई स्टेप वाले कामों के लिए middleware रखें; बाक़ी काम webhook को करने दें।
Leads उसी फ़ॉर्मेट में भेजें जो दूसरी तरफ़ चाहिए
बायर्स और APIs की अपनी-अपनी शर्तें होती हैं। एक को सीधा form post चाहिए, जिसमें फ़ील्ड के नाम ठीक उसके spec जैसे हों; दूसरे को JSON चाहिए, जिसमें कॉन्टैक्ट एक lead object के अंदर nested हो, ट्रैकिंग दूसरे के अंदर, और उनके बगल में एक फ़िक्स्ड source टैग और कैंपेन ID। Webhook दोनों करता है: एक आसान फ़ील्ड लिस्ट, जिसमें आप फ़ील्ड पर टिक करते हैं और हर key का नाम बदलते हैं, या एक JSON body जिसे आप nested objects, arrays और static values के साथ ख़ुद लिखते हैं।
Methods में GET, POST और PUT हैं, body JSON या URL-encoded form डेटा के रूप में जाती है, और custom headers API key या token ले जाते हैं, ताकि क्रेडेंशियल्स कभी URL में न रहें।
हर lead पर कम्प्लायंस और एट्रिब्यूशन फ़ील्ड
LanderLab हर lead में अपने फ़ील्ड जोड़ता है: पूरा पेज URL, विज़िटर का IP और user agent, UTC में सबमिशन का समय और दिखाया गया A/B वेरिएंट। Lead पर विवाद होने पर बायर यही फ़ील्ड जांचता है, और यही आपको यह साबित करने के लिए चाहिए कि lead कहां से आया।
अपने URL पैरामीटर के नाम वाले हिडन फ़ील्ड जोड़ें, जैसे utm_campaign, gclid या किसी ट्रैकर का click ID, और वे lead के साथ सेव भी होते हैं और उसके साथ भेजे भी जाते हैं। बायर को एट्रिब्यूशन मिलता है, और आप हर वेरिएंट को सिर्फ़ भरे गए फ़ॉर्म से नहीं, बल्कि स्वीकार हुए leads से परख सकते हैं।
GET से postbacks और pings
हर डेस्टिनेशन को body नहीं चाहिए। ट्रैकर का postback, एफ़िलिएट नेटवर्क का conversion URL या एक सादा ping अपना डेटा क्वेरी स्ट्रिंग में लेता है, और GET webhook मैप किए गए फ़ील्ड ठीक उसी तरह भेजता है: click ID उसी पैरामीटर नाम से जो ट्रैकर चाहता है, उसके बगल में एक static पेआउट या स्टेटस। सबमिट होते ही कन्वर्ज़न उस कैंपेन पर वापस जाता है जिसने उसके पैसे दिए।
कब इसकी जगह workflow इस्तेमाल करें
Webhook अपने पेज का हर lead भेजता है। जब सिर्फ़ कुछ leads जाने चाहिए, जैसे US के leads एक बायर को और बाक़ी दूसरे को, या डिले के बाद एक फ़ॉलो-अप, तो LanderLab के Workflows (बीटा) में वैसी ही रिक्वेस्ट HTTP Request नोड के रूप में है, फ़िल्टर, If और Switch नोड्स के पीछे, और एक Runs व्यू के साथ जो हर lead का रास्ता और कोई भी फ़ेल हुआ स्टेप दिखाता है।
दोनों ही सूरतों में lead, LanderLab के लीड्स टैब में भी सेव होता है, इसलिए डाउन पड़े endpoint की वजह से आपका lead नहीं खोता, बशर्ते “Compliance लीड Delivery” चालू न हो, जो जान-बूझकर स्टोरेज छोड़ देता है।
