A perda de um bit inteiro realmente vale a pena? A verdade sobre a atribuição de fonte única do iOS 14.5+

A mensuração no iOS 14.5+ tornou-se mais complexa para anunciantes e profissionais de marketing mobile. Para ajudar com essa complexidade, os parceiros de mensuração mobile (MMPs) e as plataformas de analytics estão trabalhando em soluções desde o anúncio inicial em abril de 2020. À medida que adotamos essas mudanças na Adjust, estamos criando soluções de última geração que capacitam os clientes a colocar a privacidade de dados em evidência ao mesmo tempo em que impulsionam o crescimento.

Nossa abordagem concentra-se em utilizar dados no nível do dispositivo e do SKAdNetwork (SKAN) lado a lado para criar relatórios abrangentes em um formato tabular altamente preciso. Algumas outras soluções no mercado adotam uma abordagem "tudo em um" ou "fonte única" (single-source), que essencialmente tentam estimar a sobreposição entre instalações atribuídas por meio do framework do SKAN com instalações atribuídas por meio do framework App Tracking Transparency (ATT). A solução pode parecer boa em teoria, mas é profundamente falha. E o mais importante, ela custa o uso de um bit inteiro, deixando de aproveitá-lo.

Ao estimar a sobreposição de instalações do SKAN e instalações do ATT, teoricamente é possível ver quais instalações do SKAN já foram atribuídas pelo ATT. Isso significaria que os profissionais de marketing poderiam confirmar, em um nível agregado, que o Total de instalações do SKAN = Total de instalações do MMP pagas. Um bom uso disso seria para confirmar as diferenças inesperadas entre os dois conjuntos de dados. Esse processo de solução de problemas, no entanto, não tem próximas etapas. E acaba-se desperdiçando um bit importantíssimo apenas para provar números que não correspondem.

Vamos ilustrar isso com dois exemplos

1. Primeiro, temos o exemplo que gostamos de chamar de Falsa Esperança:

   Período: julho de 2022

   Instalações pagas do MMP: 80 mil

   Instalações orgânicas do MMP: 40 mil

   Instalações do SKAN: 100 mil, em que usando o bit de atribuição, 80 mil retornaram 1, o que significa que foram atribuídas

   Nesse cenário, um gerente de UA pode acreditar falsamente que todas as suas instalações do SKAN foram atribuídas e que seu MMP está mostrando o mesmo número de instalações pagas e que o número correto está sendo relatado. Essa é uma conclusão errada. Mesmo que os números pareçam corresponder em um nível geral, temos que dar um passo adiante. Das 80 mil instalações atribuídas pelo SKAN, digamos que 40 mil foram atribuídas ao Facebook e as outras 40 mil foram atribuídas ao Google com informações mínimas da campanha. O MMP, por outro lado, mostra 20 mil para o Facebook, 20 mil para o Google, 20 mil para uma campanha na web (que não é possível executar via SKAN hoje) e 20 mil para AppLovin. Portanto, enquanto os totais correspondem, os parceiros atribuídos não. Você pode fazer uma referência cruzada das janelas de atribuição por meio de seu MMP, mas como não pode ver as janelas do SKAN, não é possível comparar adequadamente os conjuntos de dados. Só porque os totais correspondem não significa que você está mais perto de uma fonte de verdade única.

