O que é signal engineering, e o que isso corrige depois do ATT?

Você provavelmente está aqui porque

Nenhum desses é um problema de compra de mídia. São problemas de sinal, e a maioria deles tem conserto.

• O Meta reporta um ROAS, o RevenueCat reporta metade disso, e o financeiro não acredita em nenhum dos dois. Eles nunca vão bater, e ninguém na equipe sabe explicar por quê.
• Os valores de conversão do SKAN voltam vazios na maioria das campanhas e ninguém sabe por quê.
• O Meta escala bem. O Google e o TikTok travam no mesmo criativo.
• Você mudou para otimização de valor e piorou.
• Os inícios de trial saem baratos e as conversões pagas nunca vêm depois.
• Existem três SDKs no app. Ninguém sabe dizer qual deles é responsável pelo valor de conversão.

O que o signal engineering corrige

Cinco camadas, na ordem em que eu construo cada uma.

• A camada de eventos. Uma taxonomia canônica de eventos para o seu app, mapeada explicitamente para os eventos padrão do Meta, os eventos de conversão do Google, os eventos do TikTok e o seu MMP. Início de trial, primeiro pagamento, renovação, cancelamento, reembolso. Cada um com um valor, uma moeda e um ID.
• Entrega pelo servidor. A Conversions API do Meta para eventos de app, a Events API do TikTok e a configuração de conversão de app do Google, via o seu MMP ou o Firebase, conectadas ao seu backend de assinatura para que renovações, reembolsos e conversões de trial cheguem às plataformas mesmo com o app fechado. Deduplicado por ID de evento para que nada seja contado duas vezes.
• O schema de valor de conversão do iOS. O pequeno valor que a Apple deixa você enviar de volta é o único sinal pós-instalação que você tem para usuários que recusaram o tracking. Eu desenho isso em torno do seu funil e do seu volume, para que as campanhas passem dos limiares de privacidade da Apple e não voltem vazias. Um único SDK é responsável por ele. Quando dois SDKs escrevem nele, vence a última chamada, e hoje isso costuma ser um acidente.
• Sinais de valor para o lance. Valor de compra, margem ou LTV previsto, enviados para todas as plataformas, não só para o Meta, e só depois que eu verifico que o valor realmente se correlaciona com o que os usuários acabam pagando. Um valor errado ensina o algoritmo a comprar os usuários errados mais rápido.
• A visão de reconciliação. Uma comparação mensal entre os números da plataforma, do MMP, do RevenueCat e dos repasses da loja, com as diferenças esperadas documentadas, para que da próxima vez que os números não baterem você saiba em cinco minutos se é algo estrutural ou um bug.

O que isso não corrige depois do ATT, e por que eu digo isso

Desde o iOS 14.5, usuários que recusam o App Tracking Transparency não podem ser atribuídos em nível de usuário. O SKAdNetwork e o AdAttributionKit da Apple retornam postbacks atrasados e agregados, sem identificador de dispositivo, e a Apple retém detalhes de campanhas de baixo volume de propósito. Nenhuma integração com a Conversions API, nenhum recurso de MMP e nenhuma ferramenta de recuperação de atribuição muda isso. O Meta encaminha esses eventos pelo Aggregated Event Measurement. O Google os modela. O TikTok os modela.

Por isso eu não prometo atribuição determinística. Eu prometo que os sinais que você pode controlar estão certos, que as plataformas recebem o melhor input possível para otimizar, e que você vai saber quais discrepâncias são normais. O ROAS da plataforma e a receita de assinatura ainda vão divergir depois do trabalho feito. Vão divergir por motivos que você consegue explicar. Se um fornecedor disser o contrário, pergunte a ele de onde vem o ID do usuário.

Qual sistema reporta o quê no iOS?

Cinco sistemas contam instalações e conversões das mesmas campanhas de iOS, e quando eles não batem, nenhum está necessariamente errado. Eles contam coisas diferentes, em janelas diferentes, com atrasos diferentes. A tabela se baseia na documentação de cada fornecedor, verificada em 29 de setembro de 2026.

