Nodos de Canvas

Los flujos de Canvas se crean con distintos tipos de nodos que definen cómo avanzan las personas por la automatización. Esta guía explica todos los nodos disponibles y su comportamiento.

Nodos de desencadenante

Los nodos de desencadenante definen cómo entran las personas en un Canvas.

Desencadenantes disponibles

Tipo de desencadenante	Descripción
Evento	La persona entra al realizar un evento específico.
Entrada en segmento	La persona entra cuando se incorpora a un segmento.
Cambio de entidad	La persona entra cuando cambia un registro de entidad relacionado.
API	La persona entra mediante una llamada a la API.
Programación	Las personas entran según una programación recurrente.
Mensaje de WhatsApp	La persona entra cuando envía un mensaje de WhatsApp.
SMS entrante	Un contacto conocido entra cuando escribe por SMS; filtra por cuenta de SMS, tipo de mensaje y condiciones de Texto / Tipo de mensaje.

Nodos de mensaje

Los nodos de mensaje envían comunicaciones a las personas a través de distintos canales.

Canales compatibles

• Email: envía emails personalizados.
• SMS: envía mensajes de texto.
• Notificaciones Push: envía notificaciones Push móviles.
• WhatsApp: envía plantillas o respuestas de WhatsApp.
• Webhook: llama a una API externa con un cuerpo creado mediante plantilla Liquid.

In-app es un nodo aparte

Los mensajes in-app no son un canal del nodo de Mensaje. Como se muestran cuando la persona vuelve a abrir tu aplicación (en lugar de enviarse), tienen su propio nodo Mensaje in-app - consulta Nodos de mensaje in-app.

Eliges el canal desde el propio nodo de mensaje. Webhook aparece en el mismo selector de canales que Email y SMS, con su propio generador de solicitud - método, encabezados, cuerpo, autenticación, reintentos y una espera opcional de asignación de respuesta - . Usa Enviar prueba para realizar una llamada de ejemplo; después haz clic en cualquier campo de la respuesta para asignarlo a una variable de recorrido, o pega una respuesta de ejemplo para crear la asignación sin una llamada en vivo. Cuando está activa la asignación de respuesta, también puedes habilitar una salida en caso de error: un segundo puerto que sigue el recorrido si la llamada falla o se agota el tiempo. Déjalo sin conectar para continuar por la salida normal - fallo abierto - .

Qué reglas se aplican a los webhooks

El canal Webhook llama a un servicio externo en vez de a la bandeja de entrada de una persona, por lo que el consentimiento de suscripción no se gestiona para webhooks: no hay opt-in de webhook y la preferencia de suscripción de la audiencia no los restringe. Todo lo demás se aplica de forma predeterminada:

• Las horas de silencio y los límites de frecuencia restringen los webhooks de forma predeterminada, igual que los mensajes. Un webhook que representa un contacto con cliente - por ejemplo, activa un mensaje en otro sistema - no debe ejecutarse en la ventana de silencio de una persona. Si tu webhook es una llamada puramente entre sistemas - sincronizar un CRM o iniciar una tarea de backend - , marca Llamada de sistema: omitir horas de silencio y límites de frecuencia en el nodo para excluir ambos.
• Las listas de supresión siempre se aplican: un contacto suprimido nunca activa el webhook. La casilla Llamada de sistema no cambia esto.
• Facturación: los contactos sobre los que se activa un webhook cuentan como perfiles activos facturables, igual que los destinatarios de mensajes. Consulta Cómo se calcula el uso.

Comportamiento de avance tras un mensaje

Important

Las personas avanzan al siguiente paso inmediatamente después de que el mensaje se pone en cola para enviarse. El Canvas no espera a que el mensaje llegue a la bandeja de entrada.

Este es el enfoque habitual de la industria. Permite:

• Escalabilidad: procesa millones de personas sin bloquearse.
• Rendimiento: la ejecución de Canvas no se ralentiza por los tiempos de entrega.
• Fiabilidad: trabajadores dedicados se ocupan de la entrega con reintentos.

Qué significa «mensaje enviado»:

1. El mensaje se personaliza con datos de la persona.
2. Se añade a la cola de envío.
3. La persona avanza al siguiente paso de Canvas.
4. Un trabajador dedicado procesa la cola y entrega los mensajes.

Garantías de entrega de mensajes:

• Los mensajes se reintentan hasta 3 veces con espera exponencial.
• Los mensajes fallidos se registran para investigarlos.
• El seguimiento de entrega - aperturas, clics y rebotes - se gestiona por separado.

Consentimiento de suscripción

Los nodos de mensaje aplican el consentimiento de suscripción en el momento del envío, por canal. Se aplican las mismas reglas que en campañas, así que un recorrido y una campaña tratan del mismo modo al mismo contacto. La preferencia de suscripción de la audiencia de Canvas determina lo estricta que es la regla:

• Suscrito - predeterminada - : envía solo a contactos que han dado consentimiento en ese canal - subscribed u opted_in - . Se omiten los contactos dados de baja explícitamente y los que no tienen ningún registro de suscripción.
• Confirmado: solo suscriptores confirmados con doble opt-in.
• Todos: envía independientemente del estado de suscripción; es la anulación explícita de «enviar incluso a no suscritos» o transaccional.

