Reportes de raw data de Protect360<br />

De un vistazo: Los reportes de raw data describen las instalaciones y los eventos in-app bloqueados por Protect360, así como las reglas de validación agregadas manualmente.

Lectura relacionada: Descripción generalPaneles de control Reglas de validación

Acerca de los reportes de raw data de Protect360

Reportes de raw data:

  • Muestran datos sobre:
    • Clics, instalaciones y eventos in-app que el motor Protect360 identificó como fraudulentos.
    • Instalaciones y eventos in-app identificados a través de Reglas de validación. 
  • Incluyen el motivo del bloqueo para cada clic, instalación o evento in-app.  
  • Los anunciantes los utilizan para conciliar las cuentas de las redes de publicidad, para la optimización y para ajustar los paneles de control de atribución para el fraude posterior a la atribución. 
  • Es posible que algunos campos estén restringidos o no estén disponibles si la Privacidad avanzada agregada (AAP) de AppsFlyer.
  • Los tipos de reportes y su disponibilidad mediante descarga, API y Data Locker (S3 bucket) se describen en las secciones a continuación.

Tipos de reportes

Tipos de reportes de raw data de Protect 360
Reporte Descripción
Instalaciones

Los reportes incluyen: 

  • Instalaciones falsas: instalaciones que Protect360 identifica como fraudulentas. Estas no aparecen en ningún panel de control de AppsFlyer ni en el raw data, excepto en el panel de control y el raw data de Protect360.
  • Instalaciones secuestradas: instalaciones de usuarios reales en las que se roba la atribución, pero Protect360 corrige la atribución.
  • Reglas de validación: que bloquean la instalación o bloquean la atribución (Protect360 corrige la atribución). 
Instalaciones post-atribución

Los reportes incluyen instalaciones atribuidas a una fuente de medios, pero que posteriormente se descubrió que eran fraudulentas.Protect360 corrige la atribución.

Eventos in-app bloqueados 

Los reportes incluyen eventos in-app de:

  • Instalaciones falsas: se bloquean los eventos in-app.
  • Instalaciones secuestradas
    • En los reportes de eventos in-app de Protect360, se muestra la fuente de medios fraudulenta.
    • En los reportes habituales de raw data de eventos in-app, se muestra la fuente de medios correcta. 
  • Eventos in-app: se identifican como fraudulentos independientemente de las instalaciones originales.
  • Reglas de validación:
    • Los eventos in-app de una regla que bloqueó la instalación o bloqueó la atribución.
    • Los eventos in-app de una regla que bloqueó el evento in-app. 
Eventos in-app post-atribución

Los reportes incluyen eventos in-app:

  • Identificados después de la atribución.
  • De instalaciones atribuidas a una fuente de medios, pero que posteriormente se descubrió que eran fraudulentas.
Clics Los reportes incluyen los clics bloqueados con los motivos del bloqueo.
Postbacks de instalación bloqueadas Los reportes incluyen copias de los postbacks de rechazo enviados a fuentes de medios que traen instalaciones bloqueadas.

Reportes posteriores a la atribución:

  • Los reportes de raw data sobre el fraude posterior a la atribución tienen la misma estructura que los reportes sobre bloqueo de fraude.
  • El reporte posterior a la atribución del mes actual (por fecha de instalación) continúa actualizándose hasta el séptimo día del mes siguiente (fecha de detección). 
  • Los reportes de raw data posterior a la atribución se limitan a los anunciantes. Las agencias necesitan permisos de acceso habilitados.
  • Los reportes contienen los eventos de fraude posteriores a la atribución identificados por Protect360 e incluyen todas las fuentes de medios en un solo reporte.
  • Los reportes de raw data sobre fraude posterior a la atribución están disponibles de la siguiente manera:

    • Interfaz de usuario del panel de control: limitada a una fuente de medios durante un mes calendario.
    • Pull API: contiene todas las fuentes de medios.  (Limitación: disponible solo para propietarios de aplicaciones)

