संपर्क आणि संमती
फक्त आपल्याकडे असलेली नव्हे, तर बचाव करता येणारी यादी
दहा हजार ई-मेल पत्ते कोणाकडेही असू शकतात. खरा प्रश्न — जो नियामक, प्रदाता आणि आपली स्वतःची हीच्या थोड्या वेगळ्या शब्दांत विचारतात — असा आहे: प्रत्येक पत्ता कुठून आला आणि कोणत्या आधारावर आपण त्याला लिहू शकतो. ClickSomo हे पुन्हा जुनवण्यासाठी लागणारी गोष्ट नव्हे, तर साठवलेला तथ्य बनवते.
ओळख म्हणजे ई-मेल पत्ता
प्रत्येक प्रोजेक्टमध्ये प्रत्येक पत्त्यासाठी एकच संपर्क, ही आशा नव्हे तर डेटाबेसद्वारे लागू केलेली. पत्ते लिहिताना सामान्यीकृत (normalised) केले जातात, वाचताना कधीही नाही — वाचताना सामान्यीकरण केले तर ही बंधन फक्त एक सजावट ठरते जी Anna@ आणि anna@ दोन्ही आत सोडते.
फोन नंबर अस्तित्वात असतील तेव्हा E.164 मध्ये साठवले जातात, पण फोन नंबर हा एक गुणधर्म आहे, ओळख नाही. येथे ओळख-निर्करण ग्राफ नाही, विलीनीकरण प्रोटोकॉल नाही आणि विलीनीकरणांचा ऑडिट ट्रेल नाही, कारण येथे प्रत्येक संपर्क अशा मार्गाने येतो ज्याकडे आधीच एक पत्ता असतो: आयात, फॉर्म, सदस्यता, किंवा आपला स्वतःचा कोड.
नाव पूर्ण स्वरूपात साठवले जाते
display_name जसे दिले गेले तसेच ठेवले जाते आणि कधीही भागांत विभागले जात नाही. नाव विभागणे ही चुकांची कारखाना आहे — "van der Berg", "Kim Min-jun", एकच नाव, पदव्युत्तर शीर्षके, आणि अँग्लो व्यतिरिक्त प्रत्येक क्रमविचार परंपरा — आणि चुकीची विभागणी मर्ज टॅगमध्ये "Dear van," असे दिसते, जे वैयक्तीकरण नसण्यापेक्षाही वाईट आहे.
संरचित भाग केवळ त्या स्रोतांसाठी अस्तित्वात असतात जे ते आधीच विभागलेले पुरवतात. त्यांची निर्मिती कोणतेही तर्क करत नाही. आणि एखाद्याने स्वतः टाइप केलेले नाव नंतरच्या CSV ने कधीही अधिलिखित केले जात नाही ज्याने वेगळे काहीतरी नोंदवले, कारण शेवटचे-लेखन-जिंकते यामुळे सर्वात घाणेरडी आयात जिंकते.
- 1ओळखईमेल, सामान्यीकृत. प्रोजेक्टमध्ये अद्वितीय.
- 2नावपूर्ण स्वरूपात साठवले.
first_nameरेंडर वेळी तयार केले जाते, कधीही साठवले जात नाही. - 3गुणधर्मआपल्याला हवे ते काहीही, JSON स्वरूपात. आपले, आणि
attrs.*म्हणून अंतर्भावित करता येते. - 4टॅग आणि याद्याटॅग प्रथम श्रेणीचे आहेत आणि एकाच साठ्यात राहतात; याद्या स्पष्ट सदस्यत्व आहेत.
- 5संमतीप्रत्येक चॅनेलसाठी एक पंक्ती, वैध आधार आणि त्याचा पुराव्यासह.
- 6घटनाया व्यक्तीने केलेल्या प्रत्येक गोष्टीची केवळ-जोडणी-शक्य अशी नोंद. उत्पादन ज्या तक्त्यावर टिकलेले आहे तोच.
- ×कधीही नाहीपासवर्ड नाही, हॅश नाही, सेशन नाही, API की नाही. एखाद्याची प्रमाणीकरण करणारे स्तंभ ही घटना असेल, वैशिष्ट्य नाही.
टेनंट आणि प्रोजेक्ट दोन्हीसाठी व्याप्त
संमती खातेवजा
अनुपस्थिती ही परवानगी नाही
प्रत्येक संपर्कासाठी प्रत्येक चॅनेलमध्ये एक पंक्ती — ईमेल, SMS, पत्र, पुश — प्रत्येकी एक स्थिती, एक वैध आधार, एक स्रोत, पुरावा, टाइमस्टॅम्प आणि न्यायक्षेत्र असते. ज्या चॅनेलसाठी संपर्काकडे आधार-पंक्ती नाही, त्या चॅनेलवर त्याला काहीही पाठवता येत नाही. "चिन्हांकित आहे" असे नाही. पाठवताच येत नाही.
consent
एखाद्याने सक्रियपणे विचारले. पुरावा साठवलेला फॉर्म सबमिशन, डबल ऑप्ट-इन, त्यांनी स्वतः चिन्हांकित केलेले चेकबॉक्स. हा सर्वात मजबूत आधार आहे आणि फॉर्म निर्माण करू शकणारा हाच एक आहे.
legitimate_interest
CSV आयात मिळवू शकणारे सर्वात चांगले. स्प्रेडशीट एखाद्याच्या संमतीचे स्मरण ठेवू शकत नाही, म्हणून तिला तसा दावा करण्यास कधीही परवानगी नाही — आणि तीच फाईल पुन्हा अपलोड केल्याने ती सुधारत नाही.
contract
आपण त्यांना लिहित आहात कारण दोघेही ज्याचे पक्षकार आहेत अशी एखादी गोष्ट. सेवा स्मरणपत्र, नूतनीकरण सूचना, जी गोष्ट न मिळाल्यास त्यांना नाराजी होईल.
मोहिमा पाठवण्यापूर्वी, आपण तिच्या प्रेक्षकांचे आधार-मिश्रण पाहता: यापैकी किती लोकांनी विचारले, कितींपर्यंत आपण वैध हितांतर्गत पोहोचत आहात, आणि किती करारामुळे आहेत. ही एक संख्या अशी आहे ज्याने कधीही लिहिलेल्या कोणत्याही चेतावणी-बॅनरपेक्षा अधिक चुकीच्या पाठवण्या थांबवल्या आहेत.
आपल्यासाठी आवश्यकतेपेक्षा हे अधिक कडक का आहे: हे खरोखर आपल्याबद्दल नाही. बल्क पाठवण्याची प्रतिष्ठा हा सामायिक संसाधन आहे, आणि एक बेजबाबदार यादी त्याच पायाभूत सुविधेवरून पाठवणाऱ्या सर्वांसाठी विहिरी विषबद्ध करते. प्रत्येक टेनंटचे तक्रार आणि बाउंस दर पाहिले जातात, आणि ज्या खात्याचे दर मर्यादा ओलांडतात ते येथे मंदावले जाते — प्रदात्याने सर्वांवर एकत्र ते करण्यापूर्वी.

