Calcul du taux de rebond dans l’application Roku

Introduction

Le taux de rebond joue un rôle très crucial en termes de mesure de la croissance du canal. Un taux de rebond élevé peut indiquer qu’il existe un besoin d’améliorations dans le flux de lancement de l’application.

Sur le Web, le taux de rebond fait référence au pourcentage d’utilisateurs qui visitent une page et quittent sans autre interaction. De même, dans les applications ROKU, le taux de rebond est le pourcentage d’utilisateurs qui lance l’application mais n’a regardé ni lu de contenu.

Taux de rebond Roku

Étapes d’intégration

• Intégrez l’API Analytics à l’aide du composant «RourlTransfer».
• Envoyer le visiteur Événement sur le lancement de l’application.
• Envoyer le téléspectateur Événement sur le premier flux vidéo lu.
• Rassemblez les données d’analyse et calculez le taux de rebond avec la formule du taux de rebond (1- téléspectateurs / visiteurs), et notre analyse de taux de rebond que vous pouvez trouver ci-dessus la conclusion de ce billet de blog.

Formule de taux de rebond

Voici la formule simple pour calculer le taux de rebond de l’application Roku.

Taux de rebond = (1- téléspectateurs / visiteurs)

Visiteurs: Un visiteur est un utilisateur qui a ouvert ou lancé une application mais n’a peut-être pas diffusé de contenu. Les visiteurs sont mesurés au niveau du compte (un seul compte peut être associé à plusieurs appareils).

Téléspectateurs: Une visionneuse est un utilisateur qui a diffusé du contenu dans l’application. Un visiteur peut également être considéré comme un spectateur, mais tous les visiteurs ne seront pas considérés comme des téléspectateurs. Les téléspectateurs sont également mesurés au niveau du compte.

Roku fournit la formule ci-dessus pour le calcul du taux de rebond, mais si nous comparons le taux de rebond calculé via notre analyse (propre analyse API ou tiers comme GA4, etc.) avec Roku Analytics, le Une différence significative est mesurée dans les nombres.

Pourquoi les écarts entre le Roku et les données d’analyse de taux de rebond interne

Même si votre logique est proche de Roku, il existe plusieurs différences subtiles dans la façon dont Roku définit probablement un «spectateur» qui pourrait expliquer l’écart:

1. Calcul des événements de la visionneuse

• Roku considère une visionneuse si l’utilisateur regarde un flux vidéo pendant une durée minimale (5 secondes ou plus) plutôt que de simplement commencer la lecture.

2. Manipulation des sessions

• Roku fusionne plusieurs applications se lance en une seule session si elles se produisent près les unes des autres (par exemple, relancez-vous en quelques minutes).
• Si vous enregistrez un «visiteur» à chaque lancement, mais que Roku fusionne les sessions, votre ratio Viewer / Visitor pourrait changer.

3. Compte vs niveau de l’appareil

• La mesure au niveau du compte de Roku signifie que si un utilisateur se lance sur plusieurs appareils (ou réinstallations), ils peuvent être comptés différemment.
• En outre, Roku compte un seul compte de visiteur / vision si le même utilisateur (lié à un ID Roku) utilise l’application avec plusieurs périphériques Roku.

4. Identifier et supprimer les dénombrements de tests, de bots et de périphériques de trafic interne

• Roku identifie les dispositifs de tests ou d’AQ et le trafic suspect. Vos analyses peuvent les inclure.

5. Différences de type de temps

• L’heure de rapport d’événement de Roku pourrait s’aligner avec l’UTC et couper différemment de votre calendrier d’analyse interne. Le nombre de téléspectateurs pourrait différer si une session traverse les limites de rapport.

Recommandations pour s’aligner plus près des chiffres de Roku

1. Faire correspondre la définition de la lecture à la logique probable de Roku
   • Le visiteur L’événement devrait se déclencher une fois par session d’application lors du premier lancement et après une période d’inactivité de 30 minutes.
   • Ne comptez pas plusieurs lancements dans un peu de temps comme séparé visiteurs.
   • Envoyez le «téléspectateur”Événement uniquement après le changement de l’état du joueur en jeu et un temps de montre minimum (1 à 5 secondes).
2. Manipuler la fusion de session
   • Ajoutez une logique pour gérer les sessions. Si l’utilisateur est inactif sur l’application pendant plus de 30 minutes, alors démarrez une nouvelle session plutôt que de compter chaque lancement d’application.
3. Filtrez des dispositifs internes
   • Ajoutez le filtre du côté analytique, par lequel il ne peut pas ajouter de compte de périphériques internes ou connus via des ID de périphérique et des adresses IP.
4. Différent dans les fuseaux horaires
   • Assurez-vous que votre fuseau horaire de rapport est le même que le fuseau horaire standard de Roku.
5. Comparez les identifiants de session bruts
   • Si possible, enregistrez les identifiants de session et comparez un échantillon de jeu avec les journaux de Roku (via le partenaire Roku PII-SAFE Matching) pour voir où les comptes divergent.

Pourquoi cela aide:

• Roku filtre probablement:
  • Des flux qui ne parviennent pas à commencer.
  • Utilisateurs qui sortent avant la première image.
  • Plusieurs lectures dans la même session (seul le premier compte pour le taux de rebond).

Conclusion

Le taux de rebond est une partie cruciale de l’analyse. Il aide à comprendre le comportement de l’utilisateur et à réduire les premières sorties. En suivant le taux de rebond, nous pouvons trouver les points faibles de notre application. Le calcul aide à développer des applications mieux expérimentées en termes UX / UI et à améliorer le taux de rétention.