Blog Como criar uma estratégia de app analytics para aplicativos com modelo de assinatura no iOS 14.5+

Como criar uma estratégia de app analytics para aplicativos com modelo de assinatura no iOS 14.5+

Os serviços de assinatura estão crescendo, com os consumidores gastando, cada, em média US$ 20 por mês. Embora apenas 1% dos aplicativos monetize com assinaturas, mais de 90% dos gastos dos consumidores mobile vêm de aplicativos com modelo de assinatura. Com uma receita tão alta em jogo, é fundamental que os desenvolvedores otimizem o funil de forma eficiente.

Como nós apontamos em um artigo recente com o gamesindustry.biz, para os aplicativos que monetizam com modelos de assinatura, é ainda mais importante ter uma boa estratégia para o opt-in do usuário pós-iOS 14.5+, para assegurar que dados determinísticos sólidos possam ser coletados em todos os pontos do ciclo de vida do usuário. Nos aplicativos com modelo de assinatura, a jornada do usuário costuma ser mais longa e mais complexa do que em outras estratégias de monetização, o que significa que vale a pena obter todos os dados possíveis.

Mas mesmo com usuários que fazem o opt-out, ter um plano pronto e robusto para a SKAdNetwork permite inferir o LTV do usuário com certa segurança.

Obtendo o opt-in

Com taxas de opt-in altas garantidas, os aplicativos têm uma vantagem competitiva significante, tanto em termos de ter mais acesso a dados determinísticos factuais sobre os usuários quanto de poder criar modelos baseados no comportamento dos usuários com opt-in.

O uso dos prompts de pré-permissão pode ajudar a explicar aos usuários o benefício de consentir ao monitoramento no nível do usuário e há bastante recomendações sobre como criar o prompt de pré-permissão perfeito.

Para aplicativos com modelo de assinatura, saber quando o método de pagamento do usuário falha ou quando o usuário pausa, cancela ou reativa uma assinatura pode ajudar na otimização. Com o Subscription Tracking da Adjust solution, você pode obter uma visão inigualável do ciclo de vida do usuário. Contudo, sem o IDFA, é cada vez mais difícil obter dados confiáveis sobre como os usuários estão navegando por essa jornada até a conversão.

Usando a SKAdNetwork

Para aplicativos que monetizam com o modelo de assinatura, o desafio do iOS 14.5+ tem dois lados. Primeiro, conseguir postergar o timer da SKAdNetwork de forma confiável para além de 24 horas é difícil, mesmo que isso seja útil para coletar sinais dos seus usuários.

É 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, 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.

Por outro lado, é complicado obter dados suficientes do usuário nas primeiras 24 horas para fazer previsões a longo prazo. Com um número limitado de pontos de contato possíveis, por causa dos 6 bits limitados dentro dos valores possíveis, é importante prestar bastante atenção nos que são mais relevantes e aproveitar ao máximos essas primeiras 24 horas.

Sinal vs. ruído

Há duas formas principais de usar os 6 bits fornecidos pela SKAdNetwork. 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.

Nossa solução padrão SKAdNetwork permite mapear eventos de conversão aos eventos de assinatura que você já monitora no painel da Adjust.

A segunda opção é designar intervalos de valores a valores de conversão diferentes, o que permite criar "buckets" de usuários dependendo de onde eles se encontrem dentro dos intervalos que você definiu. Nosso sistema de gerenciamento de valor de conversão avançado suporta a criação de esquemas para definir esses buckets.

Para aplicativos de streaming de vídeos e de relacionamento, o engajamento do usuário é uma das métricas mais importantes — por isso, recomendamos que nossos clientes usem as condições "sessions" (sessões) na nossa solução avançada.

A condição "sessions" permite monitorar o número total de sessões registradas. No exemplo abaixo, o valor de conversão "3" será retornado se o usuário registrar entre 5 a 10 sessões.

"sessions": { "count_min": 5, "count_max": 10 }

  • count_min (padrão: 1) – A quantidade total de sessões monitorada não deve ser inferior à quantidade especificada;
  • count_max (padrão: ilimitado) – A quantidade total de sessões monitorada não deve ser superior à quantidade especificada;

Criando um modelo

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.

Por isso, aplicativos com modelo de assinatura podem usar um "período de teste" como o sinal da SKAdNetwork a ser otimizado, pois isso pode ocorrer de forma mais confiável na janela onde há visibilidade e por se tratar de uma ação repleta de intenção dentro da janela inicial.

Contudo, simplesmente usar o "período de teste" pode levar ao caminho errado. E sem insights sobre os eventos que ocorreram durante o teste, sem o IDFA, será ainda mais difícil presumir que um teste gratuito levou à conversão de um usuário que traz receita.

O teste

Pela razão mencionada acima, você pode considerar o "período de teste" e um sinal adicional relacionado que tem o potencial de enriquecer esse tipo de teste. Por exemplo, um usuário pode acionar um "período de teste" e ser designado um valor de conversão inicial. Depois você pode atualizar o valor de conversão se ele cancelar o teste durante a janela de valor de conversão. Isso exclui imediatamente um grande número de pessoas que dificilmente comprariam a assinatura, criando um bucket vasto de usuários com "teste cancelado" que, podemos presumir, provavelmente têm um LTV menor.

Ou, de outra perspectiva, talvez você queira monitorar as pessoas que se inscreveram para um teste gratuito e incluíram informações de pagamento. As pessoas que tiverem incluído informações de pagamento já indicam que estão abertas à conversão — e talvez são mais propensas a se tornarem usuárias pagantes a longo prazo.

Em caso de dúvidas sobre a implementação do iOS 14.5+, entre em contato com seu CSM ou Gerente de Contas. Nosso guia pode ser baixado aqui ou consulte o centro de recursos do iOS 14.5+.

Assine nossa newsletter: