# Pixel Meta e API de Conversões no PrestaShop > O pixel do navegador já só vê uma parte das suas conversões, e a perda agrava-se. Como articular os dois canais, porque é a deduplicação o ponto crítico, e aquilo de que o envio pelo servidor não dispensa. - Página: - Idioma: pt - Publicado em: 2026-09-12 - Atualizado em: 2026-09-12 - Outros idiomas: [fr](https://www.datafirefly.com/2026/09/12/pixel-meta-api-conversions-prestashop/index.md), [en](https://www.datafirefly.com/en/2026/09/12/meta-pixel-conversions-api-prestashop/index.md), [es](https://www.datafirefly.com/es/2026/09/12/pixel-meta-api-conversiones-prestashop/index.md), [de](https://www.datafirefly.com/de/2026/09/12/meta-pixel-conversions-api-prestashop-einrichten/index.md), [it](https://www.datafirefly.com/it/2026/09/12/pixel-meta-api-conversioni-prestashop/index.md), [pl](https://www.datafirefly.com/pl/2026/09/12/piksel-meta-api-konwersji-prestashop/index.md), [nl](https://www.datafirefly.com/nl/2026/09/12/meta-pixel-conversies-api-prestashop/index.md) - Índice: 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. ## 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 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.