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