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.
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 por descarga, API y Data Locker (bucket S3) se describen en las siguientes secciones.
- La retención de reportes históricos de raw data es de hasta 90 días, dependiendo de la herramienta de reporte y el origen del raw data.
Tipos de reportes
Tipos de reportes de raw data de Protect 360
| Reporte | Descripción |
|---|---|
| Instalaciones |
Los reportes incluyen:
|
| 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:
|
| Eventos in-app post-atribución |
Los reportes incluyen eventos in-app:
|
| 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. Nota: Si no se identifica ningún evento de fraude posterior a la atribución para el intervalo de fechas seleccionado, el reporte se muestra vacío.
-
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:
|
||||
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:
- 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.
- Selecciona el reporte Protect360 y reglas de validación para descargar.
O
- En panel de control de AppsFlyer, ve a Datos exportados.
- 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 de un usuario administrador.
- Ve al Reporte > Acceso a la API.
Se abre la página de Pull API. - En la sección de reportes de fraude de Protect360, selecciona la llamada de Pull API necesaria.
- Completa los parámetros según sea necesario. En la tabla siguiente se enumeran los parámetros.
- 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 | Sí |
| api_token | Recupera la clave del dashboard. Ve a Reporte > Acceso a la API. Solo un usuario administrador puede recuperar el token de la API. | String | Sí |
| desde |
Inicio del rango de fechas:
|
AAAA-MM-DD | Sí |
| a |
Fin del rango de fechas:
|
AAAA-MM-DD | Sí |
| 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: |
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 |
Data Locker
Data Locker escribe raw data en un bucket AWS S3.
Consultar la lista de reportes disponibles de Protect360.
Consultar las instrucciones de configuración del Data Locker.
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 |
| input_validation | Nombre de fuente de medios no válido |
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.