WhatsApp

Remarketing Dinâmico no Google Ads: Parâmetros que Fazem o Feed Bater

Fábio Oliveira

items[], ID no Merchant Center, value/currency e Consent Mode: o que faz o criativo dinâmico e o match rate funcionarem de verdade.

Contexto

A campanha de remarketing “funciona”: você paga impressão, o anúncio roda. O criativo mostra o logo e um pack genérico — nunca o tênis que a pessoa acabou de abrir no site. O media buyer culmina o PMax. O Merchant Center parece populado. O Tech Lead jura que “a tag de remarketing está no site”.

Remarketing estático só responde: esta pessoa visitou. Remarketing dinâmico responde: qual item do feed ela tocou — e monta o criativo a partir do catálogo (imagem, preço, título). O mesmo sinal de evento alimenta aprendizado de prospecção e redes que rodam catálogo (Display, Performance Max). Sem parâmetro certo, o algoritmo não tem o que casar.

Este guia é o contrato de dados, com foco retail na web e GTM: o que vai no items[], como o ID bate no Merchant Center, o que quebra match rate e o que privacidade faz com as listas.

Estático vs dinâmico (e por que o parâmetro importa)

No modelo antigo (e ainda vivo em scraps de implementação), bastavam chaves planas: ecomm_prodid, ecomm_pagetype, ecomm_totalvalue. Hoje o padrão alinhado ao Help do Google Ads e ao ecommerce do GA4 é evento nomeado + array items: um objeto por produto tocado, com ID legível para o feed.

Sem items (ou com ID que não existe no Merchant Center), a plataforma tem usuário para remarketing genérico — e zero produto para o criativo dinâmico. Match rate baixo no diagnóstico do Google quase nunca se resolve “subindo lance”.

Eventos que importam

Para catálogo/retail, implemente a mesma lógica de funil do ecommerce (mesmo se a tag final for Google Ads, não só GA4):

  • view_item — PDP: um item no array
  • view_item_list / view_search_results — intenção em grade ou busca
  • add_to_cart — intenção forte; base de “abandonadores”
  • purchase — fecha o ciclo; usado para excluir quem já comprou (e para valor)

Outras verticais (hotel, voo, emprego…) têm feed keys diferentes (destination, datas ISO, etc.). O Help de eventos e parâmetros de remarketing dinâmico lista cada vertical. Aqui o miolo é retail: se o negócio não é loja, troque o key principal, não só o nome da campanha.

O contrato do payload (retail)

No mínimo, o hit precisa carregar:

  • Evento com nome estável (view_item, add_to_cart…)
  • items: array; cada item com identificador (id ou item_id — o que a doc da tag/evento e o seu mapping GTM combinarem)
  • google_business_vertical: por exemplo retail — evita buscar o ID no catálogo errado se a conta tem mais de um tipo de feed
  • value e currency: número + ISO 4217 (BRL, USD), sem R$, sem vírgula de milhar, sem string "99,90"

Exemplo de orientação para o front/dataLayer (ajuste nomes ao template oficial da tag no seu container):

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });

window.dataLayer.push({
  event: 'view_item',
  ecommerce: {
    currency: 'BRL',
    value: 299.9,
    items: [{
      item_id: 'SHOE-RUN-ALPHA-RED-42',
      item_name: 'Tênis Corrida Alpha',
      price: 299.9,
      quantity: 1,
      google_business_vertical: 'retail'
    }]
  }
});

O ponto de verdade não é “ter um push qualquer”. É o mesmo ID que o Merchant Center indexa. Detalhe de contrato ecommerce e tipagem: Data Layer para devs. Erros clássicos de funil/receita: erros de e-commerce no GA4.

Match com o Merchant Center

O motor tenta casar o ID do evento com atributos do feed, em especial:

  • id — SKU / variante (ex.: cor+tamanho)
  • item_group_id — produto pai
  • display_ads_id — when você quer ID/título só para Display, desacoplado do Shopping

Se a tag manda o SKU fino e o feed só tem o pai (ou o contrário sem regra clara), o match rate cai e o anúncio vira genérico ou some. Decida uma lógica: “sempre mandamos o id da variante” ou “sempre o group” — e documente para eng, feed e mídia.

