Anúncios dinâmicos de produto (DPA): o catálogo que remarketa sozinho

Uma pessoa entra numa loja virtual, olha um tênis, compara duas cores, coloca no carrinho e sai sem finalizar. Minutos depois, no Instagram, aparece um anúncio exatamente daquele tênis, com o preço certo e a cor que ela tinha selecionado. Ninguém no time de mídia escreveu esse anúncio nem escolheu aquele produto para aquela pessoa — quem fez isso foi o DPA, o anúncio dinâmico de produto da Meta, funcionando a partir de duas peças que trabalham juntas: um catálogo com todos os itens da loja e um conjunto de eventos que dizem, em tempo real, o que cada usuário fez com cada produto.

O nome "dinâmico" é literal: não existe um anúncio fixo por trás dessa campanha. Existe um molde e um catálogo, e a Meta preenche o molde com o produto certo para a pessoa certa no momento do leilão. Isso muda completamente como se pensa a operação — em vez de criar dezenas de anúncios individuais para dezenas de produtos, você estrutura os dados uma vez e deixa o sistema montar a peça publicitária sob demanda. Este guia percorre como essa engrenagem funciona: de onde vem o catálogo, quais eventos o alimentam, como funciona o casamento entre feed e pixel, os dois usos principais (recuperar quem já demonstrou intenção e prospectar público novo a partir do catálogo) e as pegadinhas que fazem um DPA parecer ativo no relatório e vazio no caixa.

O catálogo é a fonte de dados#

Tudo começa no catálogo de produtos, dentro do Commerce Manager. É uma lista estruturada com um item por linha: identificador único, título, descrição, preço, disponibilidade, imagem, categoria, link do produto e, para quem vende variações, atributos como cor e tamanho. Sem catálogo aprovado não existe DPA — a campanha simplesmente não tem o que anunciar.

O catálogo chega até a Meta por caminhos parecidos com o que qualquer loja já conhece de outras plataformas de anúncio: um feed em arquivo (CSV, XML, TSV) hospedado numa URL que a Meta busca periodicamente, uma planilha atualizada manualmente para catálogos pequenos, ou uma integração direta da plataforma de e-commerce, que sincroniza o catálogo automaticamente sempre que um produto muda de preço ou de estoque. A forma de envio importa menos que a frequência de atualização. Um feed que sincroniza uma vez por dia é arriscado para uma loja com estoque instável; um feed que sincroniza a cada poucas horas, ou em tempo real via integração nativa, reduz o risco de anunciar algo que não existe mais na prateleira.

Vale um adendo: a disciplina exigida aqui é essencialmente a mesma de qualquer feed de produtos em qualquer canal de mídia paga — título rico em atributos, imagem limpa, preço e disponibilidade fiéis à página de destino, categorização correta. A diferença não está na qualidade dos dados que o catálogo pede, mas no que a Meta faz com ele depois: ela não usa o catálogo só para exibir produto numa busca, ela usa para decidir, produto a produto, qual anúncio mostrar para qual pessoa.

Os eventos que alimentam o DPA#

Um catálogo sozinho não sabe quem viu o quê. Quem entrega essa informação é o conjunto de eventos que o site (ou o app) reporta para a Meta a cada interação relevante do visitante com um produto. Os três que sustentam o DPA são:

• ViewContent. Disparado quando alguém visualiza a página de um produto específico. É o evento mais volumoso e o que alimenta o retargeting de topo — "essa pessoa olhou este item".
• AddToCart. Disparado quando o produto entra no carrinho. Sinaliza intenção mais forte que a simples visualização, e costuma justificar um lance mais agressivo ou uma janela de retargeting mais curta e insistente.
• Purchase. Disparado na conversão. Além de fechar o funil, o Purchase é o que permite excluir quem já comprou — sem ele, a campanha continua oferecendo o mesmo produto para quem já pagou por ele, o que é desperdício puro e ainda incomoda o cliente.

