How can we help?

Actualización de los datos y soporte de zona horaria

  • Actualización

En resumen: La actualización de los datos es el período entre la ocurrencia de los eventos y la disponibilidad de los datos en la plataforma.

Zonas horarias

TimeZoneMap.jpg

Actualización de los datos y soporte para zonas horarias específicas de la aplicación

Actualización de los datos

La plataforma AppsFlyer utiliza diferentes tipos de actualización de los datos, como diaria y en tiempo real. Se utilizan para presentar y hacer que los datos estén disponibles. Cada uno tiene su propia tasa de actualización de datos

Ejemplo: Índices de actualización de datos en el panel de control de Eventos:

  • Métrica KPI: en tiempo real
  • KPI promedio: diario

Zonas horarias

En la plataforma AppsFlyer, un día comienza a las 00:01 y termina a las 24:00. La zona horaria predeterminada es UTC (GMT). Puedes modificar el valor predeterminado estableciendo una zona horaria específica de la aplicación. 

Principios de fecha y zona horaria

La hora UTC es constante y no tiene horarios de verano/invierno. 

Hemisferios

  • Eastern: Time zones designated as UTC+ son las que se encuentran al este de UTC.
  • Occidental: las zonas horarias designadas como UTC son aquellas ubicadas al oeste de UTC.

Zona horaria específica de la aplicación

Puedes establecer una zona horaria específica de la aplicación. Esto significa que los datos se agrupan en días utilizando la hora local en lugar de UTC.

Ejemplo: 

Pekín: si la zona horaria específica de la aplicación se establece en Pekín (UTC +8), el día comienza a las 16:01 UTC y finaliza a las 16:00 UTC del día siguiente. 

Los Ángeles: si la zona horaria específica de la aplicación se establece en Los Ángeles (UTC -8), entonces el día comienza a las 08:01 UTC y finaliza a las 08:00 UTC del día siguiente.

Lineamientos de zona horaria

  • Alinea tu zona horaria específica de la aplicación con la zona horaria que establezcas para otros proveedores de servicios de atribución, como Google y Anuncios de Meta.
  • Si tienes más de una aplicación, la mejor práctica es configurar todas las aplicaciones en la misma zona horaria. Para ver la configuración de la zona horaria de una aplicación, ve a Configuración > Configuración de la aplicación. Sin embargo, asegúrate de crear plantillas separadas con el subdominio; no agregues manualmente el subdominio al ID de plantilla.
  • La mayoría de los reportes y las herramientas de extracción de datos admiten zonas horarias específicas de la aplicación. Esto incluye reportes de varias aplicaciones si todas las aplicaciones están configuradas en la misma zona horaria específica de la aplicación.

Procesamiento diario 

Algunos reportes y listas desplegables se procesan una vez al día, esto se conoce como actualización diaria o procesamiento diario. Estos son los principios del procesamiento diario:

  • Los datos que pertenecen a un día específico, por ejemplo, el lunes, se recopilan en un bucket. El día comienza a las 00:01 y termina a las 24:00 usando la hora específica de la aplicación.
  • Los datos recibidos hasta dos horas después de la medianoche se incluyen en el bucket del día. Los datos recibidos hasta las 02:00 del martes se incluyen en el bucket del lunes.
  • A las 02:00 hora local, el bucket se cierra y no se pueden agregar más datos a él.
  • Los datos recibidos después de las 02:00 se colocan en el siguiente bucket disponible, independientemente de la fecha del evento.
  • El procesamiento diario del bucket cerrado comienza dos horas después de la medianoche UTC, independientemente de la zona horaria específica de la aplicación. En aras de la simplicidad, afirmamos que el procesamiento comienza a la medianoche UTC. Esto significa que, dependiendo de la zona horaria local, el bucket debe esperar hasta la medianoche UTC antes de que comience el procesamiento.

Hemisferio oriental y zona horaria UTC:

mceclip9b.png

  • Pueden pasar hasta 11 horas desde que termina el día (hora local) hasta que comienza el procesamiento. Por ejemplo:
    • Pekín (UTC+8): se debe esperar ocho horas antes de que comience el procesamiento
    • Berlín (UTC +1): se debe esperar una hora antes de que comience el procesamiento
    • UTC: sin tiempo de espera.
  • Según el tipo de reporte, los datos están disponibles entre 8 y 20 horas después del inicio del procesamiento. Por ejemplo, los datos de Beijing están disponibles a partir de las 16:00 hora local. Los datos de Berlín están disponibles a partir de las 09:00.

Hemisferio occidental:

