Sobre ad networks de autorrelato (SRNs)

Visão geral: saiba mais sobre redes de autorrelato (SRNs), ou seja, redes de auto-atribuição, que comunicam eventos atribuíveis por meio de APIs, e não por meio de links de atribuição, que costumam ser usados por não-SRNs. 

blobid0.jpg verizonmedia.png
Google Marketing Platform  Anúncios do Apple Search Google Ads Snapchat Facebook Tencent Social Ads Yahoo! Search Ads Verizon Media Twitter

Redes de autorrelato

  • SRNs:
  • Não SRNs (ad network) reportam eventos usando links de atribuição da AppsFlyer.
  • Implicações da SRN para iOS 14.5:  use o dashboard da SKAN, considerando a performance da SRN. Espere uma redução nas instalações atribuídas a SRNs no dashboard tradicional; use o dashboard da SKAN. 

Como funcionam as SRNs?

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, na plataforma, o aplicativo está configurado para receber tráfego de SRNs.
  • Se sim, a AppsFlyer usará o ID de publicidade (ID do dispositivo) para consultar SRNs (API).
  • A AppsFlyer executa a atribuição com base nos resultados retornados.

Exemplo A

SRN_1.png

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.

Observe que, no caso da Apple Search Ads (ASA), a AppsFlyer obtém as informações de atribuição de dentro do SDK. Se disponíveis, a AppsFlyer devolve para a ASA somente a hora e a data da inicialização do aplicativo.

Provedores de atribuição externos e SRNs

As SRNs usam uma metodologia de atribuição diferente. A abordagem delas é a seguinte:

  • Use uma API para se comunicar com provedores de atribuição e de mensuração (ao invés de reportar links de atribuição).
  • Quando os provedores de atribuição detectam uma instalação, eles consultam a ad network sobre um ID de publicidade.
  • A SRN informa os detalhes relevantes de cliques ou impressões de anúncios.
  • A AppsFlyer usa sua lógica de atribuição padrão para sequenciar os dados relevantes de impressão e cliques. 
  • A atribuição da AppsFlyer é baseada tanto da metodologia de último toque quanto na multitoque.

Exemplo B

Este exemplo continua o Exemplo A, descrito acima.

SRN_2.png

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.

SRNs e 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 abrir o aplicativo quando o link é clicado, você só precisa configurar o esquema de App Links/Universal Links/URI. 

No entanto, realizar deep linking ou deferred deep linking para uma página/atividade específica no aplicativo é diferente. SRNs têm seus próprios métodos proprietários para deep linking, que não envolvem links de atribuição de serviços de atribuição externos.

Então, como você pode fazer a vinculação profunda dos seus usuários e obter os dados relevantes das SRNs?

Vinculação profunda direta com SRNs

As SRNs usam seus próprios métodos para realizar deep linking.
Isso significa que o método de deep linking da AppsFlyer não é chamado quando um dispositivo do usuário executa deep linking a partir de uma SRN. Dessa forma, se houver necessidade de dados diretos de deep linking dentro do aplicativo, isso precisará ser feito usando osmétodos da SRN, para que seja possível obtê-los na inicialização do aplicativo.

Vinculação profunda adiada com SRNs

Em contrapartida, é possível usar o deferred deep linking com SRNs.
A AppsFlyer sempre 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 redirecionamento em uma SRN podem ser redirecionados dentro do aplicativo após a inicialização, usando os dados de conversão.

Contudo, com as SRNs, os parâmetros de vinculação profunda regulares do AppsFlyer, como af_dp, não estão presentes como parte dos dados de vinculação profunda. 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.

 Exemplo

Jill, comerciante de celulares da greatapp, decide realizar uma campanha de links diretos no Facebook, direcionada ao público geral.
A campanha redireciona quaisquer usuários que clicarem para uma atividade "bônus".
Jack, o desenvolvedor de celulares, adiciona essa lógica após obter os dados de conversão:
1. Tem origem no Facebook ("is_fb=true")?
2. Se verdadeiro, obtenha o valor do parâmetro do grupo de anúncios.
3. Se o valor contém a palavra "bonus", envie o usuário para a atividade "bônus".
Usando métodos do Facebook, usuários existentes que clicarem no anúncio são redirecionados para a atividade diretamente, enquanto os novos usuários obtêm a mesma experiência usando os dados de conversão da AppsFlyer.

Como alternativa, se seu aplicativo também incluir o SDK da SRN, você poderá coletar diretamente dados de deep link, por exemplo, com o Facebook Ads.

FAQ

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

O clique é realizado no ambiente SRN, mas sem um link de atribuição da AppsFlyer. Portanto, alguns SRNs não fornecem dados de cliques e impressões à AppsFlyer.

O Facebook e o Google fornecem alguns dados agregados à AppsFlyer.

Configurar uma campanha com uma agência e SRN

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 Parceiros integrados, selecione a SRN, 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 Facebook 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. 

mistargeted_users.png

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.

Implicações de atribuição da SRN no iOS 14.5

A partir do iOS 14.5, espere o seguinte:

  • A maioria das SRNs é compatível com a SKAdNetwork e tem a integração necessária com a AppsFlyer. 
  • A SRN instala:
    • Pode refletir tanto na SKAdNetwork quanto nos dashboards tradicionais se os usuários derem o consentimento à ATT nos aplicativos do anunciante e do publisher (também conhecido como consentimento duplo).
    • São registradas no dashboard da SKAdNetwork. Atenção! O dashboard é 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.

No geral, espere uma redução nas instalações atribuídas às SRNs com um aumento correspondente de instalações orgânicas.

O iOS 14 afeta o envio de postbacks de eventos para SRNs?

  • Atualmente, as SRNs que recebem postbacks de eventos dependem da inclusão da 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—não permitem acesso ao ID do dispositivo (IDFA).

O iOS 14 afeta as SRNs da seguinte forma:

  • Uma diminuição no número de postbacks de eventos para SRNs
  • Discrepâncias no número de postbacks de eventos entre SRNs e AppsFlyer; que registram todos os eventos.
  • 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.
Este artigo foi útil?