Google Analytics in 30 secondi

Tempo fa vi avevo parlato di BIME, un sistema per creare dashboard professionali che importa dati anche da Google Analytics. Poiché per i primi 30 giorni la versione completa è gratuita ho deciso di provarlo meglio e dirvi cosa ne pensavo. Anche perché l’ho promesso a Freédéric, che mi ha telefonato il giorno stesso per sapere cosa ne pensavo (e preciso, a scanso di equivoci, che non mi è stato offerto nulla in cambio della recensione: la faccio perché è in tema con i contenuti di questo blog).

Ogni iscrizione crea un sottodominio dell’applicazione, nel mio caso ovviamente si tratta di https://goanalytics.bimeapp.com, che non linko tanto vi rimanderebbe alla pagina di login. Una volta entrati nel sistema si hanno quattro tab: una panoramica che riepiloga le connessioni, le dashboard e l’attività dei giorni scorsi, una parte di Analyze che serve a creare i report veri e propri, una parte di monitor che serve a visualizzare i dati e le dashboard create e la classica parte di Admin dove creare utenti, gestire l’account, pubblicare le dashboard, eccetera. L’interfaccia è molto carina, e dentro ogni tab le schermate sono rappresentate come facce di un cubo che ruota; il tutto è creato in Flash.

Creare una connessione è abbastanza semplice: dal tab Analyze -> connection builder è necessario dare un nome alla connessione, eventualmente una descrizione, se essa sarà privata (visibile solo a voi) o pubblica (visibile anche agli altri utenti cui darete accesso), una categoria, se i dati dovranno essere messi in cache (cioè copiati dentro BIME, evitandovi di doverli richiedere nuovamente a Google Analytics nel nostro caso), e finalmente il tipo di dato che andrà a riempire la sorgente, tra tutti quelli possibili in BIME. Ecco uno screenshot di come si presenta la schermata di creazione del connettore:

La library delle connessioni è una specie di riassunto di tutte le connessioni che avete, se ne avete più d’una, con eventulmente un dettaglio dei dati che possono essere estratti: nel caso di un connettore a GA dentro ci sono le metriche e le dimensioni che sono normalmente disponibili tramite le API. La library delle query è invece un elenco delle interrogazioni che avete creato tramite l’interfaccia disponibile nel tab Pivot Tables, il cuore del sistema.
La scheda Pivot Tables a prima vista può sembrare parecchio complicata, è una versione ingigantita dell’interfaccia di creazione di un custom report, ma alla fine il concetto è piuttosto semplice: bisogna trascinare gli elementi al posto giusto per creare la visualizzazione che vogliamo. Quindi sulla sinistra c’è una colonna con gli elementi e al centro degli spazi dove trascinarli: colonne, righe, righe che si devono presentare già espanse, metriche, filtri sulle metriche, colori e dimensioni nel caso di grafici. Poi c’è la selezione del tipo di visualizzazione tra tutte quelle possibili.

Ad esempio con tre click creo una heatmap del bounce rate diviso per nazione, restringo la visualizzazione della cartina alla sola Europa, e filtro solo i paesi che mi interessano, eliminando quelli africani e mediorientali che compaiono sulla mappa ma i cui dati non voglio visualizzare.
Oppure con quattro click creo un tachimetro con le pagine/visita con fondo scala a 2.0 pagine per visita, mentre il mio indicatore si ferma a 1,86.
Oppure, con molti click in più, un report che Tommaso Galli mi diceva su twitter come esempio di dimensione secondaria sempre espansa che vorrebbe come regalo di Natale da GA: visite per keyword divise per network location (in questo caso solo da traffico organic e rristrette a dicembre):

Questo è il cuore del sistema, e una volta compreso il funzionamento c’è solo da dare sfogo alla fantasia. Tenendo presente che Google Analytics è solo una delle fonti di dati possibili, capite benissimo che le possibilità sono infinite: potete importare e incrociare dati, cambiare le visualizzazioni, impostare dashboard da dare ai clienti. Servono un paio di giorni per ambientarsi bene, ma considerando che il lavoro di recupero dei dati l’ha fatto tutto BIME, voi potete concentrarvi sulle analisi e le visualizzazioni.

Da quando ho scritto la mia segnalazione BIME è passato alla versione 2, e i prezzi sono stati ritoccati. Adesso la versione base che include il connettore per GA parte da 120$ al mese e comprende 10 connettori, 20 dashboard e 10Gb di storage per la cache dei dati. Se pagate un anno intero avrete il 15% di sconto.

