SaaS और प्रोडक्ट टीमें
आपका प्रोडक्ट वे बातें जानता है जो कोई मार्केटिंग टूल नहीं देख सकता
किसने ऑनबोर्डिंग पूरी की और कौन तीसरे चरण पर अटक गया। किसने सहकर्मी को आमंत्रित किया। किसने इस सप्ताह दो बार सीमा छुई। किसने पखवाड़े से उस चीज़ को नहीं खोला। इनमें से हर एक, ईमेल ओपन से निकाली गई किसी भी चीज़ से बेहतर ट्रिगर है, और ये सभी उस तक पहुँचने के लिए दो पंक्तियों के कोड की दूरी पर हैं।
इवेंट्स ही पूरा इंटीग्रेशन हैं
अपने टोकन के साथ POST /v1/events: आपके चुना हुआ एक नाम, एक संपर्क, एक पेलोड, एक आइडेम्पोटेंसी कुंजी। यही पूरा कनेक्शन है। कोई SDK अद्यतित रखने को नहीं, कोई मैपिंग स्क्रीन नहीं, और हमारी कोई ऐसी शब्दावली नहीं जिसमें आपको अपना प्रोडक्ट अनुवाद करना पड़े।
प्रत्येक इवेंट संपर्क के केवल-जोड़ने-योग्य लॉग पर दर्ज होता है, और वहाँ से वह एक साथ तीन चीज़ें है। एक ट्रिगर, ताकि उसके आने पर फ़नल शुरू हो। एक प्रेडिकेट, ताकि कोई सेगमेंट कह सके "पिछले चौदह दिनों में यह किया है" या, अधिक उपयोगी रूप से, "नहीं किया है"। और एक लक्ष्य, ताकि जिस क्षण कोई वह चीज़ कर दे जिसकी ओर सीक्वेंस उसे धकेल रहा था, सीक्वेंस उसी क्षण समाप्त हो जाए।
यही तीसरी चीज़ है जो लाइफ़साइकिल संदेशों को प्राप्त करने योग्य बनाती है। अपना खाता पूरा सेट अप करने का अनुस्मारक उसी सेकंड अस्तित्व में नहीं रहना चाहिए जिस सेकंड खाता सेट अप हो जाए, और अधिकांश टूल्स में ऐसा नहीं होता, क्योंकि सीक्वेंस और प्रोडक्ट आपस में बात नहीं करते।
- ⚡ट्रिगर
api_event—signup.completed, प्लानfree। - 2ई-मेल भेजेंसबसे पहले करने वाला एक काम। ग्यारह फ़ीचर का टूर नहीं।
- 32 दिन प्रतीक्षा करेंरन पर
wake_at। कुछ भी कतार में नहीं, कल इसे फिर से लिखने पर कुछ भी सुलझाने की ज़रूरत नहीं। - ?शर्तक्या
project.createdआ गया? नहीं → सहायता शाखा। हाँ → नीचे का लक्ष्य। - 4सहायता शाखाएक संदेश, जो वह विशिष्ट चीज़ पेश करे जो उन्होंने नहीं की। फिर एक और प्रतीक्षा।
- 5लक्ष्य
project.createdआ जाता है। रन समाप्त हो जाता है। इस व्यक्ति के लिए आगे कभी कोई ऑनबोर्डिंग मेल नहीं।
आपके इवेंट नामसक्रियण की आपकी परिभाषा
पाँच फ़नल
जीवनचक्र, उसी क्रम में जिसमें वह वास्तव में घटित होता है
1 · सक्रियण
ट्रिगर: साइन-अप। दो या तीन संदेश, प्रत्येक एक क्रिया के बारे में, प्रत्येक में एक लक्ष्य जो उस क्रिया के होने पर अनुक्रम समाप्त कर दे। यह सबसे मूल्यवान फ़नल है जो आप बनाएँगे, और वह जिसे तीन बार फिर से लिखना सबसे उपयोगी है।
2 · रुकावट
ट्रिगर: segment_enter — साइन अप किया, सात दिनों में कोई सार्थक इवेंट नहीं। एक संदेश जो बताने के बजाय पूछे, और एक जो कोई विशिष्ट चीज़ पेश करे। फिर रुक जाएँ। जिस किसी ने तीन संदेश नज़रअंदाज़ किए हों, उसे चौथा संदेश किसी को नहीं पहुँचता।
3 · विस्तार का क्षण
ट्रिगर: कोई इवेंट जो दर्शाता है कि उन्हें मूल्य मिल रहा है — सीमा तक पहुँच गए, तीसरे सहकर्मी को आमंत्रित किया, दूसरी बार निर्यात किया। यही एकमात्र क्षण है जब अपग्रेड संदेश स्वागत योग्य होता है, और यह एक ऐसा क्षण है जिसे आपका उत्पाद सटीक रूप से नाम दे सकता है।
4 · नवीनीकरण और डनिंग
ट्रिगर: नवीनीकरण से पहले date_field, या कोई भुगतान इवेंट। सूचना, अनुस्मारक, और — यदि भुगतान विफल हो — एक छोटा अनुक्रम जो सफल होते ही तुरंत रुक जाए। डनिंग में लक्ष्य नोड्स वैकल्पिक नहीं हैं; वे अनुस्मारक और उत्पीड़न का अंतर हैं।
5 · पुनः जोड़ना (विन-बैक)
ट्रिगर: segment_enter — रद्द किया या साठ दिनों से निष्क्रिय। दो संदेश, ईमानदार वाले, फिर एक टैग और मौन। उनके जाने के बाद क्या बदला, यह छूट से बेहतर संदेश है।
और आंतरिक वाला
notify_team किसी मानव को सूचित करता है जब मानव के लायक कोई खाता किसी रेखा को पार करता है। फ़नल का अंत ग्राहक को ई-मेल में होना ज़रूरी नहीं; कभी-कभी सही कार्य यह बताना है कि आपकी ओर का कोई व्यक्ति फ़ोन उठाए।
कोई जानबूझकर नहीं छोड़ता। वे बस इसे खोलना बंद कर देते हैं।
डेवलपर को यह वास्तव में क्यों पसंद आ सकता है
जब एकीकरण आप ही कर रहे हों तो वे हिस्से जो मायने रखते हैं
कोई निजी एंडपॉइंट नहीं
हर स्क्रीन सार्वजनिक API से बनाई जा सकती है, क्योंकि दूसरा कोई प्रकार है ही नहीं। यदि आप अपने स्वयं के एडमिन में कैंपेन रिपोर्ट एम्बेड करना चाहें, तो कुछ भी आपके रास्ते में नहीं है और कुछ भी रिवर्स-इंजीनियर नहीं करना पड़ेगा।
हर जगह आइडेम्पोटेंसी कीज़
हर परिवर्तनकारी रूट पर। आपका रिट्राय लॉजिक, आपकी at-least-once कतार और आपका अस्थिर नेटवर्क — सब किसी और की समस्या बन जाते हैं — विशेष रूप से, एक यूनिक इंडेक्स की समस्या।
शिप करने से पहले सिमुलेट करें
POST /v1/simulate किसी संपर्क को फ़नल से ड्राई-रन करता है और पथ तथा वह हर संदेश लौटाता है जो वह भेजता। चाहें तो इसे CI में डालें: फ़नल एक ग्राफ़ है, और ग्राफ़ का परीक्षण किया जा सकता है।
एक MCP सर्वर
किसी एजेंट को /mcp की ओर इंगित करें और उससे फ़नल बनवाएँ व जाँचवाएँ। भेजने में सक्षम टूल्स को स्पष्ट पुष्टि चाहिए और वे कोटा तक सीमित हैं, इसलिए गलत पढ़ा गया प्रॉम्प्ट पचास हज़ार ई-मेल नहीं बन सकता।
वेबहुक बाहर
हस्ताक्षरित, बैकऑफ़ के साथ पुनः प्रयासित, कम से कम एक बार। वही इवेंट शब्दावली जो रिपोर्ट उपयोग करती हैं, ताकि आपका वेयरहाउस और आपका डैशबोर्ड "delivered" के अर्थ पर असहमत न हों।
मिटाना जो वास्तव में पहुँचता है
हटाने का अनुरोध संपर्क और उनका संदेश इतिहास यहाँ हटाता है और हर सहोदर सेवा तक फैलता है जिसके पास प्रतिलिपि थी। एक अनुरोध, एक परिणाम, और कुछ ऐसा जिसकी ओर पूछे जाने पर इशारा कर सकें।
सीमा कहाँ है
ClickSomo एक मेलिंग सूची और उस सूची ने क्या किया, यह रखता है। यह आपका उपयोगकर्ता डेटाबेस नहीं है और बनने की कोशिश भी नहीं करता: संपर्क कभी कोई क्रेडेंशियल नहीं रखता, कभी साइन इन नहीं करता, और कभी खाता नहीं बनता। आपके उपयोगकर्ता आपके उत्पाद में रहते हैं; संपर्क यहाँ रहते हैं, और दोनों एक ई-मेल पते तथा आपके द्वारा भेजे चुने इवेंट्स से जुड़े होते हैं।
यह पृथक्करण जानबूझकर है और यही कारण है कि सहमति मॉडल काम करता है। आप अपने उपयोगकर्ताओं के लिए डेटा नियंत्रक हैं; हम आपकी ओर से प्रक्रिया करते हैं। ऐसा डिज़ाइन जहाँ कोई मार्केटिंग टूल चुपचाप पहचान-भंडार बन जाए, बाद में उसे सुलझाया नहीं जा सकता, और यही वह विफलता है जिससे बचने के लिए यह बनाया गया है।
व्यावहारिक संस्करण: इवेंट भेजें, वे एट्रिब्यूट भेजें जिन पर आप सेगमेंट बनाना चाहते हैं, और बाकी सब अपने स्थान पर रखें। यदि आप अपनी पूरी स्कीमा यहाँ धकेलने लगें, तो जिस सेगमेंट को आप बनाने की कोशिश कर रहे हैं वह संभवतः आपके अपने डेटाबेस में एक क्वेरी है जिसे एक बूलियन एट्रिब्यूट के रूप में आना चाहिए।