Cloudflare Workers pra marketing: redirects, A/B test, geo

Cenário que todo time de marketing conhece: promoção regional no ar, usuário de SP deveria cair em landing específica, o redirect dependia de dev. Dev estava em outra sprint. Promoção veio. Redirect não estava.

Com Cloudflare Workers, isso não existe. Você escreve 20 linhas de JavaScript, faz deploy em 30 segundos, e a lógica roda em 320+ data centers incluindo São Paulo e Brasília, sem servidor pra gerenciar.

Esse artigo cobre os 3 casos que todo time de marketing deveria dominar: redirects inteligentes, A/B test sem flicker e geo-personalização. Com código funcional pra cada um.

O que é Cloudflare Workers em 30 segundos

Se você usa Cloudflare como CDN ou DNS (maioria dos sites BR já usa), tem acesso imediato.

Workers é um ambiente de execução JavaScript que roda no servidor mais próximo do usuário final. Quando alguém de SP abre seu site, o Worker roda em SP. Sem chamada pra servidor central, sem latência extra.

A diferença de uma edge function genérica é ecossistema: Workers vem junto com KV (chave-valor), D1 (banco no edge), R2 (storage) e Analytics Engine. Tudo integrado.

Free tier: 100.000 requests por dia. Pra maioria das necessidades de marketing, cabe de sobra.

Caso 1: Redirects inteligentes sem depender de dev

Essa é a demanda mais comum. E a que mais trava time de marketing em fila de ticket.

Redirect por parâmetro UTM

Quer que link com utm_campaign=promo-julho caia em landing específica?

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const campaign = url.searchParams.get('utm_campaign');

    if (campaign === 'promo-julho') {
      return Response.redirect(
        'https://seusite.com.br/promo-julho',
        302
      );
    }

    return fetch(request);
  }
};

Deploy feito. Qualquer link com esse UTM cai na landing certa. Sem mexer no site, sem plugin de redirect, sem fila.

Redirect por device

Mobile e desktop com destinos diferentes — comum em e-commerce com app próprio ou negócio local com agendamento só mobile:

export default {
  async fetch(request) {
    const ua = request.headers.get('User-Agent') || '';
    const isMobile = /Mobile|Android|iPhone|iPad/i.test(ua);

    const url = new URL(request.url);

    if (isMobile && url.pathname === '/agendamento') {
      return Response.redirect(
        'https://seusite.com.br/agendar-mobile',
        302
      );
    }

    return fetch(request);
  }
};

Redirect por data — campanha com prazo real

Promoção com data de expiração, sem depender de ninguém lembrar de desativar depois:

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const now = new Date();
    const endDate = new Date('2026-08-31T23:59:59-03:00');

    if (url.pathname === '/promo' && now > endDate) {
      return Response.redirect('https://seusite.com.br', 301);
    }

    return fetch(request);
  }
};

Isso resolve um problema sério de campanhas sazonais: depois que a promoção fecha, links em emails continuam circulando. Com o Worker, todo mundo que chega fora do prazo vai pra página principal automaticamente.

Redirect por referral de parceiro

Usuário vindo de site parceiro cai em página co-branded:

const referer = request.headers.get('Referer') || '';

if (referer.includes('parceiro.com.br')) {
  return Response.redirect(
    'https://seusite.com.br/parceria-exclusiva',
    302
  );
}

Pra cada redirect acima: 15-20 linhas de código, deploy em 30 segundos. Zero ticket aberto.

Caso 2: A/B test sem flicker

O problema do A/B test tradicional (VWO, Google Optimize, Optimizely): o JavaScript carrega, o usuário vê o conteúdo original por 200-400ms, depois a variante aparece. É o flicker — aquele flash antes da mudança. Em conversão, isso interfere no resultado do teste.

A solução de edge resolve porque a lógica roda antes do HTML chegar no browser. O usuário recebe a versão certa desde o primeiro byte.

Código básico de A/B test no edge