Natale è ormai passato, ma oggi m’è capitato l’occhio su un post di Matthew Curry di Econsultancy.com e sulla relativa risposta di Joe Teixeira su morevisibility.com; entrambi focalizzati sulle richieste di Natale al team di sviluppo di Google Analytics, per miglioramenti o nuove feature che Matthew vorrebbe vedere introdotte e che Joe commenta. Ve le traduco, e inoltre aggiungo le mie note.

• Matthew: Rendere più facili le combinazioni tra metriche e dimensioni. Matthew si lamenta che spesso non è possibile combinare alcune metriche con alcune dimensioni, e che specialmente via API queste limitazioni fanno perdere tempo prezioso.
  Joe: è sostanzialmente d’accordo, anche se almeno l’interfaccia di creazione di un custom report si preoccupa di rendere non selezionabili le combinazioni non ammesse.
  Marco Cilia: non so quante delle combinazioni non ammesse derivino dalla volontà di Google di renderle indisponibili o da problemi tecnici (alcune non avrebbero proprio senso a prescindere), ma devo dire che fino ad ora non ho trovato grossi problemi. I miglioramenti sono però sempre bene accetti.
• Matthew: Meno beta. Ci sono ancora troppe funzioni in beta: Intelligence, Analisi in-page, Adwords.
  Joe: Google e beta sono due parole che vanno a braccetto da sempre, non è un fastidio.
  Marco Cilia: ci siamo tenuti cinque anni Gmail in beta, possiamo anche tenerci un paio l’Intelligence, specie se tanto funziona già bene 🙂
• Matthew: Velocità. Alcune parti dell’interfaccia richiedono fino a 30 secondi per caricarsi.
  Joe: Se si allarga l’intervallo temporale e si applicano tanti segmenti il tempo di elaborazione tende a salire, ma se fosse più veloce sarebbe più contento.
  Marco Cilia: In ufficio io avevo uno strumento enterprise, e comunque richiedeva i suoi tempi. Alcune persone che avevo lo stesso strumento nella versione online mi hanno detto che alcuni report richiedevano decine di minuti per essere calcolati e visualizzati. Non mi dà nessun problema attendere 10 secondi per avere il dato che cerco, anche se ovviamente come tutti non mi dispiaccio se le cose migliorano.
• Matthew: API più robuste. Matthew vede spesso andare a vuoto le richieste fatte attraverso le API di Google Analytics, e questo mina la possibilità di dare Cruscotti personalizzati ai clienti. Dice anche che almeno in Google Docs il richiamo dei dati di GA dovrebbe essere facilissimo, e invece così non è.
  Joe: Secondo Joe il team ci sta lavorando e presto vedremo un buon irrobustimento delle API
  Marco Cilia: Non ho esperienza così estesa con le API da poter dare un giudizio adeguato, ma concordo che Google Docs dovrebbe importare tutto con pochi clic!
• Matthew: Meno dati campionati. Specie quando si lavora con le API.
  Joe: E’ importante avere un dato completo e meno accurato, piuttosto che il contrario, come dice Avinash.
  Marco Cilia: Lo dico sempre nei miei corsi: se anche quel che vedete fossero il 90% dei VERI visitatori del sito, non sarebbe comunque più tranquillizzante sapere che quel 90% è coerente nel tempo, piuttosto che concentrarsi sull’avere il 100 un giorno, l’87 il giorno dopo e il 95 quello dopo ancora? le decisioni è meglio prenderle su dati coerenti!
• Matthew: Più opzioni per i grafici. Matthew suggerisce ad esempio l’istogramma del valore delle transazioni con evidenziazione di anomalie e deviazioni dalla media.
  Joe: non ne sente la necessità, in fondo ci sono cinque tipi di grafici differenti.
  Marco Cilia: Io invece vorrei la possibilità di aggiungere linee di trend in base a vari parametri (secche o medie ponderate a n giorni).
• Matthew: migliore gestione dei segmenti avanzati. Magari potendoli raggruppare in cartelle, sicuramente abbattendo il limite di 100.
  Joe: è d’accordo.
  Marco Cilia: siamo tutti d’accordo 🙂