O que faz esses três eventos funcionarem especificamente para DPA, e não só como conversão genérica, são dois parâmetros que precisam vir junto em cada disparo: o content_id (o identificador do produto exato, o mesmo que aparece no catálogo) e o value (o valor monetário daquela interação, geralmente o preço do produto no caso de ViewContent e AddToCart, e o valor total do pedido no Purchase). Sem content_id, a Meta sabe que alguém visitou uma página de produto mas não sabe qual produto — e sem saber qual produto, não tem como montar um anúncio dinâmico daquele item específico. Sem value, a campanha perde a capacidade de otimizar por valor de conversão, que é justamente o que separa um DPA bem calibrado (prioriza recuperar carrinhos caros) de um que trata todo abandono como igual.

Conjuntos de produtos: o catálogo fatiado por regra#

Um catálogo com milhares de itens raramente deve ser anunciado como um bloco só. Os conjuntos de produtos (product sets) são filtros salvos dentro do catálogo — por categoria, faixa de preço, marca, disponibilidade, tag customizada ou qualquer combinação de atributos — que definem qual fatia do catálogo uma campanha específica pode usar.

Essa fatia importa porque ela vira o universo de anúncios possíveis daquele conjunto de anúncios. Uma campanha de retargeting para "quem visitou tênis de corrida" deve apontar para um conjunto de produtos que contenha só tênis de corrida, não o catálogo inteiro — senão a Meta pode preencher o anúncio com um produto que a pessoa nunca viu, o que quebra a lógica do dinâmico e devolve algo parecido com prospecção disfarçada de retargeting. Já uma campanha de prospecção ampla, que não depende de histórico de navegação, costuma usar um conjunto mais largo, às vezes o catálogo inteiro, deixando o sistema escolher o produto certo para cada pessoa com base em sinais de propensão à compra.

Conjuntos de produtos também são a ferramenta para excluir o que não deve ser anunciado: itens sem estoque, produtos de margem baixa demais para pagar o clique, linhas descontinuadas ou SKUs em teste que ainda não devem circular em mídia paga. Manter esses conjuntos organizados e revisados é parte do trabalho de estrutura de conta, não um detalhe técnico esquecível.

Retargeting e prospecção: os dois usos do mesmo catálogo#

O DPA nasceu para uma coisa e cresceu para duas. Entender a diferença entre elas evita misturar objetivos incompatíveis na mesma campanha.

• Retargeting dinâmico (recuperação). É o uso clássico: a campanha mira em quem já interagiu com produtos do catálogo — viu, colocou no carrinho, iniciou o checkout — e mostra de volta exatamente o item (ou itens relacionados) que essa pessoa deixou para trás. A audiência aqui é definida por comportamento passado no site, capturado pelos eventos do catálogo, e normalmente segmentada por janela de tempo (últimos 1, 7, 14 ou 30 dias, por exemplo) e por estágio de funil (quem só viu versus quem chegou a carrinho).
• Prospecção ampla a partir do catálogo (Advantage+ catalog). É o uso mais recente e menos intuitivo: em vez de depender de quem já visitou o site, a campanha usa o catálogo inteiro (ou um conjunto amplo) e deixa o sistema de otimização encontrar, dentro de um público amplo ou até sem segmentação manual, quem tem maior propensão a comprar cada produto, mesmo sem histórico de navegação prévio. Esse uso resolve um problema que o retargeting puro tem por definição: ele só alcança quem já visitou, e uma loja que depende só de retargeting está limitada ao topo de funil que ela mesma já gerou por outros canais. A prospecção via catálogo amplia o alcance usando os mesmos dados de produto, mas trocando "quem já viu" por "quem parece com quem compra".

Os dois usos compartilham catálogo, feed e formatos de anúncio, mas pedem estrutura de campanha separada, com metas de custo por resultado bem diferentes — o retargeting tende a converter mais barato porque mira em intenção já demonstrada, e a prospecção precisa de um teto de custo mais generoso porque está descobrindo compradores do zero. Rodar as duas no mesmo conjunto de anúncios, sem separação de orçamento e de leitura, mistura duas eficiências muito diferentes numa média que não representa nenhuma das duas.

