O evento que aciona a aquisição de usuários. Essa é uma ação importante que define o ponto em que você considera que um usuário realmente foi "adquirido".

Por que personalizar? 

A primeira visita padrão costuma ser um sinal fraco para determinar o valor do usuário, pois um usuário pode clicar em um anúncio acidentalmente ou dar bounce. Ao personalizar essa configuração, você garante que o lifetime value (LTV) seja atribuído à fonte de marketing que gerou uma ação verdadeiramente significativa.

Padrão: primeira visita (o usuário é adquirido na primeira visita ao site)

Alternativas comuns por vertical

Como funciona

Se definido como primeira visita:

• Os usuários são classificados como adquiridos logo na primeira visita ao site.
• A atribuição começa a partir da primeira visita.

Se definido como um evento personalizado (por exemplo, sign_up):

• Os usuários entram em um "período de pré-aquisição", entre a primeira visita e o momento em que o evento ocorre.
• Durante a pré-aquisição, os eventos são atribuídos ao último touchpoint não orgânico dentro da janela de atribuição (atribuição de último toque).
• Assim que o evento personalizado é acionado, uma conversão de aquisição é criada e a atribuição de longo prazo se inicia.

Exemplo (evento de UA = sign_up):

• Dia 0: o usuário visita o site a partir de um anúncio no Facebook → o período de pré-aquisição se inicia
• Dia 2: o usuário visita o site a partir de um anúncio no Google → o crédito muda para o Google (último toque)
• Dia 3: o usuário completa o cadastro no site → a aquisição é atribuída ao anúncio do Google

Dia 10: o usuário faz uma compra → a compra é atribuída ao Google para mensuração de LTV

Representa o período de tempo analisado pela AppsFlyer para identificar o touchpoint de marketing responsável por impulsionar a aquisição.

Essa janela controla o limite de tempo durante o qual a AppsFlyer "se lembra" de um touchpoint de marketing. Se um usuário faz uma visita depois de interagir com um anúncio, mas só completa o evento de aquisição após um tempo, essa configuração determina se o anúncio ainda receberá o crédito pela atribuição.

Padrão: 30 dias

Intervalo: 1 hora a 90 dias

Como funciona

Quando um usuário realiza o evento de UA (por exemplo, sign_up), a AppsFlyer analisa o período da janela de lookback para identificar o touchpoint não orgânico mais recente, atribuindo a aquisição a uma fonte de marketing.

Exemplo 1 (lookback de 30 dias):

• Dia 0: o usuário clica em anúncio do Facebook e visita o site
• Dia 25: o usuário retorna diretamente ao site e completa o evento sign_up
• Resultado: a aquisição é atribuída ao Facebook (pois ocorreu dentro da janela de lookback de 30 dias)

Exemplo 2 (janela expirada):

• Dia 0: o usuário clica em anúncio do Facebook e visita o site
• Dia 40: o usuário retorna diretamente ao site e completa o evento sign_up

Resultado: a aquisição é registrada como orgânica (pois ocorreu fora da janela de lookback de 30 dias)

Representa o período de tempo após uma conversão de reengajamento, durante o qual a AppsFlyer continua atribuindo eventos para um touchpoint de marketing.

Essa configuração determina por quanto tempo campanhas de retargeting podem continuar recebendo créditos pela atividade do usuário, garantindo a distribuição de créditos aos esforços de retargeting e a atribuição do LTV de longo prazo à fonte de aquisição original.

Padrão: 30 dias

Intervalo: 1 hora a 90 dias

Como funciona

Quando um usuário adquirido retorna ao site através de uma fonte não orgânica (como um anúncio de retargeting) e atende aos critérios de reengajamento, uma conversão de retargeting é criada. Eventos realizados dentro dessa janela passam por atribuição dupla:

1. Atribuição primária → Campanha de retargeting
   • Objetivo: creditar a campanha de retargeting
2. Atribuição secundária → Fonte de aquisição original
   • Objetivo: oferecer suporte à mensuração completa do lifetime value (LTV) do usuário e sua atribuição à aquisição original

Exemplo (dentro da janela):

• Dia 0: o usuário é adquirido a partir de um anúncio do Facebook
• Dia 50: o usuário clica no e-mail de uma campanha de retargeting e retorna ao site (uma conversão de retargeting é criada)
• Dia 60: o usuário faz uma compra de R$100 (10 dias após o retargeting)
• Resultado - Atribuição dupla:
  • Primária (retargeting): a campanha de e-mail recebe crédito pela compra de R$100
  • Secundária (UA): o anúncio do Facebook também é vinculado à compra de R$100 no LTV do usuário
