Implementa reglas de validación para evitar el fraude

• Para las instalaciones: Las reglas de validación, según la acción seleccionada, bloquean la atribución y la corrigen a la última fuente de medios válida, o bloquean la atribución por completo.
• Para eventos in-app: Las reglas de validación bloquean la atribución del evento in-app.

• Consulta la siguiente tabla que muestra los resultados del tipo de bloqueo de la regla de validación.
   

  	Tipo de bloqueo	Descripción	Dónde se pueden ver los datos de instalación	Eventos in-app que siguen
  Instalaciones	Bloquear la atribución y corregirla a la última fuente de medios válida.	Se selecciona cuando consideras que la instalación es real, pero tus condiciones determinan qué fuentes deben o no atribuirse para ella. La atribución se corrige y la instalación se atribuye a la última fuente de medios válida. Si no se identifica una fuente de medios válida, la instalación se marca como orgánica.	Reportes de raw data y dashboards de AppsFlyer como una instalación regular (atribuida a la última fuente de medios válida) Con el plan Protect360 Premium: Dashboard de instalaciones de Protect360 Reporte de raw data de instalaciones de Protect360 (con la fuente de medios bloqueada) Sin el plan Protect360 Premium: Reporte de raw data de instalaciones de Protect360 (con la fuente de medios bloqueada)	Tiene la misma atribución corregida que la instalación Datos disponibles con el plan Protect360 Premium: Con la atribución corregida en los dashboards y reportes de AppsFlyer como un IAE regular Con la fuente de medios bloqueada en el dashboard de eventos in-app de Protect360 y el reporte de raw data de eventos in-app bloqueados de Protect360
  	Marcar las instalaciones como inválidas y no atribuirlas	Se selecciona cuando las instalaciones que son inválidas en función de las condiciones de la regla se consideran falsas. La instalación no se atribuye en absoluto (ni como orgánica ni como no orgánica)	Con el plan Protect360 Premium: Dashboard de instalaciones de Protect360 Reporte de raw data de instalaciones de Protect360 (con la fuente de medios bloqueada) Sin el plan Protect360 Premium: Reporte de raw data de instalaciones de Protect360 (con la fuente de medios bloqueada)	Bloqueos Datos disponibles con el plan Protect360 Premium en el dashboard de eventos in-app de Protect360 y en el reporte de raw data de eventos in-app bloqueados.
  Eventos in-app	Bloqueo de la atribución	Se selecciona cuando los eventos in-app que no son válidos según las condiciones de la regla se consideran falsos.	Con el plan Protect360 Premium: Dashboard de IAE de Protect360 Reporte de raw data de eventos in-app de Protect360 Sin el plan Protect360 Premium: N/A	Datos disponibles con el plan Protect360 Premium en el dashboard de eventos in-app de Protect360 y en el reporte de raw data de eventos in-app bloqueados.
  	Eliminar de AppsFlyer por completo	Recomendado para usar cuando hay eventos in-app para los que no necesitas ningún dato. AppsFlyer no registra estos eventos en absoluto.

• Las ad network y las agencias solo pueden ver los datos si el anunciante les otorga los permisos necesarios.
• Cuando se bloquea o atribuye una atribución de instalación a una fuente de medios válida en tiempo real, se envía instantáneamente un postback rechazado a la ad network bloqueada para agilizar el flujo de reconciliación. Cuando la atribución se bloquea y se corrige a la última fuente de medios válida, también se envía un postback a la última ad network válida.
• Cuando se bloquea un evento in-app, se envía instantáneamente un postback de rechazo a la ad network bloqueada.
  Note:
  • Un postback solo se envía si la ad network configurada para recibirlo está integrada con AppsFlyer para recibir postbacks.
  • Los reportes de postbacks y postbacks rechazados están disponibles en la página de exportación.
  • Saber más sobre los postbacks y los postbacks rechazados.
• El bloqueo de atribución de instalaciones y eventos in-app solo afecta a cómo y dónde se reportan los datos en AppsFlyer. No impiden el uso de la aplicación por parte de tus usuarios finales.
  • Si es necesario, puedes usar los reportes de raw data de eventos in-app bloqueados e instalaciones bloqueadas (disponibles a través de exportación, Pull API y Data Locker) para obtener la lista de usuarios de la aplicación a deshabilitar. 
