Procurando pelo sinal: dicas para aplicativos com modelo de assinatura no iOS 14

Artigo de Guilherme Kapos, diretor de Vendas LATAM na Adjust:

Desde a introdução das regras do AppTrackingTransparency (ATT) da Apple em abril, o ecossistema mobile tem trabalhado para minimizar transtornos nas estratégias de monetização e campanhas de UA. As soluções foram desenvolvidas com muito cuidado para que os profissionais de marketing possam continuar tomando decisões baseadas em dados no mundo pós-IDFA.

Para aplicativos que monetizam com o modelo de assinatura, é ainda mais importante ter uma boa estratégia para o opt-in do usuário, assim é possível obter dados determinísticos sólidos 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 robusto para a SKAdNetwork permite inferir o LTV do usuário com certa segurança.

Se o usuário consentir o compartilhamento do IDFA tanto na fonte de mídia onde seu anúncio é exibido e dentro do seu aplicativo após o download, o IDFA estará presente em ambos os lados e é possível que um MMP faça a correspondência determinística — com 100% de confiança. Por definição, essa é a atribuição determinística.

Obtendo o opt-in

Garantir uma alta de taxa de opt-in permitirá uma significativa vantagem competitiva aos aplicativos, tanto por ter mais acesso a dados determinísticos sobre os usuários, quanto por poder criar modelos baseados no comportamento dos usuários com opt-in.

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

Em relação ao prompt do ATT em si, os profissionais de marketing estão aprendendo rapidamente o que funciona e o que não funciona. Você pode navegar por esta galeria de pop-ups ATT em uso para ver como diferentes aplicativos no ecossistema estão lidando com esse problema.

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. Sem o IDFA, é cada vez mais difícil obter dados confiáveis sobre como os usuários estão navegando por essa jornada confusa até a conversão.

Usando a SKAdNetwork

A Apple lançou a SKAdNetwork em 2018, introduzindo uma abordagem diferente para a mensuração de campanhas onde não há dados no nível do usuário disponíveis. Com o iOS 14, o framework SKAdNetwork tem sido desenvolvido e expandido, e a Apple tem tentado amenizar o impacto da redução do acesso ao IDFA para os desenvolvedores.

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 a 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 o modelo de assinatura, a dificuldade no iOS 14 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.

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. Trata-se de um método elegante para o monitoramento de eventos — e poderoso quando usado corretamente — porém limitado a seis eventos e eles precisam ser feitos como perguntas binárias de “sim ou não”.

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 encontram dentro dos intervalos que você definiu.

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 buckets para fazer melhorias gerais, como os aplicativos de jogos dividindo usuários em “whales” e “not-whales”, deve funcionar bem, enquanto traçar diferenças pequenas entre classes semelhantes de usuários é difícil.

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.

Como otimizar o “período de teste”

Pela razão mencionada acima, você pode considerar o “período de teste” e um sinal adicional e independente. 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 sejam mais propensas a se tornarem usuárias pagantes a longo prazo.

Porém, todo aplicativo é diferente, e faz sentido descobrir quais são os sinais no seu aplicativo. Por exemplo, talvez o melhor indicador para seu aplicativo seja registrar uma sessão adicional mais tarde no dia, após a configuração inicial, mostrando que o usuário está engajado e pronto para usar seus recursos. Ou talvez seja um bom sinal de uma provável conversão que o usuário está aceitando notificações push, indicando que ele está disposto a receber prompts para retornar ao aplicativo.

Bons indicadores de LTV não precisam ser necessariamente complicados. Por exemplo, o critério do Facebook é que quando o usuário adiciona sete novos amigos dentro de 10 dias, é mais provável que ele permaneça no aplicativo. Pense no que você pode descobrir sobre seus usuários desde o início e para que você pode usar essa informação. Colocar os usuários em buckets desde o primeiro dia ajuda a prever o valor deles a longo prazo.

O iOS 14 trouxe muitos desafios para os profissionais de marketing, mas usando as estratégias certas, há bastante oportunidades para quem conseguir sair à frente. Para os aplicativos com modelo de assinatura, em especial, isso significa identificar os sinais fortes iniciais para o LTV e garantir que eles estão iterando sua estratégia de opt-in constantemente para obter resultados melhores.

Deixe uma resposta