export default {
  async fetch(request) {
    const url = new URL(request.url);

    // Só roda na home
    if (url.pathname !== '/') {
      return fetch(request);
    }

    // Verifica variante existente (consistência entre sessões)
    const cookie = request.headers.get('Cookie') || '';
    let variant = cookie.match(/ab_variant=([AB])/)?.[1];

    // Se não tem, atribui 50/50
    if (!variant) {
      variant = Math.random() < 0.5 ? 'A' : 'B';
    }

    // Variante B busca URL alternativa na origem
    const targetUrl = variant === 'B'
      ? 'https://seusite.com.br/home-variante-b'
      : request.url;

    const response = await fetch(targetUrl);

    // Seta cookie pra manter consistência
    const newResponse = new Response(response.body, response);
    newResponse.headers.append(
      'Set-Cookie',
      `ab_variant=${variant}; Path=/; Max-Age=2592000; SameSite=Lax`
    );

    return newResponse;
  }
};

O cookie garante que o mesmo usuário sempre vê a mesma variante. Sem isso, o teste fica inconsistente e os dados não têm valor.

Como rastrear qual variante o usuário viu

O cookie ab_variant que o Worker seta é lido pelo GTM depois. Você cria uma variável de cookie no GTM, usa como dimensão customizada no GA4 e segmenta sessões por variante no relatório. Sem código extra no site.

Workers vs ferramentas tradicionais de A/B test

Critério	VWO / Optimizely	Workers
Flicker	Presente (200-400ms)	Zero
Setup inicial	Interface visual, fácil	Requer JS básico
Custo	US$ 200-2.000/mês	~US$ 0
Flexibilidade	Média	Máxima
Rastreamento	Integrado	Manual via GTM/GA4

Pra teste simples de headline ou cor de botão, VWO ainda é mais prático. Pra teste de layout completo, fluxo de checkout ou página inteira, Workers ganha no custo e na ausência de flicker.

Caso 3: Geo-personalização de conteúdo

Cloudflare entrega país (e às vezes cidade) do usuário em cada request, sem lookup externo. Dado disponível em qualquer Worker:

const country = request.cf?.country; // "BR", "PT", "US"
const city    = request.cf?.city;    // "São Paulo", "Lisboa"

Redirect por país

Negócio com múltiplos mercados:

export default {
  async fetch(request) {
    const country = request.cf?.country;
    const url = new URL(request.url);

    if (url.pathname !== '/') return fetch(request);

    const redirectMap = {
      'PT': 'https://seusite.pt',
      'US': 'https://seusite.com',
    };

    if (redirectMap[country]) {
      return Response.redirect(redirectMap[country], 302);
    }

    return fetch(request);
  }
};

Personalizar conteúdo sem redirecionar

Às vezes você não quer redirect. Quer mostrar banner diferente, mudar oferta ou ajustar texto dentro da mesma URL. Possível com HTMLRewriter, ferramenta nativa do Cloudflare que modifica HTML em streaming:

export default {
  async fetch(request) {
    const country = request.cf?.country || 'BR';
    const response = await fetch(request);

    if (country !== 'BR') return response;

    return new HTMLRewriter()
      .on('#banner-promocao', {
        element(element) {
          element.setInnerContent(
            '<p>Frete grátis pra SP hoje!</p>',
            { html: true }
          );
        }
      })
      .transform(response);
  }
};

HTMLRewriter processa HTML em streaming. Não carrega tudo na memória, não adiciona latência perceptível. Funciona em qualquer site com estrutura HTML padrão.

Setup do zero ao primeiro Worker

Pré-requisito

Domínio precisa estar proxiando pelo Cloudflare (ícone laranja ativo no DNS). Quem usa Cloudflare pra CDN já está configurado.

Passo 1: Cria o Worker

dash.cloudflare.com → seleciona o domínio → Workers & Pages no menu → Create application → Create Worker → dá um nome descritivo (ex: marketing-redirects).

Passo 2: Escreve e testa o código

O dashboard abre editor inline. Cola o código, ajusta URLs e condições pro seu caso. A aba Preview tem simulador de request — testa com diferentes User-Agents, parâmetros UTM e países simulados antes de publicar.

Passo 3: Adiciona rota ao domínio

Settings → Triggers → Add Route

Exemplos de rota:

