Como ler uma cadeia de redirecionamento

Os saltos, a grosso modo, na ordem em que você vai encontrá-los

Um anúncio de busca com o nome da marca quase nunca leva direto a uma página de destino. Ele leva a um redirecionamento, que envia o navegador para outro redirecionamento, que eventualmente, depois de um a quatro saltos, chega a algum lugar onde o comprador realmente pode comprar algo. Conhecer o formato dessa cadeia antes de sair investigando evita que você confunda o salto errado com a história completa.

O primeiro salto, no Google, costuma ser o próprio rastreador de cliques do buscador: uma URL em um domínio de veiculação de anúncios do Google carregando um parâmetro gclid. Esse gclid pertence ao Google. É assim que a própria plataforma de anúncios do Google atribui o clique à campanha que o comprou, e ele não informa absolutamente nada sobre quem é o anunciante ou se ele é um afiliado. Já vi gente tratar um gclid como se fosse prova de identidade de um afiliado. Não é. É um token interno de contabilidade do Google.

O segundo salto é onde a coisa começa a ficar interessante: um redirecionamento pelo próprio domínio de rastreamento da rede de afiliados, ou ocasionalmente um encurtador de links do próprio afiliado posicionado na frente dele. Esse é o salto que geralmente, não sempre, carrega o parâmetro que identifica quem recebe o pagamento.

Às vezes há um terceiro salto que não faz nada além de decidir para onde o salto quatro deve realmente ir, com base em algo sobre a requisição: o país do visitante, o dispositivo dele, se o user agent parece um navegador de verdade ou um script. Nem toda cadeia tem esse salto. Quando ele existe, vale a pena prestar atenção nele, por motivos que vou explicar mais adiante.

O último salto é a própria página de destino do comerciante, a página em que o comprador realmente pode comprar. É também, infelizmente, a página que a maioria das pessoas anota quando está tentando documentar um problema, porque é a única visível sem nenhum esforço extra.

Onde o ID de afiliado realmente fica

O nome do parâmetro é diferente em cada rede e, às vezes, em cada programa dentro da mesma rede. Já vi a_aid, subid, clickref, affid e uma dúzia de variantes opacas que não passam de uma string alfanumérica curta sem significado óbvio até você consultá-la nos próprios relatórios da rede. A maioria das redes com que já lidei usa algo dessa família; eu não presumiria que uma variante específica se aplica à sua sem antes checar um link conhecidamente válido de um afiliado que você já aprovou.

utm_source é uma coisa completamente diferente, e confundi-lo com um ID de afiliado é o erro mais comum que vejo. Um parâmetro utm é uma convenção de rotulagem que a pessoa que monta o link escolhe aplicar. Ele não é emitido por ninguém, não é verificado por ninguém, e é trivialmente fácil de omitir, falsificar ou copiar do link de outra pessoa. Trate-o, no máximo, como um indício, nunca como prova de quem realmente está veiculando um anúncio.

Aqui está a parte que confunde quase todo mundo que faz isso pela primeira vez: o parâmetro identificador geralmente fica no segundo salto, no próprio domínio de rastreamento da rede, não na URL final. Quando a rede redireciona adiante para o comerciante, ela geralmente já leu esse parâmetro, registrou-o, gravou um cookie com a mesma informação e removeu o parâmetro da URL antes de enviar o navegador adiante. A URL final da página de destino, aquela que todo mundo instintivamente copia e cola em um e-mail como "prova", frequentemente não carrega nenhum vestígio do afiliado.

Como isso fica quando registrado por escrito

Uma cadeia que vale a pena documentar se parece com isto, salto por salto, não resumida em uma única linha: o link do próprio anúncio, uma URL em googleadservices.com carregando o gclid do Google; depois um redirecionamento para algo como track.[network].com/click?a_aid=4471&subid=coupon-hub-2; depois, se houver um salto de camuflagem, uma terceira URL que resolve de forma diferente dependendo de quem está perguntando; depois o próprio domínio do comerciante, chegando a uma página sem nenhum parâmetro de afiliado visível em nenhum lugar da barra de endereços.

O caso está na segunda linha. Tudo antes dela é contexto; tudo depois dela é onde uma verificação ingênua para de procurar, o que é exatamente o oposto do que deveria ser. a_aid=4471 (ou qualquer que seja o parâmetro e o valor equivalentes na sua cadeia) é o que você entrega à rede e pede que identifiquem. Não a URL do comerciante. Não o texto exibido no anúncio. Aquele único parâmetro, naquele único salto.

Por que a URL final sozinha não prova nada

É por isso que um print mostrando apenas a página de destino, com uma legenda do tipo "vejam quem está anunciando com o nome da nossa marca", raramente sobrevive a uma conversa real com a equipe de compliance de uma rede. Ele mostra que um anúncio existiu e que uma página carregou. Não mostra quem colocou o anúncio, e sem isso não há ID de parceiro para checar em um cadastro de parceiros autorizados, nem nada sobre o qual a rede possa agir.

