Ci sono parecchie aziende che gestiscono un sito e un'app mobile, li misurano con due strumenti diversi, e scoprono che i due non vanno mai d'accordo su niente. La risposta solita è scegliere il numero che sostiene la discussione in corso. Ecco che cosa sta davvero andando storto, e che cosa deve essere vero di uno strumento perché li copra entrambi senza mentirti.

Le quattro cose che differiscono davvero

È allettante trattare un'app come un sito con un browser peggiore. Quattro differenze rompono quell'ipotesi, e qualunque strumento che misuri entrambi deve avere una risposta per ognuna.

Non c'è nessun URL. Un sito ha un indirizzo di pagina che fa anche da nome, da gerarchia e da modo di raggruppare le cose. Un'app ha schermate, i cui nomi li scegli tu e puoi cambiare. Non c'è niente che imponga coerenza, quindi Checkout, checkout e CheckoutViewController finiscono come tre schermate nello stesso report.

Non c'è nessun caricamento di pagina. Sul web, una navigazione è un evento ovvio e osservabile che il browser annuncia. In un'app, passare da una schermata all'altra è una chiamata di funzione. Se non la strumenta niente, non viene registrato niente, e non viene sollevato nessun errore.

La rete non è affidabile. Una scheda di browser di solito è connessa. Un'app regolarmente non lo è: una galleria, un aereo, una zona morta. Gli eventi devono essere messi in coda sul dispositivo e mandati dopo, il che vuol dire che uno strumento che dia per scontato che l'ordine di arrivo sia l'ordine del tempo li metterà in disordine, e uno che non abbia idea che un evento sia stato in coda gli marcherà l'ora sbagliata.

Le sessioni finiscono in modo diverso. Una sessione web scade dopo un periodo di inattività, per convenzione trenta minuti. Un'app passa in secondo piano, e ci può restare per giorni prima di tornare in primo piano con il suo processo ancora vivo. Una regola di sessione ingenua riporta una sessione durata quattro giorni.

Che cosa dovrebbe voler dire «nello stesso posto», e che cosa di solito vuol dire

La maggior parte degli strumenti che pubblicizzano tutti e due fa una di due cose, e la differenza conta più di quanto il marketing suggerisca.

La prima è una dashboard condivisa sopra due insiemi di dati del tutto separati. Ottieni un accesso. Non ottieni un numero, perché i due lati contano cose diverse e non c'è niente che li riconcili.

La seconda è un insieme di dati con una colonna per la piattaforma, così un report si può filtrare o dividere. È questo che le persone di solito credono di comprare.

C'è una terza sistemazione, e vale la pena dirla chiaramente perché è quella che causa le discussioni: un'app e un sito sono davvero cose diverse, e forzarli dentro un'entità sola produce report in cui non è giusto nessuno dei due. Una schermata vista non è una pagina vista. Un'app ha versioni, e un sito no. Un'app va in crash; un sito restituisce un 500.

La sistemazione utile è che siano entità separate con i propri identificativi, misurate dallo stesso prodotto, riportate nella stessa interfaccia, tariffate dallo stesso account. Puoi guardare l'una senza che la forma dell'altra ci coli dentro, e puoi guardarle tutte e due.

Domande che vale la pena fare a un fornitore

  • Come si comporta l'SDK senza rete? Nel concreto: mette in coda, quanti eventi, che cosa succede quando la coda è piena, e conserva il timestamp originale invece dell'ora di invio?
  • Che cosa succede a un evento malformato? Un SDK che riprova per sempre un evento rifiutato in modo permanente è un problema di batteria e di piano dati per le persone che ti usano. Il comportamento giusto è buttarlo via e contare lo scarto.
  • Il formato di trasmissione ha una versione? Le app non si aggiornano in un giorno. Una parte delle persone che ti usano sarà su una versione di un anno fa, e il server deve continuare ad accettare quello che quella versione manda.
  • Come si decide un nome di schermata? Se la risposta è «quello che passi», chiedi che cosa fanno gli strumenti per tenerlo coerente.
  • Qual è la regola di sessione dopo un passaggio in secondo piano? Un numero preciso, non un «ce ne occupiamo noi».

Quella terza domanda prende più problemi veri di tutte le altre messe insieme, ed è quella che nessuno fa. Un tracker web si può cambiare modificando una pagina ed è in produzione quel pomeriggio. Un SDK di app esce quando esce l'app, viene adottato nell'arco di settimane o mesi, e non raggiunge mai tutti. Rompere il formato che mandano le tue versioni vecchie non è un difetto che si corregga a caldo; è una flotta di installazioni che smette di riportare.

Dove si colloca Skomi

Skomi tratta un'app misurata come un'entità a sé con il proprio spazio di nomi, accanto ai siti invece che dentro di loro. I report vivono nello stesso account e si navigano allo stesso modo, ma un'app non viene mai descritta come un sito e le sue schermate non vengono mai chiamate pagine.

Ci sono SDK per le piattaforme comuni, e il formato di trasmissione che parlano ha una versione ed è congelato, proprio perché una versione vecchia non si può correggere a distanza. La pagina App Analytics copre che cosa viene misurato e quali piattaforme sono supportate.

I crediti sono condivisi da tutto quello che sta sull'account (siti e app allo stesso modo), quindi aggiungere un'app non è un secondo abbonamento. La pagina dei prezzi ha l'aritmetica.

Le due metà tengono il proprio vocabolario dove differiscono (un sito ha pagine viste, un'app ha schermate viste), e condividono la finestra di sessione che le rende paragonabili.