Forums Développement Multimédia

Les formations Mediabox
Les formations Mediabox

Principes d'Analyse d'Audience

Par draad (Pradeilles Thomas), le 11 janvier 2013

Ici, nous parlerons d'une méthode de collecte et traitement d'informations sur l’expérience des utilisateurs au sein de vos jeux et applications en tout genre. Nous verrons des exemple pour interpréter et jouer avec celles ci afin d’améliorer et orienter vos développement.

Prérequis

- Savoir créer une base de données sql et communiquer avec celle ci.

Introduction

Avis préalable : Ce tutoriel est tiré de mon expérience de développement de jeux mobiles, j'utiliserais donc pour simplifier le langage associé à ces deux mondes, mais ces principes peuvent être appliqués à tous les langages, toutes les plateformes et à tous les types d'applications.

Définition

L'analyse d'audience est un outil qui permet de récolter à distance des informations sur vos applications, ses utilisateurs et la façon dont ces derniers se comportent au sein de votre application. La collecte et l'analyse des informations ainsi collectées va permettre de tirer des conclusions sur le comportement de votre application et des ses utilisateur, et permettra entre autre d'améliorer votre application lors des prochaines mises à jour.

On ne peut pas récolter n'importe quel type de données sur les utilisateurs sans leur accord ! Selon les pays, des lois régissent ses activités. Renseignez vous correctement avant de récolter des informations personnelles. Dans ce tutoriel, nous ne récolterons donc aucune information personnelle sur l'utilisateur.

Ici nous allons créer un système personnalisé, mais il existe des logiciels a licence professionnelle pour réaliser ce genre de d'analyse d'audience, comme par exemple :

Mise en place

Je ne vais pas expliquer ici comment créer une base de données, ni comment communiquer avec celle ci, vous trouverez plusieurs tutoriels très bien fait expliquant tout cela sur le site Mediabox ou un peu partout sur le net.

Voici la façon dont j'ai procédé:

Création de la base de données

Une base de données comprenant un champ pour chaque information que vous souhaitez collecter.

Le script php

Ce script va nous permettre de dialoguer entre la base de données et l'application :

<?php 

$hostname = "monHost";
$user = "monId";
$bd = "monBaseDeDonnees";
$password = "monMotDePasse";
$connexion = mysql_connect($hostname, $user, $password) or die(print_r($req->errorInfo()));

$TelemetryVar = mysql_real_escape_string($_GET['data']);

try
{
        $pdo_options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION; 
        $bdd = new PDO('mysql:host=$hostname;dbname=$bd', '$user', '$password');
 
        $reponse = $bdd ->prepare('SELECT '.$TelemetryVar.' FROM maTableTelemetrique');
	$reponse->execute()or die(print_r($req->errorInfo()));


	while ($donnees = $reponse -> fetch())
        { 	 
                echo ($donnees["$TelemetryVar"]);

		$X = $donnees["$TelemetryVar"] + 1;

		$reponse = $bdd ->prepare('UPDATE maTableTelemetrique SET '.$TelemetryVar.'=?');
		$reponse->execute(array($X));
	}
 
} 
 
catch (Exception $e) 
{ 
        die('Erreur : ' . $e->getMessage()); 
} 


?>

J'ai choisis de rester très simple, et de lui transmettre seulement le nom d'un champ de ma base de données, il va ensuite lire ce champ et lui ajouter simplement un +1 pour me signifier qu'un utilisateur a réalisé telle action.

La classe TelemetryDispatcher

Dans mon application, je crée une classe TelemtryDispatcher qui me servira a communiquer au script php les données que je souhaite stocker dans la base de donnée :

package classes
{
	import flash.events.Event;
	import flash.events.IOErrorEvent;
	import flash.net.*;



	public class TelemetryDispatcher
	{
		
		public static var CHAMP_BDD_1			:String = 'CHAMP_BDD_1';
		public static var CHAMP_BDD_2			:String = 'CHAMP_BDD_2';
		public static var CHAMP_BDD_3			:String = 'CHAMP_BDD_3';

		
		public static function sendTelemetry (variableCible:String):void
		{	
			var urlLoader:URLLoader = new URLLoader ();
			var urlRequest:URLRequest = new URLRequest ("url_de_mon_script_telemetrique.php?data=" + variableCible);
				
			urlLoader.addEventListener(Event.COMPLETE, onTelemetryComplete);
			urlLoader.addEventListener(IOErrorEvent.IO_ERROR, onLoadError);
			urlLoader.load(urlRequest);	
	
		}
		
		private static function onLoadError (e:IOErrorEvent):void
		{
			trace ('error telemetry' + e.errorID);
		}
		
		private static function onTelemetryComplete (e:Event):void
		{
			trace ('Telemetry Sent' + e.currentTarget);
		}
	}
}

