Data strength no Google Ads e WooCommerce: dados first-party e GTM no servidor

No Outono de 2026 a Google colocou os dados first-party no centro da medição do Google Ads. A 10 de Setembro anunciou a métrica Data Strength Uplift e um Data Manager alargado (blog Google Ads and Commerce), e a página de ajuda Data Strength Best Practices lê-se agora como um guia de implementação passo a passo. A direcção é clara: colar um píxel de JavaScript no cabeçalho das páginas já não chega. Face ao reforço das exigências de privacidade, às limitações nativas dos navegadores como o Safari ITP e ao uso generalizado de bloqueadores de anúncios, a rentabilidade das campanhas de comércio electrónico depende hoje directamente da integridade dos dados first-party e de infraestruturas de medição executadas no servidor.

Para os proprietários de lojas WooCommerce e arquitectos de software no ecossistema WordPress, este cenário exige a substituição de plugins genéricos por arquitecturas de dados concebidas com rigor. Uma loja que transmite dados fragmentados ou incompletos às plataformas de anúncios paga por isso: os algoritmos de licitação inteligente (Smart Bidding) operam com pouca clareza de atribuição e o custo por aquisição (CPA) sobe.

Neste guia técnico explicamos o que abrange o Data Strength, que sinais a Google pede, os requisitos de engenharia das conversões melhoradas (Enhanced Conversions) e como implementar o Google tag gateway e o Server-Side Google Tag Manager (sGTM) no domínio da própria loja.

#O que significa data strength no Google Ads e porque determina os custos das campanhas

Data Strength é o termo genérico que a Google usa para a configuração de medição baseada em dados first-party que alimenta o Google Ads. A página de ajuda divide-a em quatro passos: ligar as fontes de dados, maximizar os sinais, activar a IA da Google (Smart Bidding, AI Max for Search, Demand Gen, Performance Max) e provar o retorno com experiências de incrementalidade e o modelo de marketing mix Meridian. Estes dados são um dos valores de entrada dos modelos de aprendizagem automática que licitam em campanhas Performance Max, Demand Gen e na rede de pesquisa, pelo que falhas nos dados se tornam falhas na licitação.

Dois pontos do Google Ads traduzem isto em números. A nova métrica Data Strength Uplift, segundo o anúncio da Google, calcula as conversões adicionais recuperadas pela configuração de dados first-party. As classificações de qualidade vêm dos diagnósticos: os diagnósticos de dados offline classificam os dados importados como Excellent (pelo menos 90% dos eventos bem formatados), Good (cerca de 70 a 90%), Needs attention (menos de 70%) ou No recent data (nenhum evento nos últimos 28 dias). As conversões melhoradas têm um relatório de diagnóstico próprio.

Numa loja WooCommerce, a configuração descrita pela Google resume-se a quatro condições técnicas:

1. Rigor e integralidade dos atributos de transacção: Cada encomenda submetida tem de apresentar o montante exacto, o código monetário padronizado segundo a norma ISO 4217 e um identificador de encomenda exclusivo (Transaction ID) para eliminar duplicações.
2. Densidade de identificadores first-party cifrados: Envio de dados de e-mail, contacto telefónico e morada devidamente normalizados e transformados em hash, permitindo à Google associar as compras a contas Google com sessão iniciada.
3. Conformidade técnica com o Consent Mode v2: Transmissão correcta dos sinais ad_user_data e ad_personalization em sintonia com a escolha declarada pelo visitante na barra de consentimento. A página de ajuda da Google não inclui o consentimento como passo do Data Strength, mas na UE nenhum identificador pode ser enviado sem ele.
4. Continuidade da conduta de dados: Supressão de falhas e quebras originadas por tempos de espera em scripts, passagens por gateways bancários externos ou bloqueios de rede.

Quando faltam dados, o Smart Bidding vê-se obrigado a trabalhar com incerteza. Vê menos conversões do que a loja regista, avalia os cliques com menos evidência, e o retorno sobre o investimento publicitário (ROAS) e o custo de conversão evoluem no sentido errado.

#Que sinais o guia de data strength da Google pede aos anunciantes