Aspectos específicos por canal:

• Email también omite direcciones con rebote duro.
• Push es más permisivo: como el permiso Push se concede en el dispositivo y no mediante un registro de opt-in, se envía salvo que el contacto se haya dado de baja explícitamente. Un contacto sin registro sigue recibiendo Push.

Un envío omitido no retira al contacto del recorrido: solo se omite el mensaje y el contacto avanza al siguiente paso - webhook, Actualizar usuario, ramificación, etc. siguen ejecutándose para todos - . El consentimiento se vuelve a comprobar en cada envío, por lo que un cambio de suscripción realizado antes en el recorrido - por ejemplo, en un paso Actualizar usuario - o desde el centro de preferencias se respeta en el siguiente mensaje. Nada queda congelado en la entrada.

También se aplican las listas de supresión en todos los canales. Se omite un contacto que pertenezca al segmento de una lista de supresión activa - y permanece en el recorrido - , salvo que las etiquetas de excepción de esa lista excluyan este Canvas. Los recorridos usan la pertenencia materializada del contacto al segmento, que se actualiza según una programación; por eso la supresión se refleja con una breve demora. Las campañas la evalúan en vivo al enviar.

Grupos de suscripción por número (SMS/WhatsApp)

Para SMS y WhatsApp, los recorridos aplican la misma regla de grupo de suscripción por número o WABA que las campañas. Una lista de suscripción vinculada a un remitente específico se convierte en el grupo de ese remitente: los grupos de SMS son por número de envío y los de WhatsApp por WABA. Un contacto que se dio de baja del grupo del número emisor - o WABA - se omite en ese mensaje, pero, como ocurre con todas las omisiones, avanza al paso siguiente: solo se descarta el mensaje.

El grupo cuya baja se comprueba depende del remitente que elijas en el nodo de mensaje: el número de SMS para un mensaje SMS y el WABA para WhatsApp. Si no eliges ninguno, se usa el remitente predeterminado del espacio de trabajo - para SMS - o el WABA predeterminado - para WhatsApp - y se comprueba el grupo de ese valor predeterminado.

Horas de silencio

Los nodos de mensaje respetan la configuración de horas de silencio del espacio de trabajo, evaluada en la zona horaria del contacto al enviar. Cuando un contacto llega a un nodo de mensaje durante una ventana de silencio - o un festivo configurado - , el comportamiento sigue la regla de cada canal de la organización:

• Omitir: el mensaje no se envía y el contacto avanza al siguiente paso.
• Retrasar: el nodo de mensaje se aplaza hasta que termine la ventana, y después se ejecuta y envía.

Esto replica el comportamiento de campañas - por ejemplo, email puede retrasarse por la noche mientras que SMS se omite - , de modo que las horas de silencio se aplican de manera coherente tanto si el contacto llega mediante una campaña como por un recorrido.

Enviar un mensaje de prueba

Cada nodo de mensaje incluye un botón Enviar mensaje de prueba en su modal de configuración. Úsalo para verificar la personalización y la conectividad con el proveedor antes de publicar.

Cobertura por canal:

• Email: abre un modal de envío de prueba con el mismo selector de usuario - aleatorio / existente / personalizado - y una anulación del email destinatario.
• SMS: abre un modal de envío de prueba con el mismo selector y una anulación de número de teléfono.
• WhatsApp: igual que SMS, pero la plantilla elegida debe estar en estado approved.

El selector resuelve las variables Liquid con los atributos de la persona elegida y luego envía directamente mediante el proveedor del espacio de trabajo, sin pasar por la cola de Canvas, la segmentación de audiencia ni las reglas de horas de silencio. La supresión sigue aplicándose: se rechaza un envío de prueba a una dirección o número suprimidos, igual que un envío real. Los envíos de prueba no cuentan en las estadísticas de ejecución, no activan webhooks y siempre son gratuitos.

Test renders match live sends

Los envíos de prueba se renderizan mediante la misma canalización que los envíos reales: los tokens de personalización, atributos personalizados y bloques de contenido se resuelven de forma idéntica. Lo que recibas en una prueba será exactamente lo que reciba la audiencia.

Nodos de mensaje in-app

Los mensajes in-app funcionan de forma distinta a cualquier otro canal, por eso tienen su propio nodo. El email, el SMS, las push y WhatsApp se envían a la persona. Un mensaje in-app se muestra cuando la persona vuelve a abrir tu aplicación, así que este nodo no "envía" nada: pone el mensaje en cola para ese usuario y tu aplicación lo muestra en la siguiente sesión apta.

Añádelo desde la ficha Mensaje in-app de la paleta del constructor.

Qué se configura

• Campaña in-app (obligatorio) - la campaña que aporta el contenido, el diseño y las variantes. El nodo reutiliza la campaña que ya creaste, de modo que el mensaje se ve igual desde donde sea que se entregue.
• Prioridad - Urgente / Alta / Normal / Baja. Cuando varios mensajes in-app son aptos en el mismo momento, se muestra primero el de mayor prioridad; los empates se resuelven por antigüedad, así un mensaje en cola nunca queda sepultado por otros más nuevos. Los mensajes de journey y las campañas in-app compiten en la misma clasificación.
• Con qué frecuencia puede mostrarse - Mostrar una vez (predeterminado), Mostrar hasta N veces (con un intervalo mínimo opcional entre apariciones) o Mostrar hasta que se pulse o se descarte.
• Dejar de intentarlo después de N días - si la persona no abre la aplicación en ese plazo, el mensaje caduca sin verse. El valor predeterminado es 7 días.
• Esperar hasta que se muestre (opcional) - ver más abajo.

