E-commerce

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

CamadaFerramentaFunção
Banner consentimentoCookiebot, Iubenda, ou banner próprio (IAB TCF v2.2)Recolher e propagar consentimento
Tag managerGoogle Tag Manager (Web + Server)Orquestrar tags
AnalyticsGA4 com Consent Mode v2Medir
Conversions MetaMeta Pixel + Conversions APIOtimizar Ads
Conversions Google AdsEnhanced Conversions com email hashedOtimizar 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çãoCusto mensalEsforçoLatência
Google Cloud Run20–80€Baixo (setup guiado)Muito baixa
Stape.io20–250€Mínimo (managed)Baixa
App Engine / DigitalOcean30–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:

Fontes

Precisas de um site ou loja online?

Agência digital portuguesa. Sites e lojas online rápidos, otimizados para o Google e feitos para resultado.

Pedir orçamento