• Matthew: più “contributori principali“. Matthew vorrebbe i contributori anche nel conversion rate e tempo medio sul sito.
  Joe: pensa che ci sarebbe solo più confusione.
  Marco Cilia: Non sono molte le persone che conosco che guardano regolarmente l’intelligence, ancora meno quelle che guardano i contributori principali. Mi trovo d’accordo con Joe, per ora bene così.
• Matthew: calcoli nei rapporti, cioè la possibilità di calcolare metriche nuove partendo dai dati esistenti.
  Joe: non vuole vedere formule dentro a Google Analytics.
  Marco Cilia: ritengo che presto o tardi arriveranno, è inevitabile. E’ una esigenza troppo forte per tutti, e l’avevo già detto a inizio anno.
• Matthew: niente più “trucchi” con le URL. Ci sono alcune cose che si possono fare solo modificando un po’ le URL dei report di Analytics (ad esempio l’export di più di 500 righe di report)
  Joe: Non avere trucchi con le URL significherebbe che Google dà a disposizione più dati e più strumenti, quindi è d’accordo.
  Marco Cilia: a me i trucchi piacciono, perché mi piace scovare i post delle persone che li pubblicano, ma ancora una volta Joe ha ragione: più dati e meno “hack” 🙂

(bonus dai commenti al post di Matthew: valute multiple per goal ed ecommerce, etichette per i report in bacheca, abbattere il limite di 50 profili per GA account, Admin per singolo profilo invece che per account, clicktracking alla crazyegg, grafici selettivi solo per alcune righe del report)

Voi cosa aggiungereste? 🙂

La domanda che PiccoloSocrate mi ha posto qualche giorno fa poteva sembrare scontata, ma in effetti non lo era. Lui si chiedeva “come si modifica un avviso personalizzato già creato, nell’intelligence di Google Analytics?”.

In effetti tutte le volte che abbiamo a che fare con un qualcosa che in GA abbiamo creato noi, che siano custom report o segmenti personalizzati, la modalità di modifica è la stessa: all’ingresso nella sezione vi è un elenco delle cose che abbiamo creato e da lì possiamo eventualmente modificarle; per gli avvisi intelligenti invece non è così, e la finestra si apre con l’elenco degli avvisi attivi.

Per modificarne uno bisogna allora pazientemente cliccare dove gli istogrammi presentano indicatori azzurri fino a trovare un avviso personalizzato che appartiene alla serie che vogliamo modificare: solo allora ci comparirà il link “modifica” di cui abbiamo bisogno, come in figura:

E’ una modalità differente di trattare la cosa – se vogliamo è anche un errore di usabilità dell’interfaccia – ma ritengo sia dettata dal fatto che all’ingresso nel report delle segnalazioni, gli ingegneri hanno dato priorità alla visualizzazione delle segnalazioni, appunto…

Una delle caratteristiche introdotte ultimamente da Google Analytics e passata più in sordina è l’ordinamento ponderato (weighted sort in inglese), che permette di ordinare alcuni report in forma tabellare secondo un criterio slegato dal mero ordine crescente o decrescente: spesso infatti quando si fa analisi si cercano informazioni che non sono ne nelle prime righe delle tabelle ne nelle ultime, ma sparse lungo tutto “l’arco” dei dati. Un esempio classico è il report sulle percentuali di bounce rate, diciamo per le keyword. Se si stessero guardando le keyword e si mettessero in ordine inverso di bounce rate, ai primi posti della tabella – e per svariate decine di righe – si avrebbero si keyword con 100% di tasso di rimbalzo, ma relativi a keyword che hanno portato una sola visita.
L’informazione di qualità che stiamo cercando è celata nelle pieghe delle righe di mezzo. Ed è qui che ci viene in aiuto l’ordinamento ponderato, che riarrangia l’ordinamento combinando due metriche e provvedendo a evidenziare più facilmente i fenomeni nascosti, permettendo di avere nelle prime righe del report le situazioni che richiedono maggiore attenzione, almeno secondo lo strumento.

