Definir o que medir antes de instalar ferramentas

Com perfil, página e checkout preparados para o clique que vem do vídeo, falta decidir o que será contado quando esse clique virar pedido. Muitas contas pulam essa etapa. Instalam o Pixel pela integração da loja e descobrem meses depois que o relatório responde a perguntas que ninguém fez.

O preço aparece na reunião de verba. O Ads Manager (o painel de anúncios do TikTok) mostra um número, o GA4 mostra outro e o Seller Center (o painel de gestão da loja no TikTok Shop) mostra um terceiro. Sem plano escrito, a conversa gira em torno de qual número merece crédito, e a decisão sobre dinheiro fica para a semana seguinte.

Plano de mensuração é o documento que liga cada pergunta da empresa a um evento, a um parâmetro e a um relatório, antes de existir código. Com ele pronto, cada número do painel passa a ter origem conhecida, um responsável e um teste que prova que ele está certo.

Tudo começa pelas perguntas de negócio, as poucas decisões que a medição precisa sustentar. Quanto cada real de mídia devolve de margem? Qual canal traz cliente novo e qual só traz recompra? Quanto do GMV (o valor de mercadorias registrado segundo a definição do relatório) vem de anúncio, de LIVE e de afiliado? Pergunta que não muda nenhuma decisão não merece evento.

Mapa de conversões é a tradução dessas perguntas em eventos com dois papéis. Evento de otimização é o que a campanha persegue: o sistema de lances aprende com ele e procura gente parecida com quem o disparou. Evento de leitura só informa. Evento personalizado, criado com nome próprio, entra em relatório e em público, mas a Central de Ajuda diz que ele não otimiza campanha.

Destino muda o jeito de medir, e o plano precisa de uma linha para cada um. No site, a compra é registrada por código que a empresa controla. No formulário instantâneo, o lead nasce dentro do TikTok e segue para o CRM por integração. Na loja do TikTok Shop, o pedido acontece dentro do aplicativo e quem conta é a própria plataforma.

Dicionário de eventos é a planilha que dá nome fixo a cada evento e descreve quando ele dispara, quais parâmetros carrega e por qual canal viaja. Os nomes seguem a lista oficial de abril de 2026: ViewContent registra a visita à página de produto, AddToCart a adição ao carrinho, InitiateCheckout o início do checkout e Purchase a compra.

Parâmetro é o dado que acompanha o evento e o torna útil. Em Purchase, value leva o total do pedido e currency leva a moeda, BRL no Brasil; sem os dois, não há ROAS nem otimização por valor. content_ids leva os códigos dos produtos, e customer_type, parâmetro opcional novo, marca se o comprador é novo ou recorrente.

UTM (os parâmetros da URL que dizem ao GA4 de onde veio a visita) completa o desenho do lado de fora do TikTok. A orientação oficial pede no mínimo utm_source e utm_id em todo destino, no modelo utm_source=tiktok&utm_id=__CAMPAIGN_ID__&utm_content=__AID__, e o Ads Manager oferece anexar esses parâmetros sozinho. Um modelo único impede que a mesma campanha apareça no GA4 com três grafias.

Plano de validação é a parte que quase ninguém escreve e que mais economiza. Ele diz qual compra de teste a equipe faz, por qual meio de pagamento, o que deve aparecer em cada ferramenta e qual diferença é aceitável entre eventos recebidos e pedidos pagos. Sem esse critério escrito, cada pessoa decide na hora se o número "parece certo".

Governança fecha o plano com três decisões. Quem é dono do dicionário e aprova evento novo. Onde fica o registro de mudanças, com data, autor e motivo. Quem tem acesso ao Pixel no Business Center. Entra aqui também a conduta com dados: peça o consentimento antes de disparar o Pixel, guarde o registro de quem aceitou e siga o guia de cookies da ANPD.

Armadilha comum: ligar a integração da plataforma da loja, ver eventos chegando no Events Manager e tratar isso como mensuração pronta. A integração decide sozinha quais eventos manda e com quais parâmetros, e ninguém confere se a compra registrada é pedido gerado ou pedido pago. O relatório parece completo e responde a uma pergunta diferente da que a empresa fez.

Foi o que a Aroeira Cosméticos, empresa fictícia do exemplo, encontrou em março de 2026. O site na Nuvemshop recebia R$ 18.000 por mês em TikTok Ads desde fevereiro, e Helena perguntou quanto daquilo voltava como margem. Otávio abriu o Events Manager e achou o Pixel ativo, instalado pela integração da loja, sem que ninguém soubesse quais eventos ele enviava nem se Purchase contava pedido pago.

Antes de mexer em código, Otávio escreveu as contas. No site, o ticket médio era de R$ 128 e a margem de contribuição antes de mídia ficava em 46 por cento, R$ 58,88 por pedido. Esse valor virou o CPA de equilíbrio do site, e o ROAS de equilíbrio saiu de 128 dividido por 58,88: 2,17. Abaixo disso, cada venda atribuída ao TikTok custava mais do que deixava.

O dicionário ficou com seis eventos e um só de otimização. O mapa de destinos ganhou duas linhas separadas: site, medido por Pixel e Events API, e TikTok Shop, que a loja abriria naquele mês e que seria lido no Seller Center. Aplicativo ficou de fora, porque a Aroeira não tinha um, e a pergunta sobre LIVE esperou a primeira transmissão, marcada para abril.

A decisão que mais pesou foi a definição de compra. Otávio escreveu no plano que Purchase significa pagamento confirmado, com a tolerância de 2 por cento de diferença entre eventos e pedidos pagos no mês. Com essa régua, o plano apontou três tarefas em ordem: limpar o Pixel, montar o envio pelo servidor e só então comparar os painéis.

Naquele março, a Aroeira trocou um Pixel que ninguém sabia ler por um documento de duas páginas que qualquer pessoa da equipe consultava. Escreva agora as suas três perguntas de negócio e, ao lado de cada uma, o evento e o relatório que a respondem. O critério de acerto é não sobrar evento sem pergunta. O próximo capítulo instala o Pixel que esse plano pede.