• Los reportes de instalaciones/eventos in-app bloqueados y los postbacks rechazados contienen el nombre de las reglas que bloquearon las instalaciones/eventos in-app bajo el motivo del bloqueo. Consulta la sección Reglas múltiples, si hay más de una regla.
  • Cuando las instalaciones/eventos in-app son bloqueados por el motor antifraude de Protect360, incluso si también hay una regla de validación, se muestran los motivos de Protect360.
• Las reglas pueden generar discrepancias en los reportes entre AppsFlyer y las SRNs como Meta Ads y Google Adwords, ya que estas implementan su propia lógica para validar las instalaciones.

• Se pueden ejecutar varias reglas de validación en la misma instalación/IAE. Esto sucede cuando la instalación cumple las condiciones de varias reglas. 
• La instalación/IAE se clasifica como inválida cuando no cumple las condiciones de ninguna de las reglas por separado.
• En los reportes de raw data y en los postbacks rechazados, el campo block reason value contiene los nombres de todas las reglas que clasifican el evento de instalación o in-app como no válido.
• Varias reglas para la misma instalación se ordenan para ejecutarse en el siguiente orden, según los tipos de bloqueo de las reglas:

La sección Fuentes es donde defines las fuentes de tráfico de las instalaciones a las que se aplica la regla.

Existen tres opciones principales: 

• Todo el tráfico: Incluye tanto instalaciones orgánicas como no orgánicas. La información de la fuente no está disponible para las instalaciones orgánicas. Esta opción incluye todas las fuentes de medios, incluidas las que se añadan en el futuro.
  Ejemplo: Aplica una regla a todo el tráfico con una versión de la app inferior a X.

• Todo el tráfico no orgánico: Se aplica a todas las fuentes de tráfico no orgánico de agencias y no agencias, incluidas las nuevas fuentes que se añadan posteriormente.
  Ejemplo: Bloquea el tráfico no orgánico de una geo específica donde no ejecutas campañas de UA o retargeting.

• Tráfico no orgánico seleccionado: Aplica la regla únicamente a agencias o fuentes de medios específicas. Debes seleccionar o añadir manualmente las fuentes de medios al editar la regla.
  Ejemplo: Bloquea las instalaciones de una fuente de medios específica si el CTIT es superior a X días.

Hay opciones adicionales de fuentes disponibles para los clientes de Protect360 para instalaciones y eventos in-app. 

La sección Condiciones es donde se definen las condiciones que determinan cuándo se bloquean las instalaciones o se atribuyen a la última fuente válida.  

Puedes agregar varias condiciones y grupos de condiciones a cada regla.

Las condiciones se definen según las condiciones, los operadores y los valores descritos en la siguiente tabla.

Carga masiva

Al seleccionar los operadores En la lista o Fuera de la lista dentro de las condiciones que la admiten, tienes la opción de cargar en masa un archivo CSV al agregar nuevos elementos.

Para ello:

1. Selecciona una condición con un operador En la lista o Fuera de la lista.
2. Selecciona En la lista o Fuera de la lista de la lista desplegable del operador.
3. Selecciona Cargar archivo CSV en el cuadro Agregar elementos nuevos. 

Nota: El archivo CSV puede contener hasta 17K valores.

Hay opciones de condiciones adicionales disponibles para los clientes de Protect360, para instalaciones y eventos in-app.  

Cuando se selecciona Eventos in-app en la sección Eventos, además de las opciones de fuentes habituales, los clientes tienen otra opción de fuente para definir a qué eventos in-app se aplica su regla. 

La fuente se define según el campo, los operadores y los valores descritos en la siguiente tabla.

Nota: Todas las demás fuentes de eventos in-app se basan en la fuente de instalación con la que está asociado el IAE (por ejemplo, agencia, fuente de medios, campaña, ID de campaña, ID de sitio, etc.).

Cuando se selecciona Eventos in-app en la sección Eventos, los clientes tienen opciones de condición adicionales para definir a qué eventos in-app se aplica su regla. Estas condiciones se pueden mezclar y combinar con cualquiera de las condiciones que no son de Protect360 listadas anteriormente.

Las condiciones de Protect360 se definen según las condiciones, los operadores y los valores descritos en la siguiente tabla.

Además de las opciones de fuente habituales, los clientes de Protect360 tienen otra opción de fuente para definir a qué instalaciones se aplica su regla. La fuente se define según el campo, los operadores y los valores descritos en la siguiente tabla.

Los clientes de Protect360 tienen un conjunto adicional de condiciones para validar sus instalaciones. Estas condiciones se pueden mezclar y combinar con cualquiera de las condiciones que no son de Protect360 listadas anteriormente.