¿Cuándo continúa el journey?

De forma predeterminada, el journey continúa de inmediato tras poner el mensaje en cola: el mismo comportamiento de "enviar y seguir" que en los demás canales, porque no se puede saber cuándo volverá a abrir la aplicación.

Marca Esperar hasta que se muestre para retener a la persona en este paso hasta que vea realmente el mensaje. Si no abre la aplicación dentro de la ventana de espera (24 horas de forma predeterminada), el journey continúa igualmente: nunca se queda bloqueado por un mensaje que no se vio.

Cuándo esperar

Usa Esperar hasta que se muestre cuando el paso siguiente solo tenga sentido después de que la persona haya visto el mensaje; por ejemplo, "muestra el consejo de bienvenida, espera y luego envía un email a quienes lo vieron". Déjalo desactivado para avisos de tipo enviar y olvidar.

Límite de frecuencia

Los mensajes in-app de un journey cuentan para el mismo límite de frecuencia in-app que las campañas: un único límite diario compartido por persona, más tu techo entre canales. Un mensaje bloqueado por el límite se omite y el journey sigue adelante. Los contactos suprimidos nunca reciben mensajes in-app.

Informes

El nodo informa como cualquier otro paso de mensaje, con terminología in-app:

• Mostrado cuenta como la entrega del nodo (en in-app, mostrarse es la entrega)
• Pulsado cuenta los toques en el mensaje
• No hay paso Abierto en in-app: el embudo es mostrado → pulsado

Las conversiones atribuidas al journey usan la misma ventana y el mismo modelo de atribución que los demás canales.

Nodos de espera

Los nodos de espera pausan el avance de la persona. Tres tipos de espera cubren los patrones habituales:

Tipos de espera

Tipo	Cuándo usarlo
Duración	Espera un tiempo fijo después de que la persona llegue a este paso; por ejemplo, «esperar 7 días».
Fecha de calendario	Espera hasta una fecha y hora específicas; por ejemplo, «liberar el 2026-05-17 a las 10:00». Las personas que entren después salen del recorrido.
Día de la semana	Espera hasta la siguiente ocurrencia de un día de la semana y hora elegidos; por ejemplo, «el próximo lunes a las 12:00».

Duración

Configuración	Descripción
Esperar	Número y unidad: minutos, horas, días o semanas.
Después esperar hasta una hora específica	Opcional. Una vez terminada la duración, sigue esperando hasta la hora elegida en la zona horaria seleccionada.
Zona horaria	Organización / hora local del usuario / UTC; se usa en la opción de hora del día.

Fecha de calendario

Configuración	Descripción
Fecha	Fecha ISO objetivo. Se elige desde el calendario en línea: haz clic en un día y usa las flechas para navegar por meses.
Hora	Selectores de hora y minuto.
Zona horaria	Organización / hora local del usuario / UTC.

Día de la semana

Configuración	Descripción
Día y hora	Día de la semana, hora y minuto. La fila de vista previa de 7 celdas de la parte superior del modal también es interactiva.
Zona horaria	Organización / hora local del usuario / UTC.
Si una persona llega después del límite	Wait - predeterminado - la pasa a la ocurrencia de la semana siguiente. Advance se activa de inmediato para que no pierda una semana.

Personalizar espera

Un interruptor presente en todos los tipos. Al activarlo, la espera lee una variable por persona en lugar de un valor fijo:

Fuente	Lee de
Variables de contexto	execution.context[varName]: el contexto entrante del recorrido - valor heredado predeterminado - .
Atributo personalizado del usuario	user.attributes.<varName> y campos de usuario de nivel superior.
Propiedad de evento	execution.context.event.<varName> y la carga útil del desencadenante.

En Fecha de calendario o Día de la semana con una variable personalizada, también puedes configurar un desplazamiento - positivo o negativo, en horas, días o semanas - ; por ejemplo, «enviar 3 días antes de la fecha de renovación».

Resolución de zona horaria

Modo	Se resuelve como
Hora de la organización	workspace.settings.timezone, almacenada en caché por trabajador durante 60 s.
Hora local del usuario	user.attributes.timezone, establecida por el SDK. Si no existe, usa la hora de la organización.
UTC	UTC.

Límites

• Todas las ramas de espera están limitadas a un máximo de 30 días. Un nodo mal configurado se activa de inmediato en vez de bloquear el recorrido y registra una advertencia estructurada.

Ejemplo: espera 24 horas antes de enviar un email de seguimiento.

Nodos de ramificación

Los nodos de ramificación dirigen a las personas por rutas diferentes según sus atributos, historial de eventos, pertenencia a segmentos y más. Un único bloque integra tanto la antigua División de decisión - Sí / No - como la Ruta de audiencia - grupos ordenados con varias píldoras - . Un interruptor del modal permite cambiar entre ambas.

