O pixel instalado no navegador já só vê uma parte das suas conversões. Bloqueadores de publicidade, recusa de consentimento, restrições dos navegadores aos cookies de terceiros: a perda é estrutural e agrava-se. A API de Conversões existe para a compensar, desde que seja implementada corretamente.
Os dois canais
O pixel do navegador executa-se no equipamento do visitante. Capta o contexto completo: identificadores publicitários, cookies, comportamento de navegação. É bloqueado assim que entra em jogo um bloqueador, uma extensão ou uma recusa de consentimento.
A API de Conversões envia o evento a partir do seu servidor para a plataforma, sem passar pelo navegador. Não é bloqueada, mas só dispõe daquilo que lhe transmitir, e é cega ao percurso de navegação.
Os dois não são alternativos. A configuração recomendada põe-nos a funcionar em conjunto nos mesmos eventos, com um mecanismo de deduplicação.
A deduplicação
É o ponto técnico central, e aquele que as implementações falham com mais frequência.
Se uma compra é enviada pelo pixel e pela API sem mecanismo de aproximação, a plataforma conta duas conversões. Os seus relatórios mostram o dobro do volume, o seu custo por aquisição aparece a metade, e as suas decisões de investimento publicitário assentam em números falsos.
A aproximação assenta em dois valores, que têm de ser estritamente idênticos nos dois envios: o nome do evento e um identificador único gerado para essa ocorrência.
Três regras práticas. O identificador deve ser gerado no servidor e depois transmitido ao pixel, não o contrário. Deve ser estável se a página for recarregada, o que exclui um sorteio aleatório a cada apresentação: a referência da encomenda é o melhor candidato para a compra. E deve ser único por ocorrência, não por produto nem por sessão.
Facebook Dynamic Ads + Pixel PRO: Feed de Produtos, Pixel e API de Conversões (PrestaShop 8 e 9)Venda os seus produtos no Facebook e no Instagram, e meça cada conversão89,00€
O que a API espera
Ao contrário do pixel, que adivinha muito, a API só conhece aquilo que enviar. Três famílias de informação.
Os dados de correspondência do cliente. E-mail, telefone, nome próprio, apelido, cidade, código postal, país. Servem para ligar a conversão a um utilizador da plataforma. Devem ser normalizados e depois processados por hash antes do envio, nunca transmitidos em claro.
Os dados do evento. Nome, data e hora, valor, moeda, conteúdo da encomenda com os identificadores de produto.
Os dados de contexto. Endereço IP e agente de utilizador do visitante, mais os identificadores de clique publicitário se estiverem presentes no URL de chegada. Estes dois últimos melhoram nitidamente a correspondência e são muitas vezes esquecidos.
A qualidade da correspondência
A plataforma calcula uma pontuação que mede a sua capacidade de ligar os seus eventos a utilizadores. Essa pontuação condiciona diretamente o desempenho das suas campanhas, e é bem mais determinante do que o volume de eventos enviados.
Três alavancas para a melhorar. Enviar mais parâmetros de correspondência: cada campo adicional aumenta a probabilidade de ligação. Normalizar corretamente antes do hash: minúsculas, remoção de espaços, formato internacional para os telefones (+351 em Portugal). E transmitir os identificadores de clique, que são os sinais mais fiáveis.
Uma pontuação baixa não se vê nos seus relatórios de conversão, vê-se no desempenho das suas campanhas. É isso que a torna difícil de diagnosticar.
O consentimento
Ponto a tratar a sério, porque o envio pelo servidor não dispensa nada.
O facto de o evento partir do seu servidor e não do navegador não muda a sua natureza jurídica. Se o visitante recusou os rastreadores publicitários, não deve transmitir os dados dele a uma plataforma publicitária, seja qual for o canal técnico. Em Portugal isto decorre do RGPD e da Lei n.º 41/2004, sob supervisão da CNPD.
A API de Conversões compensa a perda devida aos bloqueadores e às limitações técnicas dos navegadores, não a devida à recusa de consentimento. Apresentar o contrário é uma leitura errada que circula muito.
Na prática, a sua implementação no servidor tem de conhecer o estado do consentimento do visitante e condicionar o envio.
Os eventos a cobrir
Cinco chegam para gerir campanhas de e-commerce: consulta de conteúdo, adição ao carrinho, início do pagamento, compra, e inscrição se lhe der uso.
A compra é o único que tem obrigatoriamente de passar pelos dois canais com deduplicação. Os outros podem ficar-se pelo pixel numa primeira fase, vindo a cobertura pelo servidor depois.
Um ponto de coerência a vigiar: os identificadores de produto enviados nos eventos têm de corresponder exatamente aos do seu feed de produtos. Uma divergência impede o funcionamento das campanhas dinâmicas, que assentam nessa ligação.
Verificar
Três controlos, por esta ordem.
A ferramenta de teste da plataforma, que mostra os eventos recebidos em tempo real com a sua origem. Faça uma encomenda completa e verifique que a compra aparece uma vez, com a menção de que houve deduplicação.
A pontuação de qualidade da correspondência, a registar ao fim de alguns dias de atividade e a comparar com as referências da plataforma.
A comparação com o seu back-office, sobre uma semana. Um desvio de 10 a 20 % a menos continua normal. Um desvio positivo, com a plataforma a contar mais compras do que as que registou, assinala uma falha de deduplicação.
O módulo Facebook Dynamic Ads e Pixel PRO para PrestaShop implementa esta dupla cobertura no PrestaShop 8 e 9: pixel do navegador e API de Conversões com deduplicação por identificador de evento, hash dos dados de correspondência, respeito pelo consentimento e geração do feed de produtos para as campanhas dinâmicas.