# Ramas

Cómo los pasos de bifurcación llevan a cada contacto por una rama según etiqueta, lista, segmento, atributo, evento, consentimiento, alcance o un reparto A/B al azar.

**Language:** es
**Audience:** platform
**TLDR:** Un paso de bifurcación lleva a cada contacto por la primera rama que cumple, de arriba abajo; quien no cumple ninguna toma la última, la rama por defecto (El resto o En caso contrario). Se puede bifurcar por etiqueta, lista, segmento, atributo del contacto, el evento de entrada, un evento que hizo el contacto, la política de consentimiento, el alcance del canal o un Test A/B por porcentaje. Al terminar su rama, el contacto sigue por lo que hay debajo de la bifurcación.
**Translation key:** platform.automations.flows.branches
**Search keywords:** condición, condicional, si/si no, si entonces, enrutar, repartir contactos, decisión, rama por segmento, rama por etiqueta, rama por atributo, rama por consentimiento, test A/B, prueba A/B, reparto por porcentaje, reparto aleatorio, sin móvil, mensaje para VIP, mensaje por país, flujo
**Related pages:** /platform/en/automations/flows/branches, /platform/es/automations/flows, /platform/es/automations/flows/building-a-flow, /platform/es/automations/flows/waits, /platform/es/automations/flows/sending-messages, /platform/es/automations/flows/contact-updates, /platform/es/automations/flows/flow-analytics, /platform/es/audience/segments, /platform/es/campaigns/compliance-policies, /platform/es/consent
**Docs index (every page):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt
**This zone's index:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/llms.txt
**This page:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/branches/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/branches.md (Markdown)
**Other language (en):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/branches.md

Una bifurcación es el paso que permite que dos contactos del mismo flow vivan recorridos
distintos. Cuando un contacto llega a ella, el paso mira algo sobre él —una etiqueta, un
segmento, un campo de su ficha, el pedido con el que entró, su consentimiento, si un
canal puede llegar a él— y lo lleva por una **rama**, el camino de pasos preparado para
contactos como él. Un cliente de España recibe el mensaje en español, un VIP recibe la
oferta VIP y un contacto que rechazó el marketing recibe una etiqueta en lugar de una
promoción. La decisión es instantánea: el contacto no espera en la bifurcación, y el paso
en sí nunca envía nada.

El panel agrupa estos pasos en **Bifurcar el flow**, dentro de la paleta de pasos, y son
nueve. Ocho deciden según una condición y uno, el **Test A/B**, reparte al azar por
porcentaje. Todos siguen las mismas reglas, que se explican primero; después cada uno
tiene su propia sección. Algunas esperas también tienen varias salidas —la **Espera por
zona horaria** y la **Espera inteligente**, según si encontraron un momento permitido; la
**Espera de entrega**, según si llegó el mensaje, y la **Espera de actividad**, según un
clic, una respuesta o un evento— y se explican en [Esperas](/platform/es/automations/flows/waits).

## Cómo funcionan las ramas

Cada paso de bifurcación se configura en su panel de ajustes, en **Ramas**, con **Añadir
rama** al final. Cada rama lleva una condición, y el panel recuerda la regla que las
gobierna a todas: *Los contactos toman la primera rama que cumplen, de arriba abajo.*

| Paso                           | Qué mira                                             | Rama por defecto                                                   |
| ------------------------------ | ---------------------------------------------------- | ------------------------------------------------------------------ |
| **Según etiqueta**             | Las etiquetas del contacto                           | **El resto**                                                       |
| **Según lista**                | Las listas a las que pertenece                       | **El resto**                                                       |
| **Según segmento**             | Los segmentos en los que está                        | **El resto**                                                       |
| **Según atributo**             | Cualquier campo de su ficha                          | **En caso contrario**                                              |
| **Según el evento de entrada** | Los datos del evento que inició el flow              | **En caso contrario**                                              |
| **Según evento**               | Si el contacto hizo un evento                        | **En caso contrario**                                              |
| **Según consentimiento**       | Si el contacto cumple una política de consentimiento | Dos salidas fijas: **Con consentimiento** / **Sin consentimiento** |
| **Según alcance**              | Si un canal puede llegar al contacto                 | **En caso contrario**                                              |
| **Test A/B**                   | Nada: un sorteo por porcentaje                       | La última parte del reparto                                        |

### Gana la primera rama que se cumple

Las ramas se evalúan en orden, de la primera de la lista a la última, y el contacto toma
la **primera** cuya condición cumple. Las siguientes ya no se miran, aunque también las
cumpliera. Por eso cada contacto toma exactamente una rama.

El orden es la manera de fijar la prioridad. En una bifurcación por etiqueta con una rama
**Uno de: vip** encima de otra **Uno de: newsletter**, un VIP que también está en la
newsletter va por la rama VIP. Si se intercambian, ese mismo contacto sigue el camino de
la newsletter. Cuando dos condiciones pueden solaparse, conviene poner arriba la más
específica o la que más importa.

### La rama por defecto

Debajo de las ramas que añades siempre hay una más: la **rama por defecto**, que el panel
describe como *Se toma cuando ninguna rama anterior cumple.* Es la que garantiza que todo
contacto sale de la bifurcación, también los que no habías previsto. Siempre es la última:
no se puede mover, eliminar ni ponerle condición, pero sí renombrar. Su nombre depende del
paso: **El resto** en Según etiqueta, Según lista y Según segmento, y **En caso
contrario** en Según atributo, Según el evento de entrada, Según evento y Según alcance.

Dejar vacía la rama por defecto es una opción perfectamente válida: quien la toma pasa
directamente a lo que haya después de la bifurcación.

### Añadir, ordenar y nombrar ramas

- **Añadir rama** añade una rama al final de la lista, justo encima de la rama por
  defecto. Una bifurcación admite hasta **10** ramas más la rama por defecto, y al menos
  una.
- **Ordenar**: se arrastra la rama por su asa o se usan **Subir** y **Bajar** en su menú.
- **Renombrar rama**, en ese mismo menú, pide un **Nombre de la rama**. Si se deja vacío,
  vuelve el título automático.
- **Eliminar** quita la rama junto con los pasos que haya dentro; el menú desactiva la
  opción cuando solo queda una rama. **Deshacer**, en la barra del editor, la recupera.

Una rama sin nombre toma un título automático a partir de su condición: **Uno de: vip** o
**Ninguno de: vip** en Según etiqueta, Según lista y Según segmento, el nombre del evento
en Según evento, los estados que abarca en Según alcance (**Alcanzable / Desconocido**) y
**Rama 1**, **Rama 2**… en el resto de casos. Entre ellos está Según atributo, donde una
rama para *País es España* se sigue llamando **Rama 1** hasta que se renombra. El mismo
título aparece en la etiqueta de la rama en el lienzo.

Una rama que nunca puede cumplirse impide publicar: una rama de Según etiqueta, Según
lista o Según segmento sin ningún valor, una de Según atributo o Según el evento de
entrada sin condición, una de Según evento sin evento o una de Según alcance sin ningún
estado. El borrador se puede guardar igualmente, y el problema aparece en **Corrige tu
flow para publicarlo** (ver
[Crear un flow](/platform/es/automations/flows/building-a-flow#corrige-lo-que-impide-publicar)).

### Después de su rama, el contacto sigue debajo de la bifurcación

Una rama es un desvío, no un final aparte. Cuando un contacto llega al final de su rama,
sigue por lo que haya **debajo de la bifurcación**, donde se unen todas sus ramas; esa
unión no se dibuja. Cómo se ve en el lienzo, y dónde inserta un paso cada **+**, se explica en
[Crear un flow › Bifurcaciones, ramas y dónde cae un paso](/platform/es/automations/flows/building-a-flow#bifurcaciones-ramas-y-dónde-cae-un-paso).

Para que la ejecución termine dentro de una rama, se pone un paso **Salir del flow** al
final de ella: la ejecución del contacto termina ahí y no sigue por debajo de la
bifurcación (ver [Objetivos y salidas](/platform/es/automations/flows/goals-and-exits)).

### Cómo de recientes son los datos

Las ramas deciden con lo que Instasent sabe del contacto en ese momento:

- **Según etiqueta**, **Según lista**, **Según consentimiento** y **Según alcance** leen
  el contacto tal como está en ese instante.
- **Según segmento**, **Según atributo** y **Según evento** pueden tardar unos segundos en
  reflejar un cambio muy reciente: un campo actualizado, o un evento recibido, en los
  segundos anteriores a que el contacto llegue a la bifurcación puede no verse todavía.
- **Una rama colocada justo después de un paso Actualizar etiquetas o Actualizar listas
  ve el valor de antes de esa actualización.** Si una bifurcación tiene que ver una
  etiqueta o una lista que el mismo flow acaba de añadir, hay que poner una espera entre
  los dos pasos (un minuto es el mínimo, y basta).

Los flows con el modo de procesamiento **Instantáneo** muestran un aviso parecido en los
ajustes del disparador: sin la breve ventana de procesamiento antes de entrar, las ramas
pueden no ver la actividad de los últimos segundos (ver
[El disparador: quién entra y cuándo](/platform/es/automations/flows/triggers-and-entry)).

### Saber por qué rama fue un contacto

El recorrido del contacto muestra cada paso por el que pasó la ejecución, con su nombre y
su estado, pero no dice qué rama tomó en una bifurcación. Se deduce por el paso
siguiente o, después de un mensaje, con **Ver el mensaje**. Por eso conviene poner a las
ramas, y a los pasos que contienen, nombres que signifiquen algo —«España», «Oferta
VIP»— en lugar de dejar **Rama 1** (ver
[Seguimiento de un flow](/platform/es/automations/flows/monitoring-a-flow)).

Una vez publicado el flow, el lienzo de la versión en vivo muestra cada rama con su
porcentaje de los contactos que ya han elegido una rama en ese paso (suman como máximo un
100 %). Ese porcentaje se calcula sobre ejecuciones, no sobre personas, así que un contacto que entró dos veces cuenta dos
(ver [Analítica de flows](/platform/es/automations/flows/flow-analytics)). Al probar un
borrador con un contacto, se puede fijar qué rama toma la prueba en cada bifurcación (ver
[Probar, publicar y versiones](/platform/es/automations/flows/versions-and-publishing)).

Las bifurcaciones no tienen coste propio: solo se facturan los mensajes que envía el flow
(ver [Enviar mensajes](/platform/es/automations/flows/sending-messages)).

## Por etiqueta, lista o segmento

**Según etiqueta**, **Según lista** y **Según segmento** deciden según aquello a lo que
pertenece el contacto. Son la forma más rápida de dar a un grupo su propio camino: los
clientes VIP, los miembros de una lista «mayoristas», los contactos de un segmento
«Compraron en los últimos 90 días».

Cada rama tiene dos partes:

- Un modo: **es una de** (el que viene por defecto) se cumple si el contacto tiene **al
  menos uno** de los valores; **no es ninguna de**, si no tiene **ninguno**.
- Los valores: etiquetas (**Elige etiquetas o escribe una nueva**), listas (**Elige listas
  o escribe una nueva**) o segmentos (**Elige segmentos**). Las etiquetas y las listas se
  pueden escribir aunque todavía no las tenga ningún contacto, algo útil cuando otro paso u
  otro flow va a añadirlas. Los segmentos tienen que existir ya.

La rama por defecto es **El resto**.

Las etiquetas y las listas se comprueban sobre el contacto tal como está en ese momento.
Un segmento es una vista dinámica sobre tu audiencia que se actualiza a medida que cambian
los datos de los contactos (ver [Segmentos](/platform/es/audience/segments)), así que
Según segmento puede tardar unos segundos en reflejar un cambio muy reciente. Cuando una
condición es demasiado compleja para una sola rama —varios campos combinados con «o», por
ejemplo—, lo práctico es crear un segmento con ella y bifurcar con Según segmento.

## Por atributo del contacto

**Según atributo** decide según cualquier campo de la ficha del contacto: país, idioma,
ciudad, fecha de nacimiento, número de pedidos o un atributo propio de tu fuente de datos
(ver [Atributos y eventos](/platform/es/audience/attributes-events)). Sirve para las
diferencias que están en la ficha: un mensaje en el idioma del contacto, una oferta
distinta por país o un camino para quien ya ha comprado antes.

Cada rama lleva una o varias condiciones, que se añaden con **Añadir condición**, cada
una con un campo, un operador y un valor. Dentro de una rama
las condiciones se combinan con **Y**: el contacto tiene que cumplirlas todas. No hay
grupos con «o» dentro de una rama; para aceptar cualquiera de dos condiciones, se añade
una segunda rama, o se crea un segmento y se usa Según segmento. Toda rama necesita al
menos una condición, y la rama por defecto es **En caso contrario**.

Las ramas sin nombre se llaman **Rama 1**, **Rama 2**… diga lo que diga su condición, así
que conviene renombrarlas: en el lienzo y en los informes, «España» dice mucho más que
**Rama 1**.

### Ejemplo: una bienvenida por país y para los VIP

Una tienda quiere que cada contacto nuevo reciba un SMS de bienvenida en su idioma, con
uno especial para los clientes VIP. El flow *Bienvenida por país* empieza con **Contacto
creado / actualizado**, una sola vez por contacto:

1. Un paso **Según atributo** con una rama, renombrada «España», para *País es España*.
   Dentro, un SMS en español.
2. En la rama **En caso contrario**, un paso **Según etiqueta** con una rama **es una de**
   `vip`, que lleva el SMS para VIP. Su rama **El resto** lleva el SMS genérico.
3. Debajo de la primera bifurcación, donde se unen todas las ramas, un paso **Actualizar
   etiquetas** añade `bienvenida-enviada`.

```mermaid
flowchart TD
    T["Disparador: Contacto creado / actualizado"] --> A{"Según atributo"}
    A -->|España| ES["Enviar SMS en español"]
    A -->|En caso contrario| V{"Según etiqueta"}
    V -->|"Uno de: vip"| VIP["Enviar SMS para VIP"]
    V -->|El resto| G["Enviar SMS genérico"]
    ES --> U["Actualizar etiquetas: añadir bienvenida-enviada"]
    VIP --> U
    G --> U
```

Un contacto de España recibe el SMS en español aunque sea VIP, porque la rama del país va
primero. Un VIP de fuera de España recibe el SMS para VIP, y todos los demás, el
genérico. Cada contacto recibe un solo mensaje, y todos acaban con la etiqueta
`bienvenida-enviada`, para lo que basta un único paso debajo de la bifurcación. Para que
los VIP de España tengan su propio mensaje, se añade también un paso Según etiqueta dentro
de la rama «España».

![Un flow que bifurca por país y luego por la etiqueta VIP, con un mensaje en cada rama](/platform/es/automations/flows/images/branches--1-split-canvas.png)
*Tras su rama, cada contacto sigue debajo de la bifurcación.*

## Por el evento que inició el flow

**Según el evento de entrada** decide según los datos del evento que hizo entrar al
contacto en esta ejecución: el importe del pedido, el código de descuento usado o el
formulario que se envió. Sirve para tratar las entradas de forma distinta sin crear
varios flows sobre el mismo evento.

Cada rama lleva una o varias condiciones sobre los parámetros del evento disparador, que
se añaden con **Añadir condición** y se combinan con **Y**. Toda rama necesita al menos
una condición, y la rama por defecto es **En caso contrario**. Los datos son siempre los
del evento que inició *esta* ejecución, así que dos contactos que entraron con pedidos
distintos se reparten según su propio pedido.

Por ejemplo, en un flow *Gracias por tu pedido* sobre **Pedido creado**, una rama para los
pedidos de 100 o más puede enviar un agradecimiento con un código regalo, mientras que
**En caso contrario** envía el agradecimiento habitual.

Las condiciones de evento del propio disparador y este paso hacen trabajos distintos: las
del disparador deciden **quién entra** en el flow (ver
[El disparador: quién entra y cuándo](/platform/es/automations/flows/triggers-and-entry)),
mientras que Según el evento de entrada reparte a los contactos que ya han entrado.

## Por un evento que hizo el contacto

**Según evento** pregunta si el contacto ha hecho un evento —comprar, enviar un
formulario, hacer clic en una campaña— y decide según la respuesta. Cada rama tiene:

- `Fuente de datos` — default: `Cualquier fuente de datos`
  Limita la búsqueda a los eventos de una fuente de datos. Opcional.
- `Evento` — required
  El evento que se busca (**Selecciona un evento**). Una rama sin nombre se titula con
  el nombre del evento.
- `Solo desde que entró en el flow` — default: `activada`
  Cuenta solo los eventos que ocurrieron después de que el contacto entrara en esta
  ejecución del flow. Al desactivarla se mira también su historial anterior.
- `En los últimos … días` — default: `Cualquiera`
  Cuenta solo los eventos del número de días indicado. Vacío significa sin límite de
  tiempo.
- `Añadir condición de evento`
  Condiciones opcionales sobre los datos del evento, como un importe mínimo del pedido.

Cuando las dos opciones de tiempo están puestas, prevalece la más estricta: con **Solo desde
que entró en el flow** activada y 30 días, cuentan solo los eventos desde la entrada. Con
las dos sin poner, cuenta todo el historial del contacto. La rama por defecto es **En caso
contrario**, y los eventos muy recientes pueden tardar unos segundos en verse.

Según evento mira hacia atrás en ese momento y decide al instante; no espera a nada. Por
ejemplo, en un flow que empieza con **Producto visto**, un día después una rama para
**Pedido creado**, desde que entró en el flow, lleva un paso **Salir del flow** para
quienes ya han comprado, y **En caso contrario** envía a los demás un recordatorio del
producto. Para esperar a que el evento ocurra —y reaccionar en cuanto ocurra— se usa una
**Espera de actividad** con una rama **Hizo un evento** (ver
[Esperas › Espera de actividad](/platform/es/automations/flows/waits#espera-de-actividad)).

Con **Solo desde que entró en el flow**, el evento que inició la ejecución no cuenta. Para decidir según los datos de ese evento, usa **Comprobar evento de entrada**.

## Por consentimiento

**Según consentimiento** decide según si el contacto cumple una política de
consentimiento en un canal. Sirve para dar a los contactos que no han aceptado el
marketing un camino propio —una etiqueta, un mensaje por otro canal, el final del flow—
en lugar de una promoción.

Es la única bifurcación con ramas fijas. Como dice el panel, *Este paso siempre tiene dos
salidas:*

- **Con consentimiento** — el contacto cumple la política y puede recibir mensajes por
  este canal.
- **Sin consentimiento** — el contacto no cumple la política (dado de baja o sin
  consentimiento). El envío ya lo omite; usa esta salida para llevarlo a otro sitio.

Sus ajustes:

- `Canales` — default: `SMS`
  Los canales cuyo consentimiento se comprueba: SMS, RCS o los dos. Al menos uno.
- `Exigir consentimiento en` — default: `Todos los canales elegidos`
  Solo con dos canales seleccionados. **Todos los canales elegidos**: Con
  consentimiento solo si todos los canales permiten enviar al contacto. **Cualquiera de
  los canales**: Con consentimiento si al menos un canal lo permite.
- `Política de consentimiento` — default: `Opt-in`
  La política con la que se comprueba al contacto, una para todos los canales
  seleccionados: **Opt-in** (solo contactos que aceptaron marketing explícitamente),
  **Sin opt-out** (excluye a los contactos que rechazaron el marketing) o **Basic**
  (todos los contactos dados de alta, sin tener en cuenta sus preferencias de
  marketing).

Qué contactos deja pasar exactamente cada política, incluidos los que no tienen
registrada ninguna preferencia de marketing, se explica en
[Políticas de cumplimiento](/platform/es/campaigns/compliance-policies). El RCS usa el
consentimiento de SMS del contacto, así que comprobar RCS da la misma respuesta que
comprobar SMS (ver
[Consentimiento compartido (RCS y SMS)](/platform/es/consent/rcs-sms-shared-consent)).

> **Warning**: Según consentimiento **reparte**; no protege. Cada mensaje ya comprueba al contacto con
> **su propia** política de consentimiento al enviarse, haya o no este paso, y un mensaje
> nuevo empieza en **Basic**, que llega a los contactos que rechazaron el marketing pero
> nunca se dieron de baja. Según consentimiento empieza en **Opt-in**: son dos ajustes
> independientes, y un mensaje conserva su propia política esté en la rama que esté. Ver
> [Enviar mensajes › Quién lo recibe](/platform/es/automations/flows/sending-messages#quién-lo-recibe-la-política-de-consentimiento).

Según consentimiento mira la política, no si de verdad se puede llegar al contacto. Un
contacto que aceptó el marketing pero no tiene móvil sigue por **Con consentimiento**, y el
SMS que viene después no se le puede enviar. Para separar a esos contactos, se añade
también un paso **Según alcance**.

![Ajustes de Según consentimiento con sus dos salidas y la política Opt-in](/platform/es/automations/flows/images/branches--2-consent-branch.png)

### Ejemplo: una oferta solo para quien aceptó el marketing

El flow *Oferta de primavera* de [Enviar mensajes](/platform/es/automations/flows/sending-messages)
empieza cuando un contacto ve un producto (**Producto visto**). Primero va un paso
**Según consentimiento**, tal como viene (SMS, **Opt-in**):

- **Con consentimiento** → el SMS con el descuento.
- **Sin consentimiento** → un paso **Actualizar etiquetas** que añade
  `sin-consentimiento-marketing`.

Laura rechazó los SMS de marketing, pero nunca se dio de baja. Sigue por **Sin
consentimiento**: no recibe nada, se le añade la etiqueta y su ejecución termina con
normalidad. Un contacto que aceptó el marketing sigue por **Con consentimiento** y recibe
la oferta. Un contacto que aceptó el marketing pero no tiene móvil también sigue por
**Con consentimiento**; el SMS no se envía y, con el ajuste que trae el mensaje por
defecto, su ejecución se detiene en ese paso con el estado **Detenida**.

## Por alcance del canal

**Según alcance** decide según si un canal puede llegar al contacto, para reaccionar antes
de intentar el envío: etiquetar a los contactos que no tienen móvil, terminar el flow para
ellos o dar un camino distinto a los contactos cuyo teléfono admite RCS.

El paso trabaja con **un canal**, que se selecciona en **Canal**: SMS (el que viene por
defecto) o RCS. Cada rama selecciona uno o varios de estos tres estados:

| Estado            | SMS                                                      | RCS                                           |
| ----------------- | -------------------------------------------------------- | --------------------------------------------- |
| **Alcanzable**    | El contacto tiene un móvil válido.                       | Se sabe que su teléfono admite RCS.           |
| **Desconocido**   | No se da nunca: los contactos SMS nunca son Desconocido. | Todavía no se sabe si su teléfono admite RCS. |
| **No alcanzable** | El contacto no tiene un móvil válido.                    | Se sabe que su teléfono no admite RCS.        |

Un paso Según alcance nuevo empieza con una rama, **Alcanzable / Desconocido**, y la rama
**En caso contrario**, que en la práctica recoge a los **No alcanzable**. Los estados de
cada rama se pueden cambiar y se pueden añadir más ramas; toda rama necesita al menos un
estado.

Solo **No alcanzable** es definitivo; **Desconocido** significa que todavía no hay datos
concluyentes. El paso no decide si un mensaje se envía: un paso **Enviar mensaje** sigue
decidiendo por su cuenta al enviar, y un paso Enviar RCS con el SMS fallback activado
sigue enviando el SMS cuando el RCS no llega al contacto (ver
[SMS Fallback](/platform/es/channels/rcs/sms-fallback)). Según alcance sirve para crear
un camino distinto; el fallback es la red de seguridad dentro del mensaje.

Por ejemplo, un flow que empieza con Según alcance en SMS puede llevar a los contactos
**No alcanzable** a un paso **Actualizar etiquetas** que añade `sin-movil` y a un **Salir
del flow**, para que no lleguen a ningún mensaje, y dejar que los demás sigan. Según
alcance mira solo el canal, no el consentimiento: para comprobar las dos cosas, se
encadena con **Según consentimiento**.

## Test A/B

El **Test A/B** lleva a cada contacto por una rama **al azar**, según los porcentajes que
fijes. Sirve para comparar dos o más versiones de un mensaje —un 10 % de descuento frente
al envío gratis, un texto corto frente a uno largo— o dos caminos distintos, con contactos
reales.

Sus ajustes tienen una sola sección, **Reparto**, con la indicación *Los contactos se
reparten al azar según estos porcentajes. El resto va a la rama por defecto.*

- Un Test A/B nuevo empieza al **50 % / 50 %**: una variante y la rama por defecto.
- **Añadir variante** añade una rama que empieza en el 10 %, que se resta de las demás.
  Admite hasta **10** variantes más la rama por defecto, y al menos una variante.
- Cada variante tiene un control deslizante, en pasos de 1 %. Al mover uno, los demás se
  reajustan para que el reparto sume siempre 100 %, cada variante puede bajar hasta el **1 %** y la rama por defecto conserva al menos un **2 %**: al arrastrar una variante, se para donde la rama por defecto bajaría de ese mínimo, así que el reparto más desigual con una variante es 98 % / 2 %.
- La última rama, la de por defecto, *Recibe automáticamente el porcentaje restante.* No
  se puede fijar directamente.
- Las ramas se titulan con su porcentaje —en el lienzo, un reparto 50/50 muestra **50%**
  y **50%**— y no se pueden renombrar. Su orden da igual, porque el sorteo no depende de
  él.

El sorteo se hace en cada ejecución, en el momento en que el contacto llega al paso. Un
contacto que vuelve a entrar en el flow puede caer en otra rama la vez siguiente. Con
pocos contactos, el reparto real puede alejarse bastante del que fijaste; se acerca a
medida que pasan más contactos.

Para comparar los resultados, se pone un mensaje, o un camino, distinto en cada rama, se
publica y se leen las cifras de cada mensaje: en la versión en vivo, cada paso Enviar
mensaje muestra sus propias métricas, y el informe del flow las desglosa por mensaje (ver
[Analítica de flows](/platform/es/automations/flows/flow-analytics)). El Test A/B compara
caminos dentro de una versión del flow. Probar una versión nueva del flow entero con una
parte de los contactos es otra función, la prueba en real (ver
[Probar, publicar y versiones](/platform/es/automations/flows/versions-and-publishing)).

### Ejemplo: qué oferta de bienvenida funciona mejor

Una tienda quiere saber si los contactos nuevos responden mejor a un 10 % de descuento o
al envío gratis. En su flow de bienvenida, un **Test A/B** al 50 % / 50 % lleva en una rama
un SMS con el código de descuento y en la otra un SMS con el código de envío gratis. Cada
contacto nuevo recibe uno de los dos SMS, asignado al azar, nunca los dos. Al cabo de unas
semanas, las cifras de cada paso Enviar mensaje muestran qué oferta consiguió más clics;
la tienda se queda con el SMS ganador y quita la bifurcación en una versión nueva.

## Temas relacionados

- [Esperas](/platform/es/automations/flows/waits) - Bifurca según la entrega, un clic, una respuesta o un evento, con un límite de tiempo.
- [Actualizar el contacto](/platform/es/automations/flows/contact-updates) - Añade etiquetas y listas por las que bifurcar después.
- [Segmentos](/platform/es/audience/segments) - Crea los grupos por los que decide Según segmento.
- [Consentimiento y suscripciones](/platform/es/consent) - Preferencia de marketing, bajas y supresión.

---

This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt — start there for full context.