5 suposições equivocadas que os anunciantes fazem sobre a SKAdNetwork
No último ano, a Apple anunciou algumas mudanças dinâmicas e gerou a revitalização de uma solução de canal de atribuição mais antiga.
Uma tecnologia que soma dois anos de idade e mal era discutida, a SKAdNetwork rapidamente se tornou principal assunto do momento, alimentando esperanças e gerando preocupações para os anunciantes que enfrentam as futuras mudanças de privacidade da Apple. Os anunciantes demonstram grande preocupação com a SKAdNetwork; há incertezas sobre como usá-la diariamente em decisões de marketing. Existem complexidades na configuração (dados agregados, valores de conversão, limites de tempo) e grande incerteza sobre como isso se relaciona com o panorama geral da Apple.
Ao longo dos últimos meses, conduzimos conversas abrangentes sobre a SKAdNetwork com centenas de anunciantes de todo o mundo, de setores que vão desde jogos, a eCommerce, finanças, delivery até companhias nível enterprise e SMBs. Com base nessas conversas, preparamos uma lista das suposições mais frequentes e equivocadas que a indústria como um todo faz sobre a SKAdNetwork.
1. O equívoco sobre o limite de tempo
Vamos começar falando sobre os limites de tempo, extensões, e atrasos, que são um equívoco fácil de explicar. A SKAdNetwork tem um timer de 24 horas anexado, que é ativado quando a função SK é chamada pela primeira vez (normalmente na primeira inicialização do app). Depois que o timer de 24 horas expira, o valor de conversão é trancado e registrado. A boa notícia é que os anunciantes ainda podem brincar com os limites do timer, usando extensões e métodos de atraso do sistema de tranca e registro do valor de conversão.
Extensão de timer
Em alguns casos, os anunciantes precisam de mais de 24 horas de atividade do usuário após a instalação para otimizar a eficácia de suas campanhas; um exemplo seria um aplicativo de jogos, em que o anunciante quer fazer a otimização com base na receita do dia 5.
A solução alternativa ao uso de extensões de timer é simples: se um aumento no valor de conversão for acionado pela abertura do aplicativo, o timer será zerado por mais 24 horas. Essa função pode ser executada várias vezes; em teoria, você poderia continuar zerando o timer por até dois meses.
O problema dessa abordagem é que ela depende do usuário abrir o aplicativo todos os dias (dentro da janela de 24 horas). Se um dia ele não iniciar o aplicativo, o timer não reiniciará, o que quebrará o ciclo. Além disso, essa abordagem irá gerar uma audiência parcial, na qual a mensuração e a otimização serão baseadas em grande parte na atividade dos seus usuários mais engajados, o que dificilmente é uma boa representação de toda a sua base de usuários.
Essa abordagem também atrasa o postback de SK único para além dos habituais 1-3 dias e requer uma distribuição de bits do valor de conversão para o mecanismo de extensão (por exemplo, um atraso de 7 dias requer 3 bits, deixando apenas 3 bits para dados mensuráveis).
Atraso no timer
Outra solução para o limite de tempo é um atraso no timer, que garante a mensuração e a otimização de eventos que ocorrem no final do funil (como cadastros após um teste de 7 dias ou a primeira compra in-app).
Você pode atrasar o timer para que ele comece apenas quando ocorrer o início de um avento. Isso é feito através do atraso da primeira chamada para as funções registerAppForAdNetworkAttribution and updateConversionValue.
Como mencionamos acima, em cada uma dessas soluções alternativas há uma desvantagem. Por um lado, atrasar o timer garante a mensuração do evento escolhido, mas se o usuário parar de usar o app antes que o evento ocorra, nenhum postback será enviado. Em outras palavras, você terá 100% de cobertura do número de usuários que realizaram o evento, mas não saberá quantos baixaram o aplicativo e pararam de usá-lo antes de o evento ser concluído.
2. O equívoco sobre os 6 bits
De fato, o valor de conversão é um recurso muito limitado. Um único campo de 64 valores, que deve conter todos os detalhes sobre a jornada do usuário. Embora limitado, um campo ainda é capaz de decodificar diferentes KPIs. Não existe uma abordagem única aqui, e a estratégia será diferente entre aplicativos e KPIs.
Existem dois métodos de abordagem: a divisão de bits e a abordagem de 64 segmentos.
Divisão de bits
A divisão de bits é usada para possibilitar a mensuração de diversos KPIs em paralelo: receita, engajamento, conversão, retenção e mais. Os anunciantes podem distribuir diferentes valores de bits para cada KPI, mas é importante lembrar que quanto mais bits você divide, menos granulares serão os seus dados de KPI. Você poderia, por exemplo, distribuir seus bits da seguinte maneira: 3 bits para receita, 3 bits para níveis completados. No entanto, isso te dará apenas 8 níveis de granularidade por KPI, ao invés dos 64 que você teria para um único KPI. Se você divide seus bits de 6 maneiras, você terá apenas 2 níveis para cada KPI (binário).
A abordagem de 64 segmentos
A abordagem de 64 segmentos permite que você mensure mais de seis diferentes eventos in-app enquanto avalia os usuários finais com base em segmentos, em vez de distribuir diretamente um bit por evento.
Isso pode ser feito definindo 64 segmentos diferentes de usuários. Por exemplo, um único intervalo pode conter os seguintes dados:
- evento1 aconteceu 2-6 vezes
- evento2 aconteceu mais de 10 vezes
- a receita total é de US$20-US$60.
Com esse método, você pode definir um número ilimitado de KPIs e eventos para cada segmento. A desvantagem dessa abordagem é que você não será capaz de decodificar o valor para um KPI específico (como a receita). Ele também requer que você seja extremamente cuidadoso ao validar esses 64 segmentos, certificando-se de que eles cobrem toda a gama de usuários do aplicativo, sem que hajam duplicações entre os segmentos. Basicamente, cada usuário deve fazer parte de apenas um segmento, sempre.
3. O equívoco sobre a mudança na configuração
Soluções para a SKAdNetwork baseadas em servidores (como a da AppsFlyer) permitem que os anunciantes mudem a configuração do valor de conversão na nuvem, onde um comando será instantaneamente enviado para o SDK. Isso garante que a lógica do cliente esteja sempre atualizada com as configurações desejadas.
Como acontece com muitas coisas na SKAdNetwork, as desvantagens são um elemento-chave aqui. Nesse caso, cada mudança de configuração ativa um curto período de tempo no qual é impossível determinar se os postbacks de entrada estão relacionados à configuração antiga ou à nova, criando um “ruído” extra na mensuração. É por isso que não recomendamos que você altere as estratégias com muita frequência (mais de uma vez por semana, por exemplo).
Temos uma boa notícia para você: existe uma alternativa para isso. Você terá que dedicar um dos 6 bits para indicar se o postback se relaciona à configuração antiga ou à nova. No entanto, como se trata da SKAdNetwork, isso traz outra desvantagem: se você quer a flexibilidade de poder mudar suas estratégias com frequência, você terá que comprometer o nível de granularidade que você pode mensurar para os seus KPIs.
4. O equívoco sobre a estratégia paralela
Existe uma maneira de ativar diferentes estratégias para diferentes segmentos de usuários. O requisito básico é que o parâmetro que distingue os grupos seja reconhecido tanto do lado do cliente (ao mudar o valor de conversão) como do lado do servidor (para que ele saiba como decodificar o valor).
Algumas segmentações recomendadas:
Segmentação baseada na localização
Mensure KPIs diferentes para regiões geográficas diferentes. Por exemplo, mensure a receita para usuários da França e o engajamento para usuários dos EUA.
Segmentação baseada na divisão aleatória
Ao dividir seus usuários finais aleatoriamente em grupos A/B, você pode mensurar seus KPIs em paralelo, sem comprometer a granularidade. Os detalhes técnicos da divisão aleatória exigem que um bit seja destinado à decodificação dos grupos A/B; por exemplo, o bit 1 indica para o servidor o que os bits 2-6 estão mensurando.
Infelizmente, nem todos os tipos de divisão em grupos são possíveis; uma divisão baseada na fonte de mídia, por exemplo, não é possível, pois esse parâmetro ainda não é reconhecido do lado do cliente quando há uma alteração no valor de conversão (já que os dados de atribuição são reconhecidos apenas do lado do servidor).
É importante notar que os resultados da divisão aleatória devem ser ampliados, assim como os postbacks para as networks. Isso pode ser feito automaticamente pela solução de divisão da AppsFlyer. Certifique-se de que a sua MMP também tenha esse suporte.
5. O equívoco sobre os eventos de servidor
Uma solução baseada em nuvem pode encaminhar eventos para o lado do cliente, alterando o valor de conversão de acordo. No entanto, esse tipo de fluxo tem outra limitação que não existe para eventos baseados em cliente: mesmo se o evento baseado em servidor foi acionado antes da expiração do timer da SKAdNetwork, o usuário final deve abrir o aplicativo novamente antes que da expiração do timer para que esse evento afete o valor de conversão.
Por esse motivo, recomendamos manter os eventos gerados pelo cliente sempre que possível.
Se, apesar dessa limitação, você quiser mensurar e otimizar com base na lógica dos seus servidores/CRM, certifique-se de que a sua estrutura de SKAdNetwork tenha suporte para essa opção. A AppsFlyer se orgulha de ser o primeiro software server-to-server compatível com a solução de SKAdNetwork.
Extraindo oportunidades de um desafio
Não há dúvidas: a SKAdNetwork apresenta novos desafios para os profissionais de marketing. Chega de “mensurar tudo” e “otimizar campanhas com base em tudo”. Isso não significa, no entanto, que esse seja o fim da otimização do marketing. Ainda existem muitas oportunidades para mensurar, otimizar e ter sucesso.
Se familiarizar com todos os bits e bytes do valor de conversão e fazer um planejamento, testes e suposições de validação adequados garantirão que você esteja aproveitando ao máximo uma solução não tão perfeita. Os anunciantes podem se colocar à frente da concorrência tomando medidas ativas e trabalhando com a melhor estrutura que atenda às suas necessidades de mensuração. E esclarecer esses 5 equívocos é um ótimo começo, não acha?