No iOS, o Google exige trabalho do seu lado. Para o Integrated Conversion Measurement, o Google pede uma campanha de app para iOS ativa, otimizada para instalações, os eventos first_open e os eventos depois da instalação do seu MMP importados no Google Ads, a medição no dispositivo com dados de eventos, e um SDK do MMP atualizado. A medição no dispositivo com dados de eventos exige iOS 12 ou mais recente, o SDK do Google Analytics for Firebase a partir da versão 11.14.0 e a propriedade do Analytics vinculada ao Google Ads, e o Google diz que ela vai ficar inativa para usuários no EEE, no Reino Unido e na Suíça. Por isso o Google Ads, o MMP e o SKAN divergem por definição, e a própria orientação do Google é ler a visão do ICM se você implementou, e o Google Ads ou o SKAN se não implementou. A configuração do ICM para cada rota de integração e como eu reconcilio o Google Ads, o MMP e o SKAN têm cada um o seu artigo.

Algumas diferenças não têm nada a ver com definições. Em uma conta do Google Ads que eu operei, o evento de receita enviava $1 em vez de $0 quando uma conversão não tinha valor, o que inflou o ROAS reportado pelo Google em todo lugar, e mais ainda no iOS. É a conta por trás do meu teste de estratégias de lance, e é exatamente o tipo de bug que a visão de reconciliação existe para pegar.

Como o SKAN 4 e o AdAttributionKit funcionam para campanhas do Meta no iOS?

Quem decide o que volta é a Apple: até três postbacks atrasados por anúncio vencedor, cada um com um valor de conversão que o seu app escreve no dispositivo, e menos detalhe quanto menor for a campanha. No Meta, cada conjunto de anúncios de promoção de app para iOS usa a atribuição do SKAdNetwork ou o Aggregated Event Measurement do próprio Meta, dependendo de a qual dos dois o seu evento de otimização se qualifica.

O SKAN 4 e o AdAttributionKit retornam três janelas de postback, e só a primeira pode levar um valor fine. A Apple reduz para coarse ou para nada quando uma campanha é pequena demais para proteger a privacidade do grupo. O primeiro pagamento de um trial de 7 dias cai no dia 7 ou 8, na segunda ou na terceira janela, como um valor coarse, dias depois. É por isso que o schema precisa ser desenhado em torno do seu funil e do seu volume, não copiado de um template, e por que dividir demais por geo e por criativo empurra todas as campanhas para baixo do limiar ao mesmo tempo. Em qual janela cai cada duração de trial, e quem escreve o valor, está em se o SKAN consegue medir o pagamento depois de um trial gratuito.

Quem pode corrigir o CAPI e o mapeamento de eventos para o Meta?

Alguém que seja dono de todo o caminho do evento, do SDK do app e do MMP até o backend de assinatura e o Events Manager, porque a maioria dos bugs de sinal no Meta fica onde duas dessas peças se encontram. Em um retainer, essa pessoa sou eu, com um engenheiro de atribuição da minha rede para o trabalho de SDK e de servidor, e um desenvolvedor do seu lado que consiga colocar mudanças no ar.

A Conversions API para eventos de app envia pelo seu servidor os mesmos eventos que o SDK ou o MMP enviam pelo dispositivo, e o Meta os deduplica pelo ID do evento. O papel dela é completude e valor: renovações, reembolsos e conversões que acontecem com o app fechado, cada um com um valor e uma moeda. Ela não restaura a atribuição de usuários que recusaram o tracking; esses eventos continuam passando pelo Aggregated Event Measurement. Vale a pena fazer, mas não é um workaround. Quando um evento chega ao Meta e continua marcado como não qualificado para o AEM, as verificações de cada rota estão em por que os eventos de trial e de compra não se qualificam para o AEM do Meta.

pLTV e otimização de valor