O passo “maximizar os sinais” da página Data Strength Best Practices enumera os identificadores que a Google quer receber com cada conversão:

• Dados do cliente: e-mail ou telefone cifrados, que as conversões melhoradas comparam com os dados de utilizadores Google com sessão iniciada para recuperar conversões não observadas.
• Endereço IP: enviado nas importações pelo Data Manager. A Google indica até 3% mais conversões observadas na Pesquisa e mais de 10% no YouTube numa simulação offline.
• Transaction ID: o número da encomenda ou do lead que liga o clique no frontend à venda no backend.
• GCLID: o identificador de clique que indica à Google qual a campanha que gerou a venda.
• Atributos de sessão: ID da campanha, URL completo da página de destino, marca temporal da sessão, navegador e sistema operativo.
• GBRAID e WBRAID: parâmetros de URL que recuperam a atribuição de conversões em iOS e em navegação privada.

Daqui resultam duas regras. A Google recomenda enviar pelo menos 3 identificadores por evento, dando prioridade ao GCLID e ao IP ao lado dos dados do cliente cifrados, e enviar todos os eventos de conversão em vez de apenas uma parte.

No WooCommerce a maioria destes valores já existe na encomenda. $order->get_order_number() é o ID da transacção, $order->get_customer_ip_address() devolve o IP registado no checkout e os campos de facturação contêm os dados do cliente. O GCLID, o GBRAID e o WBRAID só aparecem como parâmetros no URL da página de destino, por isso uma loja que queira enviar conversões a partir do servidor tem de os captar na primeira visualização de página e guardá-los com a encomenda.

A Google sustenta a página com números próprios, cada um com a base indicada:

São medições internas da Google, não estudos independentes. Use-as como indicação do sentido do efeito e meça a sua loja antes e depois.

#Porque é que os píxeis tradicionais no navegador perdem conversões

Durante mais de duas décadas, as métricas de comércio electrónico dependiam quase em exclusivo de código executado no navegador do comprador (client-side tracking). Assim que a compra ficava concluída, um script extraía valores da estrutura DOM da página de agradecimento e disparava uma comunicação HTTP para servidores externos. Em 2026, esta abordagem tornou-se extremamente vulnerável.

#Como os bloqueadores de anúncios e o Safari ITP encurtam a vida dos cookies

Existem três obstáculos estruturais que conduzem à perda irreversível de dados nas arquitecturas de rastreio clássicas:

Sempre que um consumidor conclui o pagamento num portal financeiro externo e não aguarda pelo reencaminhamento automático para a página de confirmação da loja, os scripts convencionais não são accionados. A encomenda fica registada no painel do WooCommerce, mas o Google Ads não recebe qualquer confirmação do evento.

#Porque é que o Smart Bidding no Google Ads precisa de dados first-party

Os algoritmos de licitação automatizada procuram prever a probabilidade de transacção de cada utilizador antes de emitirem uma licitação no leilão. Quanto maior for o volume de atributos de identidade que o modelo consegue ligar a uma impressão, mais preciso se torna o cálculo do valor esperado desse utilizador.

Na ausência de identificadores first-party, o modelo detecta unicamente uma sessão genérica e um clique anónimo. Com um endereço de e-mail cifrado, a Google faz corresponder a conversão a uma conta Google com sessão iniciada e pode atribuí-la à interacção com o anúncio que a precedeu (Ajuda do Google Ads). Mais conversões atribuídas dão ao modelo de licitação mais exemplos dos cliques que acabam em encomenda.

#Como funcionam as conversões melhoradas (Enhanced Conversions) no WooCommerce

O mecanismo de conversões melhoradas agrega aos eventos de compra normais um pacote de identificadores recolhidos no formulário de pagamento e transformados por uma função de hash irreversível. Desde Abril de 2026 as conversões melhoradas para a Web e para leads são uma única definição de activar/desactivar no Google Ads, e os utilizadores existentes foram migrados automaticamente.

#Que dados do cliente devem ser cifrados com SHA-256 antes do envio

O guia da Google sobre conversões melhoradas exige que os dados pessoais sejam normalizados e cifrados com SHA-256 em hexadecimal, e que cada valor seja enviado como cadeia de texto:

• Endereço de e-mail: Eliminação de espaços em branco marginais, conversão integral para minúsculas e cálculo do valor de dispersão SHA-256. A partir de [email protected] obtém-se o termo de entrada [email protected]. Nos endereços gmail.com e googlemail.com removem-se ainda os pontos antes do @.
• Contacto telefónico: Eliminação de traços, espaços e parênteses, estruturação de acordo com a norma E.164, com 11 a 15 dígitos incluindo o sinal mais e o código de país (por exemplo, +351912345678), e aplicação do algoritmo SHA-256.
• Primeiro e último nome: Caracteres em minúsculas, supressão de pontuação e de espaçamentos desnecessários.
• Código postal e país: Código postal limpo de caracteres supérfluos e sigla de duas letras atribuída ao país em conformidade com a norma ISO 3166-1 alpha-2 (como PT ou ES). A correspondência por morada exige nome próprio, apelido, código postal e país em conjunto.

#Código PHP completo para woocommerce_thankyou e o dataLayer

O fragmento de código que se apresenta deve ser integrado no ficheiro functions.php do tema filho ou através de um plugin funcional. Este script alimenta a camada de dados (dataLayer) na página de finalização da encomenda com hashes SHA-256 obtidos directamente no PHP:

<?php
/**
 * Implementação da camada de dados para Enhanced Conversions no WooCommerce
 */
add_action('woocommerce_thankyou', 'wppoland_inject_enhanced_conversions_datalayer', 20);

function wppoland_inject_enhanced_conversions_datalayer($order_id) {
    if (!$order_id) {
        return;
    }

    $order = wc_get_order($order_id);
    if (!$order || $order->has_status('failed')) {
        return;
    }

    // Normalização e cifragem do endereço de correio eletrónico
    $raw_email = strtolower(trim($order->get_billing_email()));
    // gmail.com e googlemail.com: remover os pontos antes do @
    if (preg_match('/^([^@]+)@(gmail|googlemail)\.com$/', $raw_email, $m)) {
        $raw_email = str_replace('.', '', $m[1]) . '@' . $m[2] . '.com';
    }
    $hashed_email = hash('sha256', $raw_email);

    // Normalização e cifragem do número telefónico (formato E.164)
    $raw_phone = preg_replace('/[^0-9+]/', '', $order->get_billing_phone());
    if (strpos($raw_phone, '+') !== 0 && strlen($raw_phone) === 9) {
        $raw_phone = '+351' . $raw_phone; // Prefixo predefinido para números em Portugal
    }
    $hashed_phone = hash('sha256', $raw_phone);

    // Preparação dos dados de nome e endereço
    $raw_first_name = strtolower(trim($order->get_billing_first_name()));
    $raw_last_name  = strtolower(trim($order->get_billing_last_name()));
    $hashed_first_name = hash('sha256', $raw_first_name);
    $hashed_last_name  = hash('sha256', $raw_last_name);

    $postal_code = trim($order->get_billing_postcode());
    $country_code = strtoupper(trim($order->get_billing_country()));

    // Enumeração dos produtos adquiridos
    $items = [];
    foreach ($order->get_items() as $item) {
        $product = $item->get_product();
        if ($product) {
            $items[] = [
                'item_id'   => (string) $product->get_id(),
                'item_name' => $item->get_name(),
                'price'     => (float) $order->get_item_total($item, false, false),
                'quantity'  => (int) $item->get_quantity(),
            ];
        }
    }

    ?>
    <script>
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
        event: 'purchase',
        ecommerce: {
            transaction_id: '<?php echo esc_js($order->get_order_number()); ?>',
            value: <?php echo (float) $order->get_total(); ?>,
            tax: <?php echo (float) $order->get_total_tax(); ?>,
            shipping: <?php echo (float) $order->get_shipping_total(); ?>,
            currency: '<?php echo esc_js($order->get_currency()); ?>',
            items: <?php echo json_encode($items); ?>
        },
        user_data: {
            sha256_email_address: '<?php echo esc_js($hashed_email); ?>',
            sha256_phone_number: '<?php echo esc_js($hashed_phone); ?>',
            address: {
                sha256_first_name: '<?php echo esc_js($hashed_first_name); ?>',
                sha256_last_name: '<?php echo esc_js($hashed_last_name); ?>',
                postal_code: '<?php echo esc_js($postal_code); ?>',
                country: '<?php echo esc_js($country_code); ?>'
            }
        }
    });
    </script>
    <?php
}

