Rastreamento de conversões em links curtos: identificador de clique, janela e eventos de servidor

Todo relatório de links tem um ponto natural de parada e, para a maioria dos times, esse ponto é o clique. O painel diz que um link foi aberto quatro mil vezes no mês passado, com quebra por país, dispositivo, navegador e origem, e é aí que a análise termina. Mas quatro mil cliques descrevem o que você gastou, não o que você ganhou. É a metade barata do funil, e é a metade que fica melhor numa captura de tela.

O rastreamento de conversões fecha essa lacuna levando um identificador do momento do redirecionamento até o sistema que acaba registrando o pedido, e depois trazendo-o de volta. A ideia é fácil de descrever e fácil de errar de maneiras que só aparecem meses depois, na forma de relatórios de receita que não batem com as notas fiscais. Este artigo cobre o identificador, a janela de atribuição e por que ela é uma decisão de negócio, a diferença entre um evento de servidor e um evento de navegador, por que dinheiro é número inteiro, como os duplicados são tratados e o que fazer quando a conversão acontece em um sistema que não é seu.

Clique é custo, não resultado

O relatório que para no clique sobrevive porque o clique é a medição fácil. O redirecionamento acontece em uma infraestrutura que é sua, então contá-lo não depende da cooperação de ninguém, enquanto tudo o que vem depois acontece em outro lugar. O nosso guia sobre como os cliques em links são de fato rastreados detalha o que um único evento de clique consegue conter, e a versão curta é que ele sabe que o clique aconteceu e nada sobre o que veio depois.

Essa limitação tem consequências reais. Duas veiculações podem produzir volumes de clique idênticos enquanto uma manda compradores e a outra manda gente que sai em três segundos. Uma quebra por país impressionante em cliques pode se inverter em receita. Testes decididos por taxa de clique escolhem rotineiramente a variante com o título mais agressivo e a pior conclusão de checkout. Enquanto a receita não estiver ligada às mesmas dimensões, cada um desses julgamentos é um palpite vestido de métrica.

Para ligá-la, basta uma coisa: um valor que sobreviva à viagem do redirecionamento até o pedido.

O identificador é o projeto inteiro

A cada redirecionamento o worker emite um token e faz duas coisas com ele. Acrescenta o token ao endereço de destino sob o nome de parâmetro que você escolher, lp_cid por padrão, e grava o mesmo valor em um cookie próprio do seu domínio de redirecionamento, válido por 90 dias.

Existem duas cópias porque qualquer uma delas pode se perder. Destinos removem parâmetros de consulta, às vezes de propósito para deixar a URL limpa, às vezes como efeito colateral de um redirecionamento do lado deles. Já um visitante que clica hoje e volta três dias depois digitando o endereço não tem mais parâmetro nenhum, mas ainda carrega o cookie. Nenhuma das cópias é confiável sozinha; juntas, elas cobrem quase todos os caminhos realistas até uma compra.

O cookie ser próprio não é um detalhe técnico. Ele é gravado pelo seu próprio domínio de redirecionamento, aquele que o visitante realmente visitou, que é justamente a categoria de cookie que os navegadores não vêm removendo. É por isso que um domínio personalizado deixa de ser preferência de marca e vira infraestrutura de medição: em um domínio compartilhado do fornecedor, o cookie é do fornecedor.

O que o token carrega

O token é assinado, e a assinatura cobre mais do que o clique. Os identificadores de espaço de trabalho e de parceiro fazem parte do payload assinado, então um token emitido no link de um cliente é recusado no espaço de trabalho de outro exatamente como uma falsificação. Para quem opera links de vários clientes, isso mantém a receita de um fora do relatório do outro por construção, e não por um filtro que alguém lembrou de aplicar.

O que o token contém é deliberadamente estreito: o momento do clique, o link, a variante do teste, o país, a classe de dispositivo, a origem do tráfego e uma marca de tráfego suspeito. Nenhum dado pessoal. Essa lista é também o que torna a coluna de receita útil, porque cada um desses campos vira uma dimensão pela qual você quebra a receita em analytics, sem precisar cruzar com nada.

O nome do parâmetro e a chave que liga e desliga o recurso ficam nas configurações do espaço de trabalho, e mudar qualquer um dos dois reescreve na hora a configuração em cache de todos os links. Uma consequência que vale planejar: quando o plano não inclui conversões, o redirecionador simplesmente para de emitir identificadores, e ativar o recurso depois não cria identificadores retroativos para cliques que já aconteceram.

A janela de atribuição é uma decisão de negócio

A janela é a idade máxima de um clique que ainda pode ser creditado por uma conversão. É uma configuração por espaço de trabalho, e é o único número aqui que merece discussão em vez de ser aceito como padrão.

Curta demais, e você joga fora receita que produziu de verdade. Longa demais, e você credita links por compras que teriam acontecido de qualquer jeito, o que é pior do que inútil, porque é errado com confiança. Escolha medindo o intervalo entre o primeiro contato e a compra em pedidos que você já consegue rastrear: uma compra por impulso fecha em minutos, uma compra pensada de consumidor leva dias, uma compra corporativa com etapa de aprovação leva semanas.

O modo de falha que este projeto evita é a recusa silenciosa. Uma conversão que chega depois da janela é recusada com attribution_expired, um código distinto de invalid_click_id. As duas situações pedem correções completamente diferentes, e uma integração que recebe um erro genérico para ambas vai passar uma semana depurando a coisa errada. Registre o código, conte os dois separadamente e trate uma taxa crescente de attribution_expired como sinal de que a sua janela não corresponde mais ao seu ciclo de vendas.

Os dois caminhos de entrada também têm tetos diferentes. O cookie vive 90 dias, então um relatório pelo navegador que dependa dele não sobrevive além disso. Um relatório pelo servidor guarda o próprio identificador e é limitado apenas pela janela do espaço de trabalho.

Dois caminhos de entrada, um só conjunto de regras

Os dois caminhos passam pelo mesmo serviço, então a janela, a deduplicação e o envio para fora se comportam de forma idêntica. O que muda é o que cada caminho sobrevive e o que cada um exige de você.

O evento de servidor

O seu backend envia o identificador com um objetivo, um identificador de pedido, um valor e uma moeda.

curl -X POST https://api.linkprofit.com/v1/conversions \
  -H "Authorization: Bearer lp_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-10241" \
  -d '{
    "click_id": "1.eyJ1aWQiOiJ...",
    "goal": "purchase",
    "order_id": "10241",
    "amount_cents": 4999,
    "currency": "usd"
  }'

A chave precisa do escopo conversions:write, o que significa que este caminho custa algo que o caminho pelo navegador não custa: uma credencial para emitir, guardar e rotacionar. Veja autenticação da API para entender como as chaves com escopo são gerenciadas, e mantenha essa chave no servidor — uma chave com acesso de escrita aos seus dados de receita não tem lugar dentro de uma página.

O que você recebe em troca é um relatório que nenhum bloqueador de anúncios, bloqueador de scripts, configuração de proteção contra rastreamento ou erro de JavaScript consegue suprimir. Ele dispara da sua própria infraestrutura no momento em que o seu próprio sistema concorda que o pedido existe, então reflete a verdade depois das checagens antifraude, e não o instante otimista em que um botão foi apertado.

O evento de navegador

O worker serve um script pequeno a partir do seu próprio domínio de redirecionamento, e a página de obrigado o chama.

<script src="https://go.example.com/cv.js" defer></script>
<script>
  window.lpConversion({ goal: 'purchase', orderId: '10241', amountCents: 4999, currency: 'usd' });
</script>

O script lê o identificador na URL ou no cookie próprio, então nada precisa ser passado a ele manualmente. Não existe host de terceiros em ponto nenhum da cadeia, e isso importa duas vezes: é uma propriedade de privacidade e também de white-label, porque a página do seu cliente não carrega nada que revele a plataforma por baixo.

O custo é o custo de sempre da medição no lado do cliente. Bloqueadores, modos de privacidade, scripts que não carregam e um visitante que fecha a aba meio segundo antes removem eventos, e a perda não é uniforme. Públicos técnicos e preocupados com privacidade suprimem muito mais desses eventos do que públicos de consumo, então uma configuração só de navegador não apenas subconta: ela subconta de forma desigual por segmento.

Como escolher entre eles

Use o caminho pelo servidor sempre que um servidor souber do pedido, o que é quase todo lugar onde dinheiro troca de mãos. Use o caminho pelo navegador para resultados que só existem no navegador, ou onde você não consegue adicionar código de servidor: uma página que você só edita por um gerenciador de tags, um cadastro em uma plataforma hospedada, a landing page de um cliente que não é sua.

Rodar os dois para o mesmo resultado é seguro por causa da deduplicação, mas só se os dois caminhos enviarem o mesmo order_id. Sem isso, você não está somando cobertura: está contando receita duas vezes.

Os objetivos em si são leves. Um objetivo é um resultado nomeado, como purchase, signup ou trial, pode carregar um valor e uma moeda padrão para conversões que chegam sem valor, e um objetivo referenciado antes de existir é criado no primeiro uso.

Dinheiro é número inteiro

Os valores são unidades mínimas inteiras. 4999 significa 49.99 em uma moeda de duas casas decimais, e um valor de 49.99 é recusado com o campo nomeado, em vez de arredondado em silêncio.

Isso irrita as pessoas por mais ou menos um dia e depois as salva por anos. O ponto flutuante binário não representa a maioria das frações decimais de forma exata, então a demonstração clássica em que somar dois valores produz um terceiro com um dígito inesperado no fim não é curiosidade: é o que acontece com toda soma de uma coluna de receita em escala. Moedas sem casas decimais também derrubam qualquer suposição de que dividir por cem vale sempre.

Recusar o decimal na fronteira empurra a única conversão honesta, a de um preço legível por humanos para unidades mínimas, para exatamente um lugar: o seu código, uma vez só, onde você consegue testá-la.

Duplicados são problema do banco de dados