El nodeType interno del bloque sigue siendo condition por compatibilidad con datos de recorridos existentes. Los recorridos nuevos se guardan como branchMode: 'yesno' | 'multi'.

Dos modos

Sí / No: una ruta con nombre y Everyone else. Úsalo cuando la pregunta sea binaria: «¿esta persona compró, sí o no?».

Múltiple: hasta 10 grupos ordenados con nombre y Everyone else - 11 rutas en total - . Úsalo cuando necesites más de dos rutas: «clientes VIP, visitantes frecuentes, compradores ocasionales, todos los demás». Convierte una rama Sí/No en Múltiple con Añadir un nuevo grupo en el panel del modal. Simplifícala de nuevo mediante Simplificar a Sí / No, visible cuando solo queda un grupo con nombre y Everyone else.

Resolución por prioridad ordenada

En modo Múltiple, los grupos se evalúan en orden. Gana el primer grupo que coincide. Las personas que no coinciden con ningún grupo con nombre se dirigen a Everyone else. Puedes arrastrar filas del panel para cambiar el orden.

«Salir de Canvas» por grupo

Cada grupo con nombre - y Everyone else - puede marcarse como Salir de Canvas en lugar de enrutar. Las personas que lleguen a ese grupo completan el recorrido en el paso de ramificación con exitReason: 'branch_exit:<group name>'. Es útil para «si se cumple la condición, no hace falta enviar nada: salir del flujo».

Filas de filtros

Cada ruta o grupo se configura con uno o más grupos de filtros. Los filtros dentro de un grupo se unen con un conector interno AND / OR; los propios grupos se unen con un groupOperator externo - normalmente OR - .

El modal Ramificación utiliza el mismo componente <FilterRow> que emplean el editor de segmentos y el selector de audiencia de campañas, por lo que admite todos los tipos de filtro de esas interfaces:

Tipo	Qué comprueba	Operadores
attribute	user.attributes[field]	equals, not_equals, gt, gte, lt, lte, contains, not_contains, exists, not_exists, in, not_in
default_attribute	Campos de usuario de nivel superior - email, phone, externalId, firstName, lastName, country, puntuaciones de ML y derivados de e-commerce -	Igual que attribute
event / behavioral	Historial de eventos con ventana temporal opcional	performed_event, not_performed_event, performed_event_in_last, not_performed_event_in_last, event_count_gte, event_count_lte
segment	Pertenencia a segmento - recursiva; los segmentos pueden referenciar otros segmentos, hasta una profundidad de 5 -	in, not_in
canvas_execution	Ejecuciones de Canvas activas, completadas o con salida	in_canvas, not_in_canvas, in_any_canvas, not_in_any_canvas, completed_canvas, exited_canvas
channel_subscription	user.subscriptions[channel].status	subscribed_to_channel, not_subscribed_to_channel, opted_in_to_channel
list_membership	Registro de suscripción a una lista elegida	member_of_list, not_member_of_list
bounce_status	Validez de email o estado de rebote duro o leve	email_valid, email_bounced, email_hard_bounced
ecommerce	Segmento RFM, número de pedidos, gasto y estado del carrito	rfm_segment_equals, rfm_segment_in, has_purchased, never_purchased, total_orders_*, total_spent_*, average_order_value_*, days_since_last_order_*, has_active_cart, no_active_cart, cart_value_*, cart_abandoned
entity	user.entityRecords[entity]	exists, not_exists
app	user.appIds	has_app, not_has_app

Los once tipos comparten un único evaluador - FilterEvaluator - que usan tanto el trabajador de ramificación de Canvas como el evaluador de campañas in-app. Los tipos nuevos que se añadan allí se habilitan automáticamente en todas partes.

Opciones de ventana temporal (filtros de evento)

• withinMinutes: minutos - por ejemplo, 30 - .
• withinHours: horas - por ejemplo, 1 o 24 - .
• withinDays: días - por ejemplo, 7 o 30 - .
• eventTimeWindow: segundos, usado por el evaluador in-app.

También se admiten condiciones de propiedad; por ejemplo, «realizó Pedido completado en los últimos 30 días con valor ≥ 100»:

{
  "type": "event",
  "eventName": "Order Completed",
  "operator": "performed_event_in_last",
  "withinDays": 30,
  "eventProperties": { "value": "100" }
}

Tarjeta de nodo de Canvas

La tarjeta de nodo se adapta al modo:

• Sí / No: dos puertos de salida en la parte inferior - verde = sí; rojo = no - .
• Múltiple: un puerto de salida por grupo en el borde derecho de la tarjeta, con el nombre del grupo en la fila. La tarjeta crece verticalmente al añadir grupos.

Las etiquetas de conexión coinciden exactamente con el nombre de grupo; el trabajador lee las conexiones por nombre al enrutar. Si cambias el nombre de un grupo, la conexión sigue vinculada porque se usa el identificador de controlador de React Flow: cambiar nombre → guardar → sin roturas.

Ejemplo: flujo de carrito abandonado

1. Desencadenante: Evento = «Producto añadido».
2. Espera: espera 1 hora.
3. Ramificación (Sí / No): not_performed_event_in_last «Pedido completado» durante la última hora.
   • Sí: envía un email de recuperación.
   • No (Everyone else): sale del flujo.