Ensuite, il ne vous reste plus qu'à ajouter les conditions qui vous intéressent dans le code de votre application pour utiliser la classe.

Le vif du sujet

Comprendre ses besoins

Récolter des données, c'est bien, mais quelles données ?

Au fond, toutes les données sont intéressantes a récolter, le nombre de clic sur tel bouton, si les joueurs jouent plutôt avec ou sans le son, en telle ou telle langue, combien de fois ils ont cliqué sur tel objet du magasin et combien de fois ils l'ont acheté, etc… mais chaque type de donnée va devoir être analysée pour que vous puissiez en tirer bénéfice.

Je vous conseille donc dans un premier temps, de sortir un bon vieux papier accompagne de votre plus fidèle bic afin de réfléchir efficacement à ce dont vous avez réellement besoin et de sélectionner les données utiles les plus pertinentes.

N’hésitez pas à observer le plus d’évènements possible, même si vous n'utilisez pas les données pour le moment, stockez les dans une table séparée afin de ne pas polluer votre sélection, elles pourraient bien s’avérer très utiles plus tard !

Des points stratégiques

Comprendre ses besoins est difficile, car au final, on aurait tendance à avoir besoin de tout. Cependant, si vous découpez le flux d'évolution de votre utilisateur, vous allez pouvoir remarquer des point stratégiques cruciaux qu'il va falloir observer, en général ces points sont le tutoriel, le magasin, et la courbe de progression des joueurs. Mais chaque besoin est à estimer en fonction de vos force et faiblesses, de vos visées commerciales et du temps que vous êtes prêts à investir dans l'analyse des résultats. Voici un exemple concret tiré de notre jeu :

Prenons la structure du jeu et simplifions la pour comprendre le flux utilisateur associe a l'analyse d'audience:

      1) L'utilisateur installe l'application           -> nombre d'installation
      2) L'utilisateur entre sont pseudo                -> nombre d'utilisateur unique
      3) L'utilisateur entre dans le menu d’accueil     -> pas de d'analyse
      3) L'utilisateur lance une partie                 -> nombre de parties jouées
      4) L'utilisateur progresse dans le tutoriel       -> chaque étape du tutoriel est observée
      5) L'utilisateur fini sa partie                   -> pas de d'analyse
      6) L'utilisateur complète un objectif             -> chaque objectif est observe
      7) L'utilisateur retourne dans le menu d’accueil  -> pas de d'analyse

Les faux amis

Faites très attention lorsque vous observez un évènement qui peut être réalisé plusieurs fois par le même joueur ! En effet, si un joueur pour une raison ou une autre effectue 500 fois cette action, alors que la majorité des joueurs ne le fait qu'une seule fois, vous risquez de vous trouver face a une information qui sera difficilement interprétable. Je choisis donc personnellement de n'observer presque que des points où l'utilisateur ne passera qu'une seule fois.

Conserver les données

La dernière phase de préparation à l'analyse se joue sur la façon d'organiser vos données. Il va être très important de récolter vos données régulièrement (si possible tous les jours).

Pour ma part, j'organise ça dans un fichier excel en récoltant les données toutes les semaines. Il faut bien séparer les données récoltées en fonction de la version de l'application entre autre (puisque d'une version a l'autre, vous aurez sans doute modifié votre application, il vous faudra donc pouvoir comparer les versions antérieures pour savoir si les derniers changements ont été bénéfiques ou non).

Une fois les données récoltées, je met la base de données à 0 afin d'améliorer la lecture de ma base de donnée a la volée.

Analyser les données

Ne vous jetez pas sur les premiers chiffres qui vont peupler votre base de données, attendez d'avoir un échantillon suffisamment conséquent de données avant de faire des analyses. Un échantillon trop petit peu vous induire en erreur et vous mener à de fausses pistes.

Une donnée c'est bien, deux données c'est mieux !

Il vous sera nécessaire de coupler vos données afin d'avoir des outils de comparaison. Soit en associant dans un même lot de données une étape, soit en associant une même étape d'une version a une autre

Prenons comme exemple les informations récoltées sur deux champs imaginaires:

  1. > Nombre d'utilisateur ayant complété la dernière étape du tutoriel = 2798
  2. > Nombre d'utilisateur ayant complété l'achèvement “Jouer une partie” = 2336
