En resumen: La serie de eventos en las reglas de validación permite a los anunciantes definir una secuencia de eventos por la que debe pasar un usuario real. Cualquier desviación del orden definido o del tiempo entre eventos se detecta y se bloquea.
Introducción
Los anunciantes pueden definir una secuencia de eventos por la que debe pasar un usuario real en tu aplicación. AppsFlyer evalúa esta secuencia mediante una ventana de evaluación que comienza el día en que se guarda la regla: crece cada día hasta los 30 días y, después, se convierte en una ventana móvil de 30 días que avanza diariamente. Los eventos activados antes de que se creara la regla no se evalúan nunca.
Si la secuencia se rompe, ya sea en el orden o en el tiempo, el usuario se considera falso y:
- Cualquier evento in-app posterior a la interrupción se bloquea de inmediato
- La instalación se bloquea en post-attribution si entra dentro de la ventana de post-attribution (7 días)
- Los eventos in-app asociados dentro de la ventana de evaluación se bloquean como parte del proceso de post-attribution
- Otros eventos in-app que cumplen las condiciones de la regla en otras partes de la aplicación no se ven afectados
Nota: si editas la regla de cualquier forma, incluida la selección de la aplicación, las condiciones, la fuente de tráfico, la secuencia de eventos o la activación/desactivación, la ventana de evaluación se restablece al día 0.
¿A quién va dirigido?
Esta función solo es adecuada para:
- Eventos del SDK: aplicaciones que crearán reglas solo con eventos del SDK.
- Eventos no repetitivos: aplicaciones que tienen una secuencia de eventos en la que los eventos no se producirán más de una vez en la secuencia. Si el mismo evento se produce más de una vez en la secuencia (por ejemplo, el evento C se envía dos veces), se trata como una infracción y los eventos asociados se bloquean.
- Tráfico NOI: esta función solo está disponible para el tráfico NOI
Cómo configurar una regla de serie de eventos
Sigue estas instrucciones para configurar una regla de serie de eventos:
- Ve a Configuración > Reglas de validación
- Haz clic en + Nueva regla
- Dale un nombre a la regla
- Selecciona la pestaña Post attribution
- Selecciona la aplicación para la que quieres configurar la regla
Nota: solo puedes seleccionar una aplicación para cada regla - Define la fuente de tráfico en la que se ejecutará la regla
- Elige las condiciones. Actualmente, las opciones son:
- Geografía
- Modelo de dispositivo
- Tu identificador único se configura automáticamente según la aplicación que hayas seleccionado: IDFA para iOS o ID de anunciante para Android. También puedes cambiarlo por ID de usuario del cliente en cualquiera de las dos plataformas.
- Define la secuencia de eventos: añade al menos 2 eventos, en el orden en que un usuario real debería completarlos
- Opcionalmente, establece un intervalo mínimo entre cada par de eventos. Si no lo estableces, se aplica de forma predeterminada un mínimo de 1 segundo
- Revisa la sección Resultado de la regla para confirmar el estado de la ventana de evaluación y el tiempo total mínimo de la secuencia
- Haz clic en Save
Dos puntos (:)
No selecciones todos los eventos de tu aplicación. Selecciona solo los eventos en los que normalmente podría haber fraude
Acceso a los datos
Cuando una regla de Serie de eventos bloquea una instalación o un evento in-app, los detalles se registran en tus reportes de raw data. Ve a Raw Data > Protect360 & Validation Rules para encontrar los eventos bloqueados y usa los campos siguientes para identificar cuáles ha bloqueado esta regla.
| Informe | Campos clave |
|---|---|
| Instalaciones posteriores a la atribución |
|
| Eventos in-app posteriores a la atribución |
|
| Eventos in-app bloqueados |
|
Ejemplos
A continuación, se muestran ejemplos de distintas series de eventos y si se considerarían fraudulentas o no.
Ejemplo 1
Regla definida
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B
- Evento C
Realmente realizado
El usuario realiza los eventos en este orden:
- Día 0: se produjo la instalación
- Día 1: se envió el evento A
- Día 2: se envió el evento B
- Día 3: se envió el evento C
Resultado:
No es fraude. El usuario realizó la serie de eventos en la secuencia definida.
Ejemplo 2
Regla definida
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B
- Evento C
Realmente realizado
El usuario realiza los eventos en este orden:
- Día 0: se produjo la instalación
- Día 1: se envió el evento A
- Día 2: se envió el evento C
- Día 3: se envió el evento B
Resultado:
Fraude. El usuario realizó el evento C antes que el evento B, lo que queda fuera de la secuencia definida. Por ende:
- El evento A se bloqueará en la atribución posterior
- El evento B se bloqueará en tiempo real
- El evento C se bloqueará en tiempo real o tras la Atribución, ya que este evento interrumpió la secuencia
- Todos los eventos siguientes se bloquearán en tiempo real
Ejemplo 3
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B (tiempo mínimo respecto al evento anterior: 1 hora)
- Evento C (tiempo mínimo respecto al evento anterior: 2 horas)
El usuario realiza los eventos en este orden:
- Día 0: Se produjo la instalación
- Día 0: Se envió el evento A
- Día 0: Se envió el evento B 10 minutos después del evento A
- Día 0: Se envió el evento C 2 horas después del evento B
Fraude. El usuario realizó todos los eventos en el orden correcto, pero el intervalo entre el evento A y el evento B fue de solo 10 minutos, lo que es inferior al mínimo configurado de 1 hora. Se incumplió la restricción temporal, independientemente de que el orden de la secuencia fuera correcto. Por ende:
- El evento A se bloqueará tras la Atribución
- El evento B se bloqueará en tiempo real, ya que incumplió la restricción de tiempo mínimo
- El evento C se bloqueará en tiempo real, ya que siguió a una secuencia incumplida
- Todos los eventos siguientes se bloquearán en tiempo real
Ejemplo 4
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B
- Evento C
El usuario realiza los eventos en este orden:
- Día 0: Se produjo la instalación
- Día 1: Se envió el evento A
- Día 2: se envió el evento B
- No se envió el evento C
No es fraude. El usuario completó los eventos A y B en el orden correcto, pero nunca envió el evento C. Las secuencias incompletas no se marcan como infracciones. No se bloquea ningún evento. La regla sigue evaluando eventos futuros dentro de la ventana de evaluación de 30 días.
Ejemplo 5
Regla definida
El usuario fue identificado mediante el ID de usuario del cliente (CUID).
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B
- Evento C
Realmente realizado
El usuario realiza los eventos en este orden:
- Día 0: se produjo la instalación
- Día 1: se envió el evento A
- Día 1: se produjo la desinstalación
- Día 1: se produjo la instalación
- Día 2: se envió el evento B
- Día 3: se envió el evento C
Resultado:
No es fraude. Dado que el usuario fue identificado mediante el ID de usuario del cliente (CUID) y los eventos se realizaron en orden.
Ejemplo 6
Regla definida
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B
- Evento C
Realmente realizado
El usuario se identificó mediante el ID del Anunciante
El usuario realiza los eventos en este orden:
- Día 0: se produjo la instalación
- Día 1: se envió el evento A
- Día 1: se produjo la desinstalación
- Día 1: se produjo la instalación
- Día 2: se envió el evento B
- Día 3: se envió el evento C
Resultado:
No es fraude. Dado que el usuario se identificó mediante el ID del Anunciante y los eventos se realizaron en orden.
Ejemplo 7
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B
- Evento C
- 1 de enero (Día 0): se creó la regla. Se inicia la ventana de evaluación. Los eventos activados antes de esta fecha se ignoran.
- 15 de enero (día 14): se envió el evento A. La ventana se amplía; ahora se evalúan los últimos 14 días.
- 30 de enero (día 29): se envió el evento B. La ventana se amplía; ahora se evalúan los últimos 29 días.
- 31 de enero (día 30): la ventana llega a 30 días y se convierte en una ventana móvil de 30 días, que avanza cada día.
- 20 de febrero: se envió el evento C. La ventana móvil ahora retrocede 30 días, hasta el 21 de enero. El evento A (activado el 15 de enero) queda fuera de la ventana y ya no se evalúa.
No es fraude. A fecha de 20 de febrero, la ventana móvil retrocede hasta el 21 de enero, por lo que el evento A (15 de enero) queda fuera de la ventana de evaluación. Solo se evalúan los eventos B y C; ambos en el orden correcto, sin que se marque ninguna infracción.
Ejemplo 8
Regla definida
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B
- Evento C
Lo que realmente se realizó
El usuario realiza los eventos en este orden:
- Día 0: se produjo la instalación
- Día 1: se envió el evento A
- Día 2: se envió el evento B
- Día 3: se envió el evento B
- Day4: Evento C enviado
Resultado:
Fraude. Como el mismo evento (evento B) ocurrió dos veces, presumimos fraude, ya que no puedes tener el mismo evento dos veces en una secuencia.
Ejemplo 9
Regla definida
El usuario se identificó mediante el ID de usuario del cliente (CUID).
El usuario debe realizar los eventos en este orden:
- Evento A
- Evento B
- Evento C
El usuario envía eventos desde dos dispositivos usando el mismo CUID:
- Día 0: la instalación se produjo en el dispositivo 1
- Día 0: la instalación se produjo en el dispositivo 2
- Día 1: el evento A se envió desde el dispositivo 1
- Día 2: el evento B se envió desde el dispositivo 2
- Día 3: el evento C se envió desde el dispositivo 1
No es fraude. Como el usuario se identificó mediante el CUID, la evaluación de la secuencia abarca todos los ID de AppsFlyer asociados al mismo CUID y al ID de la regla. Los eventos A, B y C se realizaron en el orden correcto, independientemente del dispositivo que los activó.
Especificaciones y limitaciones
- Se pueden definir hasta 100 eventos en cada regla.
- Al llegar a 80 eventos, se muestra una advertencia. Al llegar a 100 eventos, se alcanza el límite y la regla debe dividirse para añadir más.
- El tiempo mínimo que se puede establecer entre eventos consecutivos es de 1 segundo. Si no se configura ningún intervalo para un par, se aplica automáticamente el valor predeterminado de 1 segundo.
- El intervalo máximo configurable entre eventos es de 30 días, en consonancia con la ventana de evaluación.
- La ventana de evaluación comienza el día 0 (fecha de creación de la regla) y aumenta cada día hasta 30 días; después, pasa a ser una ventana móvil de 30 días que avanza cada día. Los eventos activados antes de la fecha de creación de la regla nunca se evalúan.
- Cualquier edición de una regla restablece la ventana de evaluación al día 0.
- Se pueden establecer hasta 10 reglas activas por cuenta.
- Las reglas de la serie de eventos solo se pueden usar para tráfico no orgánico.
- Solo se admite tráfico SDK. El tráfico S2S queda fuera del alcance de la fase 1.
- Las secuencias incompletas no se marcan como infracciones. Una secuencia solo se evalúa una vez que se han activado todos los eventos definidos.
- El mismo evento no puede aparecer dos veces en una sola secuencia.
- Solo se admite la lógica AND entre las condiciones. La lógica OR no se admite.
Preguntas frecuentes
¿Qué ocurre después de una reinstalación?
Si la reinstalación restablece eventos que el usuario ya había completado, se trata como una infracción. Si el usuario retoma desde donde lo dejó, no se marca ninguna infracción.
This article was translated automatically and may contain errors. The English version is the most accurate - use the language selector below to switch.