clickSomo
ClickSomo खोल्नुहोस्

सम्पर्कहरू र सहमति

तपाईंले बचाउन सक्ने सूची, केवल भएको सूची मात्र होइन

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

पहिचान भनेको इमेल ठेगाना नै हो

प्रत्येक ठेगाना र प्रोजेक्ट अनुसार एक सम्पर्क मात्र, आशामा भर नपरी डेटाबेसले नै लागू गरिएको। ठेगानाहरू लेख्दा सामान्यीकरण गरिन्छ, पढ्दा कहिल्यै होइन — पढ्दा सामान्यीकरण गरे बाध्यता केवल सजावट मात्र बन्छ जसले Anna@ र anna@ दुवैलाई भित्र छिर्न दिन्छ।

फोन नम्बरहरू भएसम्म E.164 मा भण्डारण गरिन्छ, तर फोन नम्बर एक विशेषता हो, पहिचान होइन। यहाँ कुनै पहिचान-समाधान ग्राफ छैन, कुनै मर्ज प्रोटोकल छैन र कुनै मर्ज अडिट ट्रेल छैन, किनकि यहाँको हरेक सम्पर्क त्यस्तो माध्यमबाट आउँछ जसमा पहिले नै ठेगाना हुन्छ: इम्पोर्ट, फारम, सदस्यता, वा तपाईंको आफ्नै कोड।

नाम पूरै रूपमा भण्डारण गरिन्छ

display_name दिइएको ठीक त्यस्तै राखिन्छ र कहिल्यै टुक्राहरूमा विभाजित गरिँदैन। नाम विभाजन बग उत्पादक हो — "van der Berg", "Kim Min-jun", एकल नाम, उपाधिहरू, र एङ्ग्लो नभएका हरेक क्रम परिपाटी — र गलत विभाजन मर्ज ट्यागमा "Dear van," का रूपमा देखिन्छ, जुन कुनै पनि व्यक्तिगतीकरण नहुनुभन्दा नराम्रो हो।

संरचित भागहरू त्यस्ता स्रोतहरूका लागि मात्र हुन्छन् जसले तिनलाई पहिले नै छुट्टाछुट्टै उपलब्ध गराउँछन्। कुनै पनि तिनलाई निकालेर बनाइँदैन। र कसैले आफैँ टाइप गरेको नाम कहिल्यै पछिको CSV ले नमिल्ने गरी अधिलेखित हुँदैन, किनकि last-write-wins ले सबैभन्दा लापरवाह इम्पोर्टलाई जिताइदिन्छ।

एक सम्पर्कके राखिएको छ
  • 1पहिचानइमेल, सामान्यीकृत। प्रोजेक्टभित्र अद्वितीय।
  • 2नामपूरै रूपमा भण्डारण गरिन्छ। first_name रेन्डर हुने बेला निकालिन्छ, कहिल्यै भण्डारण गरिँदैन।
  • 3विशेषताहरूतपाईंले चाहेको जुनसुकै कुरा, JSON का रूपमा। तपाईंकै हो, र attrs.* का रूपमा इन्टरपोलेट गर्न मिल्छ।
  • 4ट्याग र सूचीहरूट्यागहरू प्रथम श्रेणीका हुन् र एउटै भण्डारमा बस्छन्; सूचीहरू स्पष्ट सदस्यता हुन्।
  • 5सहमतिप्रत्येक माध्यमका लागि एक पङ्क्ति, कानूनी आधार र त्यसको प्रमाणसहित।
  • 6घटनाहरूयो व्यक्तिले गरेको सबै कुराको append-only लग। यो उत्पादन टाँसिएको तालिका।
  • ×कहिल्यै होइनकुनै पासवर्ड छैन, कुनै ह्यास छैन, कुनै सेसन छैन, कुनै API कुञ्जी छैन। कसैलाई प्रमाणीकरण गर्ने कुनै स्तम्भ घटना हुनेथियो, सुविधा होइन।

टेनेन्ट र प्रोजेक्ट दुवैमा सीमित

सहमति खाता

