Un código QR, varios destinos: reglas de redirección y test A/B

Un código QR impreso tiene un solo patrón, pero quienes lo escanean no son un único público. La mitad lleva iPhone y la otra Android. Unos leen alemán, otros italiano. Quien escanea el cartel de tu cafetería a las 9:00 quiere desayuno; a las 21:00 quiere la carta de cócteles. Las reglas de redirección permiten que un solo código responda distinto, decidido en el momento del escaneo.

Cómo se evalúa

Las reglas son una lista corta y ordenada. En cada escaneo se comprueban de arriba abajo y gana la primera que coincide: las siguientes ni se miran. Si ninguna coincide, decide un reparto A/B ponderado opcional. Si tampoco lo hay, el visitante va al destino por defecto del código.

Ese orden es todo el modelo mental: una regla amplia colocada encima de una específica se la come. «Todo móvil → página de la app» encima de «Android → Play Store» significa que la regla de Play Store nunca se dispara. Lo específico arriba, el comodín abajo.

Las tres condiciones

Dispositivo

Coincidencia por sistema operativo (iOS, Android, Windows, macOS…) y/o tipo de dispositivo (móvil, tableta, escritorio). El uso obvio son las descargas de apps, aunque para un reparto puro entre tiendas existe un tipo de código App Store propio que enruta iOS y Android automáticamente sin reglas.

La regla de dispositivo gana valor de forma más sutil: manda los escaneos de escritorio (alguien fotografió el código y lo abrió luego en el portátil) a una página completa, y los móviles a una ligera. O las tabletas a una carta pensada para pantalla grande.

Un detalle: una regla de dispositivo sin sistema ni tipo seleccionados no coincide con nada. Vacío significa «sin filtro», no «todo».

Idioma

Coincidencia con la preferencia de idioma del navegador, con códigos de dos letras. Un escaneo cuyo navegador pide de-AT coincide con una regla para de. Para un producto multilingüe es la regla más útil que hay: un código en el envase y cada cliente aterriza en documentación que puede leer.

El idioma no es la ubicación. Refleja cómo está configurado el teléfono, no dónde está. Una turista ucraniana en Roma obtiene la página en ucraniano del código del museo: normalmente justo lo que quieres, y muy distinto de lo que haría una regla por país.

Hora

Coincidencia por días de la semana y una franja horaria. La franja es semiabierta —11 a 15 cubre de 11:00 hasta las 15:00 sin incluirlas—, así que franjas consecutivas se escriben sin solaparse.

Las horas son UTC. Esta es la trampa de toda la función. Si tu cafetería está en Madrid y quieres la carta del mediodía de 11:00 a 15:00 locales, en verano configuras 09:00–13:00 UTC y en invierno 10:00–14:00. El cambio de hora desplazará tu regla dos veces al año en silencio, así que merece un recordatorio en el calendario. Los días van de 0 para domingo a 6 para sábado, también en UTC: cerca de medianoche el día UTC no es tu día local.

Test A/B

En lugar de enrutar por atributo puedes repartir tráfico por peso entre hasta diez destinos. Los pesos son relativos, no porcentajes: 3 y 1 manda unas tres cuartas partes a un lado. Dos destinos a 50 y 50 es el simple cara o cruz.

Dos límites honestos que conviene tener en cuenta al diseñar:

• El reparto no es persistente. Cada escaneo se sortea de forma independiente, así que la misma persona escaneando dos veces puede ver ambas variantes. Para probar un titular está bien; para cualquier flujo donde quien vuelve deba encontrar lo mismo —un proceso de compra, un formulario a medias— no.
• La medición es cosa tuya. La analítica de escaneos dice cuánta gente escaneó en total, no a qué variante fue. Dale a cada variante sus parámetros UTM o URLs distintas y lee la conversión en tu propia herramienta.