Ao processar as cadeias SHA-256 no próprio servidor PHP, os dados de identificação em texto limpo nunca são expostos a variáveis de JavaScript acessíveis no navegador, assegurando a protecção de dados e a robustez da solução.

#Como verificar se as conversões melhoradas funcionam no WooCommerce

A Google indica três verificações, todas no mesmo artigo de ajuda:

1. Pedido de rede na página de agradecimento: faça uma encomenda de teste, abra o Chrome DevTools, vá ao separador Network e localize o pedido de conversão. Deve conter um parâmetro em: o e-mail aparece como tv.1~em seguido de um hash e o telefone como tv.1~pn. Um prefixo sem hash significa que o campo estava vazio quando o tag disparou, o que no WooCommerce costuma indicar que o tag dispara antes do push para o dataLayer.
2. Relatório de diagnóstico: o Google Ads mostra o diagnóstico das conversões melhoradas cerca de 48 horas após a implementação.
3. Impacto: o efeito nas conversões reportadas torna-se visível ao fim de cerca de 30 dias.

Duas definições bloqueiam a recolha sem qualquer aviso. Os dados não são recolhidos enquanto os termos relativos aos dados de clientes não forem aceites no Google Ads ou no Google Analytics, e no tag Google a opção Allow user-provided data capabilities tem de estar activa. Quando o fragmento de código e a detecção automática fornecem dados em simultâneo, a Google dá sempre prioridade ao fragmento de código.

#Como implementar o Server-Side Google Tag Manager num subdomínio próprio

Mesmo que a estrutura de dataLayer no cliente esteja impecável, os dados perdem-se se a chamada HTTP for cancelada por filtros de conteúdo. É aqui que entra um contentor Server-Side Google Tag Manager (sGTM).

#Porque é que o server-side GTM no domínio próprio é mais difícil de bloquear

No esquema de rastreio convencional, o navegador estabelece ligação directa a domínios externos como googleadservices.com. Os sistemas de bloqueio mantêm registos actualizados destes destinos e cortam os pedidos na origem.

Numa implementação de sGTM, o ponto de recolha funciona no domínio da própria loja, por exemplo num subdomínio como:

https://metricas.a-sua-loja.pt

O guia da Google sobre domínio próprio descreve três opções:

Aos olhos do navegador, os pedidos nas duas primeiras opções pertencem ao domínio da loja (contexto de primeira parte), pelo que as listas de bloqueio dirigidas aos domínios da Google não os apanham. Há uma ressalva para o subdomínio: desde o Safari 14, o WebKit detecta a camuflagem CNAME de terceiros e limita a 7 dias os cookies definidos nessas respostas (blog do WebKit). Um subdomínio que seja um CNAME para o domínio de um fornecedor de alojamento pode cair nessa regra, o que é mais uma razão para preferir a mesma origem.

No servidor, o contentor de sGTM:

1. Acolhe um único pacote consolidado de eventos gerado pelo cliente.
2. Filtra cabeçalhos e suprime atributos redundantes ou sensíveis.
3. Define cookies na resposta HTTP no domínio da própria loja, em vez de o fazer por JavaScript.
4. Encaminha as notificações em simultâneo para o Google Ads, a Meta Conversions API (CAPI) e o Google Analytics 4.

#Quanto custa manter o server-side GTM no Cloud Run

O guia da Google para o Cloud Run apresenta valores de dimensionamento que convém conhecer antes de avançar para o sGTM:

