Tracking no checkout: Pixel CAPI, Consent Mode v2 e RGPD em lojas PT

A maior parte das lojas portuguesas instalou o Meta Pixel e o Google Analytics há anos, esqueceu-se deles, e em 2026 está numa de três situações: tracking partido (iOS 17/Safari ITP comeram os cookies), tracking ilegal (sem consentimento válido), ou tracking redundante (Pixel client-side a duplicar o CAPI server-side). Para uma loja a fazer 30 mil€/mês, isto traduz-se em decisões de Ads tomadas com 30-40% dos dados que devia ter, e em risco real de queixa CNPD.

Este guia mostra o stack mínimo correto em 2026: Consent Mode v2 + GTM server-side + Meta CAPI + email hashed, com RGPD em primeiro lugar.

O que mudou (e porque o teu setup de 2022 já não chega)

Três forças simultâneas:

1. Apple ITP / iOS 17, cookies third-party morreram em Safari. First-party cookies têm vida útil curtíssima.
2. Browsers a bloquear Pixel client-side, Brave, Firefox strict, extensões. Perda típica: 25-45% dos eventos client-side.
3. CNPD e EDPB mais ativas em consentimento e transferências para EUA, Schrems II, Data Privacy Framework, decisões recentes contra Google Analytics 3.

O efeito prático: tracking só client-side dá menos sinal e mais risco. A solução é server-side + consentimento sério.

O stack que recomendamos em 2026

Camada	Ferramenta	Função
Banner consentimento	Cookiebot, Iubenda, ou banner próprio (IAB TCF v2.2)	Recolher e propagar consentimento
Tag manager	Google Tag Manager (Web + Server)	Orquestrar tags
Analytics	GA4 com Consent Mode v2	Medir
Conversions Meta	Meta Pixel + Conversions API	Otimizar Ads
Conversions Google Ads	Enhanced Conversions com email hashed	Otimizar Ads

Não é o stack mais simples. É o mínimo razoável para uma loja PT que pretende ficar legal e continuar a otimizar Ads em iOS.

Consent Mode v2, o que é, em concreto

Desde março de 2024, o Google exige Consent Mode v2 para usar dados em otimização de Ads no EEE. Há dois sinais que tens de propagar a partir do teu banner:

• ad_storage, cookies de Ads.
• ad_user_data, dados do utilizador para Ads.
• ad_personalization, personalização de anúncios.
• analytics_storage, cookies de analítica.

Sem isto, o GA4 e o Google Ads passam a operar em modelo "consent-denied" e perdes capacidade de remarketing e de Enhanced Conversions.

Implementação: o teu banner (cookie banner e consentimento) tem de chamar gtag('consent', 'update', {...}) com os 4 sinais conforme escolha do utilizador. Cookiebot e Iubenda fazem isto automaticamente. Banner caseiro tem de ser cuidadosamente programado.

GTM server-side: porque vale o trabalho

Tags server-side (GTM Server Container, alojado em Cloud Run/App Engine ou subdomínio próprio) trazem três benefícios:

1. Sobrevivência a bloqueadores, o cliente bate no teu subdomínio (gtm.tualoja.pt), não em googletagmanager.com. Não é bloqueado por ad-blockers genéricos.
2. Controlo de dados, decides o que sai do teu servidor para o Google/Meta. Podes minimizar payload, remover IPs, hash de emails.
3. Conversions API real, em vez de o Pixel cliente disparar PII para a Meta, o teu servidor envia eventos curados via CAPI.

Custo típico em PT: ~30-50€/mês de infra + dia de setup. Para lojas a partir de 15.000€/mês de revenue, paga-se em redução de CAC.

Meta Pixel + Conversions API: o duo certo

A combinação canónica em 2026 é Pixel client-side + CAPI server-side com deduplicação por event_id.

• Pixel dispara PageView, ViewContent, AddToCart no browser (quando há consentimento).
• CAPI envia os mesmos eventos do servidor, com mais robustez (email hashed, IP, user agent).
• event_id comum permite à Meta deduplicar.

Resultado: cobertura de eventos sobe de ~55-65% (só Pixel) para ~85-95% (Pixel + CAPI deduplicado). Em iOS é a diferença entre otimizar Ads bem ou às cegas.

Configuração: no Events Manager da Meta + plugin oficial (WooCommerce Pixel Manager, ou Facebook for WooCommerce com CAPI ativo) ou via GTM Server.

Email hashed e Enhanced Conversions

Tanto Google Ads (Enhanced Conversions) como Meta CAPI suportam email hashed em SHA-256. Não é o email em claro, é um hash irreversível que permite ao Google/Meta cruzar com a base deles sem teres partilhado PII em claro.

Implementação: no teu purchase event no checkout, envias hashed_email, hashed_phone (se relevante), hashed_first_name, e o sistema do lado de lá faz match.

Ganho real: +10 a +30% em conversões reportadas em campanhas de remarketing/Pmax. É a diferença entre um Pmax que aprende e um que não aprende. Vale tanto para Google Ads como para Meta Ads, qualquer plano de Ads sério em 2026 assume este sinal.

Cuidado: hashing não dispensa consentimento. O envio destes dados continua a precisar de base legal, o utilizador autorizou a transferência para fins de marketing, e a tua política de privacidade (website RGPD) explica-o.

IAB TCF v2.2, quando precisas