Usar los reportes posteriores a la atribución

  • Selecciona cualquier combinación de instalación/evento in-app y detecta rangos de fechas según sea necesario.
  • Ten en cuenta que Protect360 realiza la detección posterior a la atribución durante el mes calendario de la instalación y hasta el séptimo día del mes siguiente. Esto significa, por ejemplo, que para las instalaciones en noviembre, Protect360 verifica el fraude hasta el 7 de diciembre. 
  • La mejor práctica para usar esta Pull API es la siguiente:
    • Supón que extraes el reporte diariamente. 
    • Establece el rango de fechas de instalación hasta los 60 días anteriores desde la fecha actual.
    • Establece el rango de detect-from/detect-to en el día anterior a la fecha actual.
      Esto significa que obtendrás la lista de fraudes posteriores a la atribución detectados ayer. Si no extrajiste el reporte durante unos días, ajusta el rango de fechas de detección y extrae el reporte.

Ejemplo

Ejemplo A: durante diciembre (fecha de instalación) se atribuyen 15 instalaciones a example_media. El 3 de enero (fecha de detección), Protect360 identifica a example_media como defraudador. Como resultado, las 15 instalaciones atribuidas a example_media se indican como fraudulentas en el reporte de fraude posterior a la atribución, para que el propietario de la aplicación tome las medidas pertinentes. 

Ejemplo B: durante diciembre, se atribuyen 15 instalaciones a example_media. El 9 de enero, Protect360 identifica a example_media como defraudador. En este caso, Protect360 no toma medidas porque el defraudador fue identificado después del cierre del mes, el 7 de enero.  

Disponibilidad de raw data por tipo de herramienta

Disponibilidad de raw data de Protect 360 por tipo de herramienta
Reporte Actualización de los datos API pull Página de datos exportados Data Locker
Instalaciones Tiempo real ✓*
Eventos in-app bloqueados  Tiempo real
Clics Tiempo real
Postbacks de instalación bloqueadas Tiempo real - -
Instalaciones post-atribución

Diariamente a las 10:00 UTC

✓*
Eventos in-app post-atribución

Diariamente a las 10:00 UTC

-

* Limitaciones para reportar a través de Data Locker:

  • No es compatible la transparencia de agencias. Esto significa que el tráfico impulsado por la agencia no contiene el nombre de la fuente de medios que envía la instalación. 
  • El reporte tiene un conjunto único de campos relativos a otros reportes de Data Locker. Esta lista no se puede cambiar. 
  • Los datos de retargeting no están disponibles en el reporte de instalaciones; solo en el reporte de instalaciones posteriores a la atribución. 

Obtener reportes de raw data

Los reportes de raw data están disponibles mediante descarga, Pull API y Data Locker (S3 bucket). También puedes brindar a los partners acceso a los reportes.

Descargar

Para descargar:

  1. En el panel de control de Protect360, ve a Reportes de raw data > Bloqueados o Posterior a la atribución.
    • Para los reportes de post-atribución, selecciona la fuente de medios y el mes.
  2. Selecciona el reporte Protect360 y reglas de validación para descargar.

O

  1. En panel de control de AppsFlyer, ve a Datos exportados
  2. Selecciona el reporte Protect360 y reglas de validación para descargar.

Nota: Los reportes descargados de la página de Datos exportados contienen todas las fuentes de los medios.

API pull

Para descargar los reportes de raw data disponibles mediante la Pull API:

Antes de comenzar:

Necesitas un token de Pull API. Obtén el token del administrador

  1. Ve a Integración > Acceso a API.
    Se abre la página Pull API.
  2. En la sección de reportes de fraude de Protect360, selecciona la llamada de Pull API necesaria.
  3. Completa los parámetros según sea necesario. En la tabla siguiente se enumeran los parámetros.
  4. Extrae el reporte. 
Parámetros del reporte de raw data de Pull API
Parámetro Descripción Formato Obligatorio
app_id  ID de aplicación tal como aparece en AppsFlyer String
api_token Recupera la clave del panel de control. Ve a Integración > Acceso a API.
Solo el administrador de la cuenta puede recuperar el token de la API.
String
desde

Inicio del rango de fechas:

  • Para las instalaciones, esta es la fecha de instalación.
  • Para los eventos in-app, esta es la fecha del evento.
AAAA-MM-DD
a

Fin del rango de fechas:

  • Para las instalaciones, esta es la fecha de instalación.
  • Para los eventos in-app, esta es la fecha del evento.
AAAA-MM-DD
event_name

