Actualisation des données et prise en charge des fuseaux horaires

Recommandé pour

Marketeurs Marketeurs Développeurs Agences Réseaux publicitaires

Dernière mise à jour : 2 juillet 2024 11:07

En bref : L’actualisation des données représente le temps qui s'écoule entre un événement et la disponibilité de ses données sur la plateforme.

Fuseaux horaires

Actualisation des données et prise en charge des fuseaux horaires spécifiques à une application

Actualisation des données

La plateforme AppsFlyer fonctionne avec différents types d’actualisation des données, exemple : actualisation quotidienne ou en temps réel. L’actualisation sert à présenter les données, et à définir leur disponibilité. Chaque type possède son propre taux d’actualisation des données.

Exemple : Taux d’actualisation des données dans le tableau de bord des événements :

KPI mesuré : en temps réel
KPI moyen : quotidien

Fuseaux horaires

Pour la plateforme AppsFlyer, une journée commence à 00:01 et se termine à 24:00. Le fuseau horaire par défaut est l’UTC (GMT). Vous pouvez modifier la valeur par défaut en définissant un fuseau horaire spécifique à l'app.

Fonctionnements de la date et du fuseau horaire

L'heure UTC est invariable sur l’année et n'a pas d'heure d'été/hiver.

Hémisphères

Oriental Les fuseaux horaires désignés par UTC + sont situés à l'est de l'UTC.
Occidental Les fuseaux horaires désignés par UTC sont situés à l'ouest de l'UTC.

Fuseau horaire spécifique à l'app

Vous pouvez définir un fuseau horaire spécifique à une application. Les données sont alors regroupées en jours, en utilisant l'heure locale au lieu de l'UTC.

Exemple :

Pékin Si le fuseau horaire spécifique à l'app est défini sur Pékin (UTC +8), alors la journée commence à 16:01 UTC et se termine à 16:00 UTC le jour suivant.

Los Angeles : Si le fuseau horaire spécifique à l'app est défini sur Los Angeles (UTC -8), alors la journée commence à 08:01 UTC et se termine à 08:00 UTC le jour suivant.

Consignes à propos des fuseaux horaires

Alignez le fuseau horaire spécifique à votre app avec celui que vous avez défini pour les autres fournisseurs de services d'attribution, comme Google et Meta Ads.
Si vous possédez plusieurs apps, nous vous conseillons de régler toutes vos applications sur le même fuseau horaire. Pour afficher les paramètres de fuseau horaire d'une app, allez dans Paramètres > Paramètres de l'app.
La plupart des rapports et outils d'extraction des données prennent en charge les fuseaux horaires spécifiques aux apps. Cela inclut les rapports multi-applications lorsque toutes les apps sont définies sur le même fuseau horaire spécifique à l'app.

Traitement quotidien

Il existe des rapports et listes déroulantes qui sont traités une fois par jour, c'est ce que l'on appelle l’actualisation quotidienne (ou le traitement quotidien). Voici comment fonctionne le traitement quotidien :

Les données concernant un jour particulier, par exemple le lundi, sont collectées dans un compartiment. La journée commence à 00:01 et se termine à 24:00 (heure spécifique à l'app).
Les données reçues jusqu'à deux heures après minuit sont comprises dans le compartiment du jour. Les données reçues jusqu'à 2 h le mardi sont incluses dans le compartiment du lundi.
À 02:00 heure locale, le compartiment est fermé et aucune autre donnée ne peut plus y être ajoutée.
Les données reçues après 02:00 sont placées dans le compartiment disponible suivant, quelle que soit la date de l'événement.
Le traitement quotidien du compartiment fermé commence deux heures après minuit UTC, quel que soit le fuseau horaire spécifique à l'app. Pour simplifier les choses, nous annonçons que le traitement commence à minuit UTC. Ce qui signifie que, selon le fuseau horaire local, le compartiment doit attendre minuit UTC avant de démarrer le traitement des données.

Hémisphère oriental et fuseau horaire UTC :

Il peut s’écouler jusqu'à 11 heures entre la fin de la journée (heure locale) et le démarrage du traitement. Exemple :
- Pékin (UTC+8) : il faut attendre huit heures avant le début du traitement
- Berlin (UTC +1) : il faut attendre une heure avant le début du traitement
- UTC : aucune attente
Selon le type de rapport, les données sont disponibles entre 8 et 20 heures après le démarrage du traitement. Par exemple, les données de Pékin sont disponibles à compter de 16:00, heure locale. Les données de Berlin sont disponibles à partir de 9:00.

Hémisphère occidental :

Il peut s'écouler jusqu'à 23 heures entre la fin de la journée et le début du traitement. Exemple :
- Los Angeles (UTC -8) : il faut attendre 16 heures avant le début du traitement
- New York (UTC -5) : il faut attendre 19 heures avant le début du traitement
Selon le type de rapport, les données traitées sont disponibles entre 8 et 20 heures après le démarrage du traitement. Par exemple, les données de Los Angeles sont disponibles à 00:01 heure locale, deux jours après l'événement. Les données de New York sont disponibles à 03:01 heure locale, deux jours après l'événement.
Exemple :
- Les événements se produisent le lundi, heure de Los Angeles (UTC -8), le traitement quotidien commence à minuit UTC le mardi. C'est à dire le mardi 16:01 pour Los Angeles.
- Huit heures plus tard, soit le mercredi à 00:01 heure de Los Angeles, le traitement des données est terminé. Concrètement, les données du lundi sont accessibles aux annonceurs de Los Angeles lorsqu'ils démarrent le mercredi matin.

Types d'actualisation des données

Taux	Disponibilité	Description
Continu (c'est-à-dire en temps réel)	15 à 60 minutes après l'événement	Le traitement des données est continu. Ce terme le distingue du traitement par lots qui a lieu, par exemple, quotidiennement. Les données continues sont mises à jour avec un décalage allant de 15 à 60 minutes après l’événement : Attributions (installations, réattributions et réengagements) : 15–30 minutes. Évènements in-app : 30–60 minutes.
Rapport en temps réel	Quelques minutes après avoir demandé le rapport	Les données sont mises à jour quelques minutes après l'événement.
Quotidien	Zone UTC : 8 heures après minuit UTC le jour de l'événement Hémisphère oriental : 9 à 20 heures après minuit UTC le jour de l'événement Hémisphère occidental : 21 à 32 heures après minuit UTC le jour de l'événement	Les données sont traitées quotidiennement La disponibilité de ces données varie en fonction du fuseau horaire spécifique à l'app Les types de données qui ne prennent pas en charge les fuseaux horaires spécifiques aux apps utilisent l'heure UTC L’attente avant la mise à disposition des données peut varier, si elle n’est pas indiquée dans des articles spécifiques
EOD	Chaque fin de journée du fuseau horaire spécifique à l'app	À la fin du jour civil. C'est-à-dire 00:01 le jour suivant. Exemple : Les données enregistrées le lundi sont disponibles à compter du mardi à 00:01, quel que soit le fuseau horaire spécifique à l'app.
Intra-jour (pendant la journée)	Toutes les 4 heures en moyenne	Les données sont collectées six fois par jour, en moyenne toutes les quatre heures. Les données SRN des clics et impressions pour les clients qui n’ont pas ROI360, sont collectées 3 fois par jour. Les données de coût ETL sont transmises 4 fois par jour, en moyenne toutes les 6 heures.
Revenus publicitaires	Dépend du type d'intégration et du rapport	Cf l'article sur les revenus publicitaires pour en savoir plus.
PBA quotidienne	Les données sont disponibles 11 à 12 heures après la fin de la journée UTC.	Le tableau de bord et les rapports PBA sont mis à jour quotidiennement en utilisant le fuseau horaire UTC. Le traitement quotidien inclut les événements reçus la veille. Au cours des sept premiers jours post-conversion, la PBA peut identifier d’autres événements liés à une conversion. Ceci peut donc modifier après coup les KPI et l'attribution de la source média. Au bout de sept jours, les chemins sont gelés et plus aucun changement n'a lieu. Les rapports de données brutes incluent le champ final_data. Quand les données true sont définitives. Exemple détaillé
SKAN	Voir les délais entre l’heure d’arrivée des postbacks et la disponibilité des données dans les tableaux de bords et rapports.	Les postbacks reçus un jour donné sont traités en fin de journée UTC. Les données sont disponibles à 11:00 UTC le jour suivant. Les postbacks iOS reçus le lundi sont donc disponibles dans les rapports et les tableaux de bord le mardi matin. De même, les postbacks sont envoyés aux partenaires le mardi matin. La date d'installation dans les rapports et les tableaux de bord correspond à l'heure d'arrivée du postback, comme indiqué dans cet article du studio de conversion conversion SKAN.
Data Locker quotidien	Les données sont disponibles de 8 à 10 heures après la fin de la journée UTC	Les données sont traitées quotidiennement. Les données sont contenues dans le dossier h=23 correspondant à la date de l'événement. Exemple : les données du lundi comprises dans le dossier h=23 du lundi, sont disponibles le mardi de 8:00 à 10:00 UTC. Les données SKAN peuvent arriver un peu plus tard (voir les infos SKAN ci-dessus).

taux d’actualisation des données et prise en charge des fuseaux horaires

Données connexes	Présentation	Taux d'actualisation des données (cf la section précédente pour le détail des taux)	Affichage des données dans le fuseau horaire spécifique à l'app
Installations	KPI	En continu	✓
Sessions, clics, impressions, utilisateurs fidèles	KPI	Liens d'attribution : En continu SRN : Dans la journée	✓
Événements in-app / revenus	KPI	En continu	✓
Revenus publicitaires	KPI	Revenus publicitaires	✓
Dépenses publicitaires (coût)	KPI	Lien d'attribution : En continu (maxi 2 heures après le clic) API : Dans la journée Ingestion des dépenses publicitaires : Jusqu'à 4 heures après l'ingestion	✓
Désinstallations	KPI	Quotidiennement. AppsFlyer envoie un ping aux app stores toutes les 24 heures. L'heure de l'événement de désinstallation correspond au moment où AppsFlyer a envoyé un ping à la notification push silencieuse, et a découvert que l'app était désinstallée. Il ne s'agit pas de l'heure réelle de la désinstallation.	x
Événements in-app dans l'interface	Liste déroulante	Les noms des événements in-app affichés dans les listes déroulantes sont mis à jour quotidiennement. Cela n’impacte aucunement le taux d’actualisation des données. Exemples : Listes déroulantes des événements in-app dans l'API Push, les tableaux de bord et les audiences.	✓
Vue d'ensemble du tableau de bord	Page	En continu	✓
Tableau de bord Protect360	Page	Quotidien	✓ (1)
Tableau de bord SKAN	Page	Quotidien	x
Page d'activité	Page	Les KPI : En continu Moyennes : À minuit, dans le fuseau horaire spécifique à l'app	✓ Exception : Les données MAU sont en UTC
Page d'évènements	Page	En continu	✓
(ligne vide)		(Cette ligne a été laissée vide volontairement)
Rétention	Page	Les KPI de rétention sont disponibles avec une granularité quotidienne et hebdomadaire. L’actualisation des données est différente pour chacun. KPI de rétention quotidiens : Quotidien KPI de rétention hebdomadaires : La semaine commence le lundi et se termine le dimanche. La rétention est calculée le lundi à 12:00 UTC. L'absence de prise en charge du fuseau horaire spécifique à l'app pour les KPI hebdomadaires entraîne une différence imperceptible.	Quotidien : ✓ Hebdomadaire : x
Cohorte	Page	En continu	✓ (2)
Tableau de bord personnalisé	Page	En continu	✓ (3)
Audiences	Page	Les mises à jour sont envoyées aux partenaires toutes les 24 heures. La base d'utilisateurs est mise à jour quotidiennement, elle détient jusqu'à 90 jours de données sur l'appareil	✓
Page d'informations du SDK	Page	Quotidien	x
Alertes en direct	Page	KPI réguliers : utilisent le fuseau horaire spécifique à l'app sont traités à minuit sont transmis à 07:00 heure locale Les alertes Protect360 sont mises à jour quotidiennement en UTC.	✓
Données d'exportation	Page	En continu Les exceptions : Données brutes des revenus publicitaires : Quotidien Protect360 : Rapports agrégés : Quotidien Données brutes bloquées : En continu Données brutes post attribution : Quotidien Evènements in-app organiques : Mise à jour avec un décalage de plusieurs heures.	✓
API Pull	API	L’actualisation des données de l'API Pull est la même que celle des données d'exportation.	✓ Par défaut UTC
Tableau croisé	Page	Quotidien	✓ KPI de rétention hebdomadaires : x
API principale	API	Quotidien	✓ (3)
Data Locker	API	Comme indiqué dans l'article Data Locker.	x UTC
Postbacks	API	En continu	N/A
API Push	API	En continu	✓ Les deux
Evénements in-app de serveur à serveur	API	En continu	N/A
Remarques : (1) Toutes les apps autorisées à l'utilisateur doivent utiliser le même fuseau horaire spécifique à l'app. Dans le cas contraire, le fuseau horaire revient en UTC. (2) Voir les Caractéristiques et limitations de la cohorte lorsque le fuseau horaire revient en UTC. (3) Toutes les apps sélectionnées doivent utiliser le même fuseau horaire spécifique à l'app. Dans le cas contraire, le fuseau horaire revient en UTC.