Resumo: a AppsFlyer determina a fonte de mídia que motiva um usuário a instalar ou reengajar com um aplicativo e atribui a ação do usuário a essa fonte, usando o modelo de atribuição da AppsFlyer.
O que é atribuição?
Atribuição é o ato de determinar o que fez com que um usuário instalasse um aplicativo ou executasse atos pós-instalação, como reengajamento ou reatribuição. O resultado da atribuição pode ser:
- Uma fonte de mídia não orgânica: o usuário interagiu (geralmente por meio de impressão ou clique) com uma fonte de mídia.
- Orgânica: o usuário não interagiu com uma fonte de mídia. Atenção! Para facilitar a compreensão, muitas vezes nos referimos a um usuário como sendo atribuído organicamente. Sabemos que isso não é exatamente verdadeiro, pois os usuários que instalam organicamente não são atribuídos.
A atribuição é essencial para otimizar a aquisição de usuários, esforços de reengajamento e resultados.
Dica
Quer saber mais sobre atribuição? Confira esse curso curto e informativo no Portal de Aprendizado da AppsFlyer.
O que é uma instalação de aplicativo?
O Modelo de atribuição é um conjunto de regras que determina como o crédito de um evento é atribuído aos touchpoints nos caminhos de conversão. Cada um dos players do ecossistema de marketing, Google Play, App Store, Apple, plataformas de CTV, PC e console, ad networks como Meta Ads e X Ads e empresas de mensuração mobile têm seus próprios modelos de atribuição. Cada um contabiliza instalações e eventos de maneira diferente.
O importante não é a diferença entre os modelos, mas sim que as regras sejam claras e aplicadas de maneira imparcial. Isso permite que os anunciantes otimizem campanhas e comparem a qualidade da performance dos seus usuários.
É importante entender os modelos e regras de atribuição dos players com os quais você trabalha. O mais importante é entender o modelo e as nuances dos métodos compatíveis com a AppsFlyer.
Na AppsFlyer, um evento atribuível acontece quando um dos seguintes eventos ocorre:
- No contexto da aquisição de usuários: Uma instalação é registrada e atribuída depois que o usuários baixa e inicia o aplicativo. Isso significa que, na AppsFlyer, o timestamp de data/hora de uma instalação é a primeira inicialização. Por outro lado, as ad networks usam o tempo de engajamento e as app stores usam a hora do download.
- No contexto do retargeting:
- Re-engajamento
- Re-atribuição
Métodos de atribuição
A AppsFlyer usa vários métodos de atribuição, listados na tabela a seguir:
| Método | Usa o device ID | Técnica | Atribuído por |
Android (Google Play e lojas de terceiros)
|
iOS | Universal Windows Platform (UWP) | Plataformas CTV, PC e console (3) |
|---|---|---|---|---|---|---|---|
| Referrer (1) | Não | Determinístico | AppsFlyer | Sim (2) | Não | Sim | Não |
| Device ID matching (1) | Sim | Determinístico | AppsFlyer | Sim | Sim | Sim | Sim |
| Modelagem probabilística (1) | Não | Probabilístico | AppsFlyer | Sim | Sim | Não | Sim |
| Privacidade Avançada Agregada (AAP) (1) | Não | Agregado | AppsFlyer | Não | Sim | Não | Não |
| Preload (1) | Não | Determinístico | AppsFlyer | Sim | Não | Sim | Não |
| SKAdNetwork (SKAN) | Não | Determinístico | Apple | Não | Sim | Não | Não |
| Apple Search Ads (1) | Não | Determinístico | Apple | Não | Sim | Não | Não |
| Deep link (1) | Não | Determinístico | AppsFlyer | Sim | Sim | Sim | Não |
|
(1) Às vezes aparece como método de atribuição "Clássico" nos dashboards e relatórios da AppsFlyer (2) Compatível com algumas lojas externas (3) Veja a lista completa de plataformas de CTV, PC e console |
|||||||
Prioridades do método de atribuição (cascata de atribuição)
Em uma nova instalação, se houver mais de um contrato válido, a AppsFlyer prioriza cliques ao invés de impressões e métodos determinísticos no lugar de métodos probabilísticos. Os métodos de atribuição são utilizados de acordo com as prioridades mostradas no gráfico.
Veja abaixo as descrições detalhadas dos modelos de atribuição da AppsFlyer.
Install referrer (apenas Android)
- Os aplicativos Android baixados do Google Play e algumas outras lojas de aplicativos são geralmente atribuídos pelo método de install referrer. O referrer fornece a URL original, que recebeu um clique antes de redirecionar para a loja Android. Esse é o principal método para atribuição do Android. No momento, Google Play, a loja de aplicativos da Huawei, a Samsung Galaxy Store e a Xiaomi GetApps Store são compatíveis com a atribuição do referenciador da instalação. Atribuição alternativa da loja de aplicativos usando o referrer.
- Meta install referrer: A AppsFlyer tem suporte para a atribuição de Meta Ads para aplicativos do Android, recebendo metadados de campanhas de anúncios do armazenamento local de um dispositivo. Esses dados são usados para mensuração de atribuição (atribuição Meta no dispositivo).
Device ID matching
Um método clássico de atribuição em que a ad network, que possui acesso ao dispositivo do usuário, envia o device ID para a AppsFlyer através da URL de clique ou ao notificar a AppsFlyer de que uma impressão foi exibida. Isso permite que a AppsFlyer faça a correspondência do click device ID com o device ID coletado pelo SDK da AppsFlyer.
O device ID matching é o principal método de atribuição no iOS.
Os IDs disponíveis são:
- Dispositivos iOS: IDFA, IDFV
- Dispositivos Android: com Google Play Services: GAID
- Dispositivos Android sem Google Play Services: OAID, Android ID, IMEI, Fire ID
Os device IDs podem ser encriptados utilizando SHA1 ou MD5 em links de atribuição.
Device ID matching usando IDFV (iOS)
- Um método clássico de atribuição usando o identificador de fornecedores (IDFV) está disponível no iOS 6.0+. Não está sujeito aos mecanismos da Apple ATTrackingManager e LAT. Assim, sempre está disponível e pode ser usado para anúncios cross-promotional de apps do mesmo fornecedor.
- O SDK da AppsFlyer coleta IDFV por padrão.
- Segundo a Apple, o valor dessa propriedade é o mesmo para apps do mesmo fornecedor que são executados no mesmo dispositivo.
- Um IDFV é gerado pela Apple quando o usuário instala o primeiro aplicativo de um determinado fornecedor. Ou seja, a Apple verifica se não há outros aplicativos do mesmo fornecedor no dispositivo. Consequentemente, excluir todos os aplicativos de um determinado fornecedor e, em seguida, instalar um aplicativo do mesmo fornecedor, resulta em um novo IDFV.
- Se o IDFV estiver disponível, você deve enviá-lo, pois ele melhora a precisão da atribuição. Usamos o IDFV em diversos cenários, incluindo:
- Atribuição de promoção cruzada.
- Atribuição de reinstalação no mesmo dispositivo.
- Relatórios de dados brutos.
- Audiences.
Device ID matching para redes de autorrelato (SRNs)
Um método de atribuição clássico onde, após a primeira abertura do app, a AppsFlyer verifica nas configurações do aplicativo se o tráfego de alguma das redes de auto-elato (SRNs) é esperado, como Meta Ads, Snapchat, e Google Ads.
A AppsFlyer consulta as SRNs relevantes usando a ID do dispositivo exclusiva da nova instalação. A consulta utiliza APIs dos Mobile Measurement Partners (MMP), conforme definido pelas SRNs. Com base na resposta, a AppsFlyer pode atribuir novos usuários a uma SRN.
Modelagem probabilística
A modelagem probabilística é uma técnica estatística que usa machine learning para estimar o desempenho da campanha. Os seguintes parâmetros de modelagem probabilística são coletados:
- Inicialmente no clique ou na visualização do anúncio (quando ativado)
- Novamente, quando o aplicativo é iniciado
Características de implementação
- Usa estatísticas e não é baseado em IDs exclusivos.
- É um método de fallback usado na ausência de um referer ou de advertising IDs. Métodos determinísticos de atribuição, ou seja, cliques com referrer ou ID matching recebem prioridade se ocorrerem dentro da janela de lookback.
- Para aplicativos mobile, a AppsFlyer determina dinamicamente a janela de atribuição com base na network do usuário. A duração da janela é adaptável, porém menor do que a janela de outros métodos (até 24 horas).
- Para aplicativos de CTV, PC e console, a janela de atribuição é determinada pelo parâmetro
af_lookback_windowdo link, mas não pode ultrapassar 7 dias. - A modelagem probabilística de click-through está sempre ativada.
- A modelagem probabilística de view-through precisa ser ativada na página de configurações do aplicativo e na aba de integração de não-SRNs. Para apps de CTV, PC e console, ela é ativada por padrão.
Parâmetros de modelagem probabilística para ad networks
Implementação de ad networks: a atribuição de modelagem probabilística deve enviar os seguintes parâmetros via no link de atribuição ou por meio de cabeçalhos de solicitação HTTP:
Privacidade Avançada Agregada (AAP)
A Privacidade Avançada Agregada (AAP) expõe resultados de performance da campanha de forma agregada, impedindo qualquer opção de rastreio dos usuários em aplicativos e sites de propriedade de diferentes empresas, e a possibilidade de identificar exclusivamente um usuário ou um dispositivo.
A AAP utiliza os níveis de privacidade da SKAdNetwork da Apple como uma referência mínima para seus limites de preservação de privacidade. A AAP é o modelo de atribuição padrão para dispositivos Apple que operam no iOS 14.5+, exceto nos casos que são explicitamente permitidos pela Apple, como em mídias próprias e usuários que deram o consentimento à ATT.
Ao contrário dos outros métodos de atribuição descritos, o objetivo do algoritmo de machine learning da AAP é maximizar a precisão da performance agregada da campanha, não a precisão da atribuição do usuário final.
Campanhas de preloa
Nas campanhas de preload, aplicativos são instalados no dispositivo por um parceiro de preload, seja na fábrica ou na ativação do dispositivo. Os parceiros de preload são:
- Fabricante do equipamento original (OEM na sigla em inglês)
- Plataformas de descoberta de aplicativos
- Operadoras móveis
Existem 3 métodos para atribuir campanhas de preload. Todos os três métodos podem ser usados simultaneamente. Eles não interferem nos mecanismos um do outro.
Os 3 métodos e algumas das principais especificações estão descritos na tabela a seguir. Clique nos links para saber mais sobre cada método de preload.
| Método de atribuição preload | Caso de uso | Informações do activation-to-app launch do dispositivo* | Janela de lookback** | Tipo de correspondência nos dados brutos |
|---|---|---|---|---|
| AppsFlyer referrer* |
|
Sim |
|
|
| Instalação automática do Google Play** | Pré-instalado na ativação do dispositivo (para apps do Google Play) | Não |
|
preload_pai |
| Pré-instalado na fábrica via propriedade do sistema ou manifest (Android)** |
|
Não | Sem limite | preload_conf |
|
A solução AppsFlyer referrer preload fornece visibilidade e capacidade de métrica entre a ativação do primeiro dispositivo e a primeira inicialização do aplicativo. Isso permite que você veja quantos dispositivos foram ativados com o aplicativo pré-instalado nos dispositivos por um parceiro específico e, em seguida, veja quando o aplicativo é iniciado pela primeira vez. Para os dois outros métodos, a atribuição é determinada somente após o usuário inicializar o aplicativo pela primeira vez - o número de dispositivos que tiveram o aplicativo instalado antes da primeira inicialização não está disponível. ** Pode levar dias ou semanas, a partir do momento em que o usuário liga seu dispositivo até que ele abra o aplicativo pré-instalado pela primeira vez. Consequentemente, a AppsFlyer dá a maior prioridade às campanhas de preload na determinação da atribuição, com janelas de lookback mais longas.
| ||||
Deep link
Um método clássico de atribuição para reengajamentos apenas, quando os usuários não são redirecionados para uma loja de aplicativos para fazer o download do app. Portanto, as informações na URL podem ser conectadas diretamente ao clique (e subsequente abertura do aplicativo). Esse método de atribuição é chamado de deep link, pois é a URL do deep link que carrega as informações usadas para atribuir o reengajamento.
Métodos de atribuição por fonte de mídia e recurso da AppsFlyer
Consulte as seções a seguir para uma análise completa sobre quais métodos de atribuição específicos são compatíveis, dependendo do/da:
- Fonte de mídia: própria ou paga
- Recurso da AppsFlyer usado
- Dispositivo do usuário: Android ou iOS
Mídia própria
| Fonte de mídia | Funcionalidade | Método de atribuição | |
|---|---|---|---|
| Android | iOS | ||
| Mídias próprias: e-mail (incluindo ESPs), SMS, posts de mídias sociais, influenciadores/afiliados, impressão etc. | OneLink |
|
Modelagem probabilística |
| Site mobile próprio/landing page com tráfego de entrada pago ou orgânico | Smart Banners |
|
Modelagem probabilística |
| OneLink Smart Script |
|
Modelagem probabilística | |
| Aplicativos mobile próprios | User invites/referral |
|
Modelagem probabilística |
| Promoção cruzada |
|
Device ID matching | |
Mídia paga
| Fonte de mídia | Método de atribuição | ||
|---|---|---|---|
| Android | iOS | Plataformas CTV, PC e console | |
| SRNs | Device ID matching |
|
Device ID matching |
|
|
|
|
| Pré-instalado no dispositivo | Pré-instalações | -- | |
Tipos de atribuição de engajamento do usuário
A atribuição é realizada com base em engajamentos por click-through e view-through. A atribuição da fonte de mídia é obtida através da utilização de técnicas de device ID matching e modelagem probabilística.
Atribuição de click-through
A maioria das instalações são resultado dos cliques do usuário em anúncios como banners, vídeos e intersticiais.
Após o clique no anúncio, a AppsFlyer abre uma janela de lookback por clique com uma duração padrão de 7 dias. Instalações que ocorrem dentro do prazo da janela de lookback não são orgânicas e são atribuídas à fonte de mídia. Instalações que ocorrem após a duração da janela de lookback são consideradas orgânicas. Muitas vezes mencionado como organicamente atribuído.
- Uma janela de lookback de cliques de sete dias é considerada o padrão da indústria. Defina a duração da janela de acordo com seu contrato com a fonte de mídia.
- Alinhe as janelas de lookback de SRN com a duração determinada pela SRN.
| Tipo de atribuição | Método de atribuição | Intervalo | Padrão |
|---|---|---|---|
|
Click-through (Todos os parceiros integrados)
|
Referrer, ID Matching | 1–30 dias | 7 dias |
| Modelagem probabilística | 0–24 horas |
|
Atribuição de view-through
Usuários que visualizam anúncios, mas não clicam neles, podem ser atribuídos à ad network responsável pelo anúncio.
A janela de lookback para atribuição de view-through:
- Menor do que a de atribuição de click-through
- Configurável.
Isto é especialmente útil para ad networks de vídeo que têm CTRs tradicionalmente baixos em seus anúncios em vídeo, mas também para as ad networks tradicionais que veiculam anúncios normais.
Nos casos em que um clique e uma impressão ocorrem, o clique sempre prevalece, uma vez que ele é um engajamento ativo.
| Tipo de atribuição | Método de atribuição | Alcance |
Padrão |
|---|---|---|---|
|
Atribuição de view-through (para parceiros integrados selecionados)
|
ID Matching | 0-24 horas | 1 dia |
| Modelagem probabilística | 0-24 horas |
|
Para ativar a atribuição de view-through:
- Configure a janela de lookback na janela de configuração.
Tópicos de atribuição avançada
Eventos in-app
A AppsFlyer utiliza o ID do dispositivo ou um ID exclusivo da AppsFlyer para atribuições (instalação, reinstalação ou reatribuição) com o objetivo de atribuir eventos in-app à fonte de mídia. Os anunciantes podem usar essas informações para acompanhar as jornadas do usuário nos dados brutos de seus aplicativos. Nos dados agregados diários, o ID do dispositivo/ID da AppsFlyer é usado para calcular o número de usuários únicos, como por exemplo o número de usuários exclusivos que realizam um evento in-app.
Para mais informações sobre atribuição de eventos, clique aqui.
Instalações assistidas
O AppsFlyer atribui integralmente apenas uma fonte de mídia por instalação, normalmente de acordo com o último clique no anúncio ou a última impressão do anúncio (se não houve nenhum clique).
Instalações assistidas (também conhecidas como atribuição multitouch) são instalações em que a fonte/campanha de mídia não foi o último ponto de contato, mas alcançou o usuário antes da instalação e o toque ocorreu na janela de lookback de atribuição.
As redes auxiliares são mostradas como colaboradoras para a instalação na AppsFlyer.
Para mais detalhes, clique aqui.
Reinstalações
Uma reinstalação ocorre quando um usuário instala o aplicativo, o desinstala e então o reinstala. A atribuição de reinstalação é regulada pela janela de reatribuição da seguinte forma:
- Se a reinstalação ocorrer após a expiração da janela de reatribuição: uma nova instalação é registrada.
- Se a reinstalação ocorrer durante a janela de reatribuição, ocorre um dos seguintes eventos:
- Se o usuário engajou com uma campanha de retargeting antes da reinstalação: uma reinstalação de retargeting (ou seja, reatribuição) será registrada.
- Se o usuário não engajou com uma campanha ou se engajou com uma campanha de UA: nenhuma instalação é registrada. Dependendo do status da atribuição de eventos após a instalação, os eventos de reinstalação desses usuários são atribuídos à instalação orgânica ou à instalação original.
Para testes de dispositivos e múltiplas instalações, registre o dispositivo na AppsFlyer. Se você não registrar o dispositivo, apenas a primeira instalação será registrada.
A AppsFlyer oferece uma melhor precisão na atribuição de reinstalações iOS sem o advertising ID. Você pode ativar essa funcionalidade na página de configurações do aplicativo.
Reinstalando aplicativos iOS que têm backup no iCloud
Quando é feito o backup de um aplicativo usando o iCloud e posteriormente restaurado (no mesmo ou em outro dispositivo), a AppsFlyer não conta como uma nova instalação ou reinstalação. Um usuário que restaura um aplicativo do iCloud mantém seu ID da AppsFlyer e dados de atribuição.
Atribuição de retargeting
Um usuário que reinstala um aplicativo dentro da janela de reatribuição (90 dias por padrão) é considerado uma reatribuição. Se essa instalação ocorrer depois do engajamento com uma campanha de retargeting, ela será registrada como reinstalação de retargeting, ou seja, reatribuição, e será relatada em retargeting.
Atualizações do app
- Quando os usuários existentes atualizam o aplicativo para uma versão seguinte, isso não é tratado como um evento de atribuição contável, se o usuário foi atribuído anteriormente pela AppsFlyer. Atenção! Se você migrar para a AppsFlyer de um MMP diferente, os usuários existentes no primeiro aplicativo aberto, após a migração, serão atribuídos como orgânicos.
- Métricas relacionadas ao número de usuários por versão do aplicativo estão disponíveis no dashboard de informações do SDK.