Como el patrón impreso no cambia nunca, el test también se puede hacer despacio: dos semanas todo a la variante A y luego dos semanas a la B. Menos piezas móviles y ningún problema de persistencia; solo más lento y sensible a la estacionalidad.

A qué se aplican las reglas

Las reglas se evalúan en códigos URL y PDF, los dos tipos donde «el destino» es un enlace que puede variar razonablemente según el visitante. Un código de Wi-Fi o una vCard resuelven en su propia página y no tienen nada que enrutar. Si necesitas comportamiento condicional, construye el código como tipo URL apuntando a páginas que controles.

Los límites son lo bastante amplios para no pensar en ellos: hasta 20 reglas y 10 destinos A/B por código. Las reglas de redirección son una función de los planes Pro y Business.

Recetas que de verdad se usan

• Atril de restaurante: reglas horarias para desayuno, comida y cena, con la carta como destino por defecto fuera de esas franjas. Un código impreso para toda la vida de la mesa.
• Envase multilingüe: reglas de idioma para tus mercados principales, inglés por defecto. Instrucciones en el idioma del cliente sin imprimir cinco etiquetas.
• Señalética de eventos: antes de abrir, el programa; durante, el horario en vivo; a la mañana siguiente, un formulario de opinión. Las reglas horarias lo hacen sin que nadie cambie carteles.
• Estand de feria: escritorio a un informe, móvil a un formulario corto: de pie nadie rellena un formulario largo.
• Test de titular en cartel: dos páginas con el mismo peso, UTM distintos, decidir a las dos semanas.

Errores que cuestan escaneos

• Regla amplia por encima de la específica. Gana la primera coincidencia; el orden es la lógica.
• Olvidar el destino por defecto. Atiende a todos los que tus reglas no describen y siempre debe llevar a algún sitio con sentido.
• Hora local en vez de UTC. El fallo más común, y falla en silencio: el código funciona, solo sirve lo equivocado durante unas horas.
• Reglas que nadie puede verificar. Prueba cada rama: cambia el idioma del móvil, escanea desde un navegador de escritorio y, si hay regla horaria, espera la franja o muévela temporalmente a ahora.
• Probar sin métrica. Un reparto A/B sin UTM y sin objetivo de conversión da dos números que no puedes comparar.

Lo que aquí las reglas no pueden hacer, dicho claro: no hay segmentación geográfica. Las condiciones son dispositivo, idioma del navegador y hora; ni país, ni región, ni ciudad. De todos modos el idioma es la mejor aproximación, porque sigue a la persona y no a la tarjeta SIM.

Con Enqre defines las reglas en el editor del código. Se evalúan en el orden en que las añadiste y todavía no hay reordenación arrastrando: añade primero los casos específicos, o borra y vuelve a crear para cambiar el orden. Cada escaneo se registra por la rama que haya tomado.

Preguntas frecuentes

¿Puede un código QR llevar a páginas distintas?

Sí, con un código dinámico y reglas de redirección. El destino se decide al escanear según el dispositivo, el idioma del navegador o la hora, así que un patrón impreso sirve a varios públicos.

¿Puedo segmentar por país o ciudad?

En Enqre no. Las reglas solo miran dispositivo, idioma del navegador y hora: no hay geolocalización en ninguna parte del producto. Para la mayoría de casos el idioma del navegador es mejor señal, porque acompaña al visitante y no a la red.

¿El test A/B recuerda qué variante vio alguien?

No. Cada escaneo es un sorteo ponderado independiente, así que un segundo escaneo puede caer en la otra variante. Úsalo para probar contenido, no para flujos donde importa la coherencia entre visitas.

¿Por qué mi regla horaria se activó a la hora equivocada?

Las horas son UTC. Convierte desde tu hora local y recuerda que el cambio de hora desplaza el desfase dos veces al año.

¿Qué tipos de código admiten reglas?

URL y PDF. Los demás resuelven en sus propias páginas y no tienen un destino alternativo al que enrutar.