Você precisa da cadeia inteira, cada salto, com as querystrings completas e intactas, não só a última. No navegador, isso significa abrir o devtools, ativar "preserve log" na aba de rede antes de clicar em qualquer coisa, depois clicar no anúncio e ler, em ordem, cada requisição com status 301 ou 302, anotando a URL completa de cada uma. No terminal, curl -sI -L na URL do anúncio, lendo um cabeçalho Location de cada vez em vez de seguir cegamente até o final, cumpre mais ou menos a mesma função para cadeias construídas inteiramente com redirecionamentos HTTP.

Essa ressalva importa: nem todo salto é um redirecionamento HTTP. Alguns são uma tag meta-refresh ou um trecho de JavaScript que define window.location depois que a página já carregou, de forma invisível para uma requisição curl simples, que só vê um 200 e para de procurar. Se uma cadeia parece terminar cedo demais em relação ao que você esperava, geralmente é por isso, e você precisa de um navegador de verdade, ou um headless que execute JavaScript, para ver o resto dela.

Como capturar evidências que realmente resistem a uma discussão

Um timestamp, com precisão de minuto, em um fuso horário que você anota em vez de presumir. A sequência completa de saltos, em ordem, com as querystrings intactas, sem resumir. Uma captura de tela da página de resultados de busca mostrando o anúncio exatamente como foi renderizado. Uma captura de tela separada da página de destino para a qual ele levou. Esse é o padrão que já vi as próprias equipes de compliance de uma rede exigirem antes de agir sobre uma denúncia, e não é um nível difícil de alcançar quando você sabe o que fazer — é só um nível que quase ninguém alcança por acidente.

Faça a captura a partir de um contexto de navegação comum: desconectado da conta, não em um IP de escritório que passou a semana inteira pesquisando o nome da sua própria marca, sem nenhum bloqueador de anúncios reescrevendo silenciosamente a página antes da captura de tela. Você está tentando reproduzir o que um comprador anônimo realmente viu, e qualquer coisa que faça sua requisição parecer incomum é motivo para o outro lado alegar que a evidência não reflete um clique real.

As armadilhas que pegam as pessoas

Redirecionamentos que checam geolocalização ou dispositivo antes de decidir para onde enviar o clique são a primeira delas. Um anúncio que se comporta de forma limpa a partir de um IP de desktop nos EUA pode enviar um visitante mobile em outro país para um lugar completamente diferente, às vezes para uma página sem nenhuma identidade de marca, às vezes para uma página abertamente camuflada, feita para parecer inofensiva a qualquer um que não seja o público-alvo pretendido. Se você só verifica a partir de um único local e um único dispositivo, está vendo apenas uma versão de uma cadeia que pode ter várias.

A segunda é mais sutil: algumas cadeias se comportam de forma diferente para um navegador que nunca visitou antes em comparação a um que carrega um cookie de uma visita anterior, o que importa enormemente se você está reverificando um caso uma semana depois de tê-lo encontrado pela primeira vez e obtém um resultado com aparência mais limpa na segunda vez. Isso não é o problema desaparecendo. É muito provavelmente a cadeia reconhecendo você.

A terceira é uma em que eu mesmo já errei antes: presumir que o identificador extraído nomeia o afiliado, quando muitas estruturas de rede permitem que um afiliado de nível superior administre subafiliados ou sub-IDs dentro da própria conta. O parâmetro que você extraiu da cadeia pode identificar um pequeno publisher operando sob o guarda-chuva de outra pessoa, não o titular da conta que você naturalmente presumiria ser o responsável. Se essa distinção importa para você depende dos termos do seu programa, mas vale a pena checar antes de nomear um parceiro específico em uma denúncia, porque errar nisso é o tipo de erro difícil de reverter com elegância.

É isso, mecanicamente, que uma varredura de monitoramento automatiza: seguir cada salto, extrair o parâmetro, checá-lo em um cadastro de parceiros autorizados, antes que qualquer coisa chegue à caixa de entrada de alguém como um caso já finalizado. Veja como funciona para a versão mais longa desse fluxo. Mas vale a pena dominar de cor a versão manual acima, independentemente de você algum dia comprar algo, porque mais cedo ou mais tarde você vai precisar checar uma cadeia sozinho, em um fim de semana, sem esperar por uma varredura agendada.

Admito que ainda abro o devtools e faço isso manualmente de vez em quando, em casos estranhos o suficiente para eu não confiar totalmente em um rastreamento automatizado até ver os saltos acontecerem com os próprios olhos. Isso não é uma crítica à automação. É só que uma cadeia com um salto de camuflagem é exatamente o tipo de coisa que vale a pena ver com os próprios olhos pelo menos uma vez, para você saber como é o normal quando não está olhando para ele.