O evento que aciona a aquisição de usuários. Esta é uma ação de negócios importante que define quando você considera que um usuário foi realmente "adquirido".

Por que personalizar 

A primeira visita padrão geralmente representa um sinal fraco do valor do usuário. Um usuário pode clicar em um anúncio acidentalmente ou sair imediatamente. Ao personalizar essa configuração, você garante que o valor de longo prazo (LTV) seja atribuído à fonte de marketing que impulsionou uma ação significativa, e não apenas um clique por curiosidade.

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 adquiridos imediatamente na primeira visita ao site.
• A atribuição começa na primeira visita.

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

• Os usuários entram em um "período de pré-aquisição" desde a primeira visita até realizarem o evento.
• Durante a pré-aquisição, os eventos são atribuídos ao último touchpoint não orgânico dentro da janela de lookback (atribuição de último toque).
• Quando o evento de UA personalizado ocorre, uma conversão de aquisição de usuários é criada e a atribuição de longo prazo começa.

Exemplo de cenário (evento de UA = sign_up):

• Dia 0: O usuário visita o site por um anúncio do Facebook → O período de pré-aquisição começa
• Dia 2: O usuário visita o site por um anúncio do Google → O crédito muda para o Google (último toque)
• Dia 3: O usuário se cadastra → A aquisição de usuários é 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

Até quanto tempo atrás a AppsFlyer procura o touchpoint de marketing que impulsionou a aquisição de usuários.

Essa janela controla por quanto tempo a AppsFlyer "se lembra" de um touchpoint de marketing. Se um usuário visita o site por um anúncio, mas só conclui o evento de UA mais tarde, essa configuração determina se o anúncio ainda recebe o crédito.

Padrão: 30 dias

Intervalo: de 1 hora a 90 dias

Como funciona

Quando um usuário realiza o evento de UA (por exemplo, sign_up), a AppsFlyer busca dentro dessa janela o touchpoint não orgânico mais recente e atribui a aquisição a essa fonte de marketing.

Exemplo 1 (lookback de 30 dias):

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

Exemplo 2 (janela expirada):

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

Resultado: a aquisição de usuários é marcada como orgânica (fora da janela de lookback de 30 dias)

Por quanto tempo, após uma conversão de reengajamento, a AppsFlyer continua a atribuir eventos a esse touchpoint de marketing.

Essa configuração determina por quanto tempo as campanhas de retargeting recebem crédito pela atividade do usuário. Ela equilibra a atribuição de crédito aos esforços de retargeting, ao mesmo tempo que continua atribuindo o LTV de longo prazo à fonte de aquisição original.

Padrão: 30 dias

Intervalo: de 1 hora a 90 dias

Como funciona

Quando um usuário adquirido retorna por uma fonte não orgânica (por exemplo, um anúncio de retargeting) e atende aos critérios de reengajamento, uma conversão de retargeting é criada. Os eventos dentro desta janela recebem atribuição dupla:

1. Atribuição primária → Campanha de retargeting
   • Objetivo: dar crédito à campanha de retargeting
2. Atribuição secundária → Fonte de UA original
   • Objetivo: dar suporte à visualização de UA que mensura o valor total do ciclo de vida do usuário (LTV) até a aquisição original

Exemplo (dentro da janela):

• Dia 0: usuário adquirido por meio de um anúncio do Facebook
• Dia 50: o usuário clica em uma campanha de retargeting por e-mail e retorna (conversão de retargeting criada)
• Dia 60: Usuário faz uma compra de US$100 (10 dias após o retargeting)
• Resultado - atribuição dupla:
  • Primária (visualização de retargeting): Campanha de e-mail recebe crédito pela compra de US$100
  • Secundária (visualização de UA): o anúncio do Facebook também é rastreado para US$100 no LTV do usuário
• Relatórios:
  • Visualização unificada: mostra a compra atribuída ao e-mail
  • Visualização de retargeting: mostra a compra atribuída ao e-mail
  • Visualização de UA: mostra a compra atribuída ao Facebook

O período mínimo de inatividade do usuário necessário para que um touchpoint não orgânico possa criar uma conversão de reengajamento (retargeting).

Evite creditar campanhas de retargeting quando os usuários já estiverem engajados ativamente com seu site. Isso otimiza o orçamento de retargeting ao garantir que as campanhas segmentem usuários realmente inativos.

Padrão: Desativado

Intervalo: 0 (desativado) a 30 dias

Como funciona

Quando desativado:

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

Quando ativado (por exemplo, 7 dias):

• Só cria uma conversão de retargeting se o usuário estiver inativo há pelo menos 7 dias
• Se o usuário esteve ativo recentemente, a visita será atribuída à fonte de UA original

Restrição:

• Não pode exceder a janela de inatividade (re-aquisição)

Exemplo (janela de inatividade de 7 dias):