[Opcional para el fraude de eventos in-app posterior a la atribución]

Filtra los eventos por evento in-app. Limita el reporte a eventos específicos.  Se pueden incluir uno o más eventos.

Ejemplo de uso: &event_name=af_purchase,af_login

String

No

 

additional_fields=rejected_reason_value

[Opcional para el fraude de eventos in-app posterior a la atribución]

rejected_reason_value muestra el colaborador válido (fuente de medios) para instalaciones y eventos in-app secuestrados. Completado con elcontributor[1-3] u orgánico.

String

No

detect-from

[Opcional para instalaciones posteriores a la atribución]

Comienzo del rango de fechas de detección de fraude. (Por defecto es from [desde].) (Utilizado en el fraude de instalación posterior a la atribución.) (Utilizado en el fraude de instalación posterior a la atribución.)

AAAA-MM-DD No
detect-to

[Opcional para instalaciones posteriores a la atribución]

Fin del rango de fechas de detección de fraude. (Por defecto es to [hasta]. )

AAAA-MM-DD No

Estructura de los reportes de Protect360

Los reportes de Protect360 tienen la misma estructura general que los campos de reportes similares de adquisición de usuarios.

Además de los campos habituales de los reportes de raw data, los reportes de Protect360 también tienen campos de motivo de bloqueo y retargeting, como se muestra a continuación:

Motivos de bloqueo

Motivos de bloqueo a nivel de clic

A nivel de clic, se bloquean los clics y el proceso de atribución los ignora.

Blocked Reason Descripción
ip_blacklist Según una lista creada de manera dinámica (detalles)
invalid_fingerprint Solo clics de S2S: parámetros inválidos enviados por la fuente (para la coincidencia probabilística)
click_capping Se detectan tasas extremadamente altas de fraude de clics en esa red de publicidad. Más información
click_signing La firma en el clic no está validada. Más información

Motivos de bloqueo a nivel de instalación

A nivel de la instalación, identificamos suficiente información en el momento de la instalación para determinar:

  • Una instalación falsa, lo que significa que el usuario que instala la aplicación no es una persona real. En este caso, la atribución se bloquea completamente.
  • Secuestro de atribución, cuando el usuario es real pero el engagement está falsificado. En este caso, el engagement fraudulento se bloquea y la atribución se reasigna a la primera red de publicidad válida que contribuye.

Las siguientes tablas enumeran los posibles motivos de bloqueo a nivel de la instalación:

Nivel de la instalación: motivos de bloqueo por instalación falsa
Blocked Reason Blocked Sub Reason Descripción
Bots fake_device_parameters Comportamiento no humano detectado en los parámetros relacionados con el dispositivo durante el proceso de instalación de la aplicación
Bots fake_install_parameters Comportamiento no humano detectado en los parámetros relacionados con la instalación durante el proceso de instalación de la aplicación
Bots bayesian_network Identificación de red bayesiana de patrones fraudulentos
install_store_validation -

Error en la validación de recibo de instalación de la App Store de Apple

validation_bots invalid_device_parameters No coinciden las expectativas de los campos específicos del dispositivo: definido por el cliente
validation_bots validation_rules

Reglas en las que el resultado son instalaciones bloqueadas en base a una regla de validación definida manualmente

Nivel de la instalación: motivos de bloqueo por secuestro de atribución
Blocked Reason Blocked Sub Reason Descripción

ctit_anomalies

short_ctit

Instalación bloqueada debido a CTIT corto: definido por Protect360

install_hijacking

referrer_hijack

Intento de secuestro bloqueado basado en los parámetros del SDK de AppsFlyer y la API de GooglePay

install_hijacking

integration_temporarily_blocked

Instalación bloqueada porque el partner (ID de anunciante [PID]) tiene tasas de fraude extremadamente altas y anomalías significativas en todo su tráfico

validation_hijacking

short_ctit

Instalación bloqueada debido a CTIT corto: definido por el cliente

validation_hijacking

empty_site_id

La instalación se ha bloqueado debido a un ID de sitio no completado. La aplicación de las normas es obsoleta. 

validation_hijacking

validation_rules

Reglas en las que el resultado es la atribución bloqueada en base a una regla de validación definida manualmente

Motivos de bloqueo a nivel de grupo

