Assim que o usuário chega à landing page, a AppsFlyer captura essa interação por meio de um listener integrado.

• Web SDK (Pixel): um snippet do lado do cliente implementado diretamente no site ou através do Google Tag Manager (GTM).
• Server-to-Server (S2S) API: uma integração do lado do servidor que ajuda a contornar problemas de mensuração no navegador e bloqueadores de anúncios, permitindo que você enriqueça seus dados antes que eles cheguem à AppsFlyer. A integração S2S pode ser feita diretamente do servidor do cliente ou via Google Tag Manager.

Após a coleta dos dados de sessão, o sistema determina se deve criar uma gravação de primeira visita. Essa gravação serve como um pré-processamento que captura a atividade bruta do usuário antes da resolução e da atribuição da fonte de mídia. Nem toda sessão é registrada como uma visita.

A AppsFlyer registra uma visita quando alguém acessa seu site em uma nova sessão ou com parâmetros de origem reconhecíveis, e ignora visitas de domínios excluídos. Essas regras evitam que as sessões sejam contadas em dobro.

Para mais informações, consulte gravação de visitas.

Após a coleta dos dados e a gravação da visita, o mecanismo faz uma análise seguindo uma ordem de prioridade definida. Esse processo em cascata (waterfall) oferece suporte a parâmetros específicos que são um padrão tanto na AppsFlyer quanto no mercado. Assim, nossos clientes não precisam alterar seus links de atribuição existentes durante a migração. O primeiro sinal com match é usado para determinar a origem da visita.

• PID: o sistema verifica primeiro os parâmetros proprietários da AppsFlyer.
• Parâmetros UTM: se não existir um PID, ele procura por tags padrão como utm_source.
• Click IDs: em seguida, ele procura por IDs específicos da rede, como Google Click ID (gclid) ou TikTok Click ID (ttclid).
• Referrer: como um fallback final, ele identifica a URL onde o usuário estava imediatamente antes de chegar.

Para mais informações, consulte resolução da fonte de mídia.

Como a maioria dos usuários faz login em 30 minutos após uma visita, a AppsFlyer intencionalmente atrasa as decisões de atribuição por meia hora. Esse atraso evita a classificação incorreta de um usuário como "orgânico", permitindo que o sistema capture o CUID para vincular corretamente os usuários que retornam com cookies expirados à fonte de aquisição original.

Após o atraso de 30 minutos, e com a fonte identificada, o sistema conecta sessões fragmentadas em uma única jornada.

• Vinculação de CUID: se um Customer User ID (por exemplo, um e-mail anonimizado) for capturado, o mecanismo vincula a sessão ao histórico cross-device do usuário.
• Fallback de cookie: se nenhum CUID estiver disponível, o sistema recorre aos cookies do navegador, embora eles sejam menos estáveis e sejam específicos de um dispositivo.

Após a resolução de identidade, o mecanismo procura a ação específica que define o usuário como adquirido. O padrão da indústria é ofirst_visit, mas ele geralmente representa um sinal fraco. Por exemplo, ele pode incluir um usuário que clica acidentalmente em um anúncio ou dá um bounce imediato. Ao definir um evento de aquisição personalizado, como um cadastro ou compra, você garante que o lifetime value (LTV) seja atribuído à fonte de marketing que gerou uma ação significativa.

Quando um evento de aquisição ocorre, o mecanismo de atribuição procura retroativamente por um período igual à janela de lookback (aquisição de usuário) para identificar uma visita não orgânica à qual esse evento pode ser atribuído. Essa configuração define o tempo máximo permitido entre a visita do usuário e a conclusão do evento de aquisição (Padrão: 30 dias). Se nenhum touchpoint não orgânico for identificado dentro desse período, o evento de aquisição é considerado orgânico e não atribuído. Você pode definir a duração da janela de lookback do evento personalizado ao adicionar seu aplicativo web à AppsFlyer. Para mais informações, consulte janela de lookback (aquisição de usuário).

Dependendo do modelo de negócio, diferentes eventos podem ser configurados para definir uma aquisição de usuário, por exemplo:

• Evento de cadastro concluído (exemplo: aplicativos bancários). O evento de aquisição é acionado apenas quando o fluxo de cadastro é concluído com sucesso.
• Evento de primeira compra (exemplo: aplicativos de delivery). Navegar pelo app ou adicionar itens à sacola não conta; o evento é disparado apenas após uma transação bem-sucedida.
• Evento de assinatura ativada (exemplo: aplicativos de streaming ou SaaS). O evento de aquisição é registrado quando a assinatura é confirmada, não no início da avaliação gratuita ou na instalação do aplicativo.

Para mais informações sobre como definir um evento de aquisição, consulte configurações de aquisição de usuário.

Após a resolução de identidade, mas antes da aquisição, pode haver uma lacuna na jornada chamada de período de pré-aquisição. Isso é relevante apenas se você definir um evento de aquisição personalizado em vez de usar o evento first_visit padrão. Nesse período, os usuários podem realizar ações significativas, como adicionar itens ao carrinho, navegar por produtos ou interagir com conteúdos, antes de completarem o evento que os registra oficialmente como adquiridos, como o cadastro ou uma primeira compra.

A AppsFlyer coleta e atribui esses eventos de pré-aquisição à fonte de marketing, sinalizando-os nos relatórios como eventos de pré-aquisição. A principal diferença entre a atribuição pré-aquisição e pós-aquisição é a janela de atribuição. Durante o período de pré-aquisição, a janela de atribuição é mais curta e corresponde à janela de lookback do evento de UA, pois esses eventos ocorrem antes do evento que define o usuário como adquirido. Após o evento personalizado ser acionado e o usuário ser adquirido, a janela de atribuição se estende para mensurar o valor do lifetime value (LTV), dando crédito de longo prazo à fonte de marketing que adquiriu o usuário.

Depois que um usuário é adquirido, ele pode retornar ao site mais tarde. Uma atribuição de reengajamento (usuário que volta a visitar o site) é acionada quando um usuário recorrente clica em um anúncio e visita o site.

Embora o reengajamento foca em usuários existentes, um retorno também pode ser classificado como uma reaquisição se o usuário ficar inativo por um longo período. Para ser elegível para a reaquisição, o usuário deve primeiro cruzar a janela de inatividade (padrão: 90 dias), que define o período de inatividade necessário para considerá-lo como um usuário "perdido". Passado esse período, se o usuário retornar, o mecanismo registra um novo evento de aquisição de usuário em vez de uma visita padrão.

Para mais informações, consulte configurações de reengajamento e configurações de reaquisição

Mesmo que um usuário tenha sido adquirido através de uma campanha de aquisição inicial ou de um esforço de retargeting subsequente, o objetivo final é mensurar seu valor completo ao longo do tempo. Depois que um usuário é atribuído com sucesso a uma fonte, o sistema mensura a atividade contínua para calcular seu lifetime value (LTV).

Essa mensuração é regida pela janela de atribuição, que é definida como "para sempre" por padrão. Isso garante que cada ação subsequente (como compras repetidas ou renovações de assinatura) seja creditada de volta à fonte de marketing original que levou o usuário ao site. Ao capturar esses dados de longo prazo, você pode ir além de simples contagens de conversão e determinar o verdadeiro retorno do investimento em anúncios (ROAS) nas suas campanhas.

Para mais informações sobre como definir a janela de atribuição, consulte janela de atribuição.