mceclip7a.png

  • Pueden pasar hasta 23 horas desde el momento en que finaliza el día hasta que comienza el procesamiento. Por ejemplo:
    • Los Ángeles (UTC -8): se debe esperar 16 horas antes de que comience el procesamiento
    • Nueva York (UTC -5): se debe esperar 19 horas antes de que comience el procesamiento
  • Según el tipo de reporte, los datos procesados están disponibles 8-20 horas después del inicio del procesamiento. Por ejemplo, los datos de Los Ángeles están disponibles a partir de las 00:01 hora local dos días después del evento. Los datos de Nueva York están disponibles a partir de las 03:01 hora local dos días después del evento.
  • Ejemplo:
    • Los eventos tienen lugar el lunes, hora de Los Ángeles (UTC -8), el procesamiento diario comienza a la medianoche UTC del martes. Esto es Los Ángeles, martes 16:01.
    • Ocho horas después, el miércoles a las 00:01, hora de Los Ángeles, el procesamiento de datos está completo. En términos prácticos, los datos del lunes están disponibles para los anunciantes de Los Ángeles cuando comienzan a trabajar el miércoles por la mañana.

Tipos de actualización de datos

 Calificación Disponibilidad Descripción 
Continua (es decir, en tiempo real) 15 a 60 minutos después de la ocurrencia del evento El procesamiento de datos es continuo. Este término lo distingue del procesamiento por lotes que tiene lugar, por ejemplo, a diario. Los datos continuos se actualizan con un retraso de 15 a 60 minutos después de que se produzca un evento de la siguiente manera: 
  • Atribuciones (instalaciones, reatribuciones y reengagements): de 15 a 30 minutos.
  • Eventos in-app: de 30 a 60 minutos.
Reporte en tiempo real Pocos minutos después de solicitar un reporte Los datos se actualizan en minutos a partir del momento en que ocurre el evento.
Diaria

Zona UTC: 8 horas después de la medianoche UTC del día del evento

Hemisferio oriental: 9-20 horas después de la medianoche UTC del día del evento

Hemisferio occidental: 21-32 horas después de la medianoche UTC del día del evento

  • Los datos se procesan diariamente.
  • La disponibilidad de estos datos difiere según la zona horaria específica de la aplicación.
  • Los tipos de datos que no admiten zonas horarias específicas de la aplicación usan la hora UTC.
  • Los tiempos de disponibilidad de los datos pueden variar de un día a otro o según se indique en artículos específicos.
Final del día Diariamente al final del día, zona horaria específica de la aplicación Al final del día calendario. Es decir, a las 00:01 del día siguiente. Ejemplo: los datos registrados el lunes están disponibles a partir del martes a las 00:01, independientemente de la zona horaria específica de la aplicación.
Intradía (durante el día) Cada 4 horas en promedio
  • Los datos se recopilan seis veces al día, en promedio cada cuatro horas.
  • Los datos de clics e impresiones de SRN para clientes sin ROI360 se recopilan 3 veces al día.
  • Los datos de ETL de costos se envían 4 veces al día, de media cada 6 horas.
Ingresos por publicidad Depende del tipo de integración y del reporte Consulta el artículo sobre los ingresos por publicidad para obtener más información.
PBA diaria Los datos están disponibles 11-12 horas después del final del día UTC.
  • El panel de control y los reportes de PBA se actualizan diariamente usando la zona horaria UTC.
  • El procesamiento diario incluye los eventos recibidos durante el día anterior.
  • Durante los primeros siete días posteriores a la conversión, la PBA puede identificar eventos adicionales relacionados con una conversión. Esto puede cambiar los KPI y la atribución de fuentes de medios de forma retroactiva.
  • Después de siete días, las rutas se congelan y no se producen más cambios.
  • Los reportes de raw data incluyen el campo final_data. Cuando los datos verdaderos son definitivos.
  • Ejemplo detallado
SKÁN Consulta sobre el tiempo desde la hora de llegada del postback hasta la disponibilidad de los datos en los paneles de control y reportes.

Los postbacks recibidos en un día determinado se procesan al final del día UTC. Los datos están disponibles antes de las 11:00 UTC del día siguiente. Lo que significa que los postbacks de iOS recibidos el lunes están disponibles en los reportes y paneles de control el martes por la mañana. Del mismo modo, los postbacks a los partners se envían el martes por la mañana. 

La fecha de instalación en los reportes y paneles de control se deriva de la hora de llegada del postback como se detalla en el artículo de SKAN Conversion Studio