2. Em segundo lugar, temos o exemplo mais comum, que gostamos de chamar de Beco Sem Saída:

   Período: julho de 2022

   Instalações pagas do MMP: 80 mil

   Instalações orgânicas do MMP: 40 mil

   Instalações do SKAN: 60 mil, em que usando o bit de atribuição, 40 mil retornaram com 1, o que significa que foram atribuídas

   Aqui, o gerente de UA pode ver que apenas metade das instalações mostradas pelo MMP como pagas são representadas em seus totais do SKAN. O gerente de UA pode verificar se talvez essas 40 mil instalações "ausentes" eram de campanhas incompatíveis com o SKAN: web, e-mail, influenciadores etc. Digamos que o MMP atribuiu 50 mil a várias campanhas da web e 20 mil ao Google e 10 mil ao Facebook. As instalações do SKAN foram atribuídas ao Google e ao Facebook, então, 30 mil para cada. Como você mapeia esses números juntos? As 40 mil que faltam no lado do SKAN não correspondem aos 50 mil das várias campanhas da web. Além disso, por que o Google e o Facebook foram atribuídos de forma tão diferente pelo SKAN e pelo MMP, respectivamente?  Você poderia, em tese, descobrir as razões exatas de como a atribuição aconteceu no lado do MMP, mas não pode fazer o mesmo no lado do SKAN. Em outras palavras, você chegou a um beco sem saída.

Em teoria, os KPIs de desempenho que você pode deduzir de um modelo de fonte única são eCPI*,* CPE e ROAS gerais, mas com as limitações inerentes em termos de precisão. Otimizar campanhas (escalonar, pausar, parar) com base no cálculo usado para estimar o desempenho seria altamente desaconselhável. Vamos analisar os detalhes das limitações de precisão a seguir.

Em resumo, os modelos de fonte única fornecem uma visão geral estimada de alto nível do total de instalações em iOS a partir de ambos os frameworks, pelo custo do uso de um bit inteiro.

Com a "fonte única", o sexto bit (o mais alto) é associado a um sinalizador (flag) TRUE/FALSE, o que significa que metade dos 63 valores de conversão que podem ser usados para mapear condições de evento e/ou intervalo de receita são perdidos. Na representação binária, fica assim:

Esses modelos baseiam-se muito em estimativas em um ecossistema que depende da precisão. Aqui, identificamos as quatro principais estimativas que os modelos "tudo em um"/de "fonte única" fazem e explicamos os problemas inerentes a cada uma.

1. Modelos de estimativa diferentes e desconhecidos: o próprio cálculo do Total de instalações pressupõe que o número de instalações pagas atribuídas via SKAN que incluem o sinalizador ATT é igual ao número total de instalações pagas atribuídas pelo framework do ATT. Sabemos por experiência que esse cálculo é incorreto. As razões para isso incluem:

• Seus parceiros precisam suportar ambos os frameworks para que os dados correspondam, o que atualmente não é o caso, por exemplo, de influenciadores e tráfego da web.
• As SANs podem não conseguir reivindicar instalações no framework do ATT devido à falta de consentimento do usuário, mas exatamente os mesmos usuários podem ser atribuídos a uma SAN no framework do SKAN (já que a atribuição ocorre independentemente do consentimento do usuário).
• A falta de acesso às informações de engajamento e à cascata de atribuição do SKAN significa que não é possível investigar como uma instalação foi atribuída a um parceiro específico.
• O SKAN e o ATT têm janelas de atribuição diferentes.

2. Atribuição de parceiro por framework: o cálculo pressupõe que, se o SKAN atribuiu uma instalação a um parceiro específico, o MMP também o fez (como mencionamos acima, a fonte do parceiro não está incluída no bit que carrega a informação sobre se a instalação foi atribuída por meio do framework do ATT ou não). Essa é uma informação que não pode ser confirmada ou negada, por isso não podemos simplesmente confiar nela. É possível supor que o número de instalações em ambos os lados se iguala, ao olhar apenas para os totais, mas, como dito no ponto anterior, isso pressupõe que você esteja trabalhando exatamente com os mesmos parceiros em ambos os frameworks, o que significa que a situação vai ficar complicada quando há uma discrepância de parceiros. Considerando a maneira como o SKAN funciona, essa não é uma situação incomum. Os anunciantes só podem executar campanhas de marketing interno (promoção cruzada, marketing por e-mail, campanhas de influenciadores e campanhas web mobile) dentro do framework do ATT. Com um modelo de "fonte única", no entanto, essas instalações também serão enviadas com o sinalizador ou flag de atribuição "true" e serão adicionadas ao número de instalações do SKAN com o sinalizador ATT, assumindo que, devido a uma sobreposição de inventário, o SKAN atribuiu esses mesmos dispositivos a uma rede de anúncios. Isso significa que você não pode presumir que instalações pagas do ATT = instalações pagas do SKAN (com sinalizador ATT) e que qualquer eCPI ou ROAS geral derivado será impreciso.

3. Dia da instalação: o dia da instalação também é uma estimativa no lado do SKAN, pois o postback não inclui o carimbo de data/hora exato. Essa estimativa pode ser feita com base na janela de CV utilizada e se o postback inclui um CV diferente de zero ou não. Uma grande complicação aqui é que, para o Google, o carimbo de data/hora do SKAN não se refere ao dia em que o Google recebeu o postback, como acontece com todos os outros parceiros. Em vez disso, refere-se ao dia estimado de engajamento, que é uma estimativa feita pelo Google. Portanto, você precisa estimar a data de instalação do SKAN com base no tempo estimado de engajamento do Google. Novamente, são estimativas demais para se confiar.

4. O limite de privacidade: o limite de privacidade da Apple cria mais complicações ao tentar criar um cálculo de fonte única. Alguns postbacks enviados do SKAN para parceiros incluem CV=null, o que significa que você não obtém as informações desejadas do postback necessárias para responder "esta instalação do SKAN foi atribuída no framework do ATT ou não?". A parcela de postbacks que retornam com valores null varia muito entre parceiros e campanhas (aprox. 10% a 40%) e nem sempre fica claro por que uma campanha tem uma parcela maior de valores null do que outra. Somente a Apple pode responder de verdade o que atinge ou não o limite. Quando se trata de instalações pagas do SKAN (sem sinalizador ATT), não há como estimar por meio de um fator de multiplicação devido à ambiguidade de como o limite de privacidade é aplicado. Qualquer tentativa seria, mais uma vez, uma estimativa.

Uma abordagem de "fonte única" ou "tudo em um" para dados de campanha do iOS é baseada em muitas estimativas. As soluções atualmente no mercado que visam combinar dados do SKAN e do ATT dependem de camadas de estimativas e sacrificam metade dos valores de conversão disponíveis para os clientes. Sacrificar um pouco em troca de dados imprecisos e não acionáveis não é um preço que vale a pena pagar. Se deseja os melhores e mais otimizados dados para ajudar o seu negócio a crescer, então é melhor não confiar em truques baratos. Dados claros, precisos e acionáveis são essenciais ao tomar decisões estratégicas importantes, como onde alocar o orçamento, quais campanhas pausar e escalonar ou em quais canais focar.

Ao levar em consideração todas as limitações do SKAN existentes, a Adjust recomenda relatórios comparativos por meio de nossa solução de analytics Datascape. Todos os dados disponíveis são exibidos em um formato fácil de entender que não usa atalhos, o que significa que essa pode ser sua verdadeira solução de fonte única. Com vários KPIs relacionados ao SKAN (conversão, receita e eventos), o Datascape permite que você crie relatórios abrangentes que podem ser justapostos aos seus dados regulares de atribuição da Adjust. Essa é a melhor maneira de garantir a precisão.

A maneira mais eficaz de navegar pela mensuração no complexo ecossistema do iOS é por meio de aprendizado de máquina e previsões que fornecerão eCPI, CPE e ROAS precisos, recursos que a Adjust está usando para desenvolver soluções de última geração. No final das contas, o que um profissional de marketing precisa é simples: uma ferramenta que demonstre claramente a receita que uma campanha recebe por cada dólar gasto, para que a decisão de pausar ou impulsionar uma campanha possa ser tomada com rapidez e confiança.

Para mais informações, você pode entrar em contato com o seu representante da Adjust.