સંપર્કો અને સંમતિ
એવી યાદી જે તમે રક્ષી શકો, માત્ર ધરાવો એ નહીં
કોઈપણ દસ હજાર ઈ-મેઈલ સરનામાં રાખી શકે છે. અસલ પ્રશ્ન — જે નિયમનકારી, સેવા પ્રદાતા અને તમારો પોતાનો વિવેક થોડા અલગ શબ્દોમાં પૂછે છે — એ છે કે દરેક ક્યાંથી આવ્યું અને કયા આધારે તમે તેને લખી શકો. ClickSomo તેને પુનર્નિર્માણ કરવું પડે એવી બાબતને બદલે સંગ્રહિત હકીકત બનાવે છે.
ઓળખ એ ઈ-મેઈલ સરનામું છે
દરેક સરનામાં માટે, દરેક પ્રોજેક્ટમાં એક જ સંપર્ક — આશા પર નહીં, ડેટાબેઝ દ્વારા લાગુ. સરનામાં લખતી વખતે પ્રમાણિત (normalised) થાય છે, વાંચતી વખતે ક્યારેય નહીં — વાંચતી વખતે પ્રમાણિત કરવાથી નિયંત્રણ માત્ર દેખાદ શણગાર બની જાય જે 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 માં બનાવેલું એક પેજ
ડેશબોર્ડ ડિઝાઇનર પેજ પ્રકાશિત કરે છે; તેમાંનું એક ફોર્મ તમારા પોતાના ક્રેડેન્શિયલ સાથે અહીં પોસ્ટ કરે છે. એ જ વેલિડેશન, એ જ consent હેન્ડલિંગ, જાળવવાનો બીજો કોઈ ઇન્ટિગ્રેશન નહીં.
જાહેર API
તમારા પોતાના ટોકન સાથે POST /v1/contacts, upsert સેમેન્ટિક્સ, idempotency key માન્ય રાખવામાં આવે છે. તમારી એપને પહેલેથી ખબર છે કે કોણે સાઇન અપ કર્યું; એ હકીકતથી ફનલ સુધીનો આ સૌથી ટૂંકો માર્ગ છે.
સેગમેન્ટ એ એક પ્રેડિકેટ છે, કમ્પાઇલ થયેલું
સેગમેન્ટ એ કોન્ટેક્ટ ફીલ્ડ્સ, એટ્રિબ્યુટ્સ, ટૅગ્સ, લિસ્ટ મેમ્બરશિપ અને વર્તન પર સંગ્રહિત પ્રેડિકેટ ટ્રી છે, જે 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વર્તનછેલ્લા 90 દિવસમાં કોઈ
order.paidઇવેન્ટ નથી. - 4સંમતિવાપરી શકાય તેવો ઈ-મેલ આધાર. જેમની પાસે એ નથી તેઓ ગણતરીમાં નથી, કારણ કે તેમને કોઈપણ રીતે મોકલી શકાય નહીં.
- iપૂર્વાવલોકન412 કોન્ટેક્ટ્સ, સૂચિબદ્ધ. મોકલતી વખતે ફરી ગણાશે, કારણ કે સેગમેન્ટ એ પ્રશ્ન છે, સ્નેપશોટ નહીં.
SQL માં કમ્પાઇલ થયેલુંગણતરી કૅશ થયેલી, જવાબ લાઇવ
સપ્રેશન, અને તે ક્યારે તપાસાય છે
સપ્રેશન્સ પ્રોજેક્ટ-સ્કોપ્ડ અને ગ્લોબલ છે: હાર્ડ બાઉન્સ, ફરિયાદો, અનસબ્સ્ક્રિપ્શન્સ, મેન્યુઅલ એન્ટ્રીઓ અને રોલ એડ્રેસ. તેઓ મોકલતી વખતે તપાસાય છે, અને પછી મોકલનારી સેવાની અંદર પણ ફરી તપાસાય છે.
એ બીજો શબ્દ જ કામ કરે છે. ત્રણ દિવસની રાહ ધરાવતી ફનલમાં ત્રણ દિવસની વિન્ડો હોય છે જેમાં કોઈ અનસબ્સ્ક્રાઇબ કરી શકે, અને જે સિસ્ટમે સંદેશ કતારમાં જતી વખતે સપ્રેશન તપાસ્યું હશે તે છતાં તેમને મેઇલ કરશે. મોકલતી વખતે તપાસવું એ અનસબ્સ્ક્રિપ્શનનું સન્માન કરવાનું અને ફક્ત નોંધવાનું તફાવત છે.
ભૂંસવું પણ એ જ રીતે કામ કરે છે: ડિલીશન વિનંતી અહીં કોન્ટેક્ટ અને તેમનો સંદેશ ઇતિહાસ દૂર કરે છે, અને પરિવારની બાકીની સેવાઓ જે આંતરિક માર્ગનો ઉપયોગ કરે છે તે જ મારગતે નકલ ધરાવતી દરેક સહોદર સેવા સુધી પહોંચે છે. પૂછવા માટે એક જ જગ્યા છે અને થતું એક જ કામ છે.