Smart Redirect Routing con geo, dispositivo, A/B y reglas condicionales
Un link de campaña puede necesitar destinos distintos por país, dispositivo, idioma, UTM, peso de experimento y fallback. Esta guía muestra cómo ordenar esa lógica sin esconderla en el código.
Un redirect es sencillo cuando todos los clics deben terminar en la misma página. En campañas reales de México, Colombia, Chile, Argentina o Perú, esa suposición se rompe rápido.
Un clic desde México puede necesitar una oferta en pesos mexicanos. Colombia puede tener otra disponibilidad. Argentina puede requerir un mensaje distinto por stock o pagos. Un usuario en iPhone puede necesitar App Store; Android, Google Play; desktop, una landing web. WhatsApp, Instagram, QR, email, afiliados y paid media deben conservar UTMs, cupones o IDs. Si hay una prueba A/B, el usuario no debería saltar de variante en variante.
Eso es Smart Redirect Routing: un link público con una política de ruteo, no una sola URL de destino.
UrlEdge permite publicar esa política en el edge. Puedes combinar país, dispositivo, idioma, query, header, cookie, campaña, pesos A/B y fallback, con analítica y rollback. La idea no es hacer links "inteligentes" por moda. La idea es no perder tráfico, atribución ni control cuando los equipos de growth, ecommerce, producto y desarrollo tocan el mismo link.
Un link de campaña suele tener varias rutas
En LATAM, la lógica se suele repartir así:
- geo redirect en una regla del CDN
- mobile redirect dentro del sitio
- test A/B con un script de terceros
- UTMs manejados por la landing
- links de WhatsApp o Instagram editados a mano
- fallback decidido en una hoja de cálculo
El problema aparece cuando una campaña cambia de país, una app cambia su fallback, un marketplace pide otro destino o una agencia necesita revisar la regla antes de publicar.
Una política de routing debe dejar claro:
| Pregunta | Por qué importa |
|---|---|
| ¿Qué fuente entra? | Dominio, path, wildcard, regex, slug, QR o link corto |
| ¿Qué contexto cuenta? | País, dispositivo, idioma, sistema operativo, query, header, cookie o referrer |
| ¿Qué regla gana? | Seguridad, campaña exacta, dispositivo, país, A/B o fallback |
| ¿A dónde va? | Tienda local, app store, landing, soporte, bloqueo o fallback |
| ¿Cómo se divide? | Pesos A/B, rollout gradual, variantes de campaña o canary |
| ¿Qué se preserva? | Path, query, UTM, ID de afiliado, cupón o sub ID |
| ¿Cómo se revierte? | Snapshot anterior, fallback, campaña pausada o owner notificado |
Sin esa política, el link funciona hasta que deja de funcionar y nadie sabe por qué.
Geo routing: país correcto, no redirect automático
La redirección geográfica tiene valor cuando mejora la intención del usuario. No debe usarse para empujar a todos a una versión local sin pensar.
| Caso | Mejor comportamiento |
|---|---|
| Ecommerce regional | Enviar a catálogo, moneda, disponibilidad y envío correctos |
| Campañas por país | Mantener México, Colombia, Chile, Perú o Argentina en la oferta aprobada |
| Producto no disponible | Waitlist, distribuidor local o mensaje claro |
| Restricción legal | Política explícita de permitido, bloqueado o fallback |
| Soporte y contenido | Idioma local solo si la página existe y se mantiene |
El país puede leerse en el edge. Cloudflare Workers, por ejemplo, expone metadatos de la request con request.cf, incluyendo país. Pero la detección no reemplaza el criterio. Para SEO, hay que evitar patrones que parezcan cloaking, conservar una alternativa global cuando tenga sentido y usar canonicals con cuidado.
Routing por dispositivo: app, web, QR y redes sociales
En campañas de WhatsApp, Instagram, TikTok, email o QR, un mismo link se abre en contextos muy distintos.
| Contexto | Destino recomendado |
|---|---|
| iOS | Universal Link si está listo; si no, App Store o web móvil |
| Android | Android App Link; si no, Google Play o web móvil |
| Desktop | Landing web, formulario o QR para continuar en móvil |
| Tablet | Muchas veces web desktop, salvo app tablet real |
| Navegador in-app | Bridge page si el webview rompe el deep link |
| Dispositivo desconocido | Página web estable antes que salto fallido a una app |
Después de Firebase Dynamic Links, muchos equipos necesitan hacerse cargo de esta capa. UrlEdge puede manejar device routing y fallback; abrir la app nativa sigue dependiendo de Universal Links y Android App Links bien configurados.
A/B testing con redirects: útil cuando cambia la landing
Un split por redirect tiene sentido cuando lo que cambia es el destino:
- landing A vs landing B
- oferta local vs oferta global
- pricing nuevo para un porcentaje bajo
- rollout canary de un nuevo storefront
- rotación de páginas de partners o afiliados
No reemplaza una suite completa de experimentation. Si necesitas eventos finos, segmentos profundos o cambios dentro de la app, usa una herramienta dedicada. UrlEdge divide tráfico antes de que cargue la página.
| Decisión | Buen default |
|---|---|
| Código HTTP | 302 o 307 porque el test es temporal |
| Consistencia | Mantener la misma variante durante la ventana del test |
| SEO | No mostrar a Googlebot una experiencia distinta a usuarios |
| Canonical | Claridad si las variantes tienen URLs separadas |
| Duración | Cerrar el test; no dejar splits antiguos vivos |
| Rollout | Subir de 10/90 a 25/75 o 50/50 solo si todo sigue sano |
Google recomienda evitar cloaking en pruebas y usar redirects temporales cuando la URL original manda a una variación. Eso encaja con 302 y splits ponderados.
Las condiciones necesitan prioridad
La lista de condiciones no basta. El orden decide el resultado.
| Prioridad | Condición | Ejemplo |
|---|---|---|
| 1 | Seguridad o legal | País no atendido va a página de indisponibilidad |
| 2 | Override de campaña | ?campaign=partner respeta su landing |
| 3 | Dispositivo u OS | iOS, Android y desktop tienen fallbacks propios |
| 4 | País o idioma | México, Colombia, Chile, Argentina o global |
| 5 | Peso A/B | Solo tráfico elegible entra al split |
| 6 | Fallback | Todos los demás van a un destino estable |
Si el orden está mal, el A/B puede tomar tráfico que debía excluirse, una regla móvil puede borrar un ID de afiliado o una regla de país puede mandar paid traffic a una página sin UTMs.
Los UTMs también son routing
Smart routing falla mucho en los detalles de query string.
Growth necesita utm_source, utm_medium, utm_campaign, click IDs, cupones, IDs de afiliado y sub IDs. Ecommerce puede necesitar moneda, locale, producto o colección. Producto puede necesitar contexto de onboarding.
| Política | Cuándo usarla |
|---|---|
| Preservar todo | Fuente confiable y atribución completa |
| Allowlist | UTMs, click IDs y afiliados sin ruido extra |
| Agregar defaults | Estandarizar campaña o canal en destino |
| Eliminar todo | Destino sensible o link público no confiable |
| Reescribir | Un parámetro define path o destino |
La atribución se puede romper en el redirect, antes de que analytics vea la visita. Por eso debe ser parte de la regla.
QA antes de mandar tráfico real
Cada condición multiplica las rutas posibles.
Prueba:
- países principales y fallback
- iOS, Android, desktop, tablet y desconocido
- URLs con y sin UTMs
- paid, orgánico, afiliados, QR, WhatsApp e Instagram
- primera visita y visita recurrente en A/B
- status final y hops
- prioridad de reglas y fallback
- analítica por país, dispositivo, regla, acción y destino
- rollback al snapshot anterior
La meta: para una URL y un contexto, el equipo debe predecir el destino antes de publicar.
Dónde entra UrlEdge
UrlEdge encaja cuando una redirección tiene más de un destino y más de un responsable:
- Smart Redirect Routing para publicar, medir y revertir reglas
- Geo Redirects para países y regiones
- Device Targeting para app, stores, móvil, tablet y desktop
- A/B Testing para splits y rollouts
- Advanced Redirect Rules para wildcards, regex y condiciones
- UTM Builder para atribución
- Redirect Checker para QA
- Broken Link Monitor para destinos que cambian después
FAQ
¿Qué es Smart Redirect Routing?
Es dirigir una misma URL pública a distintos destinos según país, dispositivo, idioma, parámetros, campaña, peso A/B y fallback.
¿Es igual a una redirección geográfica?
No. Geo redirect es una condición. Smart routing combina geo, dispositivo, idioma, query, header, cookie, A/B y fallback dentro de una regla gobernada.
¿Un A/B test por redirect usa 301 o 302?
Normalmente 302, porque el test es temporal. Usa códigos permanentes solo para cambios permanentes.
¿Reemplaza una herramienta de experimentation?
No. Sirve para tests de landing, variantes de campaña y canary releases. No reemplaza experimentación profunda dentro de producto.
Referencias
Crea reglas de smart routing en el edge
Dirige clics por país, dispositivo, idioma, parámetros, peso A/B y fallback sin enterrar la lógica en el sitio.
Explorar smart routingArtículos relacionados
Ver todo
API de redirecciones y reglas como código: CI/CD para cambios de URL más seguros
Las redirecciones son configuración de tráfico en producción. Deben revisarse, validarse, probarse, publicarse, medirse y poder revertirse.
Geo redirects para ecommerce: tiendas por país, moneda, idioma y fallbacks SEO-safe
Redirigir por país ayuda a llevar compradores a la tienda correcta, pero también puede esconder páginas locales si la regla es demasiado agresiva.