Contatti e consenso
Una lista che puoi difendere, non solo una lista che hai
Chiunque può possedere diecimila indirizzi e-mail. La domanda che conta — quella che un regolatore, un provider e la tua stessa coscienza pongono con parole leggermente diverse — è da dove provenga ciascuno di essi e su quale base tu possa scrivergli. ClickSomo ne fa un fatto memorizzato invece di qualcosa che dovresti ricostruire.
L'identità è l'indirizzo e-mail
Un contatto per indirizzo per progetto, garantito dal database e non dalla speranza. Gli indirizzi vengono normalizzati in scrittura, mai in lettura — normalizzare in lettura rende il vincolo un ornamento che lascia entrare sia Anna@ sia anna@.
I numeri di telefono sono memorizzati in E.164 dove esistono, ma un numero di telefono è un attributo, non un'identità. Non c'è grafo di risoluzione delle identità, né protocollo di merge, né audit trail dei merge, perché ogni contatto qui arriva attraverso un canale che ha già un indirizzo: un'importazione, un modulo, un'iscrizione o il tuo codice.
Il nome è memorizzato per intero
display_name è conservato esattamente come è stato fornito e non viene mai diviso in parti. Spezzare i nomi è una fabbrica di bug — "van der Berg", "Kim Min-jun", mononimi, titoli, e ogni convenzione di ordine che non sia anglosassone — e uno split sbagliato emerge in un merge tag come "Caro van,", che è peggio di nessuna personalizzazione.
Le parti strutturate esistono solo per le fonti che le forniscono già separate. Nulla le deriva. E un nome digitato da una persona non viene mai sovrascritto da un CSV successivo che ha osservato qualcosa di diverso, perché last-write-wins fa vincere l'importazione più sciatta.
- 1IdentitàE-mail, normalizzata. Unica all'interno del progetto.
- 2NomeConservato per intero.
first_nameè derivato al momento del rendering, mai memorizzato. - 3AttributiQuello che vuoi, come JSON. Tuoi, e interpolabili come
attrs.*. - 4Tag e listeI tag sono entità di prima classe e vivono in un unico store; le liste sono appartenenze esplicite.
- 5ConsensoUna riga per canale, con una base giuridica e la sua evidenza.
- 6EventiUn log di sola aggiunta di tutto ciò che questa persona ha fatto. La tabella su cui poggia il prodotto.
- ×MaiNessuna password, nessun hash, nessuna sessione, nessuna chiave API. Una colonna che autentica qualcuno sarebbe un incidente, non una funzionalità.
Ambito limitato a tenant e progetto, entrambi
Il registro dei consensi
L'assenza non è un permesso
Una riga per contatto per canale — e-mail, SMS, lettera, push — ciascuna con uno stato, una base giuridica, una fonte, l'evidenza, i timestamp e la giurisdizione. A un contatto senza riga di base per un canale non si può inviare nulla su quel canale. Non "è segnalato". Non si può.
consent
Qualcuno ha richiesto attivamente. Un invio di modulo con l'evidenza conservata, un double opt-in, una casella che ha spuntato da solo. È la base più solida ed è l'unica che un modulo può produrre.
legitimate_interest
Il massimo che un import CSV può raggiungere. Un foglio di calcolo non può ricordare qualcuno che ha accettato qualcosa, quindi non gli è mai permesso dichiarare che lo abbia fatto — e ricaricare lo stesso file non lo migliora.
contract
Ti scrivi con loro per qualcosa a cui partecipate entrambi. Il promemoria del servizio, l'avviso di rinnovo, la cosa che sarebbero infastiditi non ricevere.
Prima che una campagna parta, vedi il mix di basi del suo pubblico: quanti di queste persone hanno richiesto, quante raggiungi sotto legittimo interesse e quante ci sono per un contratto. È un solo numero che ha fermato più invii sbagliati di qualsiasi banner di avviso mai scritto.
Perché è più severo del necessario per te: in realtà non è una questione che ti riguarda. La reputazione dell'invio in blocco è una risorsa condivisa, e una lista trascurata avvelena il pozzo per chiunque invii dalla stessa infrastruttura. I tassi di reclamo e di bounce per tenant sono monitorati, e un account che supera la soglia viene limitato qui — prima che lo faccia un provider a tutti insieme.
Dietro ogni riga della lista, qualcuno ha detto sì.
Quattro modi d'ingresso
Ogni via d'accesso alla tua lista sei tu, che agisci sui tuoi dati
Non esiste una lane di ingest con token di servizio e nessun prodotto gemello che scriva silenziosamente nei tuoi contatti. Se vuoi qualcuno su una lista, uno di questi quattro lo ha messo lì.
Import CSV
Mappato colonna per colonna, normalizzato in scrittura, con verifica MX così i domini morti o sbagliati vengono intercettati prima di generare hard bounce, e registrato con una base che imposti esplicitamente. L'import riceve un id, e ogni contatto che ha creato punta a esso.
Un modulo ClickSomo
Renderizzato dallo stesso documento di tutto il resto, con validazione, honeypot e limite di frequenza. Un invio è l'unica via che può legittimamente produrre consent, perché è l'unica in cui la persona è presente.
Una pagina che hai costruito in dash-b
Il designer della dashboard pubblica le pagine; un modulo su una di esse invia qui con le tue credenziali. Stessa validazione, stessa gestione del consenso, nessuna seconda integrazione da mantenere.
L'API pubblica
POST /v1/contacts con il tuo token, semantica upsert, chiave di idempotenza rispettata. La tua app sa già chi si è iscritto; questo è il percorso più breve da quel fatto a un funnel.
I segmenti sono un predicato, compilato
Un segmento è un albero di predicati memorizzato su campi dei contatti, attributi, tag, appartenenza a liste e comportamento, compilato in SQL e messo in cache con un conteggio. Gli operatori sono quelli ordinari — equals, not equals, in, not in, starts with, ends with, contains, is set, is not set — combinati con and, or e not alla profondità che ti serve.
Anteprima prima di usarlo. L'endpoint restituisce contatti reali, quindi "chi c'è davvero dentro" è una domanda a cui rispondi guardando, non inviando e scoprendolo dopo.
I segmenti fanno poi doppio servizio: come pubblico di una campagna, come condizione su un ramo di funnel e come trigger a pieno titolo — segment_enter avvia un run nel momento in cui qualcuno diventa idoneo.
- 1Tag
tags contains "regular" - 2Attributo
attrs.total_orders >= 3— il tuo campo, il tuo nome per esso. - 3ComportamentoNessun evento
order.paidnegli ultimi 90 giorni. - 4ConsensoUna base e-mail utilizzabile. I contatti senza non sono nel conteggio, perché comunque non si potrebbe inviare loro nulla.
- iAnteprima412 contatti, elencati. Ricontati al momento dell'invio, perché un segmento è una domanda e non un'istantanea.
Compilato in SQLConteggio in cache, risposta live
Soppressione, e quando viene verificata
Le soppressioni sono per progetto e globali: hard bounce, reclami, cancellazioni, voci manuali e indirizzi di ruolo. Vengono verificate al momento dell'invio, e poi di nuovo all'interno del servizio di invio stesso.
Quella seconda parola fa il lavoro. Un funnel con un'attesa di tre giorni ha una finestra di tre giorni in cui qualcuno può cancellarsi, e un sistema che ha verificato la soppressione quando il messaggio è stato messo in coda gli invierà comunque la mail. Verificare all'invio è la differenza tra onorare una cancellazione e registrarne una.
La cancellazione funziona allo stesso modo: una richiesta di cancellazione rimuove qui il contatto e la sua cronologia dei messaggi, e raggiunge ogni servizio gemello che ne deteneva una copia attraverso la stessa lane interna che il resto della famiglia usa. C'è un solo posto dove chiedere e una sola cosa che accade.