Customer.io paso a paso: usuarios, eventos y primera automatización
Customer.io envía mensajes según lo que hacen los usuarios en tu producto. Antes de enviar el primer mensaje automático, debes configurar dos cosas clave.
👁 120 lecturas
Customer.io envía mensajes basándose en lo que las personas hacen en tu producto: se registran, compran, dejan de iniciar sesión. Antes de enviar el primer mensaje automático, necesitas transmitirle dos cosas: quiénes son los usuarios y qué hacen. Este tutorial te guía paso a paso, según la documentación oficial de Customer.io.
Atención a la nomenclatura: los materiales más recientes de Customer.io llaman a las campañas automatizaciones, mientras que los más antiguos siguen hablando de campañas. Es lo mismo.
Antes de empezar: lista de eventos
La mayoría de los problemas con Customer.io surgen porque los eventos se envían sin planificación. Antes de que el desarrollador añada la primera llamada, escribe en una página la lista de eventos que son relevantes para tu comunicación: registro, primera acción clave, compra, cancelación del plan. Para cada uno, anota el nombre que vais a usar y qué detalles debe contener.
Estableced una convención de nombres, por ejemplo, solo minúsculas y guiones bajos. Un evento llamado una vez «Compra» y otra «purchase_completed» son dos eventos diferentes y los segmentos empezarán a desincronizarse.
Paso 1. Usuarios
El primer paso es transmitir la lista de personas. La documentación propone dos vías. El desarrollador envía una llamada identificando al usuario desde la aplicación, por ejemplo, en el registro. Una persona no técnica puede añadir usuarios desde un archivo CSV o manualmente. Cada persona tiene atributos, por ejemplo, nombre, plan, fecha de registro.
Paso 2. Eventos
Los eventos son acciones de las personas en la aplicación o en el sitio web: clic en un botón, compra, añadir producto al carrito. Los envías con una llamada track, con el nombre del evento y sus detalles. Regla importante de la documentación: primero identificas a la persona, solo después envías sus eventos. Los eventos previos al inicio de sesión se pueden registrar de forma anónima y asignar a la persona después de su identificación.
Paso 3. Segmentos
Un segmento es un grupo de personas. Hay dos tipos. Los segmentos basados en datos se actualizan solos cuando alguien empieza o deja de cumplir las condiciones, por ejemplo, «registrados en la última semana que no han añadido su primer proyecto». Los segmentos manuales son fijos. Puedes construir criterios basados en atributos, eventos y otros datos.
Paso 4. Primera automatización
Una automatización tiene tres partes: disparador, es decir, quién y cuándo entra, flujo con mensajes y acciones, y condiciones de salida. El disparador puede ser un evento, entrada a un segmento o cambio de atributo. El recorrido de una persona a través del flujo es su journey.
Una buena primera automatización es una serie de bienvenida: disparador registro, primer email inmediato, segundo después de dos días si el usuario no ha hecho la acción clave, y salida cuando la haga.
Paso 5. Envíos únicos y transaccionales
Además de las automatizaciones, están los envíos únicos, por ejemplo, anuncio de una nueva función a un segmento seleccionado, y los mensajes transaccionales, enviados en respuesta a una acción del usuario, como confirmación o restablecimiento de contraseña. Las automatizaciones y envíos soportan email, SMS, notificaciones push y mensajes in-app, y además pueden enviar un mensaje a Slack, llamar a un webhook o actualizar un atributo.
Ejemplo: serie de bienvenida para app de planificación
Una aplicación de planificación de comidas envía a Customer.io la identificación en el registro y el evento «creó primer plan». Automatización: disparador registro, email inmediato con tres pasos para empezar, después de dos días recordatorio con plan de ejemplo para personas sin el evento «creó primer plan», salida tras crear plan. Las personas que ya empezaron no reciben recordatorios, porque salen de la automatización.
En esta serie, lo más importante es el momento del segundo mensaje. Dos días es un punto de partida, no una regla: si los usuarios suelen volver a la aplicación el fin de semana, un recordatorio enviado el martes caerá en el vacío. Después de unas semanas, vale la pena comprobar cuándo las personas que realizaron la acción clave solían hacerlo, y ajustar los intervalos. Customer.io permite cambiar el retraso en el flujo de la automatización sin reconstruir todo, así que estos ajustes llevan unos minutos.
Errores más frecuentes
- Eventos enviados antes de identificar a la persona.
- Falta de condiciones de salida, por lo que las personas reciben recordatorios sobre cosas que ya hicieron.
- Nombres de eventos sin convención establecida, por lo que los segmentos se dessincronizan.
Cómo evaluar el primer mes
Después de un mes de funcionamiento de la serie de bienvenida, compara dos cifras: qué porcentaje de nuevas personas realizó la acción clave antes de lanzar la automatización y después. Es la única métrica que realmente cuenta. Las aperturas de emails son agradables, pero si no se traducen en que las personas empiecen a usar el producto, hay que cambiar el contenido o el momento del envío.
Comprueba también que nadie reciba mensajes sobre cosas que ya hizo. Es señal de que falta una condición de salida o el evento no llega a tiempo.
Por último, un consejo organizativo: cada automatización debe tener un responsable, es decir, una persona que una vez al mes revise sus resultados y el contenido de los mensajes. Las automatizaciones de las que nadie se acuerda, al cabo de un año envían información desactualizada sobre funciones que ya no existen, o enlaces que no llevan a ninguna parte.
More on this from FULGOR
revista·Factory y Droid paso a paso: instalación y revisión de códigoFactory ofrece agentes de programación llamados Droid que trabajan en el terminal, el editor y GitHub: leen el proyecto, proponen cambios y revisan pull requests.