Ejemplo: enrutamiento RFM de varias rutas

1. Ramificación (Múltiple) con 3 grupos con nombre y Everyone else:
   • Clientes VIP - ecommerce.rfm_segment_equals: champions - → envía una oferta exclusiva.
   • Visitantes frecuentes - evento Page Viewed en los últimos 7 días, event_count_gte: 10 - → envía una campaña de reactivación.
   • En riesgo - ecommerce.days_since_last_order_gte: 60 - → envía una campaña de recuperación.
   • Everyone else → sale de Canvas.

Nodos de bifurcación de comportamiento

Una bifurcación de comportamiento dirige a las personas según lo que hacen dentro de una ventana temporal. Mientras que Ramificación lee el estado en el momento de evaluación, la bifurcación de comportamiento deja a la persona en espera y observa el futuro: el primer evento que coincida - o el vencimiento de la ventana - decide qué ruta sigue.

Integra los antiguos bloques Ruta de acción - un solo evento y condición - y Ruta de audiencia basada en evento. Un concepto, dos estados.

Dos modos

Modo	Cuándo usarlo
Hizo / No hizo	Una ruta «hizo» con nombre y la alternativa implícita «Sin evento en la ventana». Equivale a la antigua Ruta de acción de un evento.
Múltiple	Hasta 10 grupos ordenados con nombre y «Sin evento en la ventana». Convierte a múltiple con Añadir un nuevo grupo; vuelve a simplificar con Simplificar a Hizo / No hizo cuando quede un solo grupo con nombre.

Ventana de espera

Configuración	Comportamiento
Esperar hasta N unidades	Límite fijo: minutos, horas, días o semanas.
Personalizar	Ventana tomada de {{canvas.x}} - variable de contexto - o {{user.x}} - atributo de usuario - . El valor debe resolverse como un número interpretado en la unidad elegida.

La ventana es de nivel de bloque: todos los grupos de la misma bifurcación de comportamiento comparten el mismo límite. Las ventanas por grupo hacían incoherentes las configuraciones de varias rutas y rara vez se usaban, por lo que se eliminaron al rediseñar el nodo.

Modo de avance

Modo	Comportamiento
As soon as an event fires - predeterminado -	Gana el primer evento que coincida con cualquier fila de desencadenante. La persona se enruta de inmediato. El orden sigue siendo el desempate para coincidencias simultáneas en un mismo ciclo de evento.
At end of window	El bloque espera toda la ventana. Si una persona coincide con varios grupos durante ella, gana el grupo con mayor prioridad. Elígelo cuando el orden importe más que la rapidez.

Selector de desencadenante

La lista de desencadenantes de cada grupo aparece en una tarjeta con un selector de tipo de desencadenante en la parte superior de cada fila. Los tipos nuevos se integran en el mismo selector sin modificar la configuración guardada.

Tipo	Estado de ejecución
Realizar evento personalizado	Totalmente conectado. Elige cualquier evento del registro de eventos. Los filtros de propiedad unidos por AND acotan la coincidencia.
Realizar pedido / Iniciar sesión / Realizar compra (heredado)	Eventos predefinidos con etiquetas claras. Están conectados y se resuelven como nombres de evento canónicos: place_order, start_session, make_purchase_legacy.
Realizar evento de conversión	Se guarda, pero aún no está conectado; está pendiente del gancho de ejecución de eventos de conversión.
Añadir una dirección de email	Se guarda, pero aún no está conectado; está pendiente del flujo de eventos de asignación de atributos.
Cambiar valor de atributo personalizado	Se guarda, pero aún no está conectado; está pendiente del flujo de eventos de cambio de atributos.

Los tipos sin conexión muestran un aviso ámbar en línea para que quienes crean el flujo no se sorprendan durante la ejecución.

Dentro de un grupo, las filas de desencadenante se unen mediante OR: basta con que coincida una para enrutar a la persona. Dentro de un desencadenante, los filtros de propiedad múltiples se unen mediante AND.

«Salir de Canvas» por grupo

Una casilla por grupo termina el recorrido al elegir esa ruta, en vez de dirigir a un nodo conectado. La ejecución se cierra con exitReason = "behavior_split_exit:<group_name>".

Tarjeta de nodo de Canvas

La tarjeta de bifurcación de comportamiento tiene una franja violeta en el encabezado - «BEHAVIOR SPLIT» - y una píldora de reloj que muestra la etiqueta de ventana - «3 días», «{{canvas.evaluation_window}} horas» - .

• Modo Hizo / No hizo: dos puertos inferiores con identificadores estables, did - violeta - y timed_out - gris azulado - . Cambiar el nombre de la ruta en el modal no deja conexiones huérfanas.
• Modo Múltiple: filas apiladas, una por grupo con nombre y la fila gris azulado «Sin evento en la ventana». Cada fila tiene su propio controlador de origen en el borde derecho de la tarjeta, con id = group-name-slug; la fila de tiempo agotado utiliza timed_out.

Cuando la lista de desencadenantes de un grupo está vacía, la fila muestra una pequeña insignia de advertencia. Ese grupo nunca puede coincidir, por lo que el bloque no funcionará correctamente hasta que añadas un desencadenante o marques Exit canvas.

Ejemplos desarrollados