यादीतील प्रत्येक पंक्तीच्या मागे, एखाद्याने होकार दिला आहे.
प्रवेशाचे चार मार्ग
आपल्या यादीतील प्रत्येक मार्ग हा आपण स्वतः, आपल्या स्वतःच्या डेटावर कृती करत आहात
येथे सेवा-टोकन इन्जेस्ट मार्ग नाही आणि आपल्या संपर्कांत शांतपणे लिहिणारे कोणतेही सख्य उत्पादन नाही. आपल्याला एखाद्याला यादीत हवे असल्यास, या चारपैकी एकाने त्याला तिथे टाकले आहे.
CSV आयात
स्तंभानुसार मॅप केलेले, लेखनावेळी सामान्यीकृत, MX-तपासलेले म्हणजे मृत आणि चुकीच्या टाइप असलेले डोमेन हार्ड-बाउंस होण्यापूर्वी पकडले जातात, आणि आपण स्पष्टपणे निश्चित केलेल्या आधारासह जमा केलेले. आयातला एक id मिळते, आणि त्याने तयार केलेला प्रत्येक संपर्क त्याकडे परत निर्देश करतो.
ClickSomo फॉर्म
बाकी सर्वांप्रमाणेच त्याच दस्तऐवजावरून रेंडर केलेले, पडताळणी, हनीपॉट आणि दर-मर्यादेसह. सबमिशन हा एकमेव मार्ग आहे जो वैधपणे consent निर्माण करू शकतो, कारण व्यक्ती उपस्थित असणारा हाच एक मार्ग आहे.
dash-b मध्ये आपण बनवलेले पृष्ठ
डॅशबोर्ड डिझायनर पृष्ठे प्रकाशित करतो; त्यापैकी एकावरील फॉर्म आपल्या स्वतःच्या क्रेडेन्शियल्ससह येथे पोस्ट करतो. तीच पडताळणी, तीच संमती हाताळणी, राखण्यासाठी दुसरे एकत्रीकरण नाही.
सार्वजनिक API
आपल्या स्वतःच्या टोकनसह POST /v1/contacts, upsert अर्थशास्त्र, idempotency की सन्मानित. आपले अॅप आधीच जाणते कोणी साइन अप झाले; हा त्या तथ्यापासून फनेलपर्यंतचा सर्वात लहान मार्ग आहे.
विभाग म्हणजे एक प्रेडिकेट, कंपाइल केलेला
विभाग म्हणजे संपर्क फील्ड्स, गुणधर्म, टॅग्स, यादीतील सदस्यता आणि वर्तनावरील साठवलेले प्रेडिकेट वृक्ष, जो SQL मध्ये कंपाइल होतो आणि संख्येसह कॅशे केला जातो. ऑपरेटर्स सामान्यच आहेत — बरोबर, बरोबर नाही, मध्ये, मध्ये नाही, ने सुरू होतो, ने संपतो, अंतर्भूत करते, सेट आहे, सेट नाही — आणि and, or आणि not च्या साहाय्याने आवश्यक तितक्या खोलीपर्यंत जोडले जातात.
वापरण्यापूर्वी त्याचे पूर्वावलोकन घ्या. या एंडपॉइंटमधून प्रत्यक्ष संपर्क येतात, त्यामुळे "यात प्रत्यक्षात कोण आहे" हा प्रश्न पाठवून शोधण्याऐवजी पाहून उत्तर देता येते.
विभागांचे दुहेरी काम आहे: मोहिमेसाठी प्रेक्षक म्हणून, फनल शाखेवरील अट म्हणून, आणि स्वतःच ट्रिगर म्हणून — segment_enter कोणी पात्र होताक्षणी रन सुरू करते.
- 1टॅग
tags contains "regular" - 2गुणधर्म
attrs.total_orders >= 3— तुमचे फील्ड, त्यासाठी तुमचेच नाव. - 3वर्तनगेल्या ९० दिवसांत
order.paidइव्हेंट नाही. - 4संमतीईमेलसाठी वापरता येईल अशी पाया. ज्या संपर्कांकडे तो नाही ते संख्येत नाहीत, कारण त्यांना पाठवताच येणार नाही.
- iप्रीव्ह्यू412 संपर्क, सूचीबद्ध. पाठवताना पुन्हा मोजले जातात, कारण विभाग हा प्रश्न आहे, स्नॅपशॉट नाही.
SQL मध्ये कंपाइल केलेसंख्या कॅशे केलेली, उत्तर ताजे
दमन आणि ते कधी तपासले जाते
दमन प्रकल्प-व्यापी आणि जागतिक आहेत: कठीण बाउन्स, तक्रारी, अनसब्सक्रिप्शन्स, मॅन्युअल नोंदी आणि भूमिका पत्ते. ते पाठवताच्या वेळी तपासले जातात, आणि नंतर पाठवणाऱ्या सेवेतही पुन्हा तपासले जातात.
ते दुसरे तपासणीचे ठिकाणच खरे काम करते. तीन दिवसांची प्रतीक्षा असलेल्या फनलमध्ये तीन दिवसांची क्षुल्लक शक्यता असते ज्यात कोणी अनसब्सक्राइब करू शकतो, आणि संदेश कतारमध्ये असताना दमन तपासणारी प्रणाली तरीही त्यांना मेल पाठवेल. पाठवताच्या वेळी तपासणे म्हणजे अनसब्सक्रिप्शनचे पालन करणे आणि फक्त ती नोंदवणे यातील फरक आहे.
मिटवणे (इरेजर) अशाच प्रकारे काम करते: डिलीट विनंती येथे संपर्क आणि त्यांचा संदेश इतिहास काढून टाकते, आणि प्रत ठेवलेल्या प्रत्येक सहोदर सेवेपर्यंत कुटुंबाच्या बाकी भागासारख्याच अंतर्गत मार्गाने पोहोचते. विचारण्यासाठी एकच ठिकाण आणि घडणारी एकच गोष्ट.