clickSomo
ClickSomo खोलें

संपर्क और सहमति

एक ऐसी सूची जिसे आप बचा सकें, न केवल जिसे आपके पास रखा हो

कोई भी दस हज़ार ई-मेल पते रख सकता है। महत्वपूर्ण सवाल — जो नियामक, सेवा प्रदाता और आपका अपना विवेक थोड़े अलग शब्दों में पूछते हैं — यह है कि हर पता कहाँ से आया और किस आधार पर आप उसे लिख सकते हैं। ClickSomo इसे फिर से जोड़ने के लिए मजबूर किए जाने वाली बात के बजाय एक संग्रहीत तथ्य बना देता है।

पहचान ई-मेल पता है

प्रति पता प्रति प्रोजेक्ट एक संपर्क, जिसे आशा के बजाय डेटाबेस द्वारा लागू किया जाता है। पते लिखते समय सामान्यीकृत (नॉर्मलाइज़) किए जाते हैं, पढ़ते समय कभी नहीं — पढ़ते समय सामान्यीकरण करने पर यह बाध्यता केवल एक सजावट भर रहती है जो 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-जाँच के साथ ताकि मृत और गलत टाइप किए डोमेन हार्ड-बाउंस से पहले पकड़े जाएँ, और आपके द्वारा स्पष्ट रूप से निर्धारित आधार के साथ संग्रहीत। आयात को एक आईडी मिलती है, और उसके द्वारा बनाया गया हर संपर्क उसी की ओर इशारा करता है।

एक ClickSomo फ़ॉर्म

बाकी सब चीज़ों की तरह उसी दस्तावेज़ से रेंडर किया गया, जिसमें वैलिडेशन, एक हनीपॉट और रेट लिमिट शामिल है। सबमिशन ही वह एकमात्र रास्ता है जो वैध रूप से consent आधार बना सकता है, क्योंकि यही एकमात्र स्थिति है जिसमें व्यक्ति मौजूद होता है।

dash-b में आपके बनाया एक पेज

डैशबोर्ड डिज़ाइनर पेज प्रकाशित करता है; उनमें से किसी एक पर मौजूद फ़ॉर्म आपके अपने क्रेडेंशियल्स के साथ यहाँ पोस्ट करता है। वही वैलिडेशन, वही consent हैंडलिंग, बनाए रखने के लिए कोई दूसरा इंटीग्रेशन नहीं।

सार्वजनिक API

आपके अपने टोकन के साथ POST /v1/contacts, अपसर्ट सिमेंटिक्स, इडेम्पोटेंसी की सम्मानित। आपका ऐप पहले से जानता है कि किसने साइन अप किया; उस तथ्य से फ़नल तक पहुँचने का यह सबसे छोटा रास्ता है।

सेगमेंट एक प्रेडिकेट है, संकलित

सेगमेंट संपर्क फ़ील्ड, एट्रिब्यूट, टैग, लिस्ट सदस्यता और व्यवहार पर एक संग्रहीत प्रेडिकेट ट्री है, जिसे SQL में संकलित कर एक गिनती के साथ कैश किया जाता है। ऑपरेटर साधारण हैं — equals, not equals, in, not in, starts with, ends with, contains, is set, is not set — जिन्हें and, or और not के साथ आपकी आवश्यकता अनुसार किसी भी गहराई तक जोड़ा जा सकता है।

उपयोग करने से पहले उसका पूर्वावलोकन करें। यह एंडपॉइंट वास्तविक संपर्क लौटाता है, इसलिए "इसमें वास्तव में कौन है" यह प्रश्न आप भेजकर पता लगाने के बजाय देखकर उत्तर देते हैं।

सेगमेंट फिर दोहरा काम करते हैं: किसी अभियान के लिए दर्शक के रूप में, फ़नल शाखा पर शर्त के रूप में, और स्वयं ट्रिगर के रूप में — segment_enter उसी क्षण एक रन शुरू कर देता है जब कोई पात्र बन जाता है।

शांत नियमित ग्राहकसेगमेंट पूर्वावलोकन · 412
  • 1टैगtags contains "regular"
  • 2एट्रिब्यूटattrs.total_orders >= 3 — आपका फ़ील्ड, उसके लिए आपका नाम।
  • 3व्यवहारपिछले 90 दिनों में कोई order.paid इवेंट नहीं।
  • 4सहमतिएक उपयोग योग्य ई-मेल आधार। जिन संपर्कों के पास यह नहीं है वे गिनती में शामिल नहीं हैं, क्योंकि उन्हें वैसे भी नहीं भेजा जा सकता था।
  • iप्रीव्यू412 संपर्क, सूचीबद्ध। भेजते समय फिर से गिना जाएगा, क्योंकि सेगमेंट एक प्रश्न है, स्नैपशॉट नहीं।

SQL में संकलितगिनती कैश में, उत्तर लाइव

सप्रेशन, और इसकी जाँच कब होती है

सप्रेशन प्रोजेक्ट-स्कोप्ड और वैश्विक हैं: हार्ड बाउंस, शिकायतें, अनसब्सक्राइब, मैनुअल प्रविष्टियाँ और रोल पते। इनकी जाँच भेजने के समय होती है, और फिर भेजने वाली सेवा के भीतर भी दोबारा होती है।

दूसरा शब्द ही असली काम करता है। जिस फ़नल में तीन दिन का इंतज़ार है, उसमें तीन दिन की ऐसी अवधि है जिसमें कोई अनसब्सक्राइब कर सकता है, और जो सिस्टम संदेश कतार में जाते समय सप्रेशन की जाँच करता है, वह फिर भी उन्हें मेल भेज देगा। भेजते समय जाँच करना ही अनसब्सक्राइब का सम्मान करने और उसे केवल दर्ज करने के बीच का अंतर है।

मिटाना भी इसी तरह काम करता है: डिलीशन अनुरोध यहाँ संपर्क और उनका संदेश इतिहास हटा देता है, और उसी आंतरिक मार्ग से — जिसका उपयोग परिवार का बाकी हिस्सा करता है — प्रत्येक सहोदर सेवा तक पहुँचता है जिसके पास प्रतिलिपि थी। पूछने के लिए एक ही जगह है और होने वाली एक ही बात है।