Las condiciones de Protect360 se definen según las condiciones, los operadores y los valores descritos en la siguiente tabla.

Cuando se selecciona Eventos in-app en la sección Eventos, los clientes de Protect360 tienen opciones de condición adicionales para definir a qué eventos in-app se aplica su regla. Estas condiciones se pueden mezclar y combinar con cualquiera de las condiciones que no son de Protect360 listadas anteriormente.

Las condiciones de Protect360 se definen según las condiciones, los operadores y los valores descritos en la siguiente tabla.

Si agregas varias condiciones o grupos de condiciones a una regla, selecciona la relación lógica entre ellos usando: 

• Y: Significa que la instalación cumple con todas las condiciones definidas.
• O: Significa que la instalación cumple al menos una de las condiciones definidas.

Por ejemplo, si deseas validar las instalaciones según la plataforma y el sistema operativo, debes seleccionar y. De esa forma, la plataforma definida debe acompañar siempre al SO definido. Si deseas validar las instalaciones según la plataforma o el sistema operativo, debes seleccionar o.

Para ver todas las reglas creadas en tu cuenta:

1. En AppsFlyer, ve a Configuración > Reglas de validación.
   Se abre la ventana reglas de validación, con la lista de reglas de validación.
2. Selecciona tu vista de tabla preferida utilizando el selector Vista de lista/Vista detallada.
3. Filtra las reglas de la lista mediante las opciones de búsqueda y filtro.
   • Puedes buscar por nombre de la regla, fuente, nombre de la condición y valor.
   • Por ejemplo, escribe 7 para encontrar todas las reglas definidas para una versión del sistema operativo que contenga 7 (por ejemplo: “2.7.4”, “7.1”, etc.). O escribe Canada para encontrar reglas definidas con Canada en la condición Geo. 

Para configurar una regla nueva:

1. En AppsFlyer, ve a Configuración > Reglas de validación.
   Se abre la ventana reglas de validación.
2. Haz clic en Agregar regla.
   Se abre la ventana “Agregar nueva regla”.
3. Inserta un nombre de regla. Utiliza un nombre único que:
   • Describe exactamente la regla.
   • no resulte ofensivo para las ad networks, ya que aparecerá en el reporte de instalaciones bloqueadas y en los postbacks rechazados enviados a las ad networks.
4. Completa las secciones del generador de reglas.
5. [Opcional] Agrega condiciones y/o grupos de condiciones, según sea necesario. Asegúrate de seleccionar la lógica relevante entre condiciones/grupos de condiciones.
6. [Opcional] Haz clic en Estimar el impacto del tráfico para ver cómo afectará tu regla al tráfico.
7. Haz clic en Guardar.

Un patrón de expresión regular está compuesto por caracteres para los que quieres encontrar una coincidencia. Los patrones simples se construyen con caracteres para los que quieres encontrar una coincidencia directa. Cuando la búsqueda de una coincidencia requiere algo más que una coincidencia directa, puedes incluir caracteres especiales en el patrón.

Ejemplos:

Hay dos razones posibles:

• Asegúrate de que las aplicaciones correspondientes estén seleccionadas. Si la aplicación no está seleccionada, los valores no se muestran en los resultados de búsqueda.
• Los resultados se muestran solo si el valor que estás buscando apareció en tu tráfico durante los últimos 30 días. Además, hay un desfase de hasta 1 día entre el momento en que se produce la conversión y el momento en que la fuente o la condición se muestra como una opción del menú.

Si el valor no aparece como resultado de la búsqueda, puedes escribir el valor como texto libre y pulsar la tecla “Enter” en tu teclado.

Las opciones del campo fuente de medios dependen de la selección realizada en agencia.

Depende de tu caso de uso. En ocasiones, cualquiera de las dos opciones produce el mismo resultado. Otras veces, ambas opciones son necesarias.

Por ejemplo, si en EE. UU. solo admites instalaciones con la versión 10 del sistema operativo o superior, pero en Brasil admites la versión 7 o superior, necesitarás una regla como esta:

{[Geo = US] y [versión del OS = 10]} OR {[Geo = Brazil] y [versión del OS = 7]}

No. Las reglas de validación pueden bloquear instalaciones, bloquear la atribución a las fuentes de una instalación (lo que impide que la fuente de medios de un clic o una impresión reciba la atribución) o bloquear eventos in-app. Sin embargo, ninguna de estas opciones bloquea el clic en sí, y los KPIs de clics no se ven afectados por la ejecución de las reglas de validación.

