SaaS y equipos de producto
Tu producto sabe cosas que ninguna herramienta de marketing puede observar
Quién terminó el onboarding y quién se atascó en el paso tres. Quién invitó a un colega. Quién alcanzó el límite dos veces esta semana. Quién no abre la cosa desde hace quince días. Cada uno de esos es un mejor disparador que cualquier cosa derivada de la apertura de un correo, y todos están a dos líneas de código de serlo.
Los eventos son toda la integración
POST /v1/events con tu propio token: un nombre que tú eliges, un contacto, un payload, una clave de idempotencia. Esa es toda la conexión. No hay SDK que mantener al día, ni pantalla de mapeo, ni vocabulario nuestro al que tengas que traducir tu producto.
Cada evento queda en el registro de solo adición del contacto, y desde ahí es tres cosas a la vez. Un disparador, de modo que un embudo arranca cuando llega. Un predicado, de modo que un segmento pueda decir «ha hecho esto en los últimos catorce días» o, más útil aún, «no lo ha hecho». Y un objetivo, de modo que una secuencia termina en el momento en que alguien hace aquello a lo que se le estaba empujando.
Ese tercero es lo que hace soportable recibir mensajes de ciclo de vida. El empujón para terminar de configurar tu cuenta debería dejar de existir en el segundo en que la cuenta está configurada, y en la mayoría de herramientas no lo hace, porque la secuencia y el producto no se hablan entre sí.
- ⚡Activador
api_event—signup.completed, planfree. - 2Enviar correoLo único que hay que hacer primero. No un recorrido por once funciones.
- 3Esperar 2 días
wake_aten la ejecución. Nada en cola, nada que deshacer si reescribes esto mañana. - ?Condición¿Ha llegado
project.created? No → la rama de ayuda. Sí → el objetivo de abajo. - 4Rama de ayudaUn mensaje que ofrece lo concreto que no hicieron. Luego, una segunda espera.
- 5ObjetivoLlega
project.created. La secuencia termina. Ningún correo de onboarding más, nunca, para esta persona.
Tus nombres de eventosTu definición de activación
Cinco embudos
El ciclo de vida, en el orden en que realmente ocurre
1 · Activación
Desencadenante: el registro. Dos o tres mensajes, cada uno sobre una acción, cada uno con un objetivo que cierra la secuencia cuando esa acción ocurre. El embudo más valioso que vas a construir, y el que más merece reescribirse tres veces.
2 · El estancamiento
Desencadenante: segment_enter — se registró, sin ningún evento significativo en siete días. Un mensaje que pregunta en lugar de ordenar, y otro que ofrece algo concreto. Después, parar. Un cuarto mensaje para alguien que ha ignorado tres es un mensaje para nadie.
3 · El momento de expansión
Desencadenante: un evento que indica que está obteniendo valor — alcanzó el límite, invitó a un tercer colega, exportó por segunda vez. Es el único momento en que un mensaje de mejora es bienvenido, y es un momento que tu producto puede nombrar con precisión.
4 · Renovación y reclamación de pagos
Desencadenante: date_field antes de la renovación, o un evento de pago. Aviso, recordatorio y — si un pago falla — una secuencia corta que se detiene en el instante en que tiene éxito. Los nodos de objetivo no son opcionales en la reclamación de pagos; son la diferencia entre un recordatorio y un acoso.
5 · Recuperación
Desencadenante: segment_enter — canceló o inactivo durante sesenta días. Dos mensajes, honestos, luego una etiqueta y silencio. Lo que ha cambiado desde que se fue es un mensaje mejor que un descuento.
Y el interno
notify_team avisa a una persona cuando una cuenta que merece una persona cruza un límite. Un embudo no tiene que terminar en un correo a un cliente; a veces la acción correcta es decirle a alguien de tu lado que coja el teléfono.
Nadie abandona a propósito. Simplemente dejan de abrirlo.
Por qué a un desarrollador le puede gustar esto de verdad
Las partes que importan cuando eres tú quien integra
Sin endpoints privados
Cada pantalla se puede construir con la API pública, porque no existe otro tipo. Si quieres incrustar un informe de campaña en tu propio panel de administración, nada se interpone en tu camino y nada hay que hacer con ingeniería inversa.
Claves de idempotencia en todas partes
En cada ruta que modifica datos. Tu lógica de reintentos, tu cola at-least-once y tu red inestable se convierten en problema de otro — concretamente, en problema de un índice único.
Simula antes de lanzar
POST /v1/simulate hace una prueba en seco de un contacto a través de un embudo y devuelve la ruta y cada mensaje que enviaría. Ponlo en tu CI si quieres: un embudo es un grafo, y un grafo se puede testear.
Un servidor MCP
Apunta un agente a /mcp y deja que cree y verifique embudos. Las herramientas con capacidad de envío requieren una confirmación explícita y están limitadas por cuota, así que un prompt malinterpretado no puede convertirse en cincuenta mil correos.
Webhooks salientes
Firmados, con reintentos con backoff, al menos una vez. El mismo vocabulario de eventos que usan los informes, para que tu almacén de datos y tu panel no discrepen sobre qué significa "entregado".
Un borrado que llega de verdad
Una solicitud de eliminación borra el contacto y su historial de mensajes aquí y se propaga a cada servicio hermano que tuviera una copia. Una solicitud, un resultado, y algo a lo que señalar cuando te pregunten.
Dónde está la frontera
ClickSomo guarda una lista de correo y lo que esa lista hizo. No es tu base de datos de usuarios y no pretende serlo: un contacto nunca lleva una credencial, nunca inicia sesión y nunca se convierte en una cuenta. Tus usuarios viven en tu producto; los contactos viven aquí, y ambos se unen mediante una dirección de correo y los eventos que decidas enviar.
Esa separación es deliberada y es la razón por la que el modelo de consentimiento funciona. Tú eres el responsable del tratamiento de tus usuarios; nosotros procesamos en tu nombre. Un diseño en el que una herramienta de marketing se convierte silenciosamente en el almacén de identidades es uno que no se puede desenredar después, y es exactamente el fallo que este está construido para evitar.
La versión práctica: envía los eventos, envía los atributos por los que quieras segmentar, y deja todo lo demás donde está. Si te encuentras empujando todo tu esquema aquí, el segmento que intentas construir probablemente es una consulta en tu propia base de datos que debería llegar como un único atributo booleano.