अनुपस्थिति अनुमति होइन

प्रत्येक सम्पर्क र प्रत्येक माध्यमका लागि एक पङ्क्ति — इमेल, SMS, चिठ्ठी, पुश — प्रत्येकमा एक अवस्था, एक कानूनी आधार, एक स्रोत, प्रमाण, समयचिह्नहरू र क्षेत्राधिकार हुन्छ। जुन सम्पर्कको कुनै माध्यमका लागि आधार पङ्क्ति छैन, त्यसलाई त्यो माध्यममा केही पनि पठाउन मिल्दैन। "फ्ल्याग गरिएको छैन" भन्ने होइन। पठाउनै मिल्दैन।

consent

कसैले सक्रिय रूपमा सोधेको। प्रमाण भण्डारण गरिएको फारम पेश, डबल अप्ट-इन, वा उनीहरूले आफैँ टिक लगाएको चेकबक्स। यो सबैभन्दा बलियो आधार हो र फारमले उत्पन्न गर्न सक्ने एक मात्र आधार पनि यही हो।

legitimate_interest

CSV इम्पोर्टले पुग्न सक्ने सबैभन्दा राम्रो स्तर। स्प्रेडसिटले कसैले केहीमा सहमति जनाएको सम्झन सक्दैन, त्यसैले त्यसले त्यस्तो दाबी गर्न कहिल्यै अनुमति दिइँदैन — र उही फाइल फेरि अपलोड गर्दा यो स्तर माथि उठ्दैन।

contract

तपाईं उनीहरूलाई त्यसैले लेख्दै हुनुहुन्छ किनकि तपाईं र उनीहरू दुवै कुनै कुराका पक्ष हुनुहुन्छ। सेवा सम्झना, नवीकरण सूचना, नपाए उनीहरू रिसाउने कुरा।

अभियान पठाउनु अघि, तपाईंले यसको दर्शकको आधार मिश्रण देख्नुहुन्छ: यी मानिसहरूमध्ये कतिले आफैँ सोधे, कति वैध हित अन्तर्गत पुगिँदैछ, र कति ठेक्काका कारण छन्। यो एउटा यस्तो अङ्क हो जसले अहिलेसम्म लेखिएका कुनै पनि चेतावनी ब्यानरभन्दा बढी नराम्रो पठाइहरू रोकेको छ।

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

सूचीको हरेक पङ्क्ति पछाडि, कसैले हो भनेको छ।

प्रवेशका चार बाटा

तपाईंको सूचीमा जाने हरेक बाटा तपाईं आफैँ, आफ्नै डेटामा काम गर्दै

कुनै सेवा-टोकन इनजेस्ट लेन छैन र तपाईंका सम्पर्कहरूमा मौन रूपमा लेख्ने कुनै दाजुभाइ उत्पादन छैन। तपाईंले कसैलाई सूचीमा राख्न चाहनुहुन्छ भने, यी चार मध्ये एकले नै त्यहाँ राखेको हुन्छ।

CSV इम्पोर्ट

स्तम्घै स्तम्भ म्याप गरिएको, लेख्दा सामान्यीकृत, MX-जाँच गरिएको ताकि मरेका र गलत टाइप भएका डोमेनहरू हार्ड-बाउन्स हुनुअघि नै समातिएका, र तपाईंले स्पष्ट रूपमा सेट गरेको आधारसहित भित्रिएको। इम्पोर्टलाई एक id दिइन्छ, र यसले बनाएको हरेक सम्पर्क त्यसतर्फ औंल्याउँछ।

ClickSomo फारम

अरू सबै कुराझैँ उही दस्तावेजबाट रेन्डर गरिएको, भ्यालिडेसन, हनीपट र दर सीमासहित। फारम पेश गर्नु वैध रूपमा consent उत्पन्न गर्न सक्ने एक मात्र बाटो हो, किनकि व्यक्ति उपस्थित हुने एक मात्र यही हो।

तपाईंले dash-b मा बनाएको पृष्ठ

