Smart Redirect Routing com geo, dispositivo, A/B e regras condicionais

Redirect parece simples quando todo clique deve cair na mesma página. Em operação de ecommerce, mídia paga, WhatsApp, Instagram, QR code, afiliados e app, isso raramente acontece.

Um clique de São Paulo pode precisar cair em uma landing com frete e oferta nacional. Tráfego de Portugal talvez precise ir para outra página. iPhone pode ir para App Store ou app link; Android, para Google Play; desktop, para uma landing web. Links de influenciadores, afiliados, marketplaces e campanhas precisam preservar UTM, cupom e sub ID. Em um teste A/B, a pessoa não pode cair em uma variante diferente a cada clique.

Isso é Smart Redirect Routing: um link público controlado por uma política de roteamento, não por um único destino.

No UrlEdge, essa política roda no edge. Você pode combinar país, dispositivo, idioma, query, header, cookie, campanha, peso A/B e fallback, com analytics e rollback. O objetivo não é criar link "esperto" por estética. O objetivo é não perder atribuição, conversão e controle operacional quando growth, ecommerce, agência e desenvolvimento dependem do mesmo link.

O problema não é o link. É a lógica espalhada.

No Brasil, a regra costuma ficar fragmentada:

• geo redirect em CDN ou plataforma
• mobile redirect no tema da loja
• A/B test via script no navegador
• UTMs tratados pela landing page
• link de WhatsApp editado manualmente
• fallback guardado em planilha ou grupo de campanha

Funciona até a campanha mudar, a VTEX/Nuvemshop/Tray/Shopify trocar URL, o afiliado pedir outra página ou o time precisar pausar uma variante.

Uma política de roteamento responde:

Sem isso, o link pode até funcionar, mas ninguém consegue explicar a rota quando dá errado.

Geo routing: país, oferta e disponibilidade

Redirecionamento por geolocalização só vale quando melhora a experiência ou evita desperdício.

O país pode ser inferido no edge. Cloudflare Workers, por exemplo, expõe metadados em request.cf, incluindo país. Mas a detecção técnica não substitui decisão de negócio. Para SEO, evite cloaking, preserve intenção canônica e mantenha fallback global quando fizer sentido.

Device routing: app, loja, webview e QR

No Brasil, boa parte do tráfego passa por WhatsApp, Instagram, TikTok, email e QR. O mesmo link precisa se comportar bem em app nativo, navegador interno e desktop.

Depois do fim do Firebase Dynamic Links, muitos times precisam assumir essa camada. UrlEdge roteia por dispositivo e fallback; abrir app nativo continua dependendo de Universal Links e Android App Links bem configurados.

A/B split por redirect: quando a landing muda

Redirect A/B é bom quando a variante é outro destino:

• landing A vs landing B
• oferta local vs global
• novo checkout para pequena fatia
• rollout canário de storefront novo
• rotação de páginas de afiliados, creators ou parceiros

Não é substituto para uma suíte completa de experimentação. Se você precisa de eventos de produto, segmentação avançada e variantes dentro da aplicação, use ferramenta própria. UrlEdge divide tráfego antes de a página carregar.

O Google recomenda evitar cloaking em testes e usar redirecionamentos temporários quando a URL original manda para uma variação. Isso combina com 302 e split ponderado.

Regra sem prioridade vira conflito

Ter país, dispositivo, A/B e query no mesmo link exige ordem.

Ordem errada gera erro silencioso: A/B pega tráfego excluído, regra mobile apaga sub ID de afiliado, regra de país manda mídia paga para landing sem UTM.

UTM e afiliado fazem parte da rota

O redirect pode quebrar atribuição antes de qualquer analytics registrar a visita.

Para campanhas brasileiras, teste URLs reais de WhatsApp, Instagram, QR, email, afiliados, creators e anúncios. É comum um crawler dizer que o redirect funciona, enquanto o relatório de mídia perde o utm_campaign.

QA da matriz antes do tráfego

Cada condição cria novas rotas para testar.

Teste:

• Brasil, Portugal, LATAM e fallback
• iOS, Android, desktop, tablet e desconhecido
• com e sem UTMs, cupom e afiliado
• WhatsApp, Instagram, QR, email e paid
• primeira visita e retorno no A/B
• status final e quantidade de hops
• prioridade e fallback
• analytics por país, dispositivo, regra, ação e destino
• rollback para snapshot anterior

O nível certo de QA é quando o time consegue prever o destino antes de publicar.

Onde o UrlEdge entra

Use UrlEdge quando um link tem vários destinos e vários donos:

• Smart Redirect Routing para publicar, medir e reverter regras
• Geo Redirects para países e regiões
• Device Targeting para app, stores, mobile, tablet e desktop
• A/B Testing para splits e rollouts
• Advanced Redirect Rules para wildcard, regex e condições
• UTM Builder para preservar atribuição
• Redirect Checker para QA
• Broken Link Monitor para destinos que mudam depois

FAQ

O que é Smart Redirect Routing?

É direcionar uma URL pública para destinos diferentes de acordo com país, dispositivo, idioma, parâmetros, campanha, peso A/B e fallback.

É igual a geo redirect?

Não. Geo redirect é uma condição. Smart routing combina geo, dispositivo, idioma, query, header, cookie, A/B e fallback em uma regra governada.

A/B por redirect usa 301 ou 302?

Normalmente 302, porque teste é temporário. Use permanente apenas para mudança permanente.

Substitui plataforma de experimentação?

Não. Serve para testes de destino, campanhas e rollouts. Experimentos profundos dentro do produto precisam de ferramenta própria.

Referências

• Cloudflare Docs: URL forwarding and redirect execution order
• Cloudflare Workers Docs: Request and cf metadata
• Google Search Central: A/B testing best practices for Search
• Google Search Central: Redirects and Google Search