Contactos e consentimento
Unha lista que podes defender, non só unha lista que tes
Calquera pode ter dez mil enderezos de correo electrónico. A pregunta que importa — a que un regulador, un provedor e a túa propia conciencia fan con palabras lixeiramente distintas — é de onde veu cada un deles e con que base podes escribirle. ClickSomo converte iso nun feito almacenado en vez de algo que terías que reconstruír.
A identidade é o enderezo de correo electrónico
Un contacto por enderezo por proxecto, impoñido pola base de datos e non pola esperanza. Os enderezos normalízanse cando se escriben, nunca cando se len — normalizar ao ler converte a restrición nun adorno que deixa entrar tanto Anna@ como anna@.
Os números de teléfono gárdanse en E.164 cando existen, pero un número de teléfono é un atributo, non unha identidade. Non hai grafo de resolución de identidades, nin protocolo de fusión, nin rexistro de auditoría de fusións, porque cada contacto chega aquí por unha canle que xa ten un enderezo: unha importación, un formulario, unha subscrición ou o teu propio código.
O nome gárdase enteiro
display_name consérvase exactamente como se deu e nunca se divide en partes. Dividir nomes é unha fábrica de erros — "van der Berg", "Kim Min-jun", nomes únicos, títulos e todas as convencións de orde que non son anglosaxas — e unha división errónea aparece nunha etiqueta de fusión como "Estimado van,", o que é peor que ningunha personalización.
As partes estruturadas existen só para as fontes que as fornecen xa separadas. Nada as deriva. E un nome que alguén escribiu el mesmo nunca se sobrescribe por un CSV posterior que casualmente observou algo distinto, porque deixar gañar á última escrita fai que gañe a importación máis descoidada.
- 1IdentidadeCorreo electrónico, normalizado. Único dentro do proxecto.
- 2NomeGárdase enteiro.
first_namederívase no momento de renderizar, nunca se garda. - 3AtributosO que queiras, en JSON. Teus, e interpolables como
attrs.*. - 4Etiquetas e listasAs etiquetas son de primeira clase e viven nun único almacén; as listas son pertenza explícita.
- 5ConsentimentoUnha fila por canle, cunha base legal e a súa evidencia.
- 6EventosUn rexistro de só adición de todo o que fixo esta persoa. A táboa da que pendura o produto.
- ×NuncaSen contrasinal, sen hash, sen sesión, sen clave de API. Unha columna que autenticase a alguén sería un incidente, non unha funcionalidade.
Delimitado por arrendatario e proxecto, ambos
O rexistro de consentementos
A ausencia non é permiso
Unha fila por contacto por canle — correo electrónico, SMS, carta, push — cada unha cun estado, unha base legal, unha orixe, a evidencia, as marcas de tempo e a xurisdición. A un contacto sen fila de base para unha canle non se lle pode enviar nada por esa canle. Non "está marcado". Non se pode.
consent
Alguén pediuno activamente. Un envío de formulario coa evidencia gardada, unha dobre confirmación, unha caixa que marcou el mesmo. Esta é a base máis forte e a única que un formulario pode producir.
legitimate_interest
O mellor ao que pode chegar unha importación de CSV. Unha folla de cálculo non pode lembrar que alguén aceptou algo, así que nunca se lle permite afirmar que o fixo — e volver subir o mesmo ficheiro non o mellora.
contract
Escribícheslle por algo no que ambos participades. O aviso do servizo, a notificación de renovación, aquilo que molestaría non recibir.
Antes de que se envíe unha campaña, ves a composición de bases da súa audiencia: cantas destas persoas o pediron, cantas alcanzas por interese lexítimo e cantas están alí por un contrato. É un número que detivo máis envíos malos que calquera banela de aviso xamais escrita.
Por que isto é máis estrito do que precisas para ti: en realidade non se trata de ti. A reputación do envío masivo é un recurso compartido, e unha lista descoidada envenena o pozo para todos os que envían desde a mesma infraestrutura. Vixíanse as taxas de queixas e rebotes por arrendatario, e unha conta cuxas taxas superan o limiar ralentízase aquí — antes de que o faga un provedor para todos á vez.
Detrás de cada fila da lista, alguén dixo que si.
Catro formas de entrar
Cada ruta cara á túa lista es ti, actuando sobre os teus propios datos
Non hai canle de inxesta con token de servizo nin produto irmán que escriba discretamente nos teus contactos. Se queres que alguén estea nunha lista, unha destas catro vías púxoo alí.
Importación de CSV
Mapeada columna por columna, normalizada ao escribir, con comprobación de MX para que os dominios mortos e mal escritos se detecten antes de que rebote en firme, e con unha base que defines explicitamente. A importación recibe un id, e cada contacto que creou apunta a el.
Un formulario de ClickSomo
Renderizado desde o mesmo documento que todo o demais, con validación, un honeypot e un límite de taxa. Un envío é a única ruta que pode producir lexítimamente consent, porque é a única na que a persoa está presente.
Unha páxina que construíches en dash-b
O deseñador do panel publica páxinas; un formulario nunha delas envía aquí coas túas propias credenciais. A mesma validación, a mesma xestión do consentimento, sen unha segunda integración que manter.
A API pública
POST /v1/contacts co teu propio token, semántica de upsert, clave de idempotencia respectada. A túa aplicación xa sabe quen se rexistrou; este é o camiño máis curto desde ese feito ata un funil.
Os segmentos son un predicado, compilado
Un segmento é unha árbore de predicados almacenada sobre campos de contacto, atributos, etiquetas, pertenza a listas e comportamento, compilada a SQL e almacenada na caché cunha conta. Os operadores son os correntes — igual, distinto, en, non en, comeza por, remata en, contén, está definido, non está definido — combinados con and, or e not ata a profundidade que precises.
Previsualízao antes de usalo. O endpoint devolve contactos reais, así que «quen está realmente aquí» é unha pregunta que respondes mirando en vez de enviar e descubrilo.
Os segmentos fan despois dobre función: como audiencia dunha campaña, como condición nunha rama do funil e como disparador por si mesmos — segment_enter inicia unha execución no momento en que alguén se vira elixible.
- 1Etiqueta
tags contains "regular" - 2Atributo
attrs.total_orders >= 3— o teu campo, o teu nome para el. - 3ComportamentoSen evento
order.paidnos últimos 90 días. - 4ConsentimentoUnha base de correo electrónico utilizable. Os contactos sen ela non están na conta, porque de todos xeitos non se lles podería enviar.
- iVista previa412 contactos, listados. Recóntase no envío, porque un segmento é unha pregunta e non unha instantánea.
Compilado a SQLConta na caché, resposta en vivo
Supresión, e cando se comproba
As supresións son por proxecto e globais: rebotes duros, queixas, baixas, entradas manuais e enderezos de rol. Compróbanse no momento do envío, e despois de novo dentro do propio servizo de envío.
Esa segunda comprobación é a que fai o traballo. Un funil cunha espera de tres días ten unha ventá de tres días na que alguén pode darse de baixa, e un sistema que comprobou a supresión cando se encolou a mensaxe enviarallaa de todos xeitos. Comprobar no envío é a diferenza entre respectar unha baixa e rexistrala.
A supresión funciona do mesmo xeito: unha solicitude de eliminación retira o contacto e o seu historial de mensaxes aquí, e chega a todos os servizos irmáns que tiñan unha copia pola mesma canle interna que usa o resto da familia. Hai un só lugar onde pedir e unha soa cousa que acontece.