Em resumo: a série de eventos nas regras de validação permite que anunciantes definam uma sequência de eventos pela qual um usuário real deve passar. Qualquer desvio da ordem definida por você ou do intervalo de tempo entre eventos é detectado e bloqueado.
Introdução
Os anunciantes podem definir uma sequência de eventos pela qual um usuário real deve passar no seu aplicativo. A AppsFlyer avalia essa sequência usando uma janela de avaliação que começa no dia em que a regra é salva: ela cresce diariamente até 30 dias e depois se torna uma janela contínua de 30 dias, que avança todos os dias. Eventos disparados antes da criação da regra nunca são avaliados.
Se a sequência for interrompida, seja na ordem ou no tempo, o usuário é considerado falso e:
- Quaisquer eventos in-app após a interrupção são bloqueados imediatamente
- A instalação é bloqueada na pós-atribuição, se ocorrer dentro da janela de pós-atribuição (7 dias)
- Os eventos in-app associados dentro da janela de avaliação são bloqueados como parte do processo de pós-atribuição
- Outros eventos in-app que atendem às condições da regra em outras partes do aplicativo não são afetados
Observação: editar a regra de qualquer forma, incluindo seleção de aplicativo, condições, fonte de tráfego, sequência de eventos ou ativação/desativação, redefine a janela de avaliação para o dia 0.
Para quem é isso?
Esse recurso é adequado apenas para:
- Eventos de SDK - Apps que criarão regras apenas com eventos de SDK.
- Eventos não repetidos - Aplicativos que têm uma sequência de eventos em que os eventos não ocorrerão mais de uma vez na sequência. Se o mesmo evento ocorrer mais de uma vez na sequência (por exemplo, o Evento C for enviado duas vezes), isso será tratado como uma violação e os eventos associados serão bloqueados.
- Tráfego NOI - Esse recurso está disponível apenas para tráfego NOI
Como configurar uma regra de série de eventos
Siga estas instruções para configurar uma regra de série de eventos:
- Acesse Configurações > Regras de validação
- Clique em + Nova regra
- Nomeie a regra
- Selecione a aba Pós-atribuição
- Selecione o aplicativo para o qual você deseja definir a regra
Observação: você só pode selecionar um aplicativo para cada regra - Defina a fonte de tráfego na qual a regra será executada
- Escolha as condições. No momento, as opções são:
- Geografia
- Modelo do dispositivo
- Seu identificador único é definido automaticamente com base no aplicativo selecionado: IDFA para iOS ou ID do anunciante para Android. Você pode alterar para ID de usuário do cliente em qualquer uma das plataformas.
- Defina a sequência de eventos: adicione pelo menos 2 eventos, na ordem em que um usuário real deve concluí-los
- Opcionalmente, defina um intervalo mínimo entre cada par de eventos. Se você não definir um, um mínimo de 1 segundo será aplicado por padrão
- Revise a seção Resultado da regra para confirmar o estado da janela de avaliação e o tempo total mínimo da sequência
- Clique em Salvar.
Importante!
Não selecione todos os eventos do seu aplicativo. Selecione apenas os eventos em que normalmente pode haver fraude
Acesso aos dados
Quando uma regra de série de eventos bloqueia uma instalação ou um evento in-app, os detalhes são registrados nos seus Relatórios de dados brutos. Acesse Dados brutos > Protect360 & Regras de validação para encontrar eventos bloqueados e use os campos abaixo para identificar quais foram bloqueados por essa regra.
| Relatório | Campos principais |
|---|---|
| Instalações pós-atribuição |
|
| Eventos in-app pós-atribuição |
|
| Eventos na aplicação bloqueados |
|
Exemplos
Abaixo estão exemplos de diferentes séries de eventos e se elas seriam consideradas fraudulentas ou não.
Exemplo 1
Regra definida
O usuário deve realizar os eventos nesta ordem:
- Evento A
- Evento B
- Evento C
Realizado na prática
O usuário realiza os eventos nesta ordem:
- Dia 0: a instalação ocorreu
- Dia 1: evento A enviado
- Dia 2: evento B enviado
- Dia 3: evento C enviado
Resultado:
Não é fraude. O usuário realizou a sequência de eventos na ordem definida.
Exemplo 2
Regra definida
O usuário deve realizar os eventos nesta ordem:
- Evento A
- Evento B
- Evento C
Realizado na prática
O usuário realiza os eventos nesta ordem:
- Dia 0: a instalação ocorreu
- Dia 1: Evento A enviado
- Dia 2: evento C enviado
- Dia 3: evento B enviado
Resultado:
Fraude. O usuário realizou o evento C antes do evento B, o que está fora da sequência definida. Como resultado,
- O evento A será bloqueado na pós-atribuição
- O evento B será bloqueado em tempo real
- O evento C será bloqueado em tempo real ou na pós-atribuição, pois esse evento quebrou a sequência
- Todos os eventos seguintes serão bloqueados em tempo real
Exemplo 3
O usuário deve executar os eventos nesta ordem:
- Evento A
- Evento B (tempo mínimo em relação ao evento anterior: 1 hora)
- Evento C (tempo mínimo em relação ao evento anterior: 2 horas)
O usuário executa os eventos nesta ordem:
- Dia 0: a instalação ocorreu
- Dia 0: Evento A enviado
- Dia 0: Evento B enviado 10 minutos após o Evento A
- Dia 0: Evento C enviado 2 horas após o Evento B
Fraude. O usuário executou todos os eventos na ordem correta, mas o intervalo entre o Evento A e o Evento B foi de apenas 10 minutos, o que é menos que o mínimo configurado de 1 hora. A restrição de tempo foi violada, independentemente da ordem correta da sequência. Como resultado,
- O evento A será bloqueado na pós-atribuição
- O evento B será bloqueado em tempo real, pois violou a restrição de tempo mínimo
- O evento C será bloqueado em tempo real, pois ocorreu após uma sequência violada
- Todos os eventos seguintes serão bloqueados em tempo real
Exemplo 4
O usuário deve executar os eventos nesta ordem:
- Evento A
- Evento B
- Evento C
O usuário executa os eventos nesta ordem:
- Dia 0: a instalação ocorreu
- Dia 1: Evento A enviado
- Dia 2: Evento B enviado
- Nenhum evento C enviado
Não é fraude. O usuário concluiu os eventos A e B na ordem correta, mas nunca acionou o evento C. Sequências incompletas não são sinalizadas como violações. Nenhum evento é bloqueado. A regra continua avaliando eventos futuros dentro da janela de avaliação de 30 dias.
Exemplo 5
Regra definida
O usuário foi identificado pelo ID do usuário do cliente (CUID).
O usuário deve executar os eventos nesta ordem:
- Evento A
- Evento B
- Evento C
Executado na prática
O usuário executa os eventos nesta ordem:
- Dia 0: A instalação ocorreu
- Dia 1: Evento A enviado
- Dia 1: A desinstalação ocorreu
- Dia 1: A instalação ocorreu
- Dia 2: Evento B enviado
- Dia 3: Evento C enviado
Resultado:
Não é fraude. Como o usuário foi identificado pelo ID de usuário do cliente (CUID) e os eventos foram executados na ordem correta.
Exemplo 6
Regra definida
O usuário deve realizar os eventos nesta ordem:
- Evento A
- Evento B
- Evento C
Realizado na prática
O usuário foi identificado pelo ID do Anunciante
O usuário realiza os eventos nesta ordem:
- Dia 0: a instalação ocorreu
- Dia 1: evento A enviado
- Dia 1: a desinstalação ocorreu
- Dia 1: a instalação ocorreu
- Dia 2: evento B enviado
- Dia 3: evento C enviado
Resultado:
Não é fraude. Como o usuário foi identificado pelo ID do Anunciante e os eventos foram realizados na ordem correta.
Exemplo 7
O usuário deve realizar os eventos nesta ordem:
- Evento A
- Evento B
- Evento C
- 1º de janeiro (Dia 0): Regra criada. A janela de avaliação começa. Eventos disparados antes desta data são ignorados.
- 15 de janeiro (Dia 14): evento A enviado. A janela está crescendo e agora avalia os últimos 14 dias.
- 30 de janeiro (Dia 29): evento B enviado. A janela está crescendo e agora avalia os últimos 29 dias.
- 31 de janeiro (Dia 30): a janela atinge 30 dias e se torna uma janela móvel de 30 dias, avançando um dia a cada dia.
- 20 de fevereiro: evento C enviado. A janela móvel agora retorna 30 dias, até 21 de janeiro. O evento A (disparado em 15 de janeiro) fica fora da janela e não é mais avaliado.
Sem fraude. Em 20 de fevereiro, a janela móvel retroage até 21 de janeiro, colocando o evento A (15 de janeiro) fora da janela de avaliação. Somente os eventos B e C são avaliados - ambos na ordem correta, sem nenhuma violação sinalizada.
Exemplo 8
Regra definida
O usuário deve executar os eventos nesta ordem:
- Evento A
- Evento B
- Evento C
Executado na prática
O usuário executa os eventos nesta ordem:
- Dia 0: a instalação ocorreu
- Dia 1: evento A enviado
- Dia 2: evento B enviado
- Dia 3: evento B enviado
- Day4: Evento C enviado
Resultado:
Fraude. Como o mesmo evento (evento B) ocorreu duas vezes, presumimos fraude, pois não é possível ter o mesmo evento duas vezes em uma sequência.
Exemplo 9
Regra definida
O usuário foi identificado pelo ID de usuário do cliente (CUID).
O usuário deve executar os eventos nesta ordem:
- Evento A
- Evento B
- Evento C
O usuário dispara eventos em dois dispositivos usando o mesmo CUID:
- Dia 0: a instalação ocorreu no dispositivo 1
- Dia 0: a instalação ocorreu no dispositivo 2
- Dia 1: Evento A enviado do dispositivo 1
- Dia 2: Evento B enviado do dispositivo 2
- Dia 3: Evento C enviado do dispositivo 1
Não é fraude. Como o usuário foi identificado pelo CUID, a avaliação da sequência abrange todos os IDs do AppsFlyer associados ao mesmo CUID e ao ID da regra. Os eventos A, B e C foram executados na ordem correta, independentemente de qual dispositivo os disparou.
Especificações e limitações
- É possível definir até 100 eventos em cada regra.
- Ao atingir 80 eventos, um aviso é exibido. Ao atingir 100 eventos, o limite é alcançado e a regra deve ser dividida para adicionar mais.
- O tempo mínimo que pode ser definido entre eventos consecutivos é de 1 segundo. Se nenhum tempo for configurado para um par, o padrão de 1 segundo será aplicado automaticamente.
- O intervalo máximo de tempo configurável entre eventos é de 30 dias, alinhado à janela de avaliação.
- A janela de avaliação começa no dia 0 (data de criação da regra) e cresce diariamente até 30 dias, após o que se torna uma janela móvel de 30 dias, avançando todos os dias. Eventos disparados antes da data de criação da regra nunca são avaliados.
- Qualquer edição em uma regra redefine a janela de avaliação para o dia 0.
- É possível definir até 10 regras ativas por conta.
- As regras de séries de eventos só podem ser usadas para tráfego não orgânico.
- Somente o tráfego do SDK tem suporte. O tráfego S2S está fora do escopo da Fase 1.
- Sequências incompletas não são sinalizadas como violações. Uma sequência só é avaliada depois que todos os eventos definidos forem disparados.
- O mesmo evento não pode aparecer duas vezes em uma única sequência.
- Somente a lógica AND tem suporte entre condições. A lógica OR não tem suporte.
Perguntas frequentes
O que acontece após uma reinstalação?
Se a reinstalação redefinir eventos que o usuário já concluiu, isso será tratado como uma violação. Se o usuário continuar de onde parou, nenhuma violação será sinalizada.
This article was translated using AI and may contain errors. For the most accurate information, please refer to the English version using the language selector.