Os erros de CAPI que não aparecem em lugar nenhum
Não são os erros com mensagem que custam caro — esses você conserta. São os seis que respondem 200, reportam sucesso e entregam a coisa errada por semanas.
Integração de conversão quase nunca falha com estrondo. Ela falha reportando sucesso — e é isso que faz o problema durar semanas em vez de minutos.
Os seis abaixo foram encontrados em produção, todos com o painel verde e a fila vazia.
1. Aceito não é pareado
O primeiro mal-entendido é o mais básico. A resposta 200 da API significa que o evento foi recebido e é válido. Não significa que ele foi atribuído a alguém, nem que ele apareceu em algum relatório.
Um evento sem identidade suficiente é aceito com a mesma resposta de um evento perfeito. A diferença só aparece na qualidade da correspondência, dias depois, agregada.
2. O nome de evento que ninguém conhece
Escreveu Purchases em vez de Purchase, ou usou o nome que a plataforma de destino não reconhece? Na maioria dos destinos isso não é rejeitado: vira um evento personalizado, com aquele nome, num canto do painel que ninguém abre.
A conversão está lá. Ela só não é a conversão que a campanha otimiza.
3. O campo que a tela oferece e o envio ignora
Já detalhamos esse em outro texto, mas ele merece a lista: é comum a interface oferecer uma opção — origem da ação, recusa de uso de dados, modo de teste — que o código de envio não lê. A escolha é gravada, e não chega a lugar nenhum.
A conferência que resolve é sempre a mesma: olhe o corpo que saiu, não a tela onde você configurou.
4. O filtro que aponta para um campo inexistente
Este é o mais caro dos seis. Um filtro que compara um campo que não existe no payload não dá erro: ele avalia como falso, e o envio para de entregar tudo. Ou, dependendo de como o operador foi implementado, avalia como verdadeiro e entrega tudo.
Medimos os dois. Num caso, uma condição sobre um campo que só existe em assinatura derrubou 100% das vendas avulsas — treze vendas reais em trinta e cinco minutos, com o painel indicando que o sinal tinha sido emitido e nada sendo entregue.
Noutro, um operador que o motor não conhecia caía no caso padrão e devolvia verdadeiro, então o filtro que deveria recortar um formulário específico deixava todos passarem, sem restrição e sem aviso.
5. A coerção que engole o valor falso
Um subtipo do anterior, e tão sutil que passou por muitos testes antes de aparecer. Um trecho de código lia o campo e aplicava um padrão para valor ausente. O problema é que o padrão disparava também para valores legítimos que o computador considera falsos: o booleano falso e o número zero.
Na prática: toda compra avulsa, que chega com um campo marcado como falso, era lida como campo vazio. A condição que testava exatamente esse valor nunca casava. O sintoma na tela era um campo mostrando vazio enquanto o payload, ao lado, mostrava o valor lá.
A lição prática que ficou: campo aparecendo vazio na auditoria enquanto existe no payload é sinal de coerção, não de dado faltando.
6. O nome do evento que se configura não é o que chega
Nas plataformas de checkout, o nome que você escolhe ao cadastrar o webhook e o nome que aparece dentro do payload frequentemente são diferentes. Você configura compra aprovada e recebe uma chave em inglês; configura carrinho abandonado e recebe uma forma completamente diferente, sem a chave de tipo.
Um filtro escrito lendo a tela de configuração da plataforma nunca casa. E como "nunca casar" não é um erro, o envio fica silencioso.
O método que encontra os seis
Nenhum deles aparece em log de erro, porque nenhum é um erro. Todos aparecem numa comparação:
- 01Conte os eventos de origem no período e as entregas aceitas no mesmo período. Divergência é a pista.
- 02Abra o payload de uma entrega real e confira campo a campo contra o que você configurou.
- 03Rode o filtro configurado sobre os últimos eventos reais e veja quantos passariam.
- 04Confira o nome do evento como ele chega no payload, nunca como aparece no painel da plataforma.
Os quatro passos levam menos de uma hora e valem por qualquer quantidade de leitura de documentação.
No CrazyLeads o payload entregue fica guardado e visível por entrega, o filtro pode ser testado contra os últimos eventos reais antes de publicar, e a auditoria mostra a condição que reprovou com o valor esperado e o valor encontrado, lado a lado.