• Relatórios:
  • Visão unificada: mostra a compra atribuída ao e-mail
  • Retargeting: mostra a compra atribuída ao e-mail
  • UA: mostra a compra atribuída ao Facebook

O período mínimo de inatividade do usuário para que uma interação não orgânica seja considerada uma conversão de reengajamento (retargeting).

Essa janela evita que campanhas de retargeting continuem recebendo crédito depois que os usuários já estão ativamente engajados com o seu site. Isso garante a otimização do orçamento de retargeting, garantindo que suas campanhas tenham como alvo somente usuários que estão realmente inativos.

Padrão: Desativada

Intervalo: 0 (desativada) a 30 dias

Como funciona

Quando desativada:

• Todo touchpoint não orgânico de um usuário adquirido cria uma conversão de retargeting

Quando ativada (por exemplo, 7 dias):

• Uma conversão de retargeting só é criada se um usuário permanecer inativo por pelo menos 7 dias
• Se o usuário esteve ativo recentemente, a visita é atribuída à fonte de UA original

Restrição:

• Não pode exceder a janela de inatividade (reaquisição)

Exemplo (janela de inatividade de 7 dias):

• Dia 0: o usuário é adquirido a partir de um anúncio do Facebook
• Dia 3: o usuário faz uma visita orgânica
• Dia 5: ele clica no anúncio de retargeting → sem conversão de retargeting (apenas 2 dias inativo)
• Dia 15: ele clica no anúncio de retargeting → conversão de retargeting criada (12 dias inativo)

Representa o período de inatividade após o qual um usuário é considerado como "churn". Usuários que deram churn podem ser readquiridos, gerando uma nova conversão de aquisição.

Essa configuração define o limite de churn do seu negócio. Ela determina quando um usuário é considerado como um cliente "perdido" e que pode ser readquirido, permitindo que campanhas de reconquista recebam crédito por trazer de volta usuários com churn.

Padrão: 90 dias

Intervalo: 1 a 180 dias

Como funciona

Quando o usuário é considerado como churn:

• No caso de novos eventos, o usuário não é mais atribuído à fonte de UA original
• O usuário entra em um estado de "pré-aquisição" (aguardando para ser readquirido)
• As janelas de atribuição da aquisição original não se aplicam mais

Quando um usuário que deu churn retorna:

• Se o usuário realizar o evento de reaquisição → uma nova conversão de aquisição é criada
• A campanha de reconquista recebe crédito como a nova fonte de aquisição
• O usuário é considerado como uma aquisição completamente nova

Exemplo (janela de 90 dias):

• Dia 0: o usuário é adquirido a partir de um anúncio do Google
• Dia 50: data da última atividade
• Dia 140: o usuário dá churn (90 dias sem atividade)
• Dia 145: ele clica na campanha de reconquista enviada por e-mail

Dia 146: o usuário realiza um evento de re-aquisição → uma nova conversão de aquisição é atribuída à campanha de e-mail

O evento que aciona a re-aquisição para usuários inativos. Apenas usuários inativos podem ser readquiridos.

Muitos eventos de aquisição representam ações únicas (por exemplo, sign_up, first_purchase) que não podem acontecer duas vezes. Essa configuração permite que você defina um evento que pode se repetir e que sinaliza que um usuário inativo retornou.

Padrão: visit (usuários inativos são imediatamente readquiridos na primeira visita após o retorno)

Alternativas comuns: sign_in ou purchase

Como funciona

Se definido como um evento personalizado (por exemplo, sign_in):

• Usuários inativos devem realizar o evento específico para serem readquiridos
• O usuário pode visitar o site várias vezes antes que a re-aquisição ocorra
• Definição mais rigorosa do que constitui uma re-aquisição "verdadeira".

Exemplo (evento de re-aquisição = sign_in):

• O usuário dá churn após 90 dias de inatividade
• Ele clica na campanha de reconquista por e-mail e visita o site → mas ainda não é considerado como uma re-aquisição
• Um dia depois, o usuário faz login → a conversão de re-aquisição é criada e atribuída à campanha de e-mail

O período máximo após a aquisição durante o qual a AppsFlyer atribui eventos a essa conversão.

Padrão: Para sempre

Opções disponíveis: nenhum, 1 dia, 7 dias, 30 dias, 60 dias, 90 dias, 180 dias, 365 dias, para sempre (limitado pela retenção de dados)

PRIMÁRIO (obrigatório, automático)

• O domínio primário do seu site (definido durante a criação do aplicativo)
• É adicionado automaticamente e não pode ser removido
• É permitido apenas um domínio primário por aplicativo web
• Exclusão automática de subdomínios: O domínio primário exclui automaticamente todos os seus subdomínios
  • Exemplo: exemplo.com exclui automaticamente shop.exemplo.com, blog.exemplo.com, etc.
