Fale Conosco

Como Configurar Eventos In-App para Otimizar Campanhas de App Install

Fábio Oliveira

De CPI para AEO e tROAS: mapa de eventos no MMP, S2S para purchase, postbacks para Meta/Google e conversion value no iOS — sem otimizar install vazio.

Contexto

A campanha de install está barata. O volume sobe. Retenção e purchase não acompanham. Meta e Google continuam entregando quem baixa o app e some em 48 horas.

Mídia aponta o criativo. Produto aponta o onboarding. Engenharia diz que o SDK do MMP está instalado. O que falta, na maioria dos casos, não é budget — é sinal de conversão pós-install chegando com o nome certo, no canal certo, na hora certa.

Otimizar campanha só para install (MAI / CPI) ensina o algoritmo a maximizar download, não valor. A saída é subir na escada: primeiro App Event Optimization (AEO) para um evento que correlaciona com retenção ou receita; depois Value Optimization (VO / tROAS) quando você tiver distribuição de ticket e volume suficiente.

Este guia é o contrato entre mídia e engenharia: qual evento otimizar, como o MMP repassa para Meta, Google e TikTok, e o que quebra silenciosamente o aprendizado. O papel do Firebase versus MMP está em Firebase vs AppsFlyer; como o evento nasce no código híbrido, em tagueamento RN e Flutter.

MAI, AEO e VO: quando usar cada estratégia

Mobile App Install (MAI) faz sentido no cold start: você ainda não tem histórico de eventos e precisa de volume para testar criativo e canal. O CPI cai, mas o perfil tende a ser de baixa intenção — muita instalação, pouco cadastro, quase nenhuma compra.

App Event Optimization (AEO) muda a meta do leilão. Em vez de “quem instala”, o sistema passa a buscar quem completa um evento definido — cadastro, trial, assinatura. Na Meta, a regra prática é cerca de 50 conversões por semana por conjunto de anúncios para sair da fase de aprendizado instável. No Google App Campaigns, o piso costuma ser mais alto (ordem de 100+ eventos otimizados por semana, conforme vertical e conta).

Value Optimization (VO / tROAS) só funciona quando purchase e receita chegam de forma confiável, com valores numéricos e distribuição de ticket que permita ao modelo distinguir usuário de alto valor. Otimizar direto para purchase quando o funil leva sete dias até a conversão costuma deixar a campanha cega por falta de sinal — escolha um evento intermediário (trial iniciado, paywall visto) que antecipe LTV.

Regra prática: documente a escada antes de subir bid. Não pule de install para purchase se o produto demora a monetizar.

Arquitetura do sinal: MMP no centro

O Mobile Measurement Partner (AppsFlyer, Adjust, Branch, etc.) valida, deduplica e atribui antes de enviar postbacks às redes. Dois caminhos alimentam o mesmo hub:

flowchart LR
    app[App_SDK] --> mmp[MMP]
    backend[Servidor_S2S] --> mmp
    mmp --> meta[Meta_Google_TikTok]
    mmp --> product[Firebase_produto]

Client-side (SDK) captura navegação, onboarding e cliques com latência baixa. É o caminho natural para af_complete_registration, tutorial concluído ou add to cart.

Server-to-server (S2S) entra quando a integridade importa: assinatura confirmada no backend, renovação, trial convertido após validação de recibo na App Store ou Play Store, compra web que completa no servidor. Fechar o app antes do SDK enviar o hit, ou manipular purchase no device, deixa buraco no funil que AEO não fecha.

A identidade cruza três chaves: appsflyer_id (gerado na primeira sessão), customer_user_id (seu ID de login/CRM) e advertising_id (GAID/IDFA) somente quando o consentimento permitir. Sem login, o S2S ainda funciona com appsflyer_id; com login, o CUID estabiliza deduplicação entre device e conta.

Campos que o backend não pode errar: eventName padronizado, eventTime em UTC (yyyy-mm-dd hh:mm:ss.sss), eventValue como JSON, receita numérica (af_revenue / value com ponto decimal, sem R$ ou vírgula), eventCurrency em ISO-4217. Use customer_dedup_id quando o mesmo evento puder ser enviado duas vezes (SDK + S2S). Mantenha o catálogo abaixo de 300 eventos únicos por dia — cardinalidade alta polui analytics e pode ser rejeitada.

Exemplo enxuto de S2S para assinatura:

{
  "appsflyer_id": "1619424823123-4567890",
  "customer_user_id": "usr_99847291a",
  "bundleIdentifier": "com.empresa.app",
  "os": "17.4.1",
  "eventName": "af_subscribe",
  "eventCurrency": "BRL",
  "eventTime": "2026-08-28 14:32:01.120",
  "eventValue": "{\"af_revenue\":29.99,\"af_content_id\":\"sub_ann_01\"}"
}

Telemetria de produto no Firebase continua paralela — funil, retenção, BigQuery — mas otimização de campanha paga olha o que o MMP postou para a rede. Gate de consentimento antes de ads ID: LGPD no app.

Taxonomia: o nome certo na rede certa

Evento custom sem mapeamento no painel do MMP vira sinal genérico. AEO roda, mas o algoritmo não aprende a distinguir cadastro de compra.