Um modelo prevê o valor de cada novo usuário a partir do primeiro dia ou dois de comportamento. Esse número vai para a plataforma como o valor de compra, ou no iOS é comprimido no valor de conversão. A plataforma então dá lances por usuários parecidos com as suas previsões de alto valor. Qual evento e qual modo de lance combinam com qual app está escrito a partir de $1.2M em investimento no Meta.

Na Videa, essa camada, um sinal de compra via CAPI feito sob medida e o LTV previsto no lance, foi o que levou o D0 ROAS de 20% a uma semana recorde de 43%. Um teste de $606K decidiu que o valor do dia zero prevê o D28 ROAS melhor do que o custo por compra.

Em qual evento você deve otimizar?

Estas são as três perguntas que eu faço, nesta ordem, antes de uma conta avançar para um evento mais profundo. A escada completa, da instalação para cima, está em em qual evento um app de assinatura deve otimizar.

1. Os eventos pagos passam do limiar de aprendizado da plataforma no seu volume? A referência do Meta é de cerca de 50 resultados por conjunto de anúncios na semana depois da última edição significativa. Se não passam, otimize para início de trial mais um evento de ativação. Se passam, vá para a pergunta 2.
2. A taxa de trial para pago está saudável? Se não, fique no início de trial mais um evento de ativação. As duas condições precisam valer antes de você mudar. Se sim, migre para compra e vá para a pergunta 3.
3. O valor que você enviaria se correlaciona com o que os usuários acabam pagando? Se não, fique em compra. Se sim, envie o valor. O LTV previsto precisa de mais três coisas: a previsão estar calibrada em cima de coortes que já amadureceram de verdade, haver volume suficiente, e a plataforma receber o dado antes que a janela de atribuição feche. Ligado cedo demais, isso otimiza para os usuários errados com muita confiança.

Reconciliando o ROAS da plataforma com a receita de assinatura, entre países

As plataformas contam conversões atribuídas e modeladas dentro da própria janela, a preço bruto, na data do clique. O RevenueCat conta recibos na data da transação, líquidos de reembolso, em uma única moeda. Os repasses da loja chegam num calendário fiscal, líquidos de comissão e de imposto local. Essas são diferenças estruturais, e são esperadas. Uma diferença que muda de tamanho de um mês para o outro geralmente tem um bug por trás: um evento de compra duplicado, uma moeda trocada, um valor que chega a uma plataforma e não à outra.

O ROAS multi país adiciona a maturidade da coorte. Um país cujos usuários pagam anualmente parece pior no dia 7 e melhor no dia 90 do que um que vende mensal, então eu comparo coortes na mesma idade, em uma única moeda, líquidas de comissão, antes de decidir qual país recebe orçamento. A auditoria de $383K mostra como isso é numa conta real, e quantas compras um ROAS precisa antes de significar alguma coisa define o piso para cada corte.

Como o trabalho funciona

Signal engineering faz parte do retainer, e vem primeiro. A leitura começa com o growth audit: o que cada plataforma recebe hoje, para onde está otimizando, e a comparação entre as quatro fontes com a variação esperada documentada. Depois da leitura, algumas equipes implementam as correções sozinhas a partir da lista priorizada, com o esforço de engenharia estimado item por item. Outras me pedem para operar as contas. As duas opções funcionam.

Para trabalho de SDK e qualquer coisa que rode nos seus servidores, eu trago um engenheiro de atribuição da minha rede. Eu desenho e sou dono da camada; as mãos técnicas são especialistas. Você precisa de um desenvolvedor que consiga colocar mudanças no ar durante o contrato, e de acesso de leitura ao Events Manager, ao MMP, ao RevenueCat ou ao seu backend de assinatura, e às contas de anúncio.

Se você ainda está antes de um retainer e quer o diagnóstico sem o contrato, uma sessão paga de 90 minutos cobre a sua configuração e o que corrigir em que ordem. Ela é agendada pelo mesmo calendário da call inicial.

Perguntas frequentes