Preço e moeda também entram no jogo. O GMC e o rastreamento se incomodam com:

  • value formatado como texto
  • moeda fora de ISO
  • preço no site/evento diferente do preço no feed (dynamic pricing, desconto por IP, imposto só no HTML)

Currency mismatch e price mismatch não “só dão warning”: podem reprovar produto e silenciar o uso no criativo dinâmico.

Do dataLayer ao GTM

Fluxo usual:

  1. Front emite o Custom Event no dataLayer com items limpos.
  2. GTM dispara no nome do evento (view_item, etc.).
  3. Tag de Google Ads / remarketing (ou parâmetros na Google Tag alinhados à doc atual) mapeia item ID, value, currency, vertical.
  4. Preview no Tag Assistant: o hit carrega o ID e não envia PII.

Entre pushes de ecommerce, limpe estado com ecommerce: null — em SPA o modelo do GTM herda item do hit anterior e o carrinho fantasmas no feed.

Plataformas (Shopify em cêntimos, checkout em sandbox, plugins Woo) mudam de onde o ID vem, não o princípio: o valor que sai na tag tem que ser o do feed, em número e moeda certos. App nativo é outro caminho (SDK / eventos de app); não reaproveite só o container web e espere deep link mágico.

Audiências que o parâmetro desbloqueia

Com eventos confiáveis você monta segmentos dos seus dados (as antigas listas):

  • Viu item, mas não comprou
  • Add to cart sem purchase posterior (abandonadores)
  • Purchase — exclusão nas combinações (não remarcar quem já pagou)

Recência importa: clone lógica de 7 vs 30 vs 90 dias se o lance deve ser mais agressivo no recente. Sobreposição de listas no mesmo leilão queima orçamento sem critério — use exclusões (AND / NOT) de propósito, não de hábito.

Consent Mode e listas dinâmicas

Remarketing dinâmico depende de personalização publicitária. Com Consent Mode v2, se ad_personalization fica denied, aquele usuário não alimenta a user list para exibir o produto depois. Ping de modelagem / conversão modelada não substitui o “mostrar o mesmo SKU”.

Default denied até o banner, update da CMP, e leitura das tags no momento certo: Consent Mode v2. Se o match rate no Docs parece “ok” e a lista não cresce no Brasil/EEE, confira consent antes de culpar o feed.

PII: o interruptor silencioso

Parâmetros de e-mail, nome ou documento na URL (form GET, ?email=, utm com PII) ou na tag violam a política de PII do Google Ads. O efeito típico: segmentos e listas desligados até limpar. Use UUID opaco se precisar de ID próprio — nunca e-mail em claro no hit de remarketing.

Enhanced Conversions (ponte, não substituto)

Cookies e ITP reduzam atribuição. Conversões otimizadas (hash de e-mail/telefone no momento da conversão) recuperam conversão e treinam lance — boa prática first-party. Não confundir com: “sem items no view_item o produto volta no Display”. Enhanced Conversions ajuda o fechamento; o catálogo dinâmico ainda exige o sinal de item + feed.

Checklist de QA

  1. PDP dispara view_item (ou equivalente) com um item e ID estável.
  2. ID do hit existe no Merchant Center (id / group / display_ads_id — a regra que vocês escolheram).
  3. value / price numéricos; currency ISO.
  4. google_business_vertical coerente com o feed (retail no e-comm).
  5. Preview: payload limpo; zero e-mail em page location / params.
  6. Match rate / diagnóstico de dynamic remarketing no Ads — tendência depois de 24–72h de tráfego real.
  7. Segmento “carrinho sem purchase” popula; purchase exclui.
  8. Com consent denied em personalização, o usuário não deve engordar lista dinâmica (comportamento esperado).

Próximo passo

Dinamico barato de manter só existe quando feed + evento + consent são o mesmo contrato. Quando a loja tem SKU divergente, plugin que manda título no lugar de ID, e mídia “otimiza” listão de 540 dias, o criativo vira roleta.

Se quiser, partimos do seu container GTM e de uma amostra do Merchant Center e fechamos: qual ID manda o site, se o match rate faz sentido e o que o Ads ainda não deveria estar tentando remarcar.