Ejemplo 1: carrito abandonado. Modo Hizo / No hizo. Desencadenante = purchase_completed. Ventana = 24 horas. Avance = As soon as an event fires. Conecta la salida timed_out a un email de recordatorio y la salida did a un agradecimiento. Quienes compren salen correctamente; quienes no, reciben un recordatorio después de un día.

Ejemplo 2: reactivación multicanal. Modo Múltiple. Tres grupos ordenados: 1. Realizó compra - evento=purchase_completed - , 2. Visitó precios - evento=page_view + filtro de propiedad page=/pricing - y 3. Abrió email - evento=email_opened - . Avance = At end of window. Ventana = 7 días. Conecta cada grupo a una secuencia de seguimiento distinta; la salida Sin evento en la ventana va a una ruta de nurturing más prolongada. El orden importa: una persona que haya comprado Y visitado precios sigue la ruta Realizó compra.

Nodos de experimento

Para pruebas A/B/n, fijar una ganadora, optimización de bandido multibrazo o personalización por persona impulsada por ML, usa el nodo Experimento. Consulta la guía del nodo de experimento para conocer todos los detalles.

El nodo independiente División A/B se ha eliminado. El nodo Experimento en modo de tipo de ruta «Estándar» cubre el mismo caso de uso con más flexibilidad: grupos de control, grupos de espera y elección opcional de ganadora.

Nodos de decisión con IA

El nodo Decisión con IA dirige a cada persona por la ruta que la IA predice que es mejor para esa persona: la decisión de «ajuste de oferta» individual dentro de un recorrido. Mientras que el nodo Experimento encuentra la ruta ganadora global, Decisión con IA elige una ruta diferente por persona según sus atributos y comportamiento.

Configuración:

• Rutas: las rutas entre las que elige la IA; cada una continúa en su propia rama posterior.
• Objetivo: Interacción - aperturas y clics - , Conversión - un evento específico - o Ingresos - valor de compra - . Determina qué optimiza el modelo.
• Evento de conversión: aparece cuando el objetivo es Conversión; es el evento que cuenta como éxito. Puede ser un evento personalizado como signup.

Cómo decide - por persona - : el modelo individual elige la mejor ruta - explotación - ; una pequeña parte explora rutas inciertas para seguir aprendiendo - de forma inteligente, no aleatoria - . Antes de que el modelo haya aprendido las rutas, las personas se distribuyen de forma justa - inicio en frío - . Los resultados se atribuyen de vuelta y el modelo se reentrena a diario.

Qué cuenta como «victoria» y de qué aprende. El éxito sigue tu objetivo: Interacción cuenta aperturas y clics; Conversión, el evento de conversión; e Ingresos, las compras. La victoria se acredita a la ruta por la que fue dirigida la persona, de modo que la IA aprende qué mensaje u oferta impulsa realmente el resultado, no solo cuál se abre. Para un objetivo de Conversión o Ingresos, una apertura o clic no es una «victoria» por sí sola: optimizaría lo equivocado; un mensaje de clickbait puede ganar aperturas y perder ventas. Las aperturas y clics siguen ayudando como entradas, a continuación. Para elegir una ruta individual, la IA analiza el comportamiento y perfil recientes a partir de tus datos existentes; no hay nada que etiquetar:

• Interacción: cuánto abren y hacen clic - email, Push e in-app - , cuándo estuvieron activas por última vez, con qué frecuencia visitan - sesiones y páginas vistas - , respuestas de WhatsApp y en qué horas o días suelen estar activas.
• Valor: lo que han comprado: pedidos, gasto total y medio y RFM - recencia / frecuencia / valor monetario - .
• Perfil: país, antigüedad como cliente y canales por los que se les puede contactar - email / teléfono - .

Se prepara por sí solo. Como las personas entran en un recorrido de forma continua, un nodo Decisión con IA aprende mientras se ejecuta el recorrido. Las primeras entradas se distribuyen de manera justa mientras recopila datos, y las posteriores reciben enrutamiento personalizado automáticamente. No requiere más configuración que definir rutas y objetivo. Los límites de frecuencia y las horas de silencio no se configuran en este nodo: se aplican en los nodos de mensaje o envío y a nivel de espacio de trabajo, porque un nodo de decisión solo enruta.

Envíos programados únicos: «Preparar antes del envío completo». Un recorrido programado para ejecutarse una vez para una audiencia fija no puede prepararse solo: todo el mundo entraría a la vez antes de que la IA hubiera visto un solo resultado. Para este caso, el nodo Decisión con IA incluye el interruptor Preparar antes del envío completo. El recorrido entrega primero a una pequeña muestra inicial de la audiencia, retiene al resto y después lo libera automáticamente con enrutamiento personalizado cuando el modelo ha aprendido las rutas - o tras el tiempo máximo de retención que definas - . Los recorridos activados continuamente no lo necesitan porque ya se preparan solos.

Cómo se reparte el crédito - multitoque - . Cuando una persona pasa por varios nodos de Decisión con IA en un recorrido y después convierte, el crédito se reparte entre esas decisiones, no se entrega por completo a la última. En un recorrido de varios pasos, las decisiones de enrutamiento anteriores también ayudaron a llegar al resultado. Las decisiones recientes reciben la mayor parte y las antiguas se desvanecen gradualmente - modelo de «decaimiento temporal» - . Un recorrido con una sola decisión acredita esa decisión íntegramente. Esto difiere de una campaña optimizada con IA, que es un envío único y acredita su única decisión más reciente: «último toque».