Os formatos dinâmicos e os campos que eles puxam do catálogo#

O DPA não é um formato único, é uma capacidade que se aplica a formatos diferentes, todos preenchidos automaticamente com os campos do catálogo:

• Carrossel. Cada cartão do carrossel é um produto, puxando imagem, título e preço do catálogo. É o formato mais comum para retargeting de múltiplos itens vistos, porque mostra vários produtos relevantes numa peça só, na ordem que o sistema julgar mais provável de gerar clique.
• Coleção. Combina uma imagem ou vídeo de capa com uma grade de produtos abaixo, também puxada do catálogo. Funciona bem em prospecção porque entrega um contexto de marca maior antes de expor os produtos individuais, o que ajuda quando a audiência não tem familiaridade prévia com a loja.
• Imagem única dinâmica. Um único produto por impressão, escolhido pelo sistema entre os candidatos do conjunto de produtos daquela campanha. É o formato mais direto para retargeting de intenção alta — "isto é exatamente o item que você deixou no carrinho".

Em todos os três, os campos dinâmicos (título, preço, preço promocional quando existe, disponibilidade) são renderizados a partir do catálogo no momento da exibição, não no momento da criação do anúncio. Isso é o que permite que um preço alterado no site apareça correto no anúncio horas depois, sem que ninguém precise editar a peça manualmente — e é também o motivo pelo qual um catálogo desatualizado vira erro visível no anúncio, não um erro escondido em algum relatório.

O casamento entre content_id do feed e content_id do pixel#

Este é o ponto onde a maioria dos DPAs mal configurados quebra, e quebra de um jeito que não avisa com clareza. Para a Meta montar um anúncio dinâmico do produto que a pessoa viu, o content_id disparado pelo evento ViewContent (ou AddToCart, ou Purchase) precisa ser exatamente o mesmo identificador usado naquele produto dentro do feed do catálogo. Não "parecido", não "o mesmo produto com nome diferente" — o mesmo valor, caractere por caractere.

Na prática, esse casamento quebra por razões banais: o pixel do site dispara o SKU interno do sistema de e-commerce, enquanto o feed do catálogo usa um ID gerado pela plataforma de anúncio ou por uma integração diferente; uma migração de plataforma de e-commerce troca o formato dos IDs sem atualizar o pixel; ou o feed usa um ID composto (produto + variação de cor/tamanho) enquanto o evento manda só o ID do produto-pai. O resultado, em qualquer desses casos, é o que a interface chama de catálogo "sem correspondência": os eventos chegam, a Meta registra que alguém visualizou um produto, mas não consegue linkar esse evento a nenhum item do catálogo — e sem esse link, não tem como montar o anúncio dinâmico daquele item específico. A campanha continua rodando, gastando, às vezes até reportando resultado, mas sem a capacidade real de mostrar o produto certo, porque a ponte entre "o que a pessoa viu" e "o que existe no catálogo" nunca foi construída corretamente.

A checagem para isso não é opcional nem esporádica: o diagnóstico de eventos do catálogo, dentro do Commerce Manager, mostra a taxa de correspondência entre eventos recebidos e itens do catálogo. Uma taxa baixa é sinal de que o pixel e o feed estão falando IDs diferentes, e vale corrigir antes de otimizar qualquer outra coisa na campanha — porque nenhuma otimização de lance ou de público conserta um casamento de dados quebrado.

Saúde do catálogo: o feed também precisa de rotina#

Assim como um feed de Shopping pode ter itens reprovados, o catálogo da Meta tem seu próprio ciclo de aprovação por item, e produtos podem ser rejeitados por violação de política, imagem inadequada, informação incompleta ou preço que diverge do site de destino. Um produto reprovado não entra no leilão de DPA — ele simplesmente não existe para efeito de anúncio, mesmo estando visível e comprável no site.

