Visão geral: saiba mais sobre redes de autorrelato (SRNs)—atribuição, deep linking, implicações do iOS e FAQ.
SRNs integradas à AppsFlyer
Observação: as SRNs têm restrições de uso e retenção de dados no nível do usuário.
Atribuição
Ao contrário de não-SRNs (ad networks), que usam links de atribuição para relatar eventos à AppsFlyer, os SRNs se autoatribuem usando o ID do dispositivo quando notificados de uma instalação pela AppsFlyer.
A atribuição da AppsFlyer para SRNs e não SRNs é baseada em:
- Metodologias último toque e multitoque.
- Lógica de atribuição padrão da AppsFlyer para sequenciar a impressão relevante e os dados de clique.
Como a atribuição funciona com SRNs?
Os SRNs relatam eventos, como novas instalações e eventos in-app, para a AppsFlyer da seguinte maneira:
- Usando APIs para se comunicar com provedores de atribuição e métrica.
- Quando os provedores terceirizados de atribuição detectam uma instalação, eles consultam a rede usando o ID de anúncios.
- Detalhes do relatório de todos os cliques ou impressões de anúncios relevantes.
Depois que a AppsFlyer realiza a atribuição, os postbacks in-app são enviados ao SRN durante o período de retenção de dados do parceiro.
Como a atribuição funciona com SRNs avançados?
Os atributos de SRNs avançados são iguais aos de SRNs. No entanto, SRNs avançados também podem atribuir engajamentos quando não há ID de dispositivo (IDFA), usando a estrutura Privacidade Avançada Agregada e usando correspondência de ID e modelagem probabilística por meio do link de atribuição.
Atribuição de instalação
Os usuários em potencial do aplicativo veem e interagem com vários anúncios antes de instalar um aplicativo. Em geral, os provedores de atribuição oferecem aos anunciantes atribuição de último toque, o que atribui uma instalação ao último clique feito antes da instalação real.
Quando um aplicativo é inicializado pela primeira vez:
- A AppsFlyer verifica se:
- O aplicativo está configurado para receber tráfego de SRNs.
- O usuário tem um ID de anúncios.
- Se ambas as condições forem cumpridas, a AppsFlyer consulta SRNs usando o ID de anúncios.
- A AppsFlyer executa a atribuição após considerar as reivindicações da SRN.
Exemplos de atribuição de instalação
Exemplo A: atribuição assistida
Segunda-feira: a rede A relata um clique do usuário.
Terça-feira: a rede B relata um engajamento com um vídeo.
Quarta-feira: a rede C relata um clique em um anúncio interativo e, 30 minutos depois, há uma instalação.
A AppsFlyer atribui a instalação à Ad network C e dá crédito às Ad networks A e B por auxiliarem a instalação.
A AppsFlyer fornece aos anunciantes dados de assistência (engajamentos não atribuídos que ocorrem antes de uma instalação). Isso permite que os anunciantes personalizem seus modelos de atribuição multitoque ou parcial. Veja esta breve explicação.
Exemplo B: atribuição do último clique
A rede D (SRN) reporta um clique alguns minutos antes da rede C.
A rede C usa integração de atribuição padrão.
A AppsFlyer atribui a instalação à Ad network C, pois ela recebeu o último clique.
Janelas de atribuição
As janelas de atribuição incluem lookback e exibição. Algumas SRNs cobram anunciantes por uma instalação baseada no Custo por Impressão (em CPM) e no Custo por ação (CPA)—elas são baseadas em cliques ou impressões que ocorrem dentro de um 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 de um anunciante e nas janelas de lookback.
Os anunciantes podem ter que pagar por instalações baseadas em janelas de lookback de atribuição e modelos de exibição de SRN.
- Os anunciantes esperam que a metodologia de atribuição universal externa da AppsFlyer otimize e distribua seus gastos com anúncios.
- Por quê? Porque a AppsFlyer reporta eCPI e eCPA reais com base em termos definidos pelo anunciante.
- As SRNs podem se beneficiar a curto prazo, pois geralmente configuram suas próprias condições de pagamento. Mas os anunciantes corrigem isso usando provedores de atribuição externos.
Vinculação profunda com SRNs
Para que os usuários possam abrir o aplicativo quando o link é clicado, você só precisa configurar o esquema de App Links/Universal Links/URI. No entanto, para executar deep links ou deferred deep linking para uma página ou atividade específica em seu aplicativo, as SRNs usam seus próprios métodos, sem envolver o método de deep linking da AppsFlyer.
Então, como você pode fazer a vinculação profunda dos seus usuários e obter os dados relevantes das SRNs?
Direct deep linking
Quando um dispositivo de usuário executa deep linking, o deep linking direto com SRNs é feito sem chamar o método de deep linking da AppsFlyer. No exemplo abaixo, os usuários existentes que clicam em um anúncio são redirecionados para a atividade diretamente, usando os métodos do Facebook, enquanto os novos usuários obtêm a mesma experiência usando os dados de conversão da AppsFlyer. Saiba como o Meta ads usa o OneLink para deep linking
Exemplo
João, profissional de marketing mobile do "greatapp", decide realizar uma campanha de deep linking no Meta ads, direcionado ao público geral. A campanha redireciona quaisquer usuários que clicarem para uma atividade "bônus".
Paulo, o desenvolvedor mobile, adiciona essa lógica após obter os dados de conversão:
- É originário do Facebook ("is_fb=true")?
- Se verdadeiro, obtenha o parâmetro do grupo de anúncios.
- Se o valor contém a palavra "bonus", envie o usuário para a atividade "bônus".
Deferred Deep Linking
Em contraste com o deep linking, o deferred deep linking com SRNs é possível usando 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.
No entanto, com as SRNs, os parâmetros de deep linking regulares da AppsFlyer não estão presentes como parte dos dados de deep link. Para usar esses dados dentro do aplicativo, o desenvolvedor precisa empregar lógica adicional com base nos parâmetros disponíveis, como campanha, nomes do conjunto de anúncios ou de anúncios únicos.
Observação: para o Meta ads, o deferred deep linking via GCD está disponível para aplicativos Android usando o mecanismo de referenciador de instalação do Google. Ele não está disponível para aplicativos iOS.
Implicações do iOS
A maioria das SRNs é compatível com a SKAdNetwork e tem a integração necessária com a AppsFlyer.
Atribuição SRN do iOS 14.5
A partir do iOS 14.5, quando os usuários dão consentimento ATT nos aplicativos do anunciante e do editor (consentimento duplo), as instalações SRN, que são registradas no painel do SKAdNetwork, também são exibidas nos painéis.
Observação
- O dashboard tradicional mostra uma redução nas instalações atribuídas a SRNs. Ao considerar a performance do SRN, use o dashboard da SKAdNetwork. No geral, espere uma redução nas atribuições de instalações da SRN, com um aumento correspondente nas instalações orgânicas. No entanto, para SRNs avançadas, o impacto é menor, pois eles também atribuem engajamentos quando não há device ID.
- O painel do SKAdNetwork é atualizado com um atraso de 48 a 72 horas após a instalação.
- As instalações trazidas pela Apple Search Ads (ASA) não são atribuídas no dashboard da SKAdNetwork.
Enviar postbacks de eventos para SRNs
Os SRNs que recebem postbacks de eventos dependem da inclusão do ID do dispositivo no postback. Isso permite que as SRNs atribuam automaticamente as ações do usuário relatadas. Muitos usuários do iOS 14 não consentem, ou seja não permitem acesso ao ID do dispositivo (IDFA). Nesse caso, você 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 AppsFlyer — que registram todos os eventos.
Observação
- Se não houver IDFA, postbacks para instalações, aberturas de aplicativos ou eventos in-app não serão enviados aos SRNs (exceto neste cenário do Google Ads). No entanto, alguns SRNs avançados obtêm postbacks agregados também quando não há IDFA.
- As ad networks de cliques não são afetadas, pois usam suas próprias IDs de transação, e não IDs de 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á indicação semelhante. Em vez disso, para permitir a atribuição de reengajamentos de SRNs, a AppsFlyer usa outra lógica:
- Pré-requisitos:
- Na página Configurações do aplicativo, habilite Ativar retargeting.
- Na página Integrações ativas, selecione o SRN e ative Retargeting.
- Com cada inicialização de aplicativo, a AppsFlyer consulta a SRN sobre engajamentos recentes do ID do dispositivo com anúncios de campanha para o aplicativo.
- Se a SRN responder com detalhes de engajamento, a AppsFlyer valida que o engajamento está dentro da janela de lookback e além do tempo mínimo entre os reengajamentos.
- Os compromissos validados são registrados como reengajamentos e atribuídos à SRN.
O que é direcionamento incorreto de SRN?
As campanhas de SRN devem direcionar uma audiência específica, mas isso nem sempre acontece: não usuários em campanhas de aquisição de usuários e usuários existentes em campanhas de retargeting.
Se uma SRN for usada para executar tanto campanhas de aquisição quanto de retargeting de usuários, isso pode levar a erros de direcionamento do usuário. Como resultado, você paga por tráfego não intencional.
Cenário: uma SRN na plataforma da AppsFlyer está habilitada para uma campanha de aquisição de usuários.
- Após cada inicialização de aplicativo, a AppsFlyer consulta a SRN para verificar se o ID de publicidade (usuário) teve um engajamento recente.
- Se sim,
- a SRN responde com o nome da campanha.
- A AppsFlyer determina se foi a primeira inicialização (ou não) e atribui de acordo
:Primeira inicialização: uma nova instalação é atribuída à campanha.
Segunda inicialização ou posterior: um evento de retargeting é atribuído à campanha.
Conclusão: é um desperdício receber eventos de retargeting de uma campanha de aquisição de usuários.
O erro de direcionamento é um problema?
Analistas de dados da AppsFlyer verificaram as campanhas de aquisição de usuários do Meta ads durante um determinado mês.
- O retargeting estava ativado.
- Em 30% das campanhas, pelo menos 15% dos usuários direcionados eram usuários de aplicativos existentes.
- Em 5% das campanhas, pelo menos 40% eram usuários de aplicativos existentes.
- Conclusão: em campanhas de aquisição de usuário da SRN, 1 a cada 10 usuários direcionados já é um usuário existente.
Resolvendo o problema do erro de direcionamento
Solução básica: não inclua usuários de aplicativos existentes em uma campanha de aquisição de usuários.
- A SRN direcionará somente novos usuários em potencial.
- Maximiza os resultados de aquisição de novos usuários com o mesmo orçamento.
- Atualize periodicamente (e manualmente) a campanha, por exemplo, uma vez por mês.
- No entanto, intervalos de tempo significam que usuários existentes podem ser direcionados a campanhas de aquisição de usuário durante o primeiro mês após a instalação de um aplicativo.
Audiences, um recurso premium da AppsFlyer, permite que você envie automaticamente, e diariamente, qualquer segmento da sua base de usuários para dezenas de ad networks.
A pesquisa da AppsFlyer mostra que resolver erros de direcionamento pode ter um impacto significativo nos seus esforços de marketing e aquisição de usuários.
Por que o campo URL original está vazio nos relatórios de dados brutos?
O clique é realizado no ambiente SRN, mas sem um link de atribuição da AppsFlyer. Portanto, os dados de URL Original associados ao clique não estão disponíveis para a AppsFlyer.
O dashboard não mostra cliques e impressões da SRN
As agências podem configurar campanhas SRN?
A AppsFlyer envia postbacks por falta de identificação publicitária (IDFA/GAID)?
- Como parte da integração para a mensuração de remarketing com o Google Ads, quando um usuário não autorizado do iOS abre o aplicativo ou realiza um evento in-app, a AppsFlyer envia o
gbraide informações do evento para o Google Ads (para o eventoadditional_data_json). -
No Android, quando não há identificação do dispositivo, mas o valor de referência contém um
gclid(para instalações) ou um evento de reengajamento contém um deep link com o parâmetrogclid, a AppsFlyer envia ogclide informações de eventos para o Google Ads.
gbraid do Google Ads: um identificador agregado gerado pelo Google que identifica um grupo de dispositivos e é referenciado pelo deep link.
gclid do Google Click ID): um parâmetro passado na URL com cliques de anúncio, que identifica a campanha e outros atributos de clique que estão associados ao anúncio. Isso é utilizado para rastreamento de anúncios e atribuição de campanhas.