Nodos de actualizar usuario

Los nodos Actualizar usuario tienen dos tipos de fila; elige uno para cada fila:

Actualizar un atributo

Establece, incrementa, reduce, añade o elimina un valor de un atributo de usuario. Los atributos proceden del registro del espacio de trabajo: empieza a escribir para filtrar; no hay texto libre, así que primero define atributos nuevos en Configuración → Atributos. Las operaciones disponibles se filtran automáticamente según el tipo de atributo: solo inc / dec para números, append / remove para matrices, etc.

Registrar un evento

Activa un evento registrado para la persona desde Canvas. Es útil para marcar hitos del recorrido - completed_onboarding, abandoned_checkout - que otros Canvas o segmentos pueden escuchar. El campo de nombre de evento se autocompleta con los eventos registrados del espacio de trabajo, pero acepta texto libre para nombres nuevos.

Puedes añadir varias filas a un nodo Actualizar usuario; se aplican en orden. Arrastra el controlador para reordenarlas.

Casos de uso

• Etiquetar a personas que completaron un flujo: engagement_tag = 'onboarded'.
• Actualizar puntuaciones: engagement_score += 10.
• Registrar eventos de recorrido para segmentación posterior: Registrar evento: onboarding_completed.
• Definir indicadores para segmentación futura: feature_eligibility = true.

Nodos de webhook

Los nodos de webhook realizan llamadas HTTP a servicios externos.

Configuración

Configuración	Descripción
Método y URL	GET / POST / PUT / PATCH / DELETE y la URL del endpoint. La URL admite Liquid.
Autenticación	Ninguna / Bearer / Básica / Clave de API / Firmada (HMAC). Bearer, Básica y clave de API se convierten en el encabezado correcto al guardar - por ejemplo, Authorization: Bearer <token> - . Firmada - HMAC - añade el encabezado X-Joryio-Signature, un HMAC SHA-256 del cuerpo de solicitud, para que quien recibe pueda comprobar que la llamada procede de Joryio.
Encabezados personalizados	Filas clave/valor. Los valores admiten Liquid. Content-Type se añade por defecto y se puede anular.
Cuerpo de solicitud	JSON, codificado como formulario - application/x-www-form-urlencoded - o Ninguno. El cuerpo JSON se valida en línea mientras escribes.
Tratamiento de respuesta	Opcional: extrae un valor del cuerpo de respuesta - una ruta $.a.b, por ejemplo $.user.crm_id - a una variable de recorrido - por ejemplo, crm_id - para que un paso posterior pueda ramificar o usarlo en una plantilla. Para guardarlo en el usuario, añade un paso Actualizar usuario que lea la variable.
Reintentos y tiempo de espera	Máximo de reintentos y tiempo de espera de solicitud por nodo. La espera sigue siendo exponencial y los reintentos se activan con errores 5xx y de red; consulta Comportamiento de webhook abajo.
Llamada de sistema: omitir horas de silencio y límites de frecuencia	Desactivada de forma predeterminada: los webhooks esperan las ventanas de silencio y respetan límites de frecuencia como cualquier mensaje. Actívala solo para llamadas puras entre sistemas que no deben retrasarse por las horas de silencio de una persona. Las listas de supresión se aplican de cualquier forma y los destinatarios de webhook son perfiles activos facturables independientemente de esta opción.

Cuerpo enviado literalmente

El cuerpo que configuras se envía tal cual al receptor. No hay ningún sobre de Joryio que lo envuelva.

Si quieres incluir metadatos de canvas, ejecución o usuario en la solicitud, añádelos tú con Liquid:

{
  "event": "user_signup",
  "user_id": "{{ user.id }}",
  "email": "{{ user.email }}",
  "canvas_id": "{{ canvas.id }}",
  "execution_id": "{{ execution.id }}",
  "node_id": "{{ node.id }}"
}

Joryio también añade automáticamente tres encabezados de metadatos (para que el receptor pueda usarlos sin cambiar la forma del cuerpo):

X-Joryio-Canvas-Id: <canvas id>
X-Joryio-Execution-Id: <execution id>
X-Joryio-Node-Id: <node id>

Espacios de nombres de Liquid

Disponibles en la URL, los valores de encabezado y el texto del cuerpo JSON:

Espacio de nombres	Contiene
user.*	Campos de usuario de nivel superior (user.id, user.email, user.phone) y todos los atributos personalizados (user.firstName, user.plan, …).
event.* / trigger.*	La carga del evento de activación que inició esta ejecución.
canvas.*	canvas.id, canvas.name.
execution.*	execution.id, execution.startedAt.
node.*	node.id, node.type, node.label.

Las claves planas heredadas ({{ canvasId }}, {{ executionId }}) siguen resolviéndose.

Comportamiento de webhook

Un nodo de webhook se ejecuta en uno de dos modos, según esté activado o no el Tratamiento de respuesta:

Asíncrono (predeterminado: sin asignación de respuesta)