• seusite.com.br/promo* — só intercepta paths de promo
• seusite.com.br/* — intercepta tudo
• *.seusite.com.br/* — inclui subdomínios

Use rota específica quando possível. Worker em /* executa em todo request, incluindo assets estáticos (imagens, CSS, JS). Pra redirect de campanha, /promo* já resolve.

Passo 4: Deploy

Clica Save and Deploy. Em segundos está no ar em todos os data centers. Sem restart de servidor, sem aguardar propagação de DNS.

Tempo do zero ao ar na primeira vez: 20-30 minutos.

Limitações que importam

Sem banco de dados por padrão

Workers são stateless. Cada execução é independente. Pra persistir informação (ex: contar quantas vezes o mesmo IP foi redirecionado), precisa de Workers KV ou D1 — ambos disponíveis, mas adicionam complexidade.

Limite de CPU no free

Free tier: 10ms de CPU por request. Pago (US$ 5/mês): 30 segundos. Pra redirect e personalização simples, 10ms é mais do que suficiente. O código dos exemplos acima roda em 1-3ms.

Workers não substituem backend

Workers ficam na camada de request/response. Operações que precisam escrever no banco, enviar email ou processar pagamento continuam no backend. O Worker fica na frente como proxy inteligente.

Custo real

Plano	Requests incluídos	Preço
Free	100.000/dia	R$ 0
Paid	10 milhões/mês	US$ 5/mês
Excedente	Por milhão	US$ 0,30

Site com 200k visitas/mês em páginas com Worker ativo: cabe no free tier. Site com 2M visitas/mês: US$ 5/mês. Custo muito baixo pra o que entrega.

Quando chamar dev vs fazer você mesmo

Se você tem JavaScript básico (consegue ler um if/else e entender o que é uma URL), faz a maioria dos casos de marketing sozinho.

Faz sozinho:

• Redirects por UTM, device, data, referral
• A/B test simples com duas variantes
• Geo-redirect por país
• Expiração automática de campanha

Precisa de dev:

• Worker que integra com banco de dados (KV, D1, banco externo)
• Worker que consome API com autenticação complexa
• HTMLRewriter em HTML com estrutura muito customizada
• Lógica com múltiplas condições encadeadas

Integração com a stack atual

Workers não vive em isolamento. Se encaixa no que já está rodando:

GTM: cookie que o Worker seta é lido como variável customizada no GTM. Tracking de variante de A/B test sem linha de código extra no site.

Server-side tracking: Worker pode adicionar headers antes de passar pro servidor de origem, facilitando o tracking server-side que já está configurado.

Vercel / Netlify / Railway: se o site está num desses provedores de deploy, Workers fica na frente como proxy inteligente. A origem continua no Vercel, o Worker intercepta no Cloudflare antes de chegar lá.

Performance: Worker bem configurado reduz requests desnecessários no servidor de origem, o que ajuda indiretamente nas métricas de PageSpeed e Core Web Vitals por diminuir carga no servidor.

Erros que aparecem mais

Redirect 301 em teste A/B: 301 é permanente, fica cacheado no browser. Se o teste muda, usuário que cacheu não vê. Pra A/B test, sempre 302.

Worker sem fallback: se o código não tem return fetch(request) no final, requests que não batem em nenhuma condição ficam sem resposta. Todo Worker precisa de fallback explícito como última linha.

Loop de redirect: Worker redireciona pra URL que tem outro Worker com outra condição. Resultado: loop infinito, erro 522 pro usuário. Testa pelo simulador de Preview antes de apontar pra domínio real.

Rota muito ampla sem filtro: Worker em /* processando imagens, fontes e CSS gera custo extra e latência onde não precisa. Use paths específicos pra cada caso.

Vale pra que tipo de negócio

E-commerce: redirect de campanha por UTM, A/B test de checkout, geo de frete. Alto valor — redirect mal gerenciado gera conversão perdida.

SaaS: A/B test de landing de pricing, geo de moeda/idioma pra multi-país. Alto valor, especialmente com múltiplos mercados.

Agência: gerenciar redirects de vários clientes sem precisar de acesso ao servidor de cada um. Valor operacional alto — uma mudança de campanha que antes exigia acesso ao servidor do cliente, agora é Worker.

Negócio local (ótica, clínica, serviço): redirect por device pra agendamento mobile, campanhas sazonais com prazo automático. Valor médio — escala menor, mas implementação simples e impacto direto na operação.

---

A Máximo configura Cloudflare Workers pra redirects, A/B test e personalização em clientes. Quer implementar isso no seu site sem depender de fila de dev? Fala com a gente.