A savoir, dans mon application, les achèvements sont complété lorsque le joueur retourne sur la page d’accueil, dans ce cas précis, un joueur aura réalisé plusieurs actions entre ces deux informations :
     1) Complété l'étape du tutoriel
     2) Fini sa partie en cours
     3) Vu l'écran de résultat
     4) Accédé a l'écran des Highscore
     5) Alors seulement là il complétera l'achèvement

On observe donc une perte de 462 joueurs entre ces deux étapes. C'est beaucoup, il y a donc quelque chose qui se passe ici et qui mérite réflexion …

Les chutes anormales

Si vous observez une chute anormale d'une étape à l'autre dans vos observations, cela vous indique à coup sur un problème. Orientez vos recherches sur ce point, peut-être est-ce le signe d'une issue majeure ou mineure.

L'analyse des données n'est pas chose aisée. Ici vous allez devoir sortir votre panoplie de Sherlock Holmes pour ré-imaginer la scène du crime à partir des restes sanguinolents de la pauvre application victime…

Avec l'exemple précédent, on peut imaginer plusieurs scénarios :

   a) L'application présente une issue majeure qui empêche son bon fonctionnement entre les deux étapes
   b) Les joueurs n'aiment pas le jeu et quittent avant la fin de la partie.
   c) Les joueurs passent dans un tunnel a ce moment précis ce qui aboutis a la non transmission des données

Parmi tous les scénarios que vous pourrez imaginer, certains seront plus cohérents que d'autre, et ce sera a vous d'orienter votre enquête. Pour ma part, sur cet exemple précis, il y a trop de possibilités différentes et d'incertitudes, je décide donc de remettre mon analyse a plus tard, et j'ajoute différents points d'observation afin d'affiner ma recherche (un lorsque le joueur fini sa première partie, un lorsque le joueur accède aux highscores la première fois).

N’hésitez pas a rajouter des points de contrôle si nécessaire, remettre vos analyses a plus tard n'est pas forcement une mauvaise solution !

Les chutes normales

Si certaines chutes doivent vous alarmer, d'autres au contraire sont tout à fait acceptables et vous ne devez pas vous en inquiéter outre mesure (en tout cas dans un premier temps).

Par exemple, dans l'observation des étapes du tutoriel (qui est une étape cruciale dans tous les jeux vidéos, et je conseille fortement a tous d'observer chacune des étapes de vos tutoriels afin d’être sûr qu'aucune étape n'est bloquante ou trop peu claire), vous ferez toujours face à une chute progressive de la fréquentation

La toute première chose que vous devrez prendre en compte, c'est qu'il s'agit ici de la première vrai confrontation du joueur avec votre jeu, il est donc normal d'avoir des pertes d'utilisateur d'une étape à l'autre du tutoriel. Si la section dans laquelle est classé votre jeu est correcte et que votre titre ne porte pas à confusion, les utilisateur qui ont lancé votre applications sont des consommateurs du genre, ils devraient donc en majorité attendre la fin de leur première partie avant de décider de continuer ou non. Pour notre part, nous perdons environ 2 a 3% de joueurs à chaque étape de tutoriel. Ceci est bon signe car cela signifie que le tutoriel est clair et qu'il n'y a pas d’étape bloquante.

Dans un autre exemple, le suivis des objectifs nous permettra de garder un oeil sur la progression de nos utilisateurs. Ici, on observera sans s’inquiéter outre mesure des chutes plus grandes d'une étape a l'autre (10 a 20%). Ces pourcentages sont bien sûr améliorables, en modifiant vos flux vous pourriez conserver les joueurs un peu plus longtemps, cependant comprenez qu'il est normal que les joueurs se lassent et quittent votre application peu a peu. Cependant, encore une fois, une chute trop élevée d'une étape à l'autre dans ce type de suivis vous indiquera soit un bug majeur, soit une incompréhension de l'utilisateur, ou encore un problème d’équilibrage (un objectif trop complexe à accomplir comparativement au précédent).

Conclusion

Nous avons pu voir quelques principes simple de l’utilité d'une analyse d'audience ciblée, la force de cet outils est vraiment immense et vous permettra d’améliorer très grandement vos jeux ainsi que votre connaissance des comportements des utilisateurs. Mais attention, cet outils demande un bon esprit d'analyse des résultats, une mauvaise interprétation peut mener à une aggravation du problème, heureusement, grâce à l'analyse d'audience, vous vous en rendrez vite compte ;)