clickSomo
Abrir ClickSomo

Contactos y consentimiento

Una lista que puedas defender, no solo una lista que tengas

Cualquiera puede acumular diez mil direcciones de correo. La pregunta que importa —la que un regulador, un proveedor y tu propia conciencia formulan con palabras ligeramente distintas— es de dónde salió cada una y con qué base puedes escribirle. ClickSomo convierte eso en un dato almacenado, no en algo que tendrías que reconstruir.

La identidad es la dirección de correo

Un contacto por dirección por proyecto, impuesto por la base de datos y no por la esperanza. Las direcciones se normalizan al escribirse, nunca al leerse —normalizar al leer convierte la restricción en un adorno que deja entrar tanto Anna@ como anna@.

Los números de teléfono se almacenan en E.164 cuando existen, pero un teléfono es un atributo, no una identidad. No hay grafo de resolución de identidades, ni protocolo de fusión, ni registro de auditoría de fusiones, porque cada contacto llega por un canal que ya tiene una dirección: una importación, un formulario, una suscripción o tu propio código.

El nombre se almacena entero

display_name se conserva tal como se dio y nunca se divide en partes. Partir nombres es una fábrica de errores —«van der Berg», «Kim Min-jun», monónimos, títulos y todas las convenciones de orden que no son anglosajonas— y una división errónea aparece en una etiqueta de fusión como «Estimado van,», que es peor que no personalizar nada.

Las partes estructuradas existen solo para las fuentes que ya las entregan separadas. Nada las deriva. Y un nombre que alguien escribió por sí mismo nunca se sobrescribe con un CSV posterior que casualmente observó algo distinto, porque el criterio de «la última escritura gana» deja ganar a la importación más descuidada.

Un contactoQué se guarda
  • 1IdentidadCorreo, normalizado. Único dentro del proyecto.
  • 2NombreSe almacena entero. first_name se deriva al renderizar, nunca se almacena.
  • 3AtributosLo que quieras, en JSON. Tuyos, e interpolables como attrs.*.
  • 4Etiquetas y listasLas etiquetas son de primera clase y viven en un único almacén; las listas son pertenencias explícitas.
  • 5ConsentimientoUna fila por canal, con una base legal y su evidencia.
  • 6EventosUn registro de solo anexado de todo lo que hizo esta persona. La tabla de la que cuelga el producto.
  • ×NuncaSin contraseña, sin hash, sin sesión, sin clave de API. Una columna que autentique a alguien sería un incidente, no una funcionalidad.

Acotado al tenant y al proyecto, ambos

El registro de consentimientos

La ausencia no es permiso

Una fila por contacto por canal —correo, SMS, carta, push—, cada una con un estado, una base legal, una fuente, la evidencia, las marcas de tiempo y la jurisdicción. A un contacto sin fila de base para un canal no se le puede enviar nada por ese canal. No «está marcado». No se puede.

consent

Alguien lo pidió activamente. Un envío de formulario con la evidencia almacenada, una doble confirmación, una casilla que marcó por sí mismo. Es la base más fuerte y la única que un formulario puede producir.

legitimate_interest

Lo mejor que puede lograr una importación CSV. Una hoja de cálculo no puede recordar que alguien aceptó algo, así que nunca se le permite afirmar que lo hizo —y volver a subir el mismo archivo no lo mejora.

contract

Le escribes por algo en lo que ambos sois parte. El recordatorio del servicio, el aviso de renovación, aquello que le molestaría no recibir.

Antes de enviar una campaña, ves la mezcla de bases de su audiencia: cuántas de estas personas lo pidieron, a cuántas alcanzas bajo interés legítimo y cuántas están ahí por un contrato. Es un solo número que ha detenido más envíos malos que cualquier banner de advertencia jamás escrito.

Por qué esto es más estricto de lo necesario para ti: en realidad no va contigo. La reputación del envío masivo es un recurso compartido, y una lista descuidada envenena el pozo para todos los que envían desde la misma infraestructura. Las tasas de quejas y rebotes por tenant se vigilan, y a una cuenta cuyas tasas superan el umbral se le limita aquí —antes de que lo haga un proveedor para todos a la vez.

Detrás de cada fila de la lista, alguien dijo que sí.

Cuatro caminos de entrada

Cada ruta hacia tu lista eres tú, actuando sobre tus propios datos

No hay carril de ingesta con tokens de servicio ni ningún producto hermano escribiendo a escondidas en tus contactos. Si quieres a alguien en una lista, uno de estos cuatro lo puso ahí.

Importación CSV

Mapeada columna por columna, normalizada al escribir, con comprobación de MX para que los dominios muertos o mal escritos se detecten antes del rebote definitivo, y aterrizada con una base que tú fijas explícitamente. La importación recibe un id, y cada contacto que creó apunta a él.

Un formulario de ClickSomo

Renderizado desde el mismo documento que todo lo demás, con validación, honeypot y límite de tasa. Un envío es la única ruta que puede producir legítimamente consent, porque es la única en la que la persona está presente.

Una página que construiste en dash-b

El diseñador del dashboard publica páginas; un formulario en una de ellas envía aquí con tus propias credenciales. La misma validación, el mismo manejo de consentimiento, sin una segunda integración que mantener.

La API pública

POST /v1/contacts con tu propio token, semántica de upsert, clave de idempotencia respetada. Tu aplicación ya sabe quién se registró; este es el camino más corto de ese hecho a un funnel.

Los segmentos son un predicado, compilado

Un segmento es un árbol de predicados almacenado sobre campos de contacto, atributos, etiquetas, pertenencia a listas y comportamiento, compilado a SQL y cacheado con un recuento. Los operadores son los de siempre — igual, distinto, in, not in, empieza por, termina en, contiene, está definido, no está definido — combinados con and, or y not a la profundidad que necesites.

Previsualízalo antes de usarlo. El endpoint devuelve contactos reales, así que «quién está realmente aquí» es una pregunta que respondes mirando y no enviando y comprobando.

Los segmentos hacen doble función: como audiencia de una campaña, como condición en una rama del funnel y como disparador por derecho propio — segment_enter inicia una ejecución en el momento en que alguien se vuelve elegible.

Habituales silenciososVista previa del segmento · 412
  • 1Etiquetatags contains "regular"
  • 2Atributoattrs.total_orders >= 3 — tu campo, tu nombre para él.
  • 3ComportamientoSin evento order.paid en los últimos 90 días.
  • 4ConsentimientoUna base de correo electrónico utilizable. Los contactos sin ella no entran en el recuento, porque de todos modos no se les podría enviar nada.
  • iVista previa412 contactos, listados. Se cuentan de nuevo al enviar, porque un segmento es una pregunta y no una instantánea.

Compilado a SQLRecuento cacheado, respuesta en vivo

Supresión, y cuándo se comprueba

Las supresiones son por proyecto y globales: rebotes duros, quejas, bajas, entradas manuales y direcciones de rol. Se comprueban en el momento del envío, y luego otra vez dentro del propio servicio de envío.

Esa segunda comprobación es la que hace el trabajo. Un funnel con una espera de tres días tiene una ventana de tres días en la que alguien puede darse de baja, y un sistema que comprobó la supresión cuando el mensaje se puso en cola le escribirá igualmente. Comprobar en el envío es la diferencia entre respetar una baja y registrarla.

El borrado funciona igual: una solicitud de eliminación quita aquí el contacto y su historial de mensajes, y llega a todos los servicios hermanos que tenían una copia por el mismo carril interno que usa el resto de la familia. Hay un único lugar donde pedirlo y una única cosa que ocurre.