Origem da jornada no webhook: ligar a campanha ao desfecho da verificação

Quem investe em aquisição mede o custo por cadastro. Quem responde por risco mede a taxa de aprovação. Os dois números vivem em ferramentas diferentes, são lidos por times diferentes e quase nunca se encontram na mesma linha. O resultado é previsível: uma campanha barata por cadastro pode trazer justamente o público que a verificação de identidade recusa, e ninguém percebe, porque o relatório de marketing para no clique e o relatório de risco começa no documento.

A pergunta que junta os dois mundos é simples de fazer e trabalhosa de responder: de cada cem pessoas que uma campanha trouxe, quantas foram aprovadas, quantas foram para revisão e quantas foram recusadas? Para respondê-la, a origem precisa viajar junto com a pessoa desde a página de chegada até o resultado da verificação, que em geral chega ao seu servidor minutos depois, por webhook.

Este artigo trata desse trajeto: o que carregar, como nomear, o que nunca colocar no rótulo e o que medir quando a origem finalmente chega ao lado do desfecho.

Onde a informação se perde

A origem de uma visita nasce no navegador. A convenção mais difundida para marcá-la são os parâmetros de campanha na URL, e a central de ajuda do Google Analytics, no artigo sobre construtores de URL, lista nove: utm_source para a origem, utm_medium para o meio, utm_campaign para a campanha, além de utm_id, utm_term, utm_content, utm_source_platform, utm_creative_format e utm_marketing_tactic, estes dois últimos com a nota de que ainda não aparecem nos relatórios do Google Analytics. A mesma página recomenda usar sempre os três primeiros.

O desfecho da verificação nasce em outro lugar: no servidor de quem verifica, depois da captura, da análise e da decisão. Ele chega ao seu backend por uma chamada assíncrona, sem navegador no meio. Entre as duas pontas há um cadastro, às vezes uma troca de aparelho, às vezes uma sessão que expira e é retomada. Cada passo é uma chance de a origem ficar para trás.

A saída mais comum é uma tabela paralela: no momento do cadastro, grava-se a campanha ao lado do identificador do usuário e, quando o resultado chega, junta-se pelo identificador. Funciona, mas é mais uma estrutura para manter, mais um lugar onde o dado pode divergir e mais uma consulta no caminho de quem só queria um número por campanha.

Mandar a origem na criação e recebê-la no resultado

Um desenho mais direto é tratar a origem como parte do pedido de verificação. O seu backend, que já leu a campanha da chegada e a guardou na sessão do seu próprio site, envia um rótulo curto no momento em que cria a sessão de verificação, e o fornecedor devolve esse rótulo, sem alteração, no webhook do desfecho. A junção deixa de existir, porque o resultado já chega dizendo de onde a pessoa veio.

Na UNIFOKAL, por exemplo, esse rótulo é o campo opcional origin_tag da criação de sessão: de 1 a 64 caracteres, ele volta exato na resposta da criação e no data.origin_tag do webhook, e a sessão renovada pelo widget herda o mesmo valor. Quem não manda o campo recebe o corpo de sempre. O contrato completo está na documentação da API.

Três cuidados valem para qualquer implementação desse desenho. O rótulo deve ser lido no servidor, a partir do que o seu site já guardou, e não de um campo que o navegador possa reescrever na hora de criar a sessão. O rótulo é do seu vocabulário, não do fornecedor, então quem define a lista de valores é você. E o rótulo é conveniência, não chave: o identificador de referência do usuário continua sendo a âncora de qualquer conciliação, inclusive para os desfechos que terminam antes de qualquer captura.

Nome é contrato: caixa, alfabeto e estabilidade

O artigo do Google Analytics sobre construtores de URL é explícito num ponto que costuma ser esquecido: os valores dos parâmetros diferenciam maiúsculas de minúsculas, e utm_source=google é um valor diferente de utm_source=Google. A recomendação da mesma página é adotar minúsculas como padrão e manter uma convenção estrita, porque SpringSale e Spring_Sale viram duas linhas no relatório.

A mesma disciplina vale para o rótulo que vai ao fornecedor de verificação, com um agravante: ele volta exatamente como foi enviado, e qualquer variação de grafia fragmenta a sua taxa de aprovação por canal. Algumas regras práticas:

• defina um formato fixo, como canal:campanha (google-ads:black-friday, indicacao:parceiro-x), e escreva a lista num lugar só;
• use minúsculas, hífen e dois-pontos, sem espaço e sem acento;
• não use valor que muda a cada disparo, como data ou número de lote, se a pergunta é por campanha;
• prefira um alfabeto fechado que recuse, na entrada, o que não é rótulo: sem arroba e sem barra, um endereço de e-mail ou uma URL inteira simplesmente não cabem.

Rótulo de campanha não é lugar de dado pessoal

O artigo de boas práticas do Google Analytics para evitar o envio de informação pessoal identificável é direto: nenhum dado pessoal deve ir nos parâmetros de campanha utm_source, utm_medium, utm_term, utm_campaign e utm_content. A razão vale em dobro no rótulo de origem de uma verificação, que viaja para mais um sistema e volta em cada entrega do webhook.

A Lei 13.709/2018 aponta na mesma direção. O artigo 6º, inciso III, estabelece o princípio da necessidade: o tratamento deve se limitar ao mínimo necessário para a finalidade, com dados pertinentes, proporcionais e não excessivos. A finalidade aqui é saber de qual campanha a pessoa veio. Nome, CPF, telefone ou e-mail não respondem a essa pergunta, e o titular já está identificado pelo seu identificador de referência, que deve ser opaco.

Idempotência e renovação: o rótulo acompanha a jornada

Quando a criação de sessão é idempotente pelo identificador de referência, repetir a chamada devolve a mesma sessão em vez de criar outra, como detalhado em idempotência em APIs. Isso tem uma consequência para o rótulo: se ele faz parte do corpo, repetir o identificador com um rótulo diferente não é uma repetição, é outro pedido, e o comportamento correto é recusar com erro nomeado, nunca trocar a origem em silêncio. Decida o rótulo antes de criar a sessão, e não numa nova tentativa.

A renovação é o caso oposto. A sessão que expira e é renovada continua sendo a mesma jornada, então herdar o rótulo é o esperado: a pessoa veio da mesma campanha, apenas demorou mais.

O que medir quando a origem chega junto do desfecho

Com a origem no resultado, três leituras passam a sair direto do webhook: taxa de aprovação por campanha, taxa de revisão por canal e taxa de recusa por origem. A primeira muda a conta da aquisição, porque o custo que importa passa a ser o custo por cliente aprovado, e não por cadastro. A segunda mostra de onde vem o volume que alimenta a fila de revisão humana. A terceira merece olhar antes de uma campanha ganhar mais verba: recusas concentradas numa única origem dizem que aquele canal está trazendo um público que não passa, seja qual for o motivo.

Duas precauções evitam números errados. Deduplique pelo identificador do evento antes de contar, porque o webhook pode ser entregue mais de uma vez, tema tratado em reconciliação de webhook. E leia a taxa de conclusão junto: uma campanha pode ter aprovação alta sobre poucas verificações concluídas, e o funil de verificação mostra onde as outras ficaram.

Fontes citadas

• Google Analytics Help, "URL builders: Collect campaign data with custom URLs": support.google.com
• Google Analytics Help, "Best practices to avoid sending Personally Identifiable Information (PII)": support.google.com
• Lei 13.709/2018 (Lei Geral de Proteção de Dados Pessoais), artigo 6º: planalto.gov.br