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