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

Provavelmente está aqui porque

Nenhum destes é um problema de compra de media. São problemas de sinal, e a maioria tem correção.

• A Meta reporta um ROAS, o RevenueCat reporta metade disso, e a equipa financeira não acredita em nenhum dos dois. Nunca vão coincidir, e ninguém na equipa sabe dizer porquê.
• Os valores de conversão do SKAN voltam vazios na maioria das campanhas e ninguém sabe porquê.
• A Meta escala sem problemas. A Google e o TikTok encravam com o mesmo criativo.
• Mudou para value optimization e piorou.
• Os inícios de trial são baratos e as conversões pagas nunca chegam.
• Há três SDKs na app. Ninguém sabe dizer qual é responsável pelo valor de conversão.

O que o signal engineering corrige

Cinco camadas, pela ordem em que as construo.

• A camada de eventos. Uma taxonomia canónica de eventos para a sua app, mapeada explicitamente para os standard events da Meta, os eventos de conversão da 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 do lado do servidor. A Conversions API da Meta para eventos de app, a Events API do TikTok e a configuração de conversões de app da Google, através do seu MMP ou do Firebase, ligadas ao seu backend de subscrição para que renovações, reembolsos e conversões de trial cheguem às plataformas mesmo com a app fechada. Sem duplicação, por ID de evento, para que nada seja contado duas vezes.
• O esquema de valor de conversão do iOS. O pequeno valor que a Apple permite enviar de volta é o único sinal pós-instalação que tem para utilizadores que recusaram o tracking. Desenho-o à volta do seu funil e do seu volume, para que as campanhas ultrapassem os limiares de privacidade da Apple em vez de devolverem nada. Um SDK é responsável por ele. Quando dois SDKs o escrevem, ganha a última chamada, e neste momento isso costuma ser um acidente.
• Sinais de valor para o bidding. Valor de compra, margem ou LTV previsto, enviados para todas as plataformas, não só para a Meta, e só depois de verificar que o valor está realmente correlacionado com o que os utilizadores acabam por pagar. Um valor mau ensina o algoritmo a comprar os utilizadores errados mais depressa.
• A vista de reconciliação. Uma comparação mensal dos números da plataforma, do MMP, do RevenueCat e dos pagamentos da loja, com os desvios esperados registados, para que da próxima vez que os números não coincidam saiba em cinco minutos se é estrutural ou um bug.

O que não tem correção depois do ATT, e porque o digo

Desde o iOS 14.5, os utilizadores que recusam o App Tracking Transparency não podem ser atribuídos ao nível do utilizador. O SKAdNetwork e o AdAttributionKit da Apple devolvem postbacks atrasados e agregados, sem identificador de dispositivo, e retêm detalhe de propósito em campanhas de baixo volume. Nenhuma integração com a Conversions API, nenhuma funcionalidade do MMP e nenhuma ferramenta de recuperação de atribuição muda isso. A Meta encaminha esses eventos através do Aggregated Event Measurement. A Google modela-os. O TikTok modela-os.

Por isso não prometo atribuição determinística. Prometo que os sinais que consegue controlar estão corretos, que as plataformas recebem o melhor input possível para otimizar, e que vai saber quais as discrepâncias normais. O ROAS da plataforma e a receita de subscrição vão continuar a discordar depois do trabalho estar feito. Vão discordar por razões que consegue explicar. Se um fornecedor lhe disser o contrário, pergunte-lhe de onde vem o ID do utilizador.

Que sistema reporta o quê no iOS?

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

Ver bem o iOS na Google exige trabalho do seu lado. Para a Integrated Conversion Measurement, a Google exige uma campanha de apps para iOS ativa, otimizada para instalações, os eventos first_open e os eventos após a 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 posterior, o SDK do Google Analytics for Firebase a partir da versão 11.14.0 e a propriedade do Analytics associada ao Google Ads, e a Google diz que ficará inativa para os utilizadores no EEE, no Reino Unido e na Suíça. Por isso o Google Ads, o MMP e o SKAN discordam por conceção, e a própria recomendação da Google é ler a vista de ICM se a implementou, e o Google Ads ou o SKAN se não o fez. A configuração do ICM para cada via de integração e a forma como reconcilio o Google Ads, o MMP e o SKAN têm cada uma o seu artigo.

Alguns desvios não têm nada a ver com definições. Numa conta Google que geri, o evento de receita enviava 1 $ em vez de 0 $ quando uma conversão não tinha valor, o que inflacionou o ROAS reportado pela Google em todo o lado, e sobretudo no iOS. É a conta por trás do meu teste de estratégias de licitação, e é exatamente o tipo de bug que a vista de reconciliação existe para apanhar.

Como funcionam o SKAN 4 e o AdAttributionKit nas campanhas da Meta no iOS?

É a Apple que decide o que volta: até três postbacks atrasados por anúncio vencedor, cada um com um valor de conversão que a sua app escreve no dispositivo, e tanto menos detalhe quanto mais pequena for a campanha. Na Meta, cada conjunto de anúncios de promoção de app para iOS usa ou essa atribuição do SKAdNetwork ou o Aggregated Event Measurement da própria Meta, consoante o sistema para o qual o seu evento de otimização é elegível.