Padronize primeiro os nomes do MMP e configure o mapeamento para cada parceiro:

  • Registro concluído: af_complete_registration → Meta CompleteRegistration, Google sign_up, TikTok CompleteRegistration
  • Trial iniciado: af_start_trial → StartTrial nas três redes
  • Compra: af_purchase com af_revenue → Meta Purchase, Google purchase / ecommerce_purchase
  • Assinatura: af_subscribe → Subscribe (renovações via S2S, não só primeiro hit no SDK)

Configure isso em Meta in-app event mapping e nas conversion events do Google dentro do painel do MMP — não só no código. Custom event só entra com mapeamento explícito; caso contrário, trate como telemetria interna, não como meta de campanha.

Postbacks: partner only ou todas as origens

Ao integrar Meta, Google ou TikTok no MMP, você escolhe quem recebe postback:

This partner only limita o envio aos usuários atribuídos àquela rede. Reduz compartilhamento de dados, mas o algoritmo só vê conversões da própria mídia — lookalike e modelos preditivos ficam mais pobres.

All media sources, including organic envia todo evento in-app qualificado para a rede. A prática recomendada para escala é incluir orgânico e outras fontes: o machine learning passa a conhecer o perfil de quem converte de verdade, não só quem veio daquele último clique pago.

Calibre também as janelas de atribuição: click-through de 7 dias e view-through de 24 horas são o padrão Meta/Google. Se seu produto converte no dia 10, janela curta subatribui campanha; janela longa demais mistura touchpoints. Alinhe lookback à jornada real, não ao default do painel.

iOS: conversion value alimenta AEO agregado

Pós-ATT, boa parte do tráfego iOS não devolve IDFA. A otimização na Apple passa por conversion value mapeado para fine (0–63) e coarse (low / medium / high) nas três janelas SKAN/AdAttributionKit. Compra no dia zero com lockPostback: true encurta o ciclo de feedback para o algoritmo em até 48 horas.

Exemplo de mapa em prosa (ajuste ao seu funil): valores 0–15 para onboarding e cadastro; 16–31 para micro-receita; 32–47 para assinatura mensal; 48–63 para plano anual ou LTV alto, com lock na compra. Implementação Swift, Info.plist e S2S condicionado ao ATT estão em tracking iOS pós-ATT. O conversion value iOS e os eventos nomeados no MMP precisam contar a mesma história para mídia e eng.

Fase de aprendizado e escala

Ligar AEO e mudar estrutura todo dia reseta o modelo.

Na Meta (Advantage+ App), espere cerca de 50 conversões por semana por conjunto antes de julgar performance. Evite alterar targeting, criativo e evento por 7 dias na fase inicial. Escale budget em 15–20% a cada 72 horas, não em saltos de 100%.

No Google UAC, o piso típico é 100+ eventos otimizados antes de convergência estável. Comece tCPA cerca de 20% acima do CPA histórico do evento escolhido e dê 7–14 dias antes de apertar meta.

No TikTok, a referência também gira em torno de 50 conversões por semana por grupo; criativo fatiga rápido — rotação (Spark Ads, UGC) pesa tanto quanto bid.

Interromper postbacks, renomear evento ou trocar o otimizado no meio da learning phase joga o algoritmo de volta ao zero.

Falhas silenciosas que destroem CPA

Estes erros não aparecem como “tag vermelha” no ads manager; aparecem como ROAS plano:

  • S2S em batch diário sem eventTime correto: o MMP carimba a chegada HTTP, não a compra. Atribuição last-touch quebra e o bid otimiza horário errado.
  • Receita formatada como texto ("R$ 29,90", vírgula decimal): servidor rejeita ou ignora af_revenue; VO vira otimização cega.
  • Evento custom não mapeado no parceiro: postback chega, rede classifica como genérico, AEO não diferencia funil.
  • Campos obrigatórios ausentes (os, bundle ID, consent flags onde exigido): requisição descartada em silêncio.
  • Duplicata SDK + S2S sem customer_dedup_id: conversão inflada, learning phase distorcida.

Audite no painel do MMP (raw data / live events) antes de confiar no dashboard da rede.

Checklist

  1. Escada documentada: install → evento intermediário → purchase/VO, com volume mínimo por rede.
  2. Eventos financeiros críticos via S2S com recibo validado; onboarding via SDK.
  3. Nomenclatura af_* mapeada para Meta, Google e TikTok no painel do MMP.
  4. Postbacks configurados como all media sources including organic se a meta for escala de AEO/VO.
  5. Janelas de atribuição alinhadas à jornada do produto (não só default 7d/1d).
  6. iOS: conversion value coerente com eventos MMP — ver guia pós-ATT.
  7. Learning phase respeitada: sem troca de evento otimizado ou estrutura por uma semana.
  8. QA de payload: revenue numérica, eventTime UTC, dedup quando SDK e S2S coexistem.

Próximo passo

Campanha de install “barata” com funil vazio no MMP é otimização para volume, não para negócio. O trabalho que move CPA de verdade é fechar o mapa: qual evento cada rede recebe, o que vai por SDK versus S2S, e quando subir de AEO para tROAS.

Se você já tem MMP no ar e a campanha ainda otimiza install, o próximo passo não é aumentar bid — é escolher um evento de funil, garantir que ele chega mapeado nas três redes principais e deixar a learning phase terminar antes de julgar.

Se quiser, partimos do seu funil (cadastro, trial, subscribe) e fechamos: evento de otimização, payload S2S e configuração de postback por rede.