• Dia 0: Usuário adquirido por meio de um anúncio do Facebook
• Dia 3: Usuário visita de forma orgânica
• Dia 5: Usuário clica em um anúncio de retargeting → Nenhuma conversão de retargeting (apenas 2 dias de inatividade)
• Dia 15: Usuário clica em um anúncio de retargeting → Conversão de retargeting criada (12 dias de inatividade)

O período de inatividade total após o qual um usuário é marcado como "churned". Usuários "churned" podem ser readquiridos, gerando uma nova conversão de aquisição de usuários.

Essa configuração define o limite de churn da sua empresa. Ela determina quando um usuário é considerado "perdido" e elegível para ser readquirido, permitindo que campanhas de win-back recebam crédito por trazer de volta usuários "churned".

Padrão: 90 dias

Intervalo: 1 a 180 dias

Como funciona

Quando o usuário é marcado como "churned":

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

Quando o usuário churned retorna:

• Se o usuário realizar o evento de reaquisição → uma nova conversão de UA será criada
• A campanha de win-back recebe o crédito como a nova fonte de aquisição
• O usuário é tratado como uma aquisição completamente nova do ponto de vista de relatórios

Exemplo (janela de 90 dias):

• Dia 0: usuário adquirido por meio de anúncio do Google
• Dia 50: última atividade
• Dia 140: usuário churned (90 dias inativo)
• Dia 145: usuário clica na campanha de win-back por e-mail

Dia 146: usuário realiza o evento de reaquisição → Nova conversão de UA atribuída à campanha de e-mail

O evento que aciona a reaquisição para usuários churned. Somente usuários que sofreram churn podem ser readquiridos.

Muitos eventos de aquisição de usuários são ações únicas (por exemplo, sign_up, first_purchase) que não podem acontecer duas vezes. Essa configuração permite definir um evento repetível que sinaliza que um usuário que sofreu churn retornou.

Padrão: visit (usuários churned são readquiridos imediatamente na primeira visita de retorno)

Alternativas comuns: sign_in ou purchase

Como funciona

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

• Usuários que sofreram churn devem realizar o evento específico para serem readquiridos
• O usuário pode visitar várias vezes antes que ocorra a reaquisição
• Definição mais rigorosa de reaquisição "verdadeira".

Exemplo (evento de reaquisição = sign_in):

• Usuário churned após 90 dias de inatividade
• Usuário clica na campanha de win-back por e-mail e visita → Ainda não foi readquirido
• Um dia depois, o usuário faz login → Conversão de reaquisição criada, atribuída à campanha de e-mail

O período máximo após a aquisição de usuários 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 principal do seu site (definido durante a criação do aplicativo)
• Adicionado automaticamente e não pode ser removido
• Exatamente 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: example.com exclui automaticamente shop.example.com, blog.example.com etc.
• Impacto da exclusão: Sem autoatribuição

INTERNO (opcional)

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

EXTERNO (opcional)

Existem dois tipos de exclusões de domínio externo:

Externo (listado por você)

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

Externo (listado pela AppsFlyer)

• Domínios automaticamente excluídos pela AppsFlyer:

  Provedores de pagamento

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

  Login com OAuth e SSO

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

Para adicionar domínios:

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

Notas Importantes:

• As exclusões entram em vigor em até 1 hora
• As alterações se aplicam somente de forma prospectiva (não afetam dados históricos)
• Provedores de pagamento comuns e domínios de entrada OAuth/SSO são excluídos automaticamente. Consulte a lista completa em Externo (listado pela AppsFlyer) (não é necessário adicioná-los manualmente)

Formato do domínio:

• Somente o nome do domínio (sem protocolos, caminhos ou portas)
• Máximo de 500 caracteres por domínio
• Protocolos (https://) removidos automaticamente, convertidos para minúsculas

Exemplos:

• example.com ✅
• shop.example.com ✅ (mas desnecessário se example.com for o domínio principal)
• https://example.com → example.com ✅ (protocolo removido)
• example.com/path ❌ (caminhos não são permitidos)
• example.com:8080 ❌ (portas não são permitidas)

Limites:

• Máximo de 100 domínios no total (incluindo 1 PRINCIPAL)

1. Criar novo aplicativo web
   1. Vá para Meus aplicativos → Adicionar aplicativo → Selecione Website
2. Escolha o ID do SDK web
   Reutilize a chave de desenvolvimento PBA existente (recomendado) para evitar alterações no código do seu site.
3. Configurar definições 
   Mapeie as definições de PBA para as novas definições de atribuição web
4. Adicionar domínios excluídos 
   Mapeie os domínios excluídos de PBA (pacote da marca) para as novas configurações de atribuição web

Observação: Cada chave de desenvolvimento de PBA só pode ser atribuída a UM novo aplicativo web.