ड्यासबोर्ड डिजाइनरले पृष्ठहरू प्रकाशित गर्छ; तीमध्ये एकमा रहेको फारमले तपाईंकै प्रमाणपत्रहरू प्रयोग गरेर यहाँ पोस्ट गर्छ। उही भ्यालिडेसन, उही सहमति व्यवस्थापन, मर्मत गर्नुपर्ने दोस्रो इन्टिग्रेसन छैन।

सार्वजनिक API

तपाईंकै टोकनसहित POST /v1/contacts, upsert सेमान्टिक्स, idempotency कुञ्जी सम्मानित। तपाईंको एपले को साइन अप गर्‍यो भन्ने पहिले नै जान्छ; त्यो तथ्यबाट फनेलसम्म पुग्ने यो सबैभन्दा छोटो बाटो हो।

सेगमेन्टहरू एक predicate हुन्, कम्पाइल गरिएका

सेगमेन्ट भनेको सम्पर्क फिल्ड, विशेषता, ट्याग, सूची सदस्यता र व्यवहारमाथिको भण्डारण गरिएको predicate वृक्ष हो, जुन SQL मा कम्पाइल भई गणनासहित क्यास गरिन्छ। अपरेटरहरू सामान्य नै हुन् — equals, not equals, in, not in, starts with, ends with, contains, is set, is not set — जुन and, or र not सँग तपाईंलाई चाहिने जति गहिराइसम्म जोडिन्छन्।

प्रयोग गर्नुअघि पूर्वावलोकन गर्नुहोस्। एन्डपोइन्टले वास्तविक सम्पर्कहरू फर्काउँछ, त्यसैले "यसमा वास्तवमा को छ" भन्ने प्रश्नको उत्तर पठाएर होइन, हेरेर दिनुहुन्छ।

सेगमेन्टहरू त्यसपछि दोहोरो काम गर्छन्: अभियानको दर्शकका रूपमा, फनेल शाखाको सर्तका रूपमा, र आफैंमा ट्रिगरका रूपमा — segment_enter ले कसैले योग्यता प्राप्त गरेको क्षणमै रन सुरु गर्छ।

शान्त नियमितहरूसेगमेन्ट पूर्वावलोकन · ४१२
  • 1ट्यागtags contains "regular"
  • 2विशेषताattrs.total_orders >= 3 — तपाईंकै फिल्ड, तपाईंकै नाम।
  • 3व्यवहारगत ९० दिनमा कुनै order.paid घटना छैन।
  • 4सहमतिप्रयोगयोग्य इमेल आधार। यस्तो आधार नभएका सम्पर्कहरू गणनामा पर्दैनन्, किनकि उनीहरूलाई भए पनि पठाउन सकिँदैनथ्यो।
  • iपूर्वावलोकन४१२ सम्पर्कहरू, सूचीबद्ध। पठाउने बेला फेरि गणना गरिन्छ, किनकि सेगमेन्ट एउटा प्रश्न हो, स्न्यापसट होइन।

SQL मा कम्पाइल गरिएकोगणना क्यास गरिएको, उत्तर लाइभ

सप्रेसन, र यो कहिले जाँचिन्छ

सप्रेसनहरू प्रोजेक्ट-दायराका र वैश्विक हुन्छन्: हार्ड बाउन्स, उजुरी, सदस्यता रद्द, म्यानुअल प्रविष्टि र रोल ठेगानाहरू। यी पठाउने समयमा जाँचिन्छन्, र त्यसपछि पठाउने सेवाभित्रै पुनः जाँचिन्छन्।

त्यो दोस्रो जाँचले नै वास्तविक काम गर्छ। तीन दिनको प्रतीक्षा भएको फनेलमा कसैले सदस्यता रद्द गर्न सक्ने तीन दिनको अवधि हुन्छ, र सन्देश क्यू भएकै बेला सप्रेसन जाँच्ने प्रणालीले भने उनीहरूलाई भए पनि पठाइदिन्छ। पठाउने बेला जाँच गर्नु भनेको सदस्यता रद्दको सम्मान गर्नु र केवल रेकर्ड गर्नुबीचको भिन्नता हो।

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