Data Locker diario Los datos están disponibles entre 8 y 10 horas después del final del día UTC 
  • Los datos se procesan diariamente.
  • Los datos están contenidos en la carpeta h=23 en la fecha del evento. Por ejemplo, los datos de los lunes están disponibles en la carpeta h=23 los martes a las 08:00–10:00 UTC.
  • Los datos de SKAN pueden llegar un poco más tarde (ver información de SKAN arriba).

Tasas de actualización de datos y soporte de zona horaria

Datos relacionados  Cómo se presenta  Tasa de actualización de los datos
(Consulta la sección anterior para conocer la clave de las tasas)
Visualizaciones de datos usando la zona horaria específica de la aplicación
Instalaciones KPI

Continua

Live Alerts

  • Las alertas de Protect360 se actualizan a la hora UTC diaria.
    • Se actualiza diariamente a las 16:00 UTC
Sesiones, clics, impresiones, usuarios fieles KPI
  • Enlaces de atribución: Continua
  • SRN: Intradía
Eventos in-app de ingresos KPI Continua
Ingresos por publicidad KPI Ingresos por publicidad
Gasto publicitario (costo) KPI
  • Enlace de atribución: Continua (máximo hasta 2 horas después del clic)
  • API: Intradía
  • Procesamiento de gastos publicitarios Hasta 4 horas después de la ingestión
Desinstalar KPI Diaria. AppsFlyer hace ping a las tiendas de aplicaciones cada 24 horas. La hora del evento de la desinstalación representa el momento en que AppsFlyer lanzó la notificación push que no se ve y descubrió que la aplicación se desinstaló. Esta no es la hora real de la desinstalación. .
Eventos in-app en la interfaz Lista desplegable

Los nombres de eventos in-app que se muestran en las listas desplegables se actualizan diariamente. 

Esto no afecta la tasa de actualización de los datos en sí. 

Ejemplos: listas desplegables de eventos in-app en Push API, paneles de control y audiencias.

Panel de vista general  Página Continua
Panel de control de Protect360 Página  Diaria (1)
Panel de control de SKAN Página Diaria .
Página de actividad  Página
  • KPIs Continua
  • Promedios: A medianoche de la zona horaria específica de la aplicación

Excepción: Los datos MAU son UTC

Página de eventos  Página Continua
(fila en blanco)    (Esta fila se ha dejado en blanco intencionalmente)  
Retención Página Los KPI de retención están disponibles con granularidad diaria y semanal. La actualización de los datos para cada uno es diferente. 
  • KPI regulares:
  • KPI semanales de retención: La semana comienza el lunes y termina el domingo. La retención se calcula el lunes a las 12:00 UTC. La falta de soporte para la zona horaria específica de la aplicación para el KPI semanal resulta en una diferencia insignificante. 

Diario:

Semanal: x

Cohorte Página Continua (2)
Panel de control personalizado Página Continua (3)
Audiencias Página
  • Las actualizaciones se envían a los partners cada 24 horas.
  • La base de usuarios se actualiza diariamente y almacena hasta 90 días de datos del dispositivo
Página de información del SDK Página Diaria  .
Exportar datos Página

Continua

 

Excepciones a tener en cuenta:

  • Raw data de ingresos por publicidad: Diaria
  • Protect360:
    • Reportes agregados:
    • Raw data bloqueado: Continua
    • Final del día
  • Eventos in-app orgánicos: Actualización con un desfase de varias horas.
API Pull API  La actualización de los datos de API Pull es la misma que la de Datos exportados.

Predeterminado: UTC

 

Pivot  Página Diaria

KPI semanales de retención: x

API maestra  API Diaria  (3)
Casillero de datos API Como se especifica en el artículo de Data Locker. 

.

UTC

Devoluciones de mensajes API Continua N/D
API Push API Continuo (4)

Oriental: las zonas horarias designadas como UTC+ son aquellas ubicadas al este de UTC.
 

Ambos

Eventos in-app de servidor a servidor API Continua N/D

Notas:

(1) Todas las aplicaciones para las que el usuario tenga permiso deben usar la misma zona horaria específica de la aplicación. De lo contrario, la zona horaria vuelve a ser UTC.

(2) Consulta en Rasgos y limitaciones de la cohorte cuándo la zona horaria volverá a ser UTC.

(3) Todas las aplicaciones seleccionadas deben utilizar la misma zona horaria específica de la aplicación. De lo contrario, la zona horaria vuelve a ser UTC.

(4) Los datos del reporte SKAN estarán disponibles todos los días entre las 08:00 y las 10:00 UTC.

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.


Share article: