Vou ser direto. Em todas as contas grandes que peguei nos últimos 4 anos, o erro mais caro não estava no criativo nem na segmentação. Estava na configuração de eventos. Gente colocando Purchase em prioridade 5, Lead bruto em prioridade 1, otimizando campanha de e-commerce pra ViewContent. Aí culpava o algoritmo do Meta.

Eventos de conversão são a fundação. Se o Meta não entende o que é sucesso pra você, ele otimiza pra qualquer clique que pareça com sucesso. E você queima R$ 30, R$ 50, R$ 100 mil por mês perseguindo um ROAS que nunca vai chegar porque o sinal que ele recebe está errado.

Esse post não é teoria. É o que eu faço em cada conta nova: como decidir os 8 eventos, como ordenar a hierarquia sem perder atribuição, quando criar custom event, e o motivo de eu nunca, em nenhuma hipótese, mudar hierarquia no meio da semana.

Por que o Meta limita 8 eventos por domínio

A limitação de 8 eventos não é capricho do Meta. Veio do iOS 14.5, quando a Apple obrigou o opt-in via ATT (App Tracking Transparency) pra qualquer rastreamento cross-app. Pra usuários iOS que deram opt-out (e são maioria absoluta no Brasil), o Meta precisou criar o Aggregated Event Measurement (AEM): um sistema de agregação que só repassa o evento de prioridade mais alta que aconteceu na sessão, sem identificador de usuário.

O cap de 8 eventos é o limite técnico desse protocolo. Não é negociável e não tem como burlar. Custom audience pra ATC é vista a partir do evento, então mesmo com 200 eventos no Pixel, se eles não estão configurados no AEM, eles não otimizam campanha pra usuário opted-out.

Pra Android e desktop a história é menos crítica, mas o Meta não trata diferente: a configuração do AEM vale pra todo o tráfego do domínio. Se você botou Purchase em 5, ele vai otimizar Purchase em 5 pra todo mundo, não só iOS.

Detalhe que pouca gente fala: o cap é por domínio, não por conta de anúncios. Se você roda 3 marcas no mesmo domínio raiz (subdomínios contam como mesmo domínio pra AEM), os 8 eventos são compartilhados entre elas. Vejo isso travar grupo holding o tempo todo. Solução é separar domínios de verdade, não só pasta.

Hierarquia: como posicionar Purchase em 1

Aqui está a parte que eu vejo mais erro. Hierarquia não é ordem em que você criou o evento, nem ordem em que ele acontece no funil. É a ordem de prioridade que o Meta vai usar pra atribuir conversão pra usuários opted-out. Só o evento mais alto que aconteceu na sessão é repassado.

Se Purchase está em prioridade 5 e Initiate Checkout em prioridade 1, e o usuário comprou, o que vai pro Meta é Initiate Checkout. Você acabou de transformar uma compra em sinal de meio-de-funil. Multiplica isso por mil eventos e você tem uma conta otimizando pra checkout abandonado.

Pra e-commerce, minha estrutura padrão é:

1. Purchase (prioridade 1) – o evento que importa.
2. Initiate Checkout (prioridade 2) – sinal forte de intenção.
3. Add to Cart (prioridade 3) – meio de funil.
4. View Content (prioridade 4) – awareness, pra retargeting.
5. Add Payment Info (prioridade 5) – micro-evento, pouco peso.
6. Search (prioridade 6) – sinal de exploração.
7. Custom: AddToWishlist (prioridade 7) – opcional.
8. Custom: ScrollDepth80 (prioridade 8) – engajamento.

Pra lead gen, troco Purchase por Lead e Initiate Checkout por SubmitApplication ou um custom event específico de qualificação. Ignoro Add to Cart e foco em micro-eventos que indicam qualidade de lead (visitou página de preço, leu até o fim, baixou material).

Pra entender melhor como tudo isso se encaixa no resto da plataforma, recomendo passar antes pelo guia geral de como funciona o Meta Ads. Hierarquia faz parte de um sistema, não é peça isolada.

Eventos custom vs standard: quando criar custom

Standard events são os 17 eventos pré-definidos do Meta (Purchase, Lead, AddToCart, etc). Custom events são qualquer coisa que você batiza com nome próprio. A pergunta certa não é “qual usar”, é “quando o standard não dá conta”.

Use standard sempre que possível. Por três motivos: o Meta já tem benchmark de comportamento pra eles (otimização é mais rápida), eles aparecem em todos os relatórios sem configuração extra, e o Lookalike consegue ser construído em cima deles com mais qualidade.

Crie custom só quando:

• Você precisa distinguir tipos de Purchase. Compra acima de R$500 vs abaixo, recorrência vs avulso. Aí é Purchase_HighValue como custom, com parâmetro de valor.
• Você tem um evento de qualificação específico. Lead_Qualificado depois de uma triagem manual, por exemplo. Não dá pra usar Lead standard se você quer otimizar pra qualidade.
• Você quer medir engajamento profundo. ScrollDepth80, TimeOnPage90s, VideoComplete75. Aqui custom é o caminho.

Erro que vejo muito: gente criando custom pra evento que o Meta já tem standard. PageView_Home, ProductView_Mobile, BuyButtonClick. Não faça isso. Standard event com parâmetros (content_type, content_category, value) resolve 90% dos casos sem fragmentar dado.

Setup via Pixel + CAPI: a deduplicação que ninguém configura direito