• Cada servidor de tagging é uma instância do Cloud Run com 1 vCPU e 0,5 GB de memória, facturada no modelo de CPU sempre atribuída. A Google estima cerca de 45 USD por servidor por mês.
• A Google recomenda um mínimo de 2 instâncias em produção para reduzir o risco de perda de dados durante uma falha.
• O escalonamento automático entre 2 e 10 servidores deverá suportar 35 a 350 pedidos por segundo, consoante o número de tags.
• O valor de max-instances define o pior cenário de custo, por isso defina-o com cuidado e crie um alerta de facturação.
• O servidor de pré-visualização, que suporta o modo de pré-visualização do Tag Manager, é aprovisionado à parte.
• Para um público global, a Google sugere a implementação em várias regiões atrás de um load balancer.

O App Engine e uma configuração manual em qualquer plataforma estão documentados como alternativas. Numa loja WooCommerce pequena, duas instâncias a funcionar o mês inteiro são um custo mensal fixo que tem de ser comparado com as conversões recuperadas.

#Como transferir os scripts de análise para o servidor melhora a velocidade da loja

As lojas WooCommerce tradicionais descarregam dezenas de ficheiros externos de rastreio: Google Ads, Meta Pixel, códigos do TikTok, Pinterest e ferramentas de gravação de sessões. Cada um destes ficheiros consome recursos de computação no dispositivo móvel do cliente, prejudicando as Core Web Vitals, em particular a métrica Interaction to Next Paint (INP).

A passagem da lógica para o servidor consolida esses ficheiros num único tag colector de baixo consumo. O navegador emite um fluxo de dados conciso, enquanto as conversões de formato e os envios para as diferentes APIs decorrem no servidor de tagging e não no telemóvel do cliente. A Google inclui a melhoria do desempenho da página entre os benefícios do tagging no servidor (Google for Developers).

#Em que difere o Google tag gateway do server-side GTM

O Google tag gateway for advertisers é a opção mais leve, e a Google refere-o no primeiro passo do guia de Data Strength. Permite implementar um tag Google na sua própria infraestrutura, servido a partir do domínio do site (Google for Developers). O gateway funciona numa CDN, num load balancer ou num servidor Web que já tenha. Serve o tag Google e os respectivos pedidos de medição a partir do seu domínio, mas não processa nem redistribui eventos como um contentor sGTM.

Com a Cloudflare, a configuração faz-se no próprio tag Google (Ajuda do Google Ads):

1. Nas definições do tag Google, abra Admin e seleccione Google tag gateway.
2. Inicie sessão na Cloudflare. A conta precisa da função Super Administrator, Administrator ou Zaraz Admin.
3. Seleccione os domínios a activar e clique em Complete setup. Os domínios devem depois apresentar o estado Active.

O gateway usa um caminho de medição no seu domínio, por predefinição quatro caracteres aleatórios, que pode ser alterado (por exemplo para /metrics). A Google pede que reveja primeiro as definições de consentimento, porque a activação altera a forma como o tag Google dispara.

As duas soluções complementam-se. O Google tag gateway coloca os tags da própria Google no seu domínio com pouca infraestrutura. O server-side GTM acrescenta uma camada de processamento que também alimenta a Meta CAPI, o GA4 e outros destinos. A Google recomenda concluir ambos para obter a configuração de tagging mais duradoura.

#Como alinhar o Consent Mode v2 com o RGPD e as normas de privacidade

A transmissão de dados de primeira parte na Europa tem obrigatoriamente de respeitar o Regulamento Geral sobre a Protecção de Dados (RGPD) e a directiva ePrivacy. O mecanismo Google Consent Mode v2 estabelece a ponte técnica entre as escolhas formuladas pelo cliente no painel de consentimento (CMP) e o comportamento dos sistemas de medição. A documentação da Google é clara: a responsabilidade de obter o consentimento continua a ser do proprietário do site.

O Consent Mode v2 trabalha com quatro tipos de consentimento:

// Configuração predefinida antes da resposta do visitante
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

• ad_storage: Define a autorização para gravar cookies dedicados a publicidade.
• analytics_storage: Regula os cookies destinados a fins analíticos e de tráfego.
• ad_user_data: Determina se os identificadores cifrados podem ser encaminhados para a Google com intuito de atribuição comercial.
• ad_personalization: Habilita ou veta a inclusão do utilizador em listas de remarketing dinâmico.