El canvas avanza inmediatamente después de poner el webhook en cola, sin esperar la respuesta HTTP. Es ideal para llamadas de disparar y olvidar (notificar a un CRM, iniciar una tarea posterior).

Síncrono (Tratamiento de respuesta activado)

Cuando asignas un campo de respuesta a una variable de recorrido, el nodo se ejecuta de forma síncrona: el recorrido se pausa en el nodo de webhook hasta que llega la respuesta (o hasta un tiempo de espera de 15 segundos), de modo que la variable esté lista para el siguiente paso. Es de fallo abierto: si hay tiempo de espera o error, el recorrido continúa igualmente (la variable queda sin definir; si conectaste una salida de error, el fallo se dirige allí). La ejecución queda aparcada (no retiene un worker), por lo que escala para audiencias grandes.

En ambos modos:

• Los fallos de webhook nunca detienen el flujo de Canvas (fallo abierto).
• Los webhooks asíncronos se reintentan ante errores 5xx y de red con espera exponencial, hasta el máximo de intentos del nodo. Las respuestas 4xx fallan de inmediato y no se reintentan; las 429 respetan el encabezado Retry-After.
• Los webhooks síncronos fallan rápido (sin bucle de reintento) para mantener el recorrido aparcado en movimiento; un endpoint que tarde más de 15 segundos agota el tiempo de espera y falla abierto. Una red de seguridad reanuda cualquier recorrido cuya respuesta se haya perdido, para que un contacto nunca quede aparcado para siempre.
• Un interruptor de circuito por host se activa tras fallos repetidos de salud del host (tiempos de espera, red o 5xx) hacia el mismo host y corta las llamadas posteriores durante un breve período de enfriamiento. Así, durante una caída del endpoint, las llamadas síncronas fallan abiertas al instante en lugar de esperar todas el tiempo completo, y no se sobrecarga un host caído. Se recupera automáticamente cuando el host vuelve a responder. (Los 4xx/429 no lo activan porque indican que el host está activo.)

Nodos de conector

Los nodos de conector sincronizan usuarios con audiencias de plataformas publicitarias externas durante la ejecución del canvas.

Configuración

Configuración	Descripción
Integración	Selecciona una integración conectada de sincronización de audiencias
Acción	Añadir a audiencia, Eliminar de audiencia o Sincronizar audiencia
Audiencia	Audiencia objetivo en la plataforma externa

Plataformas compatibles

• Meta Ads (Custom Audiences)
• Google Ads (Customer Match)
• TikTok Ads (Custom Audiences)
• LinkedIn Ads (Matched Audiences)
• Criteo Ads (Contact Lists)

Comportamiento del conector

Procesamiento asíncrono

Las acciones del conector se ponen en cola y se procesan de forma asíncrona. El canvas avanza inmediatamente después de poner la acción en cola. Las acciones fallidas se reintentan hasta tres veces con espera exponencial.

Los datos de usuario (email, teléfono e ID externo) se someten a hash según los requisitos de cada plataforma antes de enviarse.

Nodos de salida

Los nodos de salida terminan el flujo de Canvas para un usuario.

Motivos de salida

Motivo	Descripción
Objetivo alcanzado	El usuario completó la acción deseada
Canceló la suscripción	El usuario se dio de baja
Ya no cumple los requisitos	El usuario ya no cumple los criterios
Salida manual	Finalización explícita del flujo

Orden de procesamiento

Cuando varios usuarios entran simultáneamente en un canvas:

1. Los workers de Canvas procesan a los usuarios en paralelo.
2. La ruta de cada usuario es independiente.
3. El envío de mensajes se distribuye en colas específicas por canal.
4. Los escenarios de gran volumen (más de un millón de usuarios) se gestionan eficientemente.

Variables de plantilla de comercio electrónico

Al enviar mensajes desde Canvas, los datos de comercio electrónico están disponibles automáticamente para personalización.

Datos del carrito

Variable	Descripción
{{ cart.items }}	Matriz de artículos del carrito
{{ cart.itemCount }}	Número total de artículos
{{ cart.value }}	Valor total del carrito
{{ cart.currency }}	Código de moneda (USD, EUR, etc.)
{{ cart.checkoutUrl }}	URL para reanudar el checkout
{{ cart.abandoned }}	Si el carrito está abandonado

Ejemplo: email de carrito abandonado

<h2>¡Has dejado artículos en el carrito!</h2>

{% for item in cart.items %}
<div style="margin: 10px 0;">
  <img src="{{ item.imageUrl }}" width="80" />
  <strong>{{ item.name }}</strong>
  <span>${{ item.price }} x {{ item.quantity }}</span>
</div>
{% endfor %}

<p><strong>Total: ${{ cart.value }}</strong></p>

<a href="{{ cart.checkoutUrl }}" style="background: #007bff; color: white; padding: 12px 24px;">
  Completa tu compra
</a>

Campos de artículos del carrito

Cada artículo de cart.items contiene:

Campo	Descripción
productId	Identificador del producto
name	Nombre del producto
price	Precio unitario
quantity	Cantidad en el carrito
total	precio × cantidad
imageUrl	URL de imagen del producto
sku	SKU del producto
variantId	Identificador de variante

Contenido relacionado

• Crear un Canvas
• Ramificación de Canvas
• Analítica de Canvas