Além da reprovação, dois problemas mais silenciosos corroem a saúde do catálogo com o tempo: divergência de preço (o feed mostra um valor, a página de destino mostra outro, geralmente por atraso de sincronização) e divergência de estoque (o feed marca "disponível" um item que já esgotou). Os dois miram no mesmo risco: o clique leva a uma experiência que contradiz o anúncio, o que derruba conversão e, com frequência, aciona penalidade de qualidade de anúncio. Uma rotina saudável revisa o painel de diagnóstico do catálogo com regularidade — não só quando a campanha para de performar, mas como manutenção preventiva, do mesmo jeito que se checa reprovação de feed em qualquer outro canal de anúncio de produto.

As pegadinhas que fazem o DPA parecer ativo e não estar#

Depois que a estrutura está de pé, os problemas que mais corroem resultado costumam ser sutis:

• Feed desatualizado anunciando produto esgotado. Uma sincronização lenta ou falha silenciosa faz o catálogo continuar oferecendo, em retargeting, um item que já não existe em estoque. A pessoa clica, chega numa página de "indisponível" e a marca perde tanto a venda quanto a credibilidade daquele clique específico.
• Evento sem value ou sem content_id. Um disparo de ViewContent ou Purchase implementado sem esses dois parâmetros passa despercebido porque o evento "dispara" e aparece no gerenciador de eventos — mas sem content_id não tem correspondência com o catálogo, e sem value não tem otimização por valor. O sintoma é uma campanha "ativa" que nunca aprende a priorizar os produtos certos.
• Retargeting canibalizando venda que aconteceria de qualquer jeito. Uma parte de quem vê um item no carrinho voltaria a comprar sozinha, sem qualquer estímulo pago. Retargeting muito agressivo — janela longa, frequência alta, desconto oferecido no anúncio para quem já ia converter — paga para "recuperar" uma venda que não estava em risco, inflando o custo de aquisição de forma invisível no relatório de conversão simples.
• Janela de retargeting mal calibrada. Uma janela curta demais (24 a 48 horas) descarta gente que ainda estava decidindo e só precisava de mais tempo. Uma janela longa demais (30, 60 dias) mantém a marca oferecendo, semanas depois, um produto que a pessoa já esqueceu ou já comprou em outro lugar, desperdiçando impressão em quem esfriou. O ponto certo depende do ciclo de decisão real da categoria — um item de compra por impulso pede janela curta; um item de compra considerada (móvel, eletrônico caro) tolera uma janela mais longa.
• Conjunto de produtos largo demais para retargeting. Deixar a campanha de recuperação livre para escolher qualquer produto do catálogo, em vez de restringir ao que a pessoa efetivamente viu, dilui a precisão que dá nome ao formato dinâmico — o anúncio deixa de parecer pessoal e passa a parecer genérico, o que reduz o efeito de reconhecimento que faz o DPA funcionar melhor que um remarketing comum.

Fechando: o anúncio é só o reflexo do dado#

O DPA impressiona por parecer inteligente — ele sabe o que cada pessoa olhou, sabe o preço certo, sabe montar a peça sozinho. Mas essa inteligência inteira mora nos dados que alimentam o sistema, não numa mágica da plataforma. Um catálogo correto e atualizado, eventos disparando content_id e value de forma consistente, o casamento entre feed e pixel validado, e conjuntos de produtos organizados por lógica de negócio — isso é o que faz o anúncio "parecer pessoal". Tirar qualquer uma dessas peças e o DPA continua rodando, continua gastando, mas perde a precisão que justifica o formato.

Antes de otimizar lance, criativo ou janela de retargeting, vale auditar a base: taxa de correspondência do catálogo, reprovações pendentes, eventos chegando com os parâmetros certos. Só depois de garantir que o sistema tem os dados corretos para trabalhar é que faz sentido discutir se a campanha deve puxar mais para retargeting de intenção alta ou para prospecção ampla via catálogo. Cuidar do catálogo é o trabalho menos visível de todo esse formato, e é exatamente por isso que costuma ser o que mais separa um DPA que recupera venda de um que só simula estar recuperando.