Tanto nei nuovi videogiochi digitali quanto nella gamification l’importanza di analizzare i dati sta diventando uno dei campi cruciali di battaglia. Sono fermamente convinto che quello che sperimentalmente l’industria gaming sta portando avanti con poche start up e figure professionali sarà presto di dominio pubblico in tanti altri campi dove l’utilizzo della telemetria è ancora focalizzato sulle classiche metriche. In un mondo sempre più digitalizzato con una fortissima concorrenza, diventa fondamentale conoscere i behaviours dei nostri giocatori per poter intervenire velocemente nella definizione dell’engagement loop, vero punto di partenza per raggiungere un saldo positivo tra ARPU (average revenue per user) e UAC (user acquisition cost). Quante volte in un prodotto ci siam chiesti “ma cosa non funziona?” ed altrettante volte si è andati a tentoni cercando di invertire la rotta? Ebbene, tracciare i comportamenti, processare i dati, analizzarli è il ciclo da seguire per poter pianificare interventi veloci per risolvere i problemi emersi.
Prima di procedere vorrei definire un paio di vocaboli:
Per Game Telemetry intendo tutti i dati che un client (un social game o un prodotto digitale gamification based) traccia su determinati comportamenti dell’utente per poi inviarli al server dove vengono storati e processati.
Per Game Metrics intendo misure quantitative standardizzate correlate ad un aspetto nel gioco. Esse, all’interno di sotto clusters, possono spaziare dal “numero di utenti che hanno effettuato una transazione nell’arco delle 24 ore” al “numero di power ups utilizzati in un dato arco temporale”, “la percentuale di colpi andati a segno” e così via.
Una delle difficoltà iniziali nel creare un set di game metrics da analizzare è individuare esattamente cosa bisogna tracciare. E’ fisicamente impossibile, costosissimo e spesso controproducente, tracciare tutte le azioni che occorrono nel sistema. Ed allora è fondamentale una pianificazione a monte delle azioni da storare su una base “ad evento”, ovvero ogni volta che l’evento individuato avviene. Per evento si intende un click su un bottone, un acquisto nello shop, un power up utilizzato, un level up etc etc.
Nel documento di design sarebbe bene prevedere una sezione “Game Telemetry” in cui richiedere ai developers le azioni da tracciare. Per facilitare il compito e l’individuazione, è possibile dividere tre classi di metriche che, come vedremo, saranno particolarmente utili a diverse figure professionali coinvolte nel progetto:
Customer Metrics: Sono le metriche che solitamente vengono già prese in considerazione nelle start up digitali, sia mobile che online. Sono particolarmente utili per il reparto marketing e per gli executives per avere un quadro “commerciale” dell’andamento del progetto. Quelle da implementare assolutamente:
– DAU: I daily active users sono gli utenti (è bene prendere solo gli unici) che sono entrati nel corso delle 24 ore solari nell’applicazione. Per essere classificati come tali basta aver avuto avuto accesso allo splash screen, nessuna ulteriore azione è richiesta. L’andamento degli utenti attivi giornalmente è calcolato giorno su giorno con eventuali variazioni positive o negative.
– MAU: I monthly active users sono gli utenti che sono entrati nel corso di un arco temporale di 30 giorni nell’applicazione. Non ha senso utilizzarlo come dato aggregato del DAU x numero di giorni mese, ma è sempre bene tracciare solo gli utenti unici.
STICKY FACTOR: Un valore molto importante che ci dice già qualcosa di qualitativo sull’andamento del prodotto è il rapporto tra DAU e MAU. Il numero di utenti che quotidianamente rientrano nell’app in relazione al montante mensile è un indicatore di quanto ingaggiante e abitudinario possa essere diventato il nostro prodotto.
Questi dati puramente quantativi oltre a dare una overview sull’andamento del prodotto sono spesso parametri presi in considerazione da alcuni store digitali (FB, ios, xbox live…) per posizionare il gioco nelle chart interne con conseguente viralità indotta.
PCU: Peak Concurrent Users è la metrica che ci indica il numero di utenti contemporaneamente connessi nell’app ogni ora. Lato infrastrutturale è un dato interessante perchè consente di pianificare servizi di customer care o gestione del traffico server (il futuro sempre più cloud renderà inutile a tal fine questa metric). Lato gameplay è molto importante conoscere la distribuzione oraria per pianificare azioni particolari di up-selling (banner che mostrano una offerta speciale).
-Conversion Rate in F2P: E’ la percentuale del numero di utenti che da non paganti diventano paganti. Su 10 utenti nel sistema, 1 ha effettuato almeno una transazione e quindi il mio conversion rate è del 10%.
ARPU: Average revenue per user è la misura delle revenue totali generate dall’app in un dato arco temporale (solitamente un emse) diviso il numero di utenti unici di quell’arco temporale. Il risultato è il guadagno medio per ciascun utente. E’ un dato importante per fare proiezioni di revenue in relazione al numero di utenti che si pensa di raggiungere.
ARPPU: Average revenue per paying user è la misura delle revenue totali generate dall’app in un dato arco temporale (solitamente un mese) diviso il numero di utenti che hanno effettuato almeno una transazione in quell’arco temporale. Il risultato è il guadagno medio generato da un utente transante.
UAC: User Acquisition cost è il totale del costo sostenuto nell’acquisire utenza (marketing, comunicazione…) diviso il numero di MAU. Il rapporto tra UAC e ARPU è vitale, se il costo di acquisizione supera le revenue medie per utente sarà necessario ricalibrare la strategia.
LTV: Lifetime si ottiene moltiplicando l’ARPU per la permanenza media nel sistema. Se un utente genera 1 euro di ARPU su scala mensile e mediamente rimane nel sistema per 12 mesi, il suo PFT sarà di 12 euro. La relazione tra LFT e UAC è altresì fondamentale per valutare la redditività del prodotto.
LTNV: Lifetime network Value è una metrica strettamente riferibile a quelle piattaforme che consentono di inviare messaggi e notifiche ad altri utenti con l’esplicità finalità della viralità. In questo caso la metrica potrebbe indicarci quanti nuovi giocatori un utente ha portato nel sistema nella durata della sua permanenza.
First Time Opening: Per esperienza personale ho notato spesso che esiste una forte discrasia tra il numero di persone che hanno scaricato/installato il nostro gioco e il numero di utenti che lo hanno “provato” almeno una volta. In molti casi il check dei 2 numeri indica problemi con il lancio del gioco o problemi con la campagna di acquisizione clienti. Si tratta di tracciare il corretto caricamento della prima pagina del gioco per il first time user.
GAMEPLAY METRICS: Sono le metriche più direttamente correlate al design e user experience del prodotto. Esse possono variare in relazione al genere videoludico prescelto e quindi diventa impossibile astrarle come fatto con le consumer metrics. Se nel vostro gioco un ruolo importante nel loop di engagement e monetizzazione lo giocano dei power ups, sarà doveroso tracciare ogni qual volta un power up viene acquistato e utilizzato per capirne il riscontro. In generale ci dicono cosa, quando, dove l’utente interagisce nel sistema. Tra quelle sempre applicabili:
– EED: Entry Event Distribution è una metrica fondamentale per capire il comportamento dell’utente nell’area principale/lobby di un gioco. A fronte di una scelta molto ampia di opzioni, modalità, bottoni e tab l’EED traccia la prima reale azione compiuta dal player nel mio sistema. Se tra tante modalità in un gioco di social poker, l’utente come prima azione sceglie sempre il Sit & Go, probabilmente dovrò priorizzare questa opzione rispetto alle altre.
XED: Exit event Distribution è la metrica che traccia l’ultima azione compiuta dal giocatore prima di uscire definitivamente dal sistema. Siccome non è dato sapere se un utente rientrerà o meno è bene configurare questa telemetria come “gli utenti che non rientrano in xx giorni” calcolando xx in relazione alla frequenza media di una visita. Se mediante un nostro giocatore entra ogni 2 giorni, è bene fissare questo parametro col moltiplicatore x10 e quindi 20 giorni. Individuare patterns comuni di uscita potrebbe aiutarci a individuare problemi di user experience o alterare il flusso di navigazione. Ammettiamo che dalla lobby si è obbligati a passare attraverso una pagina intermedia prima di accedere alla game area e XED indica quello come un ripetuto momento di uscita dal gioco. Probabilmente sarà possibile rimuovere quella pagina intermedia per riproporla sotto forma di pop up liberamente attivabile successivamente.
ENGAGEMENT: E’ un termine inflazionato, ma come realmente possiamo provare a cogliere quanto è ingaggiato un utente nel nostro sistema. Uno schema di tracking potrebbe arrivare dall’insieme di: lunghezza della sessione media di gioco, numero di pagine viste, numero di sessioni giornaliere, ciclo di vita (numero di giorni/mesi medi di permanenza nel sistema) e numero di azioni compiute in una sessione.
Currency: Tener traccia di quando, chi, quanti pacchetti di moneta virtuale (soft e/o hard) acquista. Da qui discende tutta la game economy fondamentale nei modelli free to play.
Il discorso è ovviamente molto più complesso, ogni gioco è una storia a sè. Conto di tornarci a breve con alcuni case concreti.