फनेल्स व ट्रिगर्स
फनेल म्हणजे आलेख. रन म्हणजे ओळ. वेट म्हणजे वेळ.
हेच संपूर्ण मॉडेल आहे, आणि या उत्पादनाचे प्रत्येक कठीण गुणधर्म या तीन वाक्यांतूनच निघतात. चालू फनेल संपादित करणे सुरक्षित आहे ते त्यांच्यामुळे. पुन्हा प्रयत्न दुहेरी पाठवणूक करू शकत नाही ते त्यांच्यामुळे. मंगळवारी अनसब्सक्राईब करणारी व्यक्ती गुरुवारी काहीही ऐकत नाही ते त्यांच्यामुळे.
चालू झाल्यावर प्रत्यक्षात काय होते
फनल प्रकाशित केल्याने एक अपरिवर्तनीय आवृत्ती तयार होते. कोणीतरी प्रवेश करतो, आणि एक ओळ दिसते: या संपर्कासाठी एक रन, त्या आवृत्तीशी बद्ध, सध्याचा नोड, एक जागृती वेळ आणि त्याचा स्वतंत्र संदर्भ यांना धारण करणारी.
वर्कर ज्या रन्सची जागृती वेळ उलटून गेली आहे त्या भाड्याने घेतो, आणि SKIP LOCKED वापरून त्यांचा दावा करतो, ज्यामुळे दोन वर्कर्स एकाच रनवर हात टाकू शकत नाहीत. तो wait किंवा terminal पर्यंत नोड्स चालवतो, नंतर पुढील जागृती वेळ लिहून सोडून देतो.
नोड हा रन, संपर्क आणि नोड यांचे शुद्ध फंक्शन आहे — आणि त्याचे परिणाम रनच्या पुढील प्रगतीसह एकाच ट्रान्झॅक्शनमध्ये कमिट होतात. हाच एक गुणधर्म रिट्राय सुरक्षित बनवतो. "पाठवा" आणि "पुढे न्या" यांच्यातील अर्ध्या सेकंदात मारला गेलेला वर्कर एकतर दोन्ही सोडतो किंवा दोन्हीही नाही, कधीही एक नाही.
आणि वेळ डेटाबेसकडून नव्हे तर ॲपकडून येत असल्याने, आत्ता लिहिलेली ओळ आत्ताच देय असते. डेटाबेस घड्याळावर डीफॉल्ट होणारा शेड्युलिंग स्तंभ लिहिल्याच्या क्षणी देय नसतो, आणि त्याला निर्माण करणारी तीच टिक मिसळते — एक बग जो संदेश तास भर उशीरा पोहोचेपर्यंत काहीही नसल्यासारखा दिसतो.
- 1लीज
wake_at <= now(),FOR UPDATE SKIP LOCKED. लीजशिवायची क्यू डीफॉल्टने दुहेरी पाठवते. - 2चालवाwait किंवा terminal पर्यंत नोड्स क्रमाने. प्रत्येक जण एक स्टेप लिहितो: त्याने काय ठरवले, काय बाहेर टाकले.
- 3कमिट करापरिणाम आणि प्रगती, एक ट्रान्झॅक्शन. हाच संपूर्ण गूढ.
- 4झोपपुढील
wake_atलिहिले जाते. अजून कोणत्याही डाउनस्ट्रीम ओळी अस्तित्वात नाहीत, आणि त्यांची गरजही नाही.
प्रति संपर्क प्रति आवृत्ती एक रन
चौदा ट्रिगर्स
रन सुरू करू शकणारे काय
यापैकी काही गोष्टी आपण करता. बहुतेक गोष्टी आपला ग्राहक करतो किंवा करत नाही — आणि कृतीचा अभावही कृतीइतकाच चांगला ट्रिगर आहे.
ते येतात
form_submit, list_join, contact_created, tag_added आणि segment_enter. सेगमेंट हा जिवंत प्रेडिकेट असल्याने, "सेगमेंटमध्ये प्रवेश" हे आपण व्यक्त करू शकता असे प्रत्येक "झाले आहे" व्यापते — तीन ऑर्डर, नव्याऐंशी दिवस शांत, एका मर्यादेपेक्षा जास्त खर्च.
ते काहीतरी करतात
साइट स्निपेटकडून page_visit, message_opened, link_clicked, booking_made आणि payment_made. संदेश उघडणे स्वतः संपर्कावरील एक इव्हेंट असल्याने, एक फनल त्याने पाठवलेल्या शेवटच्या गोष्टीला मिळालेल्या प्रतिक्रियेची वाट पाहू शकतो.
वेळ, किंवा आपण
ऑफसेटसह date_field — वाढदिवस, नूतनीकरण, "एक वर्ष झाले", आधी सात दिवस किंवा नंतर तीन दिवस. आवर्ती गोष्टीसाठी schedule. आपण ठरवल्यामुळे पाठवता त्या घोषणेसाठी manual.
आपले स्वतःचे ॲप्लिकेशन
api_event हा आपल्या स्वतःच्या कोडमधून आपल्या स्वतःच्या टोकनसह पोस्ट केलेला कस्टम इव्हेंट आहे. आपले प्रॉडक्ट काहीही जाणते ते ट्रिगर बनते: ॲक्टिव्हेट झाले, सहकाऱ्याला आमंत्रित केले, मर्यादा गाठली, रद्द केले, एक्सपोर्ट केले. हाच तो एक गोष्ट आहे जी मेलिंग टूलला आपल्या प्रॉडक्टचा भाग बनवते.
पुनःप्रवेश, एकदाच ठरवलेला
फनल एकतर पुनःप्रवेशयोग्य असतो किंवा नाही, आणि डेटाबेस ते लागू करते: आपण अन्यथा सांगितले नाही तोपर्यंत प्रति संपर्क प्रति फनल एक रन. त्याच सेकंदात दोनदा वाजणारा तोच ट्रिगर चुकून दोन रन्स तयार करू शकत नाही.
प्रवेश अटी
ट्रिगर वाजतो आणि एंट्री स्पेक ठरवते की या विशिष्ट संपर्काला पात्रता आहे का — दारासमोर एक सेगमेंट प्रेडिकेट. पहिल्या स्टेपवर कंडिशन नोडपेक्षा स्वस्त, आणि त्यामुळे ग्राफ "कोण आत येऊ शकतो" याऐवजी "काय घडते" याबद्दलच राहतो.
चौदा गोष्टी त्याला सुरू करू शकतात. पुढे सोळा गोष्टी घडू शकतात.
सोळा ॲक्शन्स आणि सात फ्लो नोड्स
फनल काय करू शकतो, आणि तो कसा ठरवतो
काहीतरी पाठवा
send_email, send_sms, send_push, send_letter — चार चॅनेल, एक ग्राफ — आणि notify_team, जेव्हा कळवायची व्यक्ती आपल्याच संस्थेत काम करते.
संपर्क बदला
add_tag, remove_tag, add_to_list, remove_from_list, set_field. जाताना कोणाला चिन्हांकित करणे हेच पुढील फनलचा सेगमेंट सोपा बनवते.
बाहेर पोहोचा
आपल्या आवडीच्या कोणत्याही गोष्टीकडे http_request, आपल्या स्वतःच्या जोडलेल्या खात्याविरुद्ध create_payment, आणि बुकिंग रिसोर्सविरुद्ध book_slot. देयक देणारा आपलाच राहतो; कोणीही आपला ग्राहक होत नाही.
फनल्समध्ये हलवा
enter_funnel आणि exit_funnel. एक वेलकम सिक्वेन्स बनवा आणि चार ठिकाणी त्याला कॉल करा, मार्चपर्यंत वेगळे वळलेल्या चार प्रती राखण्यापेक्षा.
पाठवताना तयार करा
ai_generate प्रत्येक संपर्कासाठी मर्ज व्हेरिएबल्स भरते, आपल्या कोटाविरुद्ध मोजले जाते आणि क्रिएटिव्ह व संपर्क-ॲट्रिब्यूट हॅशनुसार कॅश होते — अन्यथा आपण प्रत्येक पाठवणीवर प्रत्येक प्राप्तकर्त्यासाठी पैसे देत असाला.
प्रतीक्षा, शाखा, विभाजन, एकत्रीकरण
wait कालावधी, दिनांक-वेळ, आठवड्याचा दिवस व वेळ, किंवा ऑफसेटसह दिनांक फील्ड घेते. condition हा होय आणि नाही असा विभाग-निर्देशक आहे. split हे वजनांसह A/B/n आहे. join शाखांना पुन्हा एकत्र आणते.
goal — जो महत्त्वाचा आहे तो
ध्येय गाठणाऱ्या प्रत्येकासाठी चालणे संपते. त्यांनी बुक केले, खरेदी केली, उत्तर दिले: त्यांच्यासाठी विशेषतः अनुक्रमाचा उर्वरित भाग रद्द होतो. कोणी परत आल्याच्या दुसऱ्या दिवशी त्यांना "आम्हाला तुमची आठवण येते" असा संदेश मिळत नाही, आणि हे ताक ते टाळणारे नोड आहे.
throttle आणि quiet_hours
थ्रॉटल एकाच वेळी येणारा ओघळ नियंत्रित करते, म्हणून कमी दरमर्यादा असलेले मेलबॉक्स निलंबित होण्याइतके ताणले जात नाही. शांत तास संदेश सभ्य वेळेपर्यंत धरून ठेवतात — हे संदेश-स्तरावर लागू होते, ग्राफच्या प्रत्येक शाखेत कॉपी केले जात नाहे.
चालण्यापूर्वी तपासले जाते
प्रमाणक आपल्यासाठी आणि AI साठी त्याच गोष्टी नाकारते
प्रकाशित होण्यापूर्वी ग्राफ तपासला जातो, आणि ही तपासणी केवळ सल्लामसलत नसते. फनेल माणसाने काढला किंवा मॉडेलने तयार केला, यासाठी तीच कोड-मार्ग वापरली जाते, आणि तयार केलेले फनेल विश्वासार्ह आहेत याचे एकमेव कारण हेच आहे.
अचूक एकच प्रवेश
दोन प्रवेश-नोड्स असा अस्पष्टपणा आहे जो यादीचा चुकीचा अर्धा भाग चुकीचा अनुक्रम मिळेपर्यंत कोणालाच लक्षात येत नाही.
प्रत्येक नोड पोहोचण्यायोग्य
अनाथ शाखा ही चूक असते किंवा असा संदेश असतो जो आपल्याला वाटते बाहेर जात आहे पण जात नाही. दोन्ही बाबतींत कळविले जाणे महत्त्वाचे आहे.
प्रत्येक चक्रात प्रतीक्षा असणे आवश्यक
आत प्रतीक्षा नसलेला लूप म्हणजे मध्यभागी पाठवणी असलेला अनंत लूप. हा नियम फनेल आणि घटना (incident) यांतील फरक आहे.
प्रत्येक पाठवणीची तयार सामग्री असते
क्रिएटिव्ह आणि विषय नसलेला send_email नोड प्रकाशित होऊ शकत नाही. योग्य विषय आणि रिकामी मजकूर असलेला संदेश ही वास्तविक अपयश-स्थिती आहे; ती येथे नाकारली जाते.
प्रत्येक चल परिचित असते
मर्ज चले प्रकाशनावेळी पडताळली जातात. {{frist_name}} ही संपादन करताना दिसणारी चुक आहे, चाळीस हजार इनबॉक्समध्ये पोहोचणारा "नमस्कार ," नाही.
मग ते सिम्युलेट करा
खऱ्या संपर्काला संपूर्ण ग्राफमधून ड्राय-रन करा आणि घेतलेला मार्ग व पाठवला जाणारा प्रत्येक संदेश, त्याच्या दिवसासह, परत वाचा. काहीही बाहेर जात नाही.
अवघड प्रकरणे
साधी इंजिन तोडणाऱ्या सात गोष्टी
यापैकी प्रत्येक गोष्टीची चाचणी निश्चित घड्याळाच्या पाठिंब्यावर आहे, कारण प्रत्येकी अशी अंमलबजावणी तोडते जी वास्तवास भेटेपर्यंत अगदी बरोबर दिसते.
- 1स्वतःमध्ये लूप होणारा फनेलवैध, सामान्य आणि ठीक — जोपर्यंत चक्रात प्रतीक्षा असते, जी प्रमाणक आग्रह धरते.
- 2कोणी वाटेतच अनसब्सक्राइब करतेप्रतिबंध पाठवताना तपासला जातो, रांगेत लावताना नाही. रांगेत लावताना तपासल्यास प्रतीक्षेदरम्यान निघून गेलेल्या लोकांनाही मेल जाते.
- 3दहा हजार लोक आत असताना फनेल संपादित केला जातोते ज्या आवृत्तीत शिरले तीच आवृत्ती शेवटपर्यंत चालवतात. नवीन येणारे नवीन आवृत्ती चालवतात.
- 4एकाच सेकंदात तोच ट्रिगर दोनदा चालतोएकच चालणे, कारण अद्वितीयता ही तपासणीनंतरची इन्सर्ट नसून अनुक्रमणिका (index) असते.
- 5चालत असताना संपर्क काढून टाकला जातोचालणे संपते. अनुक्रम अजून कोणाला संबोधित असा ठेवणारे मिटवणे हे मिटवणे नसते.
- 6प्रतीक्षा डेलाइट-सेव्हिंग बदलावर येते"सकाळी नऊ तीन दिवस" याचा अर्थ घड्याळ बदलाच्या दोन्ही बाजूंनी सकाळी नऊ असा होतो.
- 7पाठवणी आणि पुढे जाण्याच्या दरम्यान वर्कर मारला जातोपरिणाम आणि पुढे जाणे हे एकच व्यवहार (transaction) आहे. दोन्ही घडले किंवा एकही घडले नाही.
निश्चित (डिटरमिनिस्टिक) घड्याळप्रत्येक चाचणी एका विश्वसनीय असलेल्या अंमलबजावणीला अयशस्वी करते
मोहिमा (कॅम्पेन) हा दुसरा अर्धा भाग आहे
फनेल प्रतिक्रिया देते. मोहिम ही एकदाच पाठवली जाणारी घोषणा असते: प्रेक्षकवर्ग, वेळापत्रक, दरमर्यादा आणि पाठवणी. ही वेगळ्या आकाराची गोष्ट आहे आणि ती एका नोडचा फनेल असल्याचे ढोंग करण्याऐवजी जाणीवपूर्वक वेगळी ठेवली जाते.
दोन नियम ते सुरक्षित करतात. प्रेक्षकवर्ग एकदाच तयार केला जातो आणि दुसऱ्यांदा चालवण्यास नकार देतो — पुन्हा तयार केल्यास पाठवणी सुरू झाल्यानंतर सामील झालेले सर्व जण शांतपणे जोडले जातील, आणि डिप्लिकेशन-प्रतिबंधक निर्देशांक त्यांना निर्माण होणारे प्रत रोखून ते लपवेल. आणि मोजके आकडे वितरण घटनांवरून पुन्हा मोजले जातात, जागेवर वाढवले जात नाहीत, त्यामुळे पुन्हा पाठवलेला वेबहुक अहवाल सुजवू शकत नाही.
कोणते वापरावे: व्यक्तीने केलेल्या कृतीमुळे घडत असेल तर तो फनेल आहे. आपण मंगळवारी ठरवलेल्या निर्णयामुळे घडत असेल तर ती मोहिम आहे. बऱ्याच मार्केटिंग ऑटोमेशनमध्ये दुसऱ्याला पहिल्याच्या आकारात भरवण्यामुळे चुका होतात.