Esto significa que el bloqueo se debió al motor de Protect360 y no a una regla de validación. Consulta también múltiples reglas.

Esto depende de la configuración de la fuente, como se describe en la siguiente tabla.

Si la regla no se aplica automáticamente, debes editarla:

• Cambia el campo Agencia a Tráfico de agencia y no agencia o selecciona la agencia específica.

Utiliza No en las últimas para permitir instalaciones de las versiones más recientes de tu aplicación y bloquear instalaciones de las versiones anteriores.

• No en las últimas X versiones: Permite instalaciones de las últimas X versiones de la app seleccionada y bloquea las instalaciones de todas las versiones anteriores.
   
• No en las últimas (mayores) X versiones: Utilízalo cuando tu esquema de versiones incluya varias series de versiones principales (por ejemplo, 1.x y 2.x). Esta condición permite las últimas X versiones de cada serie principal y bloquea las versiones anteriores de cada serie.

Ejemplo: No en las últimas

Tienes estas versiones existentes de la app:

• 1.0.01
• 1.0.02
• 1.0.03
• 2.0.01
• 2.0.02
• 2.0.03

Una regla definida con No en las últimas 2 versiones:

• Permite: 
  • 2.0.02
  • 2.0.03
     
• Bloquea: 
  • 1.0.01
  • 1.0.02
  • 1.0.03
  • 2.0.01

Ejemplo: No en las últimas (mayores)

Usando la misma lista de versiones anterior, una regla definida con No en los últimos (mayores) 2 versiones:

• Permite: 
  • 1.0.02
  • 1.0.03
  • 2.0.02
  • 2.0.03
     
• Bloquea: 
  • 1.0.01
  • 2.0.01

Comprende cómo funciona esta condición con varias apps

Si seleccionas varias apps en la regla, AppsFlyer evalúa la condición No en las últimas por separado para cada app.

Por ejemplo, si configuras No en las últimas 3 versiones y seleccionas la App A, la App B y la App C:

• La App A permite sus últimas 3 versiones según el historial de versiones de la App A.
• La App B permite sus últimas 3 versiones según el historial de versiones de la App B.

La App C permite sus últimas 3 versiones según el historial de versiones de la App C.

Utiliza una regla de validación cuando quieras evitar la atribución procedente de interacciones basadas en impresiones y mantener la atribución únicamente para clics válidos. Si no se encuentra una fuente de medios válida basada en clics, la instalación se atribuye como orgánica. Esta configuración puede ayudar a abordar escenarios de atribución relacionados con el secuestro de instalaciones.

Para configurar la regla:

• En Fuentes de tráfico, selecciona Todo el tráfico no orgánico.

• En Condiciones, selecciona Tipo de toque de atribución.

  • Configura el operador como En la lista.

  • En Impresión.

• En Acción, selecciona Bloquear atribución y corregir a la última fuente de medios válida.

No selecciones Marcar instalaciones como inválidas y no atribuirlas para este caso de uso. Esa acción está pensada para instalaciones que consideras no válidas o falsas. Si la instalación es real, pero no quieres atribuirla a una interacción basada en impresiones, utiliza Bloquear atribución y corregir a la última fuente de medios válida.

Sí. El modo Tagged admite todos los operadores y campos de las reglas de validación, incluida la lógica And/Or, Geo, OS version, SDK version y Event value.

No. Los datos Tagged no se clasifican como tráfico bloqueado. El tráfico Tagged se identifica como Tagged y se considera un subconjunto del tráfico válido. Es visible en los reportes válidos de Data Locker.

Utiliza Data Locker para ver los datos Tagged de las reglas de validación. Las instalaciones Tagged están disponibles en el informe de instalaciones y los eventos in-app Tagged están disponibles en el reporte de evento in-app.

Los datos Tagged no son visibles en el dashboard de Protect360 ni en el paquete de protección contra el fraude.

Sí. Después de revisar los datos exportados y confirmar que la regla funciona según lo previsto, edita la regla, configura la detección como Implemented y guarda la regla. A partir de ese momento, la regla bloquea activamente el tráfico que coincide según el Rule outcome seleccionado.

El modo Tagged está disponible para los clientes Premium. No existe un límite estricto para la cantidad de reglas que pueden configurarse como Tagged. Como práctica recomendada, revisa las reglas Tagged y cámbialas a Implemented cuando tengas la certeza de que son precisas.