O SKAN 4 e o AdAttributionKit devolvem ambos três janelas de postback, e só a primeira pode levar um valor fine. A Apple desce para coarse ou para nada quando uma campanha é demasiado pequena para proteger a multidão. 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 esquema tem de ser desenhado à volta do seu funil e do seu volume, e não copiado de um template, e é por isso que demasiadas divisões de geografia e criativo empurram todas as campanhas para baixo do limiar ao mesmo tempo. Em que 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 a Meta?

Alguém que seja responsável por todo o caminho do evento, do SDK da app e do MMP até ao backend de subscrição e ao Events Manager, porque a maioria dos bugs de sinal na Meta está onde duas destas peças se encontram. Num retainer, essa pessoa sou eu, com um engenheiro de atribuição da minha rede para o trabalho de SDK e de servidor, e um developer do seu lado que consiga lançar alterações.

A Conversions API para eventos de app envia, a partir do seu servidor, os mesmos eventos que o SDK ou o MMP enviam a partir do dispositivo, e a Meta remove as duplicações por ID de evento. A sua função é completude e valor: renovações, reembolsos e conversões que acontecem com a app fechada, cada uma com um valor e uma moeda. Não restaura a atribuição para utilizadores que recusaram o tracking; esses eventos continuam a passar pelo Aggregated Event Measurement. Vale a pena fazer, não é um workaround. Quando um evento chega à Meta e continua marcado como não elegível para o AEM, as verificações para cada via estão em porque é que os eventos de trial e de compra não são elegíveis para o AEM da Meta.

pLTV e value optimization

Um modelo prevê o valor de cada novo utilizador a partir do primeiro dia ou dois de comportamento. Esse número chega à plataforma como valor de compra, ou no iOS é comprimido no valor de conversão. A plataforma faz então lances por utilizadores parecidos com as suas previsões de alto valor. Que evento e que modo de bidding se ajustam a que app está escrito a partir de 1,2M$ de investimento na Meta.

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

Em que evento deve otimizar?

Estas são as três perguntas que faço, por ordem, antes de uma conta avançar para eventos mais profundos. A escada completa, da instalação para cima, está em em que evento uma app de subscrição deve otimizar.

1. Os eventos pagos ultrapassam o limiar de aprendizagem da plataforma com o seu volume? A referência da Meta é de cerca de 50 resultados por conjunto de anúncios na semana a seguir à última edição significativa. Se não, otimize para início de trial mais um evento de ativação. Se sim, passe à pergunta 2.
2. O trial to paid está saudável? Se não, fique em início de trial mais um evento de ativação. As duas condições têm de se verificar antes de mudar. Se sim, passe para compra e siga para a pergunta 3.
3. O valor que enviaria está correlacionado com o que os utilizadores acabam por pagar? 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 face a cohorts que já amadureceram, haver volume suficiente, e a plataforma recebê-la antes de a janela de atribuição fechar. Ativada cedo demais, otimiza para os utilizadores errados com grande confiança.

Reconciliar o ROAS da plataforma com a receita de subscrição, entre países

As plataformas contam conversões atribuídas e modeladas dentro da sua própria janela, a preço bruto, na data do clique. O RevenueCat conta receitas na data da transação, líquidas de reembolsos, numa única moeda. Os pagamentos da loja chegam segundo um calendário fiscal, líquidos de comissão e imposto local. Estes são desvios estruturais, e são esperados. Um desvio que muda de dimensão de um mês para o outro costuma ter um bug por trás: um evento de compra duplicado, um desfasamento de moeda, um valor que chega a uma plataforma e não à outra.

O ROAS multi país acrescenta a maturidade das cohorts. Um país cujos utilizadores pagam anualmente parece pior ao dia 7 e melhor ao dia 90 do que um que vende mensalmente, por isso comparo cohorts com a mesma idade, numa única moeda, líquidas de comissão, antes de decidir que país recebe orçamento. A auditoria de 383 mil $ mostra como isso se traduz numa conta real, e quantas compras um ROAS precisa antes de significar alguma coisa define o mínimo para cada corte.

Como funciona o trabalho

O signal engineering faz parte do retainer, e vem primeiro. A leitura começa com o growth audit: o que cada plataforma recebe atualmente, para que está a otimizar, e a comparação a quatro bandas com a variação esperada registada. Depois da leitura, algumas equipas implementam as correções sozinhas a partir da lista priorizada, com o esforço de engenharia estimado por item. Outras pedem-me para gerir as contas. Ambas as opções são válidas.

Para trabalho de SDK e tudo o que corre nos seus servidores, trago um engenheiro de atribuição da minha rede. Eu desenho e sou responsável pela camada; as mãos de engenharia são especialistas. Precisa de um developer que consiga lançar alterações durante o contrato, e de acesso de leitura ao Events Manager, ao MMP, ao RevenueCat ou ao seu backend de subscrição, e às contas de anúncios.

Se ainda está numa fase anterior a 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, e em que ordem. Marca-se através do mesmo calendário da chamada inicial.

Perguntas frequentes