A deduplicação acontece como uma única inserção atômica, e não como uma leitura seguida de gravação. Entregas repetidas do mesmo order_id criam uma conversão só e a devolvem marcada como duplicada.

A distinção parece acadêmica e não é. Uma checagem seguida de inserção tem uma brecha entre as duas operações, e um webhook repetido por um remetente impaciente joga duas chamadas dentro dessa brecha. As duas não encontram registro nenhum e as duas gravam. É assim que um relatório de receita ganha dez por cento fantasmas que ninguém consegue localizar depois, porque cada registro isolado parece perfeitamente legítimo.

A regra prática é escolher um identificador de pedido estável e único no seu sistema, e nunca mudar a forma de derivá-lo. O seu próprio número de pedido costuma ser o certo; um timestamp ou qualquer coisa regerada a cada nova tentativa é exatamente o errado. Combine isso com o cabeçalho Idempotency-Key, como na requisição acima, e uma chamada que falhou vira algo que você repete, e não algo que você investiga.

Tráfego suspeito é rotulado, não escondido. O veredicto do classificador viaja dentro do token, então uma conversão atribuída a um data center ou a um proxy já nasce marcada como suspeita no registro e aparece nos relatórios como um segmento próprio. Duzentas conversões, e duzentas conversões com quarenta delas vindas de uma única faixa de hospedagem em uma hora, são fatos diferentes, e só um deles vale o que se paga por ele. É aí que dados de conversão e filtragem de tráfego deixam de ser recursos separados.

Quando a conversão acontece em outro lugar

A maior parte da dificuldade na prática não está na API. Está no fato de que o momento que vale medir acontece dentro de uma loja hospedada, de um CRM ou de um provedor de cobrança, e o seu trabalho é levar uma string do clique até esse sistema e trazê-la de volta.

Lojas hospedadas. Se a plataforma permite atributos ou metadados personalizados no pedido, esse é o caminho limpo: leia o identificador quando o visitante chegar, leve-o pelo checkout em um campo oculto, grave-o no pedido e envie a conversão pelo seu servidor quando o pedido for confirmado, e não quando o botão for apertado. Se a plataforma não permite campos personalizados, mas permite um script na página de confirmação, use o caminho pelo navegador. A nossa página de soluções para e-commerce detalha essas escolhas.

CRM e vendas assistidas. Capture o identificador como campo oculto no formulário de lead e grave-o no registro, depois envie a conversão quando o negócio for marcado como ganho. A armadilha aqui é o tempo: um negócio que fecha em sete semanas precisa de uma janela que comporte sete semanas e, se o seu CRM é o único lugar que conhece o identificador, a retenção e a exportação dele passam a fazer parte da sua arquitetura de atribuição. Considere enviar um objetivo signup na captura do lead e um objetivo purchase no fechamento, para que o topo do funil seja medido mesmo quando o fundo leva um trimestre.

Cobrança e assinaturas. Deixe o webhook do provedor de cobrança ser o gatilho. Quando uma fatura é paga, o seu servidor busca o identificador guardado para aquele cliente e envia uma conversão usando o identificador da fatura como identificador do pedido. As cobranças recorrentes chegam então naturalmente como conversões separadas, e os primeiros pagamentos continuam distinguíveis das renovações pelo objetivo.

Nos três formatos o padrão é idêntico: o sistema externo não precisa saber nada sobre links. Ele guarda uma string opaca e a devolve para você.

Para onde os números vão depois é deliberadamente convencional. Um evento conversion.created assinado é emitido pelo mecanismo de webhooks de sempre, e as integrações de publicidade configuradas recebem a conversão por uma fila de entrega com espera crescente documentada e uma marca de desistência, em vez de tentativas infinitas. Os planos também podem limitar as conversões aceitas por mês civil, contadas em UTC, e ultrapassar esse limite responde quota_exceeded, e não uma restrição de plano, de modo que “não está no seu plano” e “acabou neste mês” ficam distinguíveis sem abrir um chamado.

Acertar de primeira

1. Ative as conversões antes da campanha, e não depois. Os identificadores são emitidos na hora do redirecionamento e não podem ser criados retroativamente.
2. Rode os links no seu próprio domínio, para que o cookie próprio pertença a você.
3. Defina a janela a partir do seu ciclo de compra medido e revise-a quando a taxa de attribution_expired se mexer.
4. Prefira o caminho pelo servidor sempre que um servidor souber do pedido.
5. Converta preços para unidades mínimas inteiras em exatamente um lugar do seu código.
6. Use o seu número de pedido real como identificador de pedido e envie-o de forma idêntica por todos os caminhos.
7. Registre os códigos de recusa separadamente, depois concilie com a cobrança uma vez por período e investigue a diferença em vez de dissolvê-la numa média.

A referência completa de campos está na documentação de conversões, e a página do recurso de rastreamento de conversões mostra como a coluna de receita se comporta nos relatórios que você já lê. Nada disso substitui a contabilidade. Isso responde a uma pergunta mais estreita que a contabilidade não responde: qual link, qual país, qual destino e qual origem de tráfego produziram o dinheiro.