No modo básico, os tags da Google não carregam enquanto o visitante não interagir com o banner, e nada é enviado se o consentimento for recusado. No modo avançado (Advanced Consent Mode), os tags carregam com recusa predefinida e, caso o visitante rejeite a utilização de cookies, emitem sinais sem cookies (cookieless pings) para a Google. Estas mensagens contêm dados sobre a interacção sem identificadores persistentes, e a Google usa-as para modelar conversões quando o tag atinge um limiar de dados recolhidos (Google for Developers).

#Como construir data strength no WooCommerce passo a passo

Construir Data Strength numa loja WooCommerce funciona melhor como uma sequência fixa. O esquema abaixo sintetiza as etapas indispensáveis:

+-------------------------------------------------------------------+
|                PLANO DE OTIMIZAÇÃO DE DATA STRENGTH               |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ PASSO 1: Auditar o evento de compra no dataLayer ]
                 (Validar Transaction ID, valores brutos e artigos)
                                  |
                                  v
        [ PASSO 2: Cifrar em SHA-256 no próprio servidor PHP ]
               (Processar e-mail, telefone e morada na origem)
                                  |
                                  v
       [ PASSO 3: Configurar o Consent Mode v2 no CMP da loja ]
               (Assegurar a actualização dinâmica de ad_user_data)
                                  |
                                  v
      [ PASSO 4: Activar o tag gateway e o Server-Side GTM ]
               (Caminho na mesma origem ou subdomínio, Cloud Run)
                                  |
                                  v
         [ PASSO 5: Mapear conversões melhoradas no sGTM ]
               (Ligar user_data aos parâmetros do tag Google Ads)
                                  |
                                  v
       [ PASSO 6: Enviar encomendas sem página de agradecimento ]
               (A partir do servidor via Google Ads API ou Data Manager API)

1. Validação da camada de dados: Confirme que o evento purchase comunica de forma consistente números de transacção únicos, montantes e taxas de imposto.
2. Cifragem de dados no PHP: Aplique rotinas de limpeza de texto e gere as sequências SHA-256 no próprio WordPress, prevenindo a transmissão de dados pessoais em aberto para a consola do navegador.
3. Integração de CMP certificado: Ligue um banner de privacidade homologado com compatibilidade nativa com Consent Mode v2 e actualização automática de estados.
4. Instalação do tag gateway e do sGTM: Sirva o tag Google a partir do seu domínio e encaminhe os eventos por um servidor de tagging num caminho da mesma origem ou num subdomínio.
5. Configuração dos tags no sGTM: No contentor de servidor, active a opção de conversões melhoradas no tag de acompanhamento do Google Ads e mapeie os atributos user_data.
6. Envio das encomendas em falta a partir do servidor: Para clientes que não aguardam pela página de agradecimento após pagamento por referência ou gateway externo, use a acção woocommerce_order_status_completed para enviar a conversão, com o ID da transacção e o GCLID guardado, ao Google Ads através da Google Ads API ou da Data Manager API.

#Conclusões práticas para lojas de comércio electrónico e especialistas de PPC

Fazer progredir o Data Strength no Google Ads é um projeto de engenharia de dados cujo resultado pode ser verificado na conta.

A implementação de conversões melhoradas estruturadas, a protecção de dados por via de SHA-256 e a adopção do Google tag gateway e do Server-Side GTM dão à loja:

• Conversões que um tag apenas no navegador perde (pedidos bloqueados, páginas de agradecimento fechadas) chegam ao Google Ads, e a métrica Data Strength Uplift mostra quantas são.
• Pelo menos 3 identificadores por encomenda (ID da transacção, e-mail cifrado, IP, GCLID quando guardado), tal como o guia da Google pede.
• Menos scripts de terceiros no navegador do cliente, o que ajuda as Core Web Vitals em dispositivos móveis.
• Uma configuração de consentimento conforme o Consent Mode v2 e o enquadramento europeu de protecção de dados.

Para verificar a conformidade técnica da sua loja com as exigências comunitárias, consulte a nossa auditoria de conformidade WooCommerce para a UE.

Uma arquitectura de medição do lado do servidor e respeitadora da privacidade mantém a medição publicitária a funcionar perante futuras alterações nos navegadores.