O IAB Transparency & Consent Framework v2.2 é um standard de comunicação de consentimento entre publisher e vendors (Google, Meta, etc.). Em PT:

• Não obrigatório para uma loja própria que só usa GA + Meta + Google Ads.
• Obrigatório de facto se trabalhas com Ad Networks tipo OpenX, Xandr, vendors esperam TCF string.
• Útil se a tua loja é também um media (publicas conteúdo, monetizas com display de terceiros).

Cookiebot e Iubenda emitem TCF strings se ligares a opção. Banner caseiro raramente cobre TCF de forma certificada.

Servidor-side, primeira parte, e a CNPD

A CNPD e o EDPB têm sido claros sobre dois pontos:

1. Consentimento ANTES de qualquer cookie/pixel não estritamente necessário. Banner que só carrega scripts após escolha. Banner que define "rejeitar" como botão tão visível como "aceitar".
2. Transferências para EUA, sob Data Privacy Framework há base legal renovada (julho 2023), mas a tua política tem de o dizer.

GA4 com IP anonymization + Consent Mode v2 + servidor de tags em UE é hoje aceite pela maioria das DPAs europeias. Vê também o post sobre analítica do site e RGPD para o detalhe da configuração.

O que mostrar e em que ordem (banner)

Banner correto, 2026:

1. Primeira camada, texto curto, 3 botões iguais em peso visual: Aceitar tudo, Rejeitar tudo, Personalizar.
2. Sem dark patterns, nada de "X" que conta como aceite, nada de pré-marcado, nada de "aceitar" gigante e "rejeitar" pequeno.
3. Categorias, Essenciais (sempre), Analítica, Marketing, Personalização. Cada uma com vendors visíveis.
4. Reabertura, link no rodapé sempre acessível.
5. Log de consentimento, guardar prova com timestamp.

Banner não conforme = nenhum dos dados que recolhes é legítimo. A primeira queixa CNPD pode mandar abaixo todo o tracking.

O que tipicamente está mal nas lojas PT em 2026

• Pixel a disparar antes de aceitar, clássico, comum em 60% das lojas auditadas.
• GA4 sem Consent Mode v2, perde sinal e está fora de compliance.
• CAPI configurado mas sem deduplicação, duplica eventos, estraga ROAS reportado.
• Banner sem botão "Rejeitar" no primeiro nível, não-conforme.
• "Marketing" e "Necessários" só no primeiro nível, falta "Analítica" como categoria separada.
• Email não hashed enviado para a Meta, risco legal sério.

Roadmap razoável (4 semanas)

• Semana 1: auditoria, o que carrega antes do consent, banner atual, configuração GA4/Meta.
• Semana 2: banner novo com Consent Mode v2, propagação correta.
• Semana 3: Meta CAPI + deduplicação por event_id; Google Enhanced Conversions com email hashed.
• Semana 4: GTM server-side se a escala justifica (>15k€/mês).

Não tentes saltar para o ideal em 3 dias, é receita para um setup partido.

GA4: o que mudar no setup standard

A maior parte das instalações GA4 em PT herdou definições UA antigas e não foi revista. Checklist do mínimo razoável em 2026:

• Anonimização de IP ativa (já é default em GA4, mas confirma).
• Data retention 14 meses (max) e revisão para "14 months" em vez do default 2 meses.
• Domains list com o teu domínio + subdomínios (sem isto, cross-domain rebenta).
• Exclusões de tráfego interno por IP da empresa.
• Eventos enhanced ecommerce completos: view_item, add_to_cart, begin_checkout, purchase com value e items.
• Conversões marcadas só para purchase + lead form submit. Não 18 conversões, não saberás qual move o ponteiro.

GA4 com 18 conversões marcadas é dashboard inútil. Foca em 2-3.

Server-side tagging, onde alojar

Se vais para GTM Server, há três caminhos:

Opção	Custo mensal	Esforço	Latência
Google Cloud Run	20-80€	Baixo (setup guiado)	Muito baixa
Stape.io	20-250€	Mínimo (managed)	Baixa
App Engine / DigitalOcean	30-60€	Médio (DevOps)	Baixa

Para a maioria das lojas PT que entra no server-side, Stape é a opção pragmática, gerem o servidor, têm templates prontos para CAPI, Google Ads, GA4. Custo mais alto que Cloud Run a sério, mas zero dor.

Em qualquer caso: subdomínio próprio (metrics.tualoja.pt) com SSL próprio, não o domínio default do provider.

Em resumo

Tracking de loja em PT, em 2026, exige um stack que não é difícil mas é detalhista: Consent Mode v2 a sério, banner que respeita o "rejeitar", Meta CAPI com event_id, email hashed, e, quando a escala justifica, GTM server-side. Fazer bem dá mais sinal em iOS, menos custo em Ads, e protege da CNPD. Fazer mal acumula nas três frentes ao mesmo tempo.

---

No sitesfixe.pt configuramos tracking de lojas online portuguesas com Consent Mode v2, Meta CAPI e RGPD em primeiro lugar, sem partir Ads nem clientes. Lojas online desde 3.500€. Manutenção desde 80€/mês. Pede um orçamento sem compromisso.

Lê também:

• Cookie banner e consentimento
• Analítica do site e RGPD
• Loja online e RGPD

Fontes

• CNPD, Comissão Nacional de Proteção de Dados
• Google, Consent Mode v2
• Meta, Conversions API