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
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
- Oriental: las zonas horarias designadas como UTC+ son aquellas ubicadas 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.
- 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:
- 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:
- 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
Tasa | 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:
|
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 |
|
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 |
|
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. |
|
SKAN |
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 |
|
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 | ✓ |
Sesiones, clics, impresiones, usuarios fieles |
KPI |
|
✓ |
Eventos in-app de ingresos |
KPI |
Continua |
✓ |
Ingresos por publicidad |
KPI |
Ingresos por publicidad |
✓ |
Gasto publicitario (costo) |
KPI |
|
✓ |
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. |
x |
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 control general |
Página | Continua | ✓ |
Panel de control de Protect360 |
Página | Diaria | ✓ (1) |
Panel de control de SKAN |
Página | Diaria | x |
Página de actividad |
Página |
|
✓ 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.
|
Diario: ✓ Semanal: x |
Cohorte |
Página |
Continua |
✓ (2) |
Panel de control personalizado |
Página | Continua |
✓ (3) |
Audiencias |
Página |
|
✓ |
Página de información del SDK |
Página |
Diaria |
x |
Live Alerts |
Página |
|
✓ |
Exportar datos |
Página |
Continua
Excepciones a tener en cuenta:
|
✓ |
API Pull |
API | La actualización de los datos de API Pull es la misma que la de Datos exportados. |
✓ Predeterminado: UTC
|
Pivote |
Página |
Diaria |
✓ KPI semanales de retención: x |
API maestra |
API |
Diaria |
✓ (3) |
Data Locker |
API | Como se especifica en el artículo de Data Locker. |
x UTC |
Postbacks |
API |
Continua |
N/A |
API Push |
API | Continua |
✓ Ambos |
Eventos in-app de servidor a servidor |
API |
Continua |
N/A |
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. |