Resumo: saiba mais sobre redes de autorrelato (SRNs)—atribuição, deep linking, implicações do iOS e FAQ.
SRNs integradas à AppsFlyer
Atenção: As SRNs têm restrições de uso e retenção de dados a nível de 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. Para aplicativos no iOS, a SKAN e o framework de Privacidade Avançada Agregada são usados para atribuição.
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?
As 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 advertising ID.
- A SRN informa os detalhes relevantes de cliques ou impressões de anúncios.
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 funciona a atribuição para SRNs—Avançadas?
As SRNs avançadas fazem a atribuição da mesma forma que as SRNs. No entanto, SRNs avançadas também podem atribuir engajamentos quando não há device ID (IDFA)—usando a estrutura de Privacidade Avançada Agregada. Em certos casos, a atribuição é realizada usando ID matching com consentimento duplo e, para algumas SRNs avançadas, por meio de modelagem probabilística através de comunicação por API para cliques e impressões.
Atribuição de instalação
Os usuários em potencial veem e interagem com vários anúncios antes de instalar um aplicativo. Em geral, os provedores de atribuição oferecem aos anunciantes a atribuição de último toque, o que atribui uma instalação ao último toque 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 advertising ID.
- Se ambas as condições forem cumpridas, a AppsFlyer consulta SRNs usando o advertising ID.
- 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 Network A relata um clique do usuário.
Terça-feira: A Network B relata um engajamento com um vídeo.
Quarta-feira: A Network C relata o clique em um anúncio jogável e, 30 minutos depois, ocorre uma instalação.
A AppsFlyer atribui a instalação à Network C e dá crédito às 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 multitouch ou parcial. Para mais informações, consulte entendendo as instalações assistidas.
Exemplo B: Atribuição do último clique
A Network D (SRN) relata um clique alguns minutos antes da Network C.
A Network C usa a integração de atribuição padrão.
A AppsFlyer atribui a instalação à Network C porque ela teve o último clique.
Janelas de atribuição
As janelas de atribuição incluem lookback e view-through. 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.
- Porquê? 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.
Deep linking 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 pode realizar deep linking dos seus usuários e obter dados relevantes dos SRNs?
Deep linking direto
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:
- Tem origem no Facebook ("is_fb=true")?
- Se verdadeiro (true), obtenha o parâmetro do grupo de anúncios.
- Se o valor contém a palavra "bonus", envie o usuário para a atividade "bonus".
Deferred deep linking
Ao contrário do deep linking, o deferred deep linking com SRNs pode ser feito usando a API GCD da Appsflyer. A AppsFlyer sempre recebe os dados de conversão e os disponibiliza para o aplicativo quando ele é aberto pela primeira vez. Usuários novos que instalam após clicar em uma campanha de deep linking/retargeting em uma SRN podem ser redirecionados dentro do aplicativo após a inicialização.
O deferred deep linking é compatível com Google Ads, Snapchat e TikTok for Business usando 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, esse valor também pode ser acessado a partir do campo deep_link_value
. No entanto, com outras 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 implementar uma lógica adicional com base nos parâmetros disponíveis, como campaign, ad set ou single ad names.
Atenção: para o Meta ads, o deferred deep linking via GCD está disponível para aplicativos Android usando o mecanismo Google Install Referrer. Ele só está disponível para aplicativos iOS se o SDK do Facebook estiver integrado ao seu app.
Implicações para iOS
A maioria das SRNs é compatível com a SKAdNetwork e tem a integração necessária com a AppsFlyer.
Atribuição SRN no iOS 14.5
A partir do iOS 14.5, quando os usuários dão o consentimento à ATT nos aplicativos do anunciante e do publisher (consentimento duplo), as instalações SRN, que são registradas no dashboard da SKAdNetwork, também são exibidas nos dashboards tradicionais.
Atenção:
- O dashboard tradicional mostra uma redução nas instalações atribuídas a SRNs. Ao considerar a performance da SRN, use o dashboard da SKAdNetwork. No geral, espere uma redução nas atribuições SRN das instalações, 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 dashboard da SKAdNetwork é atualizado com um atraso de 48 a 72 horas após a instalação.
- As instalações trazidas pelo Apple Search Ads (ASA) não são atribuídas no dashboard da SKAdNetwork.
Enviar postbacks de eventos para SRNs
SRNs que recebem postbacks de eventos dependem da inclusão do device ID 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 o acesso ao device ID (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 a AppsFlyer — que registra todos os eventos.
Atenção:
- Se não houver IDFA, postbacks para instalações, aberturas de aplicativos ou eventos in-app não serão enviados às SRNs. No entanto, em alguns casos, a AppsFlyer envia postbacks para SRNs mesmo sem o advertising ID.
- 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.
Perguntas frequentes
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 usa outra lógica:
- Pré-requisitos:
- Na página Configurações do aplicativo, habilite Ativar retargeting.
- Na página Integrações ativas, selecione a SRN e ative Retargeting.
- Com cada inicialização de aplicativo, a AppsFlyer consulta a SRN sobre engajamentos recentes do device ID com anúncios de campanha para o aplicativo.
- Se a SRN responder com informações 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 engajamentos validados são registrados como reengajamentos e atribuídos à SRN.
O que é uma segmentação equivocada de SRN?
As campanhas de SRNs devem ter como alvo um público específico, mas nem sempre isso acontece: Pessoas que não são usuários em campanhas de aquisição 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 segmentação de usuários. Como resultado, você paga pelo tráfego errado.
Cenário: uma SRN na plataforma da AppsFlyer está habilitada para uma campanha de aquisição de usuários.
- Após cada abertura do aplicativo, a AppsFlyer consulta a SRN para verificar se o advertising ID (usuário) teve um engajamento recente.
- Se sim,
- a SRN responde com o nome da campanha.
- A AppsFlyer determina se essa é a primeira abertura (ou não) e atribui os atributos em conformidade:
Primeira abertura: Uma nova instalação é atribuída à campanha.
Demais aberturas: Um evento de retargeting é atribuído à campanha.
Conclusão: receber eventos de retargeting de uma campanha de aquisição de usuários é um desperdício.
Por que isso é 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 segmentados já eram usuários do aplicativo.
- Em 5% das campanhas, pelo menos 40% já eram usuários do aplicativo.
- Conclusão: em campanhas de aquisição de usuários dessa SRN, 1 a cada 10 usuários segmentados já é um usuário existente.
Resolvendo o problema de erros de segmentação
Solução básica: não inclua usuários existentes em uma campanha de aquisição de usuários.
- A SRN segmentará somente novos usuários em potencial.
- Maximize 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, com diferentes intervalos de tempo, os usuários existentes podem ser segmentados em 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 segmentação 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 ocorre no ambiente SRN, mas não tem 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 para advertising IDs ausentes (IDFA/GAID)?
Quando os advertising IDs contêm uma string vazia ("") ou mostram o valor '00000000-0000-0000-0000-000000000000' (IDFAs zerados), a AppsFlyer não envia postbacks para instalações, eventos de abertura ou eventos in-app, exceto para os seguintes cenários:
- Google Ads: 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
gbraid
e informações do evento para o Google Ads (para o eventoadditional_data_json
). - Google Ads: No Android, quando não existe um device ID, mas o valor do referrer contém
gclid
(para instalações) ou um evento de reengajamento contém um deep link com o parâmetrogclid
, a AppsFlyer envia ogclid
e a informação do evento para o Google Ads. - Meta: Cookies do Facebook ou IDs de campanha (em deep link ou reengajamento anterior) ou toggle de AEM ativado.
- Snapchat e TikTok (SRN Avançada) - Se atribuirmos ao Snapchat ou TikTok via PMOD e depois chegar um evento in-app ligado a essa instalação, enviaremos o postback.
gbraid
do Google Ads : Um identificador agregado gerado pelo Google que identifica um grupo de dispositivos e é referenciado pelo link direto. Os cliques e impressões de SRNs estão disponíveis nos relatórios de dados brutos?
Não, cliques e impressões de SRNs não são compartilhados em relatórios de dados brutos. Embora os dados da SRN sejam usados para atribuição, cliques e impressões brutos não estão incluídos nos relatórios. Isso se aplica a todas as SRNs, incluindo TikTok, Snap, Meta e Google.