Em 2026, rodar só Pixel é jogar dinheiro fora. Browser bloqueia cookie de terceiro, ad-blocker filtra script do Meta, iOS 14.5+ filtra metade dos eventos. A Conversions API (CAPI) é o canal server-side que envia o evento direto do seu servidor pro Meta. Recupera 20-40% dos eventos que o Pixel perdia.

Mas se você roda Pixel e CAPI sem deduplicação, está contando o mesmo evento duas vezes. Meta vê 2 Purchases pra 1 venda real, ROAS aparente sobe, otimização vai pro errado. A deduplicação é feita via parâmetro event_id idêntico em ambos os lados, mais event_name e event_time próximos (janela de 48h).

Setup completo da CAPI via GTM eu cobri em outro post: Conversions API (CAPI) do Meta via GTM. Pra ler sobre o problema raiz (Pixel sozinho não dá conta), recomendo o guia de Pixel + Conversions API. E pra entender o ataque do iOS 14.5 ao Meta como um todo, iOS 14.5+ e o impacto no Meta Ads.

A configuração técnica é repetível, mas o erro humano não. O que eu peço pra time validar em toda conta:

1. Pixel e CAPI estão enviando o mesmo event_id? (Não é o event_name. É o ID único da transação.)
2. O event_time está em UTC? (Inconsistência de timezone quebra dedup silenciosamente.)
3. Match rate de CAPI está acima de 7.0 no Events Manager? (Abaixo disso, o sinal está fraco.)
4. Você está enviando hashed customer data (email, telefone, fbp, fbc)? Sem isso, CAPI vira sinal sem nome.

Como mudar hierarquia sem perder dados

Essa é a parte chata. Toda vez que você mexe em hierarquia de eventos no Events Manager, o Meta força uma janela de 72h de re-pessoas. Durante essa janela, otimização pausa, custo sobe (porque o algoritmo está procurando sinal novo) e os dados de conversão ficam ruidosos.

Regras que eu sigo pra não tomar prejuízo:

• Nunca mude na sexta. Janela vai pegar o fim de semana inteiro, quando você não consegue ajustar nada. Faça segunda ou terça.
• Nunca mude no meio de campanha de venda. Black Friday, lançamento, sazonalidade alta. Espera o pico passar.
• Faça uma mudança por vez. Não troque hierarquia E adicione evento novo no mesmo dia. Você não vai saber qual mexida quebrou o que.
• Documente a hierarquia anterior. Print do Events Manager, screenshot. Se a mudança piorar, você quer voltar pra mesma config exata, não pro que você acha que era.
• Pausa campanhas de teste durante a janela. Não tem por que queimar verba em teste de criativo enquanto o sistema está ruidoso.

Detalhe: adicionar evento novo na hierarquia (entrar nos 8) também conta como mudança e dispara as 72h. Remover evento também. Só reorganizar prioridade de 1 e 2 sem trocar os 8 também dispara. Não tem mudança “pequena”.

Verified domain: por que importa pra eventos

Verificar domínio é o pré-requisito que ninguém menciona até dar erro. Sem domínio verificado, você não configura Aggregated Event Measurement, não tem acesso aos 8 slots de evento, e seu Pixel funciona como se fosse 2019 (mal). Pra contas novas, é a primeira coisa que faço, antes mesmo de subir campanha.

Verificação é feita via DNS TXT, meta tag no HTML ou upload de arquivo. Recomendo DNS TXT porque não depende do desenvolvedor do site mexer em código. Coloca o registro no Cloudflare, no provedor de hospedagem ou onde o domínio aponta, espera propagação, valida no Business Manager.

Detalhe que eu vejo errado o tempo todo: verificar domínio errado. Se o site é loja.empresa.com.br, você verifica empresa.com.br. O sufixo (loja, app, checkout) é tratado como subdomínio e fica coberto pela verificação raiz. Mas se o checkout é em pagamento.outroprovedor.com, isso é outro domínio. Não está coberto. Precisa cross-domain tracking, que cobri no post de Cross-Domain Tracking.

Erros comuns: Purchase em 5, Lead bruto em 1

Pra fechar, os erros que eu mais corrigi em conta nova nos últimos 12 meses:

Outro erro comum é não revisar eventos a cada 6 meses. O Meta atualiza standard events, libera novos (recentemente: Subscribe, StartTrial, AddToWishlist com mais peso), e o que era melhor configuração há 2 anos pode estar sub-ótimo hoje. Coloque na agenda: revisar AEM a cada semestre, antes de Black Friday e antes de qualquer lançamento grande.

Pra fechar o circuito de mensuração, recomendo conectar evento de Meta com atribuição no GA4 e o modelo de atribuição do próprio Meta. Ver os dois mundos te dá noção real de o que o Pixel está enxergando vs o que o Analytics está enxergando, e onde tem gap. Em paralelo, vale entender como deduplicação de conversão funciona entre Pixel, CAPI e server-side. Pra fechar ROAS, ROAS no Meta Ads aprofunda o cálculo.

Referências externas que valem leitura: a documentação oficial do Meta sobre Aggregated Event Measurement, a cobertura da Search Engine Land sobre evolução do AEM pós-iOS 14.5, e o blog do Simo Ahava pra detalhes técnicos de implementação de Pixel+CAPI via GTM (é o tipo de leitura que diferencia time bom de time médio).

Perguntas frequentes