Cuando se detecta un patrón de fraude, la fuente del fraude aparece en la lista de denegación. Las instalaciones de esta fuente en la lista de denegación se bloquean debido a:

  • Una instalación falsa, lo que significa que el usuario que instala la aplicación no es una persona real. En este caso, la atribución se bloquea completamente.
  • Secuestro de atribución, cuando el usuario es real pero el engagement está falsificado. En este caso, el engagement fraudulento se bloquea y la atribución se reasigna a la primera red de publicidad válida que contribuye.

Las siguientes tablas enumeran los posibles motivos de bloqueo a nivel de grupo:

Nivel de grupo: motivos de bloqueo de instalación falsa
Blocked Reason Blocked Sub Reason Descripción
Bots timestamp_anomalies Anomalías relacionadas con los tiempos de clics del flujo de atribución y otras marcas de tiempo recopiladas del dispositivo
bots, site_blacklist device_emulators Instalaciones generadas a gran escala por scripts automáticos que trabajan en entornos virtuales.
site_blacklist device_farms Altas tasas de dispositivos desconocidos (nuevos)
behavioral_anomalies behavioral_anomalies Comportamiento sospechoso in-app en comparación con el patrón de comportamiento del usuario común de la aplicación
Nivel de grupo: motivos de bloqueo por secuestro de atribución
Blocked Reason Blocked Sub Reason Descripción
ctit_anomalies, install_hijacking ctit_anomalies Patrón de CTIT anormal según los estándares de la aplicación
click_flood click_flood Volumen de clics anormalmente alto en una distribución de CTIT largo
install_hijacking click_clusters Clics generados por un malware a nivel del dispositivo

Motivos de bloqueo a nivel in-app

Los eventos in-app se pueden bloquear por los siguientes motivos:

  • La instalación inicial se identificó como falsa.
  • Debido a una regla de validación definida.
  • Porque nuestro algoritmo detecta fraude. 

La siguiente tabla enumera los posibles motivos de bloqueo a nivel in-app.

Motivos de bloqueo a nivel in-app
Blocked Reason Blocked Sub Reason Descripción
Hereda de la instalación Hereda de la instalación Instalación inicial identificada como falsa basada en motivo de nivel de la instalación o lista de denegación
inapps_bots fake_device_parameters El algoritmo AppsFlyer detecta fraude
in_app_store_validation - Error en la validación de recibo de compras in-app. 
validation_inapps validation_rules

En base a una regla de validación definida manualmente

Retargeting

El raw data de Protect360 incluye instalaciones y sesiones fraudulentas de campañas de retargeting (conocidas como reatribuciones y re-engagements, respectivamente). Los datos se muestran utilizando los campos nombre del evento y tipo de conversión de retargeting. Se marcan como:

  • Instalación (se aplica al nombre del evento, pero no al tipo de conversión de retargeting)
  • Reatribución
  • Re-engagement
  • Reinstalación

El raw data de retargeting de Protect360 está disponible para bloqueos y fraude en tiempo real identificados luego de la atribución de la siguiente manera:

Reporte  Exportar datos API pull Data Locker
Instalaciones ✓* ✓* -
Instalaciones post-atribución
* Datos de re-engagement no disponibles

Corrección de atribución de instalaciones secuestradas

Para las instalaciones secuestradas, AppsFlyer bloquea la atribución a la red fraudulenta y, en su lugar, atribuye la última fuente de contribución legítima. 

Para las instalaciones secuestradas usa el campo rejected_reason_value para identificar al colaborador válido (fuente de medios), es decir el colaborador que debería haber recibido originalmente la atribución.

  • El campo rejected_reason_value se completa con contributor[1-3] u organic. Verifica los campos contributor[1-3] media source/partner para ver los detalles del colaborador y reconciliar.
  • Si los campos del colaborador no aparecen en tu reporte, están disponibles para que los agregues desde la página Exportar datos .

Nota: Cuando las instalaciones secuestradas se bloquean en tiempo real, las atribuciones correctas se muestran en los paneles de control y reportes de AppsFlyer (no solo en Protect360). Cuando las instalaciones secuestradas se identifican después de la atribución, las atribuciones correctas se muestran solo en el raw data de Protect360. 

¿Fue útil este artículo?