Visão geral: Saiba mais sobre as Redes de Autorrelato (SRNs): atribuição, ligações diretas, implicações no iOS e perguntas frequentes.
SRNs integrados com a AppsFlyer
Nota: Os SRNs têm restrições de uso e retenção de dados a nível do utilizador.
Atribuição
Diferente das redes de anúncios não-SRNs, que utilizam links de atribuição para relatar eventos à AppsFlyer, os SRNs realizam a auto-atribuição utilizando o ID do dispositivo quando notificados de uma instalação pela AppsFlyer. Para apps iOS, utilizam-se o SKAN e o framework de Privacidade Avançada Agregada para atribuição.
A atribuição da AppsFlyer tanto para SRNs como para não-SRNs baseia-se em:
- Metodologias de last-touch e multi-touch.
- Lógica padrão de atribuição da AppsFlyer para sequenciar os dados de impressão e clique relevantes.
Como funciona a atribuição com SRNs?
Os SRNs relatam eventos, como novas instalações e eventos na aplicação, à AppsFlyer da seguinte forma:
- Utilizando APIs para comunicação com provedores de atribuição e medição.
- Quando provedores de atribuição de terceiros detectam uma instalação, consultam a rede utilizando o ID de publicidade.
- Relatam detalhes de quaisquer cliques ou impressões de anúncios relevantes.
Após a AppsFlyer realizar a atribuição, os postbacks in-app são enviados para o SRN durante o período de retenção de dados do parceiro.
Como funciona a atribuição com Advanced SRNs?
Os SRNs avançados atribuem-se da mesma forma que os SRNs. Entretanto, os SRNs avançados também conseguem atribuir envolvimentos quando não há ID do dispositivo (IDFA), utilizando o framework de Privacidade Avançada Agregada. Em certos casos, a atribuição é realizada usando correspondência de ID com consentimento duplo e, para alguns SRNs avançados, por meio de modelagem probabilística através de comunicação por API sobre cliques e impressões.
Atribuição de instalação
Os potenciais utilizadores da aplicação veem e interagem com vários anúncios antes de instalar a aplicação. Geralmente, os fornecedores de atribuição oferecem aos anunciantes a atribuição de último toque – isto é, atribui uma instalação ao último clique feito antes da instalação propriamente dita.
Quando uma aplicação é lançada pela primeira vez:
- A AppsFlyer verifica se:
- A aplicação está configurada para receber tráfego de SRNs.
- O utilizador possui um ID de publicidade.
- Se ambas as condições forem verdadeiras, a AppsFlyer consulta os SRNs utilizando o ID de publicidade.
- A AppsFlyer realiza a atribuição após considerar as reivindicações dos SRNs.
Exemplos de atribuição de instalação
Exemplo A: Atribuição assistida
Segunda-feira: A Rede A reporta um clique do utilizador.
Terça-feira: A Rede B reporta um envolvimento de vídeo.
Quarta-feira: A Rede C reporta um clique num anúncio jogável e, 30 minutos depois, ocorre uma instalação.
A AppsFlyer atribui a instalação à Rede C e reconhece as Redes A e B pelo suporte na instalação.
A AppsFlyer fornece aos anunciantes dados de assistência (envolvimentos não atribuídos que ocorrem antes de uma instalação). Isso permite que os anunciantes personalizem os seus modelos de atribuição multitoque ou fracionados. Para mais informações, consulte Explicação das instalações assistidas.
Exemplo B: Atribuição do último clique
A Rede D (SRN) reporta um clique alguns minutos antes da Rede C.
A Rede C utiliza a integração de atribuição padrão.
A AppsFlyer atribui a instalação à Rede C porque esta teve o último clique.
Janelas de atribuição
As janelas de atribuição incluem retrospeção e visualização. Alguns SRNs cobram aos anunciantes por uma instalação com base no Custo por Impressão (CPM) e no Custo por Ação (CPA), com base em cliques ou impressões que acontecem num período de 1 a 28 dias.
A AppsFlyer atribui instalação, atividade, Custo Efetivo por Instalação (eCPI) e Custo Efetivo por Ação (eCPA) com base na metodologia de atribuição preferida e nas janelas de retrospeção do anunciante.
Os anunciantes podem ter que pagar pelas instalações com base nas janelas de retrospeção de atribuição e modelos de visualização dos SRNs.
- Os anunciantes esperam que a metodologia de atribuição universal terceirizada da AppsFlyer otimize e aloque eficazmente o seu investimento em publicidade.
- Porquê? Porque a AppsFlyer reporta o eCPI e o eCPA reais com base nos termos definidos pelo anunciante.
- Os SRNs podem beneficiar a curto prazo, pois frequentemente definem as suas próprias condições de pagamento. Contudo, os anunciantes resolvem isso usando fornecedores de atribuição terceirizados.
Ligação direta com SRNs
Para que os utilizadores possam abrir a sua aplicação ao clicar no link, basta configurar o esquema App Links/Universal Links/URI. Contudo, para realizar deep linking ou deep linking diferido para uma página ou atividade específica na sua aplicação, os SRNs utilizam os seus próprios métodos, sem recorrer ao método de deep linking da AppsFlyer.
Então, como pode realizar deep linking dos seus utilizadores e obter dados relevantes dos SRNs?
Deep linking direto
Quando um dispositivo de utilizador realiza deep linking, o deep linking direto com SRNs é efetuado sem utilizar o método de deep linking da AppsFlyer. No exemplo abaixo, utilizadores existentes que clicam num anúncio são redirecionados diretamente para a atividade utilizando os métodos do Facebook, enquanto novos utilizadores têm a mesma experiência utilizando os dados de conversão da AppsFlyer. Saiba como os anúncios Meta utilizam OneLink para deep linking.
Exemplo
Jill, a especialista em marketing móvel da "greatapp", decide lançar uma campanha de deep linking nos anúncios Meta, dirigida ao público em geral. A campanha redireciona todos os utilizadores que clicam para uma atividade de "bónus".
Jack, o programador móvel, adiciona esta lógica após obter os dados de conversão:
- Tem origem no Facebook ("is_fb=true")?
- Se for verdade, obtenha o valor do parâmetro do grupo de anúncios.
- Caso o valor contenha a palavra "bónus", redirecione o utilizador para a atividade "bónus".
Deep linking diferido
Ao contrário do deep linking direto, o deep linking diferido com SRNs é viável utilizando a API GCD da AppsFlyer. A AppsFlyer recebe os dados de conversão e os disponibiliza para o aplicativo quando iniciado pela primeira vez. Usuários novos que instalarem após clicar em uma campanha de deep linking/de retargeting em uma SRN podem ser redirecionados dentro do aplicativo após a inicialização, usando os dados de conversão.
O deep linking diferido é suportado para o Google Ads, Snapchat e TikTok for Business, utilizando o valor real do deep link, que pode ser consultado através do GCD usando o campo af_dp. No caso do TikTok for Business, este valor também pode ser acedido a partir do campo deep_link_value. Contudo, com outros SRNs, os parâmetros habituais de deep linking da AppsFlyer não estão presentes nos dados de deep link. Para usar estes dados na aplicação, o programador precisa aplicar lógica adicional com base nos parâmetros disponíveis, como campanha, conjunto de anúncios ou nomes de anúncios individuais.
Nota: Para anúncios Meta, o deep linking diferido via GCD está disponível para aplicações Android utilizando o mecanismo Google Install Referrer. Está disponível apenas para aplicativos iOS se o SDK do Facebook estiver integrado ao seu aplicativo.
Implicações para iOS
A maioria dos SRNs suporta a SKAdNetwork e possui a integração necessária com a AppsFlyer.
Atribuição SRN no iOS 14.5
A partir do iOS 14.5, quando os utilizadores dão consentimento para ATT nas aplicações do anunciante e do editor (duplo consentimento), as instalações SRN, que são registadas no painel SKAdNetwork, também são exibidas nos painéis tradicionais.
Nota:
- O painel tradicional mostra uma redução nas instalações atribuídas aos SRNs. Ao analisar o desempenho dos SRNs, use o painel SKAdNetwork. No geral, é expectável uma diminuição nas atribuições de instalações SRN, com um aumento correspondente nas instalações orgânicas. No entanto, para SRNs avançados, o impacto é menor, pois também atribuem interações quando não há ID de dispositivo.
- O painel SKAdNetwork é atualizado com um atraso de 48 a 72 horas após as instalações.
- As instalações promovidas pelo Apple Search Ads (ASA) não são atribuídas no painel SKAdNetwork.
Envio de postbacks de eventos para SRNs
Os SRNs que recebem postbacks de eventos dependem da inclusão do ID do dispositivo no postback. Isto permite que os SRNs autoatribuam ações de utilizador relatadas. Muitos utilizadores do iOS 14 não consentem, o que significa que não permitem acesso ao ID do dispositivo (IDFA). Neste caso, deve esperar:
- Uma diminuição no número de postbacks de eventos enviados para SRNs
- Discrepâncias no número de postbacks de eventos entre SRNs e a AppsFlyer, que regista todos os eventos.
Nota:
- Se não houver IDFA, os postbacks para instalações, aberturas de aplicações ou eventos in-app não são enviados para os SRNs. No entanto, em alguns casos, a AppsFlyer envia postbacks para SRNs mesmo sem existir ID de publicidade.
- As redes de anúncios por clique não são afetadas, pois usam os seus próprios IDs de transação e não os IDs do dispositivo para autoatribuir informações de postback de eventos.
FAQ
Como funciona o retargeting com SRNs?
Os cliques de retargeting de não SRNs são facilmente identificáveis pela existência do parâmetro is_retargeting=true no link de atribuição de retargeting.
Com SRNs, não há uma indicação semelhante. Em vez disso, para permitir a atribuição de reengajamentos de SRNs, a AppsFlyer utiliza outra lógica:
- Pré-requisitos:
- Na página Definições da App, ative Ativar retargeting.
- Na página Integrações Ativas, selecione o SRN e ative Retargeting.
- A cada lançamento da aplicação, a AppsFlyer consulta o SRN sobre os envolvimentos recentes do ID do dispositivo com anúncios das campanhas da app.
- Se o SRN responder com detalhes de envolvimento, a AppsFlyer valida que o envolvimento está dentro do período de retrospectiva e além do tempo mínimo entre reengajamentos.
- Os envolvimentos validados são registados como reengajamentos e atribuídos ao SRN.
O que é a segmentação incorreta de SRN?
As campanhas de SRN devem ter como alvo um público específico, mas nem sempre isso acontece: Pessoas que não são utilizadoras em campanhas de aquisição de utilizadores e utilizadores existentes em campanhas de retargeting.
Se um SRN for usado para executar tanto campanhas de aquisição como de retargeting, isto pode levar a erros na segmentação do utilizador. Como resultado, acaba por pagar por tráfego não intencional.
Cenário: Um SRN na plataforma AppsFlyer está ativado para uma campanha de aquisição de utilizadores.
- Após cada lançamento da aplicação, a AppsFlyer consulta o SRN para verificar se o ID de publicidade (utilizador) teve um envolvimento recente.
- Se sim,
- O SRN responde com o nome da campanha.
- A AppsFlyer determina se foi o primeiro lançamento (ou não) e atribui os atributos em conformidade:
Primeiro lançamento: Uma nova instalação é atribuída à campanha.
Segundo ou mais lançamentos: Um evento de retargeting é atribuído à campanha.
Conclusão: É um desperdício obter eventos de retargeting de uma campanha de aquisição de utilizadores.
A segmentação errada é um problema?
Os analistas de dados da AppsFlyer examinaram campanhas de aquisição de utilizadores dos meta-anúncios ao longo de um determinado mês.
- O redirecionamento estava ativado.
- Em 30% das campanhas, pelo menos 15% dos utilizadores-alvo eram já utilizadores da aplicação.
- Em 5% das campanhas, pelo menos 40% eram utilizadores já existiam na aplicação.
- Conclusão: Nas campanhas de aquisição de utilizadores via SRN, 1 em cada 10 utilizadores-alvo já é um utilizador existente.
Resolvendo o problema de segmentação incorreta
Solução básica: Não inclua utilizadores já existentes da app numa campanha de aquisição de novos utilizadores.
- A SRN focará apenas potenciais novos utilizadores.
- Maximize os resultados de aquisição de novos utilizadores com o mesmo orçamento.
- Atualize a campanha periodicamente (e manualmente), por exemplo, uma vez por mês.
- Contudo, os intervalos temporais podem implicar que utilizadores existentes sejam alvo durante o primeiro mês após instalarem uma aplicação.
Públicos, uma funcionalidade premium da AppsFlyer, permite automatizar o envio diário de qualquer segmento da sua base de utilizadores para dezenas de redes de anúncios.
As investigações da AppsFlyer indicam que resolver a segmentação errada pode ter um impacto significativo nos seus esforços de marketing e aquisição de utilizadores.
Porque é que o campo URL Original está vazio nos relatórios de dados brutos?
O clique ocorre no ambiente SRN, mas não tem um link de atribuição da AppsFlyer. Por isso, os dados do URL Original associados ao clique não estão disponíveis para a AppsFlyer.
O painel não apresenta cliques e impressões de SRN
O clique ocorre no ambiente SRN, mas não tem um link de atribuição da AppsFlyer. Por isso, algumas SRNs não fornecem dados de cliques e impressões para a AppsFlyer.
Os meta-anúncios e o Google oferecem alguns dados agregados à AppsFlyer.
Podem as agências configurar campanhas SRN?
A AppsFlyer envia postbacks para IDs de publicidade ausentes (IDFA/GAID)?
Quando os IDs de publicidade contêm uma cadeia vazia (“”) ou têm o valor ‘00000000-0000-0000-0000-000000000000’ (IDFAs zerados), a AppsFlyer não envia postbacks para instalações, aberturas de apps ou eventos in-app, exceto nos seguintes cenários:
- Anúncios do Google: Como parte da integração para a medição de remarketing com o Google Ads, quando um utilizador iOS sem consentimento abre a aplicação ou realiza um evento na aplicação, a AppsFlyer envia o
gbraide as informações do evento para o Google Ads (para o eventoadditional_data_json). - Anúncios do Google: No Android, quando não existe ID de dispositivo, mas o valor do referenciador contém um
gclid(para instalações) ou um evento de reengajamento contém um link direto com o parâmetrogclid, a AppsFlyer envia ogclide a informação do evento para o Google Ads. - Meta: Cookies do Facebook ou IDs de campanha (em link direto ou reengajamento anterior) ou alternância de AEM ativada.
- Snapchat e TikTok (SRN Avançado) - Se atribuirmos ao Snapchat ou TikTok via PMOD e depois chegar um evento na aplicação ligado a essa instalação, enviaremos o postback.