Como monetizar com compras in-app no iOS 14.5+

O marketing mobile foi bastante impactado em abril quando a Apple introduziu as esperadas regras da AppTrackingTransparency (ATT).

Para os aplicativos que geram receita por meio de compras in-app (IAP, na sigla em inglês), se tornou mais difícil assegurar que suas decisões são baseadas em dados, pois há menos dados determinísticos.

No que diz respeito à receita em si, o iOS 14.5+ não deve afetar os gastos dos usuários no aplicativo. O custo das compras in-app não mudará; os usuários ainda poderão pagar por bens no aplicativo, como moedas de ouro ou vidas extras. Contudo, para os app publishers, a falta de atribuição determinística para usuários com opt-out pode dificultar uma compreensão clara de quanta receita é gerada por cada campanha.

Agora está mais difícil ligar cada compra in-app a uma instalação inicial ou reatribuição, por isso, entender quais canais de aquisição de usuários estão se saindo bem e prever o LTV no nível do usuário são grandes desafios.

Mas há estratégias que você pode usar para aproveitar ao máximo os dados disponíveis no mundo pós-IDFA. Maximizando o número de usuários com opt-in, você pode manter uma linha de base de dados determinísticos com os quais trabalhar, para modelar e prever objetivos. E identificando sinais importantes para suas otimizações, o sistema SKAdNetwork da Apple pode funcionar para você.

SKAdNetwork para compras in-app

A SKAdNetwork foi introduzida pela Apple em 2018, porém, com pouca adoção. A filosofia por trás da SKAdNetwork é que ela fornece uma mensuração de campanha onde não há dados disponíveis no nível do usuário. Com o iOS 14.5+, a Apple tornou o framework da SKAdNetwork — com recursos expandidos — a única forma de acessar dados de performance publicitária nos casos em que os usuários optam por restringir o acesso dos desenvolvedores ao IDFA.

A SKAdNetwork fornece espaço para 6 bits de métricas de downstream, um número entre 0 e 63 (ou entre 000000 e 111111 em binário), com um timer inicial de 24 horas. Esse "valor de conversão" pode ser atribuído a qualquer valor que pode ser expresso em binário. Toda vez que um valor de conversão é atualizado para um código de 6 bits novo definido no aplicativo, isso estende o janela do timer para mais 24 horas.

Quando essa janela do valor de conversão expira, um segundo timer de 24 horas inicia a contagem progressiva para a atribuição. Dentro dessa janela de 24 horas, a SKAdNetwork retorna dados de atribuição aleatoriamente. A ideia por trás desse timer aleatório é ofuscar o horário da instalação para que os gatilhos do evento não possam ser vinculados a usuários individuais. O sistema SKAdNetwork compartilha esses dados de forma agregada, sem dados granulares acessíveis no nível do usuário.

Para aplicativos que monetizam com compras in-app, esse insight restrito sobre o comportamento do usuário pode ser um problema. Em muitos games, o onboarding do usuário e a explicação sobre o valor de compras in-app pode levar mais de 24 horas. Se um usuário está disposto a pagar por vidas extras, ele pode não demonstrar essa vontade até atingir níveis maiores. É difícil monitorar isso se você só tem uma visualização pós-instalação de 24 horas.

É possível estender o timer usando um bit para prolongar a janela de conversão, simplesmente acionando uma atualização do valor de conversão (por exemplo, de 000001 para 000011, e assim por diante) periodicamente para obter mais 24 horas —, mas o usuário precisa fazer o login todos os dias para que o gatilho do valor de conversão possa rodar com o aplicativo em primeiro plano. Se o usuário não abrir o aplicativo novamente nessa janela, o valor de conversão não pode ser atualizado, o que significa que você perde os dados que esperava que prolongassem o timer para coletar.

Fazendo a SKAdNetwork funcionar para compras in-app

Dependendo do nível de precisão necessário, é possível monitorar o comportamento de compras in-app com a SKAdNetwork de duas formas principais.

A primeira é usando a abordagem "bit masking" (máscara de bits), na qual você designa cada um dos seis bits a um evento, e se o bit correspondente é definido como 0 ou 1 revela se aquele evento ocorreu. Essa abordagem é suportada pelo nosso mapeamento de valor de conversão simples.

Para monitorar seis ou menos eventos IAP, essa técnica pode ser usada, onde um bit simplesmente é vinculado a cada evento e você pode monitorar essas conversões Se você planeja otimizar em direção a marcos importante — por exemplo, "completar tutorial", "completar nível um" e "fazer uma compra" — então a abordagem "bit masking" é ideal.

Contudo, para insights mais aprofundados sobre intervalos e escalas de valores, você pode criar buckets de "compras" ou outras métricas. Um valor de conversão baseado em buckets permite definir valores que monitoram quanto os usuários gastam nas primeiras 24 horas. Para as categorias games, e-commerce, delivery e reservas de viagem, o Valor Médio do Pedido (AOV, na sigla em inglês) é um KPI bastante usado que mensurar a quantia gasta pelos usuários in-app. Se você está otimizando o AOV, é bom usar buckets englobando valores de compras totais diferentes.

Na abordagem baseada em buckets, você pode configurar intervalos de US$ 1 - US$ 5, US$ 6 - US$ 10 etc., com um valor retornando no postback de valor de conversão que corresponde a cada um desses buckets.

O modelo preditivo de LTV usa o comportamento do usuário no primeiro dia que ele usa o aplicativo para prever a receita futura a médio prazo. Tais modelos preditivos funcionam melhor quando usados em buckets ou categorias mais vastas. Você deve criar definições abrangentes para o sucesso possível e usá-las para filtrar os usuários com base no comportamento deles. Usar bucket para ações mais gerais, como dividir os usuários em "whales" ou "not whales", é possível usando o comportamento inicial deles.

Maximizar o número de opt-ins é o primeiro passo para adquirir dados determinísticos que você pode usar para modelar, prever e trabalhar de maneira eficiente com a SKAdNetwork. Com esses dados, você pode monitorar o comportamento de compras in-app usando o "bit masking" ou criando buckets de compras - dependendo de como você configurar e definir sua estratégia e de quais (e quantos) eventos IAP você desejar monitorar.

Para mais informações sobre como a Adjust promove seu crescimento, confira nosso guia ou visite nosso centro de recursos para o iOS 14.5+ aqui.