• Impacto da exclusão: Impedir a autoatribuição

INTERNO (opcional)

• Outros domínios da sua marca que não cobertos pelo domínio primário
• Adicione até 99 domínios adicionais
• Exemplo: Diferentes domínios de nível superior como exemplo.co.uk, exemplo.in
• Impacto da exclusão: Impedir a autoatribuição

EXTERNO (opcional)

Existem dois tipos de exclusões de domínios externos:

Externo (listado por você)

• Domínios usados diretamente pelo seu site, mas que não fazem parte da marca.
• Por exemplo, gateways de pagamento, sites de processamento de pagamentos, provedores de autenticação
• Adicione até 99 domínios adicionais
• Exemplos: auth0.com, okta.com, facebook.com, google.com
• Impacto da exclusão: Visitas são desconsideradas

Externo (listado pela AppsFlyer)

• Domínios excluídos automaticamente pela AppsFlyer:

  Provedores de pagamento

  • PayPal (pagamento no checkout)
  • Stripe (pagamento no checkout)
  • Adyen (pagamento no checkout)
  • Klarna (pagamento no checkout)
  • Braintree (pagamento no checkout)
  • Square (pagamento no checkout)
  • Paddle (pagamento no checkout)
  • Mollie (pagamento no checkout)
  • Alipay (pagamento no checkout)
  • Razorpay (pagamento no checkout)
  • Paytm (pagamento no checkout)
  • PayU (pagamento no checkout)
  • Mercado Pago (pagamento no checkout)
  • Yandex Pay (pagamento no checkout)
  • Naver Pay (pagamento no checkout)

  Login via OAuth e SSO

  • Google Sign-In (login com a conta do Google)
  • Apple ID (login com a conta da Apple)
  • Microsoft (login com a conta da Microsoft 365 / Entra)
  • Microsoft Live (login com a conta do Outlook/Live)
  • Início de sessão Facebook (apenas o domínio de login com a conta do Facebook)
  • Início de sessão Yandex (login com a conta da Yandex)
  • Início de sessão Kakao (login com a conta da Kakao)
  • Início de sessão Naver (login com a conta da Naver)
  • Início de sessão LINE (login com a conta da LINE)
  • Início de sessão Weixin (login com o OAuth do WeChat)
  • Início de sessão VK (login com a conta da VK)
  • Início de sessão Daum (login com a conta da Daum)
• A lista de domínios automáticos não pode ser editada.
• Impacto da exclusão: Visitas são desconsideradas

Para adicionar domínios:

1. Vá para as configurações do seu aplicativo web → Atribuição
2. Acesse a seção de Domínios excluídos
3. Clique em Adicionar domínio
4. Insira o nome do domínio (por exemplo, gateway-personalizado.com)
5. Selecione o tipo de domínio: Interno ou externo
6. Clique em salvar

Observações importantes:

• As exclusões entram em vigor dentro de 1 hora
• As alterações aplicam-se apenas prospectivamente (não afetam o histórico de dados)
• Provedores de pagamento comuns e domínios de login via OAuth/SSO são excluídos automaticamente. Consulte a lista completa na seção Externo (lista criada pela AppsFlyer) - no caso desses domínios, não é necessário adicioná-los manualmente

Formato do subdomínio:

• Apenas nome de domínio (sem protocolos, paths ou ports)
• Máximo de 500 caracteres por domínio
• Protocolos (https://) removidos automaticamente, convertidos para minúscula

Exemplos:

• exemplo.com ✅
• shop.exemplo.com ✅ (desnecessário se exemplo.com for o domínio principal)
• https://exemplo.com → exemplo.com ✅ (protocolo removido)
• exemplo.com/path ❌ (paths não são permitidos)
• exemplo.com:8080 ❌ (ports não permitidos)

Limites:

• Máximo de 100 domínios no total (incluindo 1 PRIMÁRIO)

1. Crie um novo aplicativo web
   1. Vá para Meus aplicativos → Adicionar aplicativo → Selecionar site
2. Escolha o Web SDK ID 
   Reutilize a dev key de PBA existente (recomendado) para evitar alterações de código no seu site.
3. Defina as configurações 
   Mapeie as configurações de PBA para as novas configurações de atribuição web
4. Adicione os domínios que devem ser excluídos 
   Mapeie os domínios excluídos do PBA (Brand Bundle) para as novas configurações de atribuição web

Atenção: Cada dev key do PBA só pode ser atribuída a UM novo aplicativo web.