Avinash tempo fa ha scritto un post molto interessante, che vorrei riprendere almeno in parte per spiegare il funzionamento dell’algoritmo di weighted sort.
La chiave di tutta la “magia” dell’ordinamento ponderato è quel che in Google chiamano expected true value (forse si potrebbe tradurre con “vero valore atteso”, ma lasciamolo invece così com’è), cioè una variante del concetto matematico di valore atteso.
Facendo seguito all’ipotesi “il vero valore di una metrica per dimensioni con basso impatto sarà impreciso” è piuttosto facile dimostrare che se si sta guardando i referrer e Bing in un mese ha portato 5 visite e convertito all’80%, non è molto indicativo di un vero valore di conversione.
Google Analytics allora calcola l’expected true value (ETV da ora in avanti) per ogni singola riga del report e lo mostra permettendo di riordinare il report secondo un criterio diverso, nuovo.

Avinash usa una scala fatta così per iniziare a spiegare il funzionamento:

Se stessimo guardando il bounce rate diviso per paese di origine della visita e il Sud Africa avesse poche visite, il bounce rate riportato dal sistema non avrebbe molto senso, ok? se invece ci fossero tante visite, allora sarebbe significativo. Oppure la si può vedere così: per i valori che stanno molto vicini alla parte sinistra di quella scala, assumeremo che l’ETV sia uguale alla media del sito. Una scommessa piuttosto difensiva, facile che questo non porti grandi problemi. Per i valori che stanno molto vicini alla parte destra invece, l’ETV sarà uguale al valore registrato. Per tutti i valori intermedi invece l’ETV sarà un mix tra la media del sito e il valore attuale; più il valore è a sinistra e maggiore sarà la componente di “media del sito” rispetto al “valore registrato”, e viceversa per i valori verso il fondo scala

Chiariamo con una immagine (sempre by Avinash)

I numeri che usa ovviamente NON SONO i veri valori che Google Analytics usa (GA usa valori diversi per ognuno di noi, basati sul contesto dei numeri registrati dal tool. In altre parole, non sapremo mai i veri valori 🙂 ), ma mi sembra che chiariscano abbastanza le idee sul funzionamento, e soprattutto sulle possibilità. Vi invito anche a leggere alcuni esempi che fa sul funzionamento e casi pratici in cui potrebbe esservi molto utile il weighted sort.

Già che siamo in tema, vale la pena anche di segnalare questo post di SEOmoz, che va un pochino oltre e fornisce anche un foglio Excel da scaricare con altre versioni dell’ordinamento ponderato, da usare direttamente con i propri dati grezzi o in altri contesti, ma non mi addentrerò nelle spiegazioni, che in quel post tendono a diventare parecchio complesse anche per me 🙂

Sento dire a sempre più persone che vogliono iniziare a sviluppare applicazioni per mobile, perché lì è il futuro, perché c’è il boom e quindi i soldi, per tanti vari motivi. E sia. Che si tratti di Iphone o Android (le due piattaforme che vanno per la maggiore), Google mette a disposizione un kit da integrare durante lo sviluppo per tenere traccia dell’uso delle app tramite il nostro sistema di web analytics preferito.

Ma con un post sul blog ufficiale oggi Google Analytics fa un passo avanti, e permette l’uso delle variabili custom anche nelle applicazioni per cellulari, cosa fino ad oggi impossibile. Le variabili personalizzate sono uno dei terreni che più hanno scatenato la fantasia delle persone, per la loro versatilità e per il fatto che i dati registrati sono poi integrati nelle analisi. Ho trovato molto interessanti ad esempio i casi descritti nel post.

Si potrebbero usare le variabili custom per differenziare l’uso da parte di utenti delle versioni demo e di quelle a pagamento, per distinguere le varie versioni dell’applicazione e vedere le basi di utenza attuali, o per vedere la versione del sistema operativo usato dagli utenti (ed eventualmente continuare a mantenere o sospendere il supporto a quelle più datate). Oppure si possono usare per capire come si comportano gli utenti dentro alle app: usano i menu o tengono premuto sullo schermo? gli utenti che hanno visualizzato il tutorial usano più opzioni di quelli che lo saltano? quanti usano la vostra applicazione in modalità landscape (cellulare orizzontale) o portrait (cellulare verticale)?

Le possibilità sono veramente tantissime, limitate soltanto dalla fantasia degli sviluppatori. Mi piace! 🙂

BIME (Business Intelligence .me) è un sistema di analisi dei dati e reporting in forma SaaS (software as a service, cioè sostanzialmente online) in grado di importare dati da parecchie fonti online e offline e integrare le viste in un’unica soluzione. Tanto per dire, ecco un elenco di possibili fonti di dati:

• Databse: Oracle, PostgreSQL, Mysql, Microsoft Sql Server
• fogli Excel
• altri sistemi du Business Intelligence basati su tecnologia OLAP, come Microsoft Analysis Services, Mondrian OLAP Engine o Oracle Essbase
• dati grezzi in formato testuale
• API in formato SOAP
• Google Analytics
• Salesforce
• Google Docs
• Lighthouse, un sistema di bug tracking
• Amazon SimpleDB, database online

Uno di questi è per noi ovviamente interessante, quindi dopo aver specificato che il servizio non è stato provato ma viene soltanto segnalato, vediamo cosa riusciamo a capire: una volta attivato un connettore per GA, basato sulle API naturalmente, l’interfaccia di BIME presenta i classici bottoni da trascinare con le metriche e le dimensioni, da combinare per avere i dati desiderati, poi è necessario scegliere una delle visualizzazioni possibili. Un elenco completo è disponibile a questo indirizzo. Sono possibili anche ulteriori affinamenti, ad esempio in un grafico a torta è possibile separare ulteriormente una “fetta”, ma la cosa più interessante è la possibilità di avere delle “misure calcolate” usando moltissimi operatori (dall’esempio oltre a CONTAINS vedo CURRENT_DAY, COUNT VALUES, ma sono veramente tanti).

Ecco invece un altro esempio di report che è possibile fare con BIME. Si tratta di una heatmap con le visite per paese

Marco, perché non l’hai provato, vedo che esiste una versione free?

Perché ahimè la versione con il connettore per GA costa invece 100 dollari al mese. E’ una cifra che però, date le potenzialità, potrebbe valere la pena di investire se si creano spesso dashboard e report personalizzati e si ha necessità di variare parecchio le visualizzazioni dei dati.

[GAADDONS NON E’ PIU’ SUPPORTATO DALL’AUTORE]

Qualche tempo fa vi ho parlato di GAaddons, un piccolo javscript scritto da Stéphan Hamel per automatizzare ed estendere alcune funzionalità di Google Analytics. Una novità di questi giorni è l’introduzione, in versione beta, della funzione _setXDomain, che serve a semplificare – e di molto aggiungerei – la normale gestione del cosiddetto crossdomain tracking, ovvero la gestione di Google Analytics quando si ha a che fare con stoddomini e domini multipli.

Nella pagina di documentazione della funzione Stéphane ha ripreso i casi dell’help ufficiale di Analytics e li ha tradotti nella sintassi per il suo addon, e così le due chiamate necessarie a tracciare un dominio e un sottodominio nello stesso profilo passerebbero da

 _gaq.push(['_setDomainName', '.example-petstore.com']);
  _gaq.push(['_setAllowHash', false]);

a un più semplice

_gaq.push(['_setXDomain', {
      domainName: '.example-petstore.com'
      }]);

Fino qua niente di che. Vediamo adesso il codice per domini multipli e sottodomini. Normalmente ci sarebbe un setdomainname, un setallowlinker e un setallowhash sul dominio principale e sul sottodominio, e un setdomainname differente con setallowlinker e setallowhash nell’altro dominio principale. Inoltre tutti i passaggi da un dominio all’altro andrebbero gestiti con le funzioni link() e linkByPost(), e bisognerebbe fare molta attenzione a non dimenticarsi qualcuno di questi link.
Con la funzione di GAaddons il tutto si riduce a

_gaq.push(['_setXDomain', {
      domainName: '.example-petstore.com',
      include: /(my-example-blogsite.com|otherdomain.com)/
      }]);

e questo farà anche si che tutti i link “incrociati” abbiano le giuste funzioni per passare i cookie. Esistono poi i casi con domini e sottodirectory, ma poiché sono minoritari non ve li riporto e vi rimando ancora alla pagina di documentazione [che non è più online].

Una cosa da tenere presente è che esistono ancora due casi reali possibili per il crossdomain tracking, e cioè il tracciamento di due sole sottodirectory nello stesso dominio e gli iframe con contenuto su dominio esterno, ma che questi non sono (ancora, si spera) contemplati da GAaddons. Per il resto, questa mi sembra veramente una buona novità ed una semplificazione molto grossa: nella mia esperienza di consulente il tracciamento su più domini è sempre un momento di grande tensione e spesso rappresenta un momento in cui il tracciamento fa perdere consistenza ai dati. Avere una semplificazione in tal senso è estremamente positivo, e speriamo che anche Google se ne renda conto e magari copi l’idea 🙂

[In chiusura, vi ricordo che la funzione è in beta: se decidete di provarla scaricate la versione del file GAaddons appropriata, e fatelo avendo ben chiari i rischi cui andate incontro usando una versione sperimentale di qualcosa]

Ebbene si, Lexmark ha sviluppato una serie di stampanti in grado di interagire direttamente con alcuni siti web, la linea smartsolutions. Oltre al “ferro fisico”, Lexmark offre sul suo sito una serie di gadget che si possono configurare e sincronizzare con la stampante, e tra questi vi è anche il connettore per Google Analytics. Una volta scaricato, immesse le informazioni di login e inviato alla stampante, essa sarà in grado di accedere direttamente ai dati e stampare 6 report tra i più comuni:

• visite/giorno
• top 10 parole chiave
• top 10 pagine
• sorgenti di traffico
• overlay mappa geografica
• panoramica adwords

Per ognuno di essi, se non ho visto male, è possibile impostare l’intervallo temporale. Per vederla in azione potete guardare questo video ufficiale:

Sono rimasto sinceramente colpito dall’idea, e in effetti a pensarci non è poi così insensata: ovvio, se personalizzate sempre i report non la troverete utile, ma se invece vi capita spesso di stampare i report predefiniti e avete bisogno di una stampante nuova, perché no? 🙂

(ovviamente il connettore per GA non è l’unico disponibile: sul sito c’è un corposo elenco da sfogliare)

Quando si parla di “coda lunga” si intendono, di solito, quelle parole chiave a medio-basso traffico i cui numeri sommati (accessi, ma anche conversioni) possono dar luogo a fenomeni di rilievo, a volte anche maggiori delle equivalenti keyword mainstream. Per intenderci, e a titolo meramente esemplificativo, potremmo associare il concetto alle parole chiave che trovate nei vostri report dalla riga 25 in giù.

Altre persone tendono a definire il concetto come “le parole chiave che contengono più di X parole”, con il numero X variabile. Io non sono d’accordo con questa definizione, ma la regular expression che vi propongo può essere utile a loro ma anche a voi per altri scopi: la regex serve a isolare le keyword con un numero di parole superiore al numero specificato. E’ questa:

^([^ ]+ ){5,}[^ ]+$

e ovviamente in questo caso prende solo le keyword con 6 o più parole (il numero indicato è infatti il numero di spazi). Potete utilizzarla con un filtro al volo direttamente nel report delle parole chiave, oppure creare un segmento avanzato come questo (clicca per ingrandire)

e verificare le performance del segmento rispetto ai dati di tutto il traffico. O crearne vari e controllare le performance di vari segmenti, tenendo ovviamente presente che il segmento con 6 o più parole contiene anche i dati di un eventuale segmento con 3 o più parole chiave.

Prima che me lo chiediate nei commenti, se volete invece la regex che seleziona SOLO le keyword con l’ESATTO numero di parole, dovete togliere la virgola dopo il numero 🙂

Mi ha scritto un lettore chiedendomi come mai il numero indicato nella panoramica dei rapporti e-commerce (le vendite di x prodotti hanno generato…) sia differente da quanto indicato nel report panoramica del prodotto (entrate generate dal prodotto). Il suo problema in realtà è leggermente differente, e vedremo di risolverlo, ma la domanda si pone all’interno di un filone piuttoto ricorrente sulle discrepanze dei numeri tra report differenti.

Spesso è solo un banale problema di traduzione dell’interfaccia, anzi di coerenza, perché Google Analytics dà a volte nomi differenti alle stesse cose. Nella fattispecie, quando guardiamo al report panoramica del prodotto il numero espresso è il prezzo dei prodotti netto, senza spese né tasse. Il numero indicato nella panoramica e-commerce è invece la REVENUE,cioè gli introiti totali comprensivi di tasse e spese di spedizione.
L’interfaccia sbaglia di grosso quando presenta nei due report sottostanti la colonna revenue per entrambi: nel primo caso (prodotti) il dato indicato sono le entrate, nel secondo caso invece (sorgente/mezzo) è davvero la revenue. Non che la cosa sia consolatoria, ma il problema c’è anche nell’interfaccia inglese, quindi si tratta di un vero e proprio errore di etichetta del dato: l’etichetta corretta di quella colonna dovrebbe essere Entrate generate dal prodotto (product revenue in inglese).