Cela peut ressembler à un bug : AV - Temps passé lecture sur un contenu affiche plus de minutes consommées que la durée réelle du contenu. La métrique fonctionne correctement — cet article explique pourquoi le calcul peut produire une valeur supérieure à la durée du contenu, et quels schémas rechercher.
Pourquoi le calcul peut dépasser la durée
AV - Temps passé lecture correspond à la somme d'av_playback_duration sur l'ensemble des événements d'une session où la lecture était active. Plusieurs schémas légitimes peuvent produire un temps cumulé supérieur à la durée nominale du contenu :
Schéma 1 : Relectures au sein d'une même session
Si un utilisateur atteint la fin d'une vidéo et la relit immédiatement, la seconde lecture s'ajoute au temps de lecture cumulé de la session, sans le réinitialiser. Une vidéo de 5 minutes regardée deux fois au cours d'une même session produit 10 minutes de temps de lecture sur un seul av_session_id.
Schéma 2 : Retours en arrière et revisionnages
Chaque fois que l'utilisateur revient en arrière et regarde de nouveau une section, les secondes revues sont comptées une nouvelle fois. Un utilisateur qui regarde trois fois le même chapitre au cours d'une session d'exploration produit un temps de lecture bien supérieur à la durée du contenu.
Schéma 3 : Plusieurs lectures avant un arrêt
Si l'utilisateur met en pause et reprend à plusieurs reprises sans que la session se ferme, chaque cycle lecture-pause-lecture continue d'accumuler du temps de lecture dans la même session.
Schéma 4 : Réallocation des durées en temps réel vs J+1
En temps réel, les durées sont placées sur l'événement suivant plutôt que sur celui auquel elles appartiennent — car au moment d'un événement, Piano ne sait pas encore combien de temps cet événement va durer. La routine d'optimisation quotidienne (exécutée vers 00:00 dans le fuseau horaire de votre site) déplace chaque durée vers l'événement qui lui correspond et fusionne les heartbeats consécutifs en une seule entrée.
L'implication concrète : Data Flow, Data Sharing et les requêtes Data Query en temps réel lisent dans la table de flux (avant la réallocation J+1) et différeront systématiquement des vues J+1 de l'interface — parfois de plusieurs heures par session lorsque de longues pauses ou des événements exclus sont en jeu. Pour obtenir des totaux comparables entre les deux côtés, interrogez les données J+1, ou tenez compte du mécanisme de réallocation dans vos traitements en aval.
Schéma 5 : Flux live
Pour un contenu live, la durée du contenu n'est pas une valeur fixe — elle augmente à mesure que le programme live se poursuit. Un spectateur qui rejoint tôt et reste pendant toute la diffusion accumule un temps de lecture qui dépasse instantanément la durée du contenu live capturé au départ.
Schéma 6 : Problèmes de marquage — événements av.heartbeat en double
Si votre lecteur ou votre intégration du SDK déclenche des heartbeats en double (par exemple, deux minuteurs de heartbeat actifs simultanément après un event listener mal configuré), chaque heartbeat ajoute de la durée. Inspectez le flux d'événements — si vous voyez des heartbeats se déclencher deux fois par intervalle, vous avez un bug de marquage.
Comment investiguer par vous-même
-
Filtrez sur une seule session présentant un temps de lecture anormalement élevé et inspectez ses événements. Si les événements montrent des relectures / retours en arrière légitimes, la métrique est correcte.
-
Vérifiez l'écart entre les timestamps des événements. Des heartbeats sains sont régulièrement espacés (généralement à la fréquence que vous avez configurée). Des intervalles doublés ou irréguliers indiquent un problème de marquage.
-
Comparez le temps réel avec l'historique du lendemain. Si le surcomptage n'est visible qu'en temps réel et disparaît le lendemain, c'est le traitement de fusion des heartbeats — pas un bug.
-
Pour un contenu live, utilisez
av_content_time_consumed(somme d'av_cursor_difference) plutôt que le temps de lecture lorsque vous souhaitez mesurer le temps unique consommé, car la différence de curseur ne compte pas deux fois les relectures.
Quand le chiffre est réellement erroné
Si, après ces vérifications, le temps de lecture reste gonflé et que le flux d'événements semble sain, la cause la plus probable est une intégration du lecteur qui envoie des heartbeats alors que le lecteur est en pause (le heartbeat continue d'accumuler av_playback_duration alors même que l'utilisateur ne regarde pas réellement). Comparez le temps de lecture à l'évolution d'av_position — si la position reste statique alors que le temps de lecture augmente, le lecteur signale mal son état.