Variantes

Registro, campo y entrada

En un modelo con las variantes activadas, un registro tiene un valor por defecto y puede tener varias variantes. Una variante a nivel de registro reemplaza todo el contenido del registro y tiene su propio estado de publicación e historial de versiones. Una variante a nivel de campo sobrescribe un campo para un público y deja el resto del registro como está. Dentro de un campo de prosa o una lista, una entrada o un elemento individual pueden variar por sí solos.

La segmentación viene del catálogo

A quién va dirigida una variante lo determina una entrada del catálogo de variantes: un conjunto de reglas de segmentación con nombre, reutilizable y con una prioridad. Editar una entrada redirige todas las variantes que la referencian. Las reglas leen dimensiones de contexto y segmentos.

Cómo elige el servidor

Las reglas de cada variante se evalúan contra la petición y, de las que coinciden, gana la de mayor prioridad en el catálogo. Un empate lo gana la variante por defecto del registro. Cuando ninguna variante puede servirse, se devuelve el contenido propio del registro.

Lo que aporta quien llama y lo que deduce el servidor

Una lectura pasa su contexto con contexts como argumento: dispositivo, plataforma, locale y cualquier dimensión personalizada que hayas definido. Una dimensión que quien llama omite queda ausente, así que una regla que la comprueba no coincide.

El estado de inicio de sesión, la pertenencia a segmentos y los datos de perfil de un usuario nunca se toman de quien llama. El servidor los deduce a partir del token del usuario con sesión iniciada e ignora una petición que intente enviarlos.

Lo que se devuelve

Los valores de la variante ganadora llegan combinados sobre los campos ordinarios del registro, y _variant nombra la variante que se sirvió. Una respuesta que contiene un registro resuelto por variante se marca como privada, para que una caché compartida no la almacene.