Kapcsolatok és hozzájárulás
Egy lista, amelyet meg tud védeni, nem csak egy lista, amellyel rendelkezik
Bárki tarthat tízezer e-mail címet. A fontos kérdés — amelyet a szabályozó, a szolgáltató és a saját lelkiismerete kissé eltérő szavakkal tesz fel — az, hogy honnan származik mindegyik, és milyen alapon írhat Ön nekik. A ClickSomo ezt tárolt tényként kezeli, nem pedig olyasvalamiként, amit Önnek újjá kellene építenie.
Az identitás az e-mail-cím
Projektenként és címenként egy kapcsolat, ezt az adatbázis érvényesíti, nem a remény. A címek íráskor normalizálódnak, olvasáskor soha — ha olvasáskor normalizálna, a megszorítás csak dísz lenne, amely beengedi az Anna@ és az anna@ címet is.
A telefonszámok ott, ahol léteznek, E.164 formátumban tárolódnak, de a telefonszám attribútum, nem identitás. Nincs identitásfeloldási gráf, nincs egyesítési protokoll és nincs napló az egyesítésekről, mert minden kapcsolat olyan csatornán érkezik, amelynek már van címe: import, űrlap, feliratkozás vagy az Ön saját kódja.
A név egyben tárolódik
A display_name pontosan úgy marad, ahogy megadták, és soha nem bontják részekre. A névbontás hibagyár — „van der Berg”, „Kim Min-jun”, egytagú nevek, címek és minden nem angolszász névsorrend —, és egy rossz bontás egy egyesítési címkében úgy jelenik meg, mint „Kedves van,”, ami rosszabb, mint a személyre szabás teljes hiánya.
Strukturált részek csak olyan forrásokhoz léteznek, amelyek eleve szétbontva szolgáltatják őket. Semmi nem származtatja őket. És amit valaki maga gépelt be, azt egy későbbi CSV soha nem írja felül, amely véletlenül mást állapított meg, mert az utolsó írás felülírása elve a leggondatlanabb importnak adna győzelmet.
- 1IdentitásE-mail, normalizálva. A projekten belül egyedi.
- 2NévEgészben tárolva. A
first_namemegjelenítéskor származtatódik, soha nem tárolódik. - 3AttribútumokBármi, amit Ön szeret, JSON-ként. Az Öné, és
attrs.*formában interpolálható. - 4Címkék és listákA címkék elsőrendűek, és egyetlen tárolóban élnek; a listák explicit tagságot jelentenek.
- 5HozzájárulásCsatornánként egy sor, jogalappal és annak bizonyítékával.
- 6EseményekCsak bővíthető napló mindarról, amit ez a személy tett. A tábla, amelyre a termék épül.
- ×SohaNincs jelszó, nincs hash, nincs munkamenet, nincs API-kulcs. Egy oszlop, amely valakit hitelesítene, incidens lenne, nem funkció.
Bérlőre és projektre is szűkítve
A hozzájárulási nyilvántartás
A hiány nem engedély
Csatornánként egy sor kapcsolatonként — e-mail, SMS, levél, push —, mindegyik állapottal, jogalappal, forrással, bizonyítékkal, időbélyegekkel és joghatósággal. Akihez egy csatornához nincs jogalap-sor, arra a csatornára semmit nem lehet küldeni. Nem „meg van jelölve”. Nem lehet.
consent
A személy kifejezetten kérte. Űrlapbeküldés tárolt bizonyítékkal, dupla opt-in, saját maga által bepipált jelölőnégyzet. Ez a legerősebb jogalap, és az egyetlen, amelyet űrlap produkálhat.
legitimate_interest
A legjobb, amiként egy CSV-import besorolható. Egy táblázat nem emlékezhet arra, hogy valaki valamihez hozzájárult, ezért soha nem állíthatja, hogy igen — és ugyanazon fájl ismételt feltöltése nem emeli a szintjét.
contract
Azért ír Ön nekik, mert mindketten részesek valamilyen jogviszonyban. A szolgáltatási emlékeztető, a megújítási értesítés, az a dolog, amelynek hiányát bosszantónak találnák.
Mielőtt egy kampány elindul, Ön látja a célközönség jogalap-összetételét: hányan kértek ezek közül, hányan érhetők el jogos érdek alapján, és hányan vannak ott szerződés miatt. Ez egyetlen szám, amely több rossz kiküldést akadályozott meg, mint bármilyen figyelmeztető sáv valaha.
Miért szigorúbb ez Önnél, mint amennyire szükséges lenne: valójában nem Önről szól. A tömeges küldés jó hírneve közös erőforrás, és egy gondatlan lista mindenki számára megmérgezi a kutat, aki ugyanarról az infrastruktúráról küld. A bérlőnkénti panasz- és visszapattanási arányokat figyeljük, és a küszöböt átlépő fiókot itt visszafogjuk — még mielőtt egy szolgáltató ezt mindenkivel egyszerre tenné.
A lista minden sora mögött valaki igent mondott.
Négy belépési mód
Minden út a listájára Ön maga, saját adatain cselekedve
Nincs szolgáltatási tokenes betöltési csatorna, és nincs testvértermék, amely csendben írna a kapcsolatai közé. Ha valakit fel szeretne venni egy listára, e négy út egyike tette oda.
CSV-import
Oszloponként leképezve, íráskor normalizálva, MX-ellenőrzéssel, hogy a halott és elgépelt domainek még a kemény visszapattanás előtt kiszűrődjenek, és az Ön által kifejezetten beállított jogalappal rögzítve. Az import azonosítót kap, és minden általa létrehozott kapcsolat visszautal rá.
Egy ClickSomo űrlap
Ugyanabból a dokumentumból jelenik meg, mint minden más, validációval, honeypot-tal és sebességkorláttal. A beküldés az egyetlen út, amely legitim módon produkálhat consent értéket, mert ez az egyetlen, ahol a személy jelen van.
Egy dash-b-ben épített oldal
Az irányítópult-tervező oldalakat publikál; az egyikükön lévő űrlap a saját hitelesítő adataival küld ide. Ugyanaz a validáció, ugyanaz a hozzájárulás-kezelés, nincs második integráció, amelyet karbantartani kellene.
A nyilvános API
POST /v1/contacts a saját tokenjével, upsert szemantikával, az idempotencia-kulcs tiszteletben tartásával. Az Ön alkalmazása már tudja, ki regisztrált; ez a legrövidebb út ettől a ténytől a tölcsérig.
A szegmens egy predikátum, lefordítva
A szegmens egy tárolt predikátumfa a kapcsolat mezői, attribútumai, címkéi, listatagsága és viselkedése felett, amely SQL-re fordítódik, és számláltanak gyorsítótárazódik. Az operátorok a szokásosak — egyenlő, nem egyenlő, benne van, nincs benne, ezzel kezdődik, ezzel végződik, tartalmazza, be van állítva, nincs beállítva —, amelyek és, vagy és nem kapcsolatokkal tetszőleges mélységben kombinálhatók.
Tekintse meg előre, mielőtt használná. A végpont valódi kapcsolatokat ad vissza, így arra a kérdésre, hogy „ki van ténylegesen benne”, nem küldéssel, hanem ránézéssel válaszol.
A szegmensek kettős szerepet töltenek be: közönségként egy kampányhoz, feltételként egy tölcsérághoz, és önmagukban kiváltó okként — a segment_enter elindít egy futást abban a pillanatban, amikor valaki jogosulttá válik.
- 1Címke
tags contains "regular" - 2Attribútum
attrs.total_orders >= 3— az Ön mezője, az Ön neve rá. - 3ViselkedésNincs
order.paidesemény az elmúlt 90 napban. - 4HozzájárulásEgy használható e-mail alap. A kapcsolatok, amelyekkel ez nem rendelkezik, nem szerepelnek a számlálásban, mert úgysem lehetne nekik küldeni.
- ésElőnézet412 kapcsolat, listázva. Küldéskor újraszámolva, mert a szegmens egy kérdés, nem egy pillanatkép.
SQL-re fordítvaGyorsítótárazott szám, élő válasz
Kizárás, és mikor történik az ellenőrzés
A kizárások projektszintűek és globálisak: kemény visszapattanások, panaszok, leiratkozások, kézi bejegyzések és szerepcímek. Ezek küldéskor ellenőrződnek, majd újra magában a küldő szolgáltatásban is.
Az a második ellenőrzés végzi el a munkát. Egy tölcsér, amelyben háromnapos várakozás szerepel, egy háromnapos ablakot nyit, amelyen belül valaki leiratkozhat, és egy rendszer, amely a kizárásokat az üzenet sorba állításakor ellenőrizte, ennek ellenére elküldené neki a levelet. A küldéskori ellenőrzés jelenti a különbséget a leiratkozás tiszteletben tartása és a leiratkozás csupán rögzítése között.
A törlés ugyanígy működik: egy törlési kérés eltávolítja a kapcsolatot és az üzenetelőzményeit itt, és eljut minden testvérszolgáltatáshoz, amely másolatot tartott, ugyanazon a belső csatornán, amelyet a család többi része is használ. Egy hely van, ahol kérni lehet, és egy dolog történik.