Come trasformare il monitoraggio di Analytics in un processo collaborativo continuo

Nota del redattore: questo articolo è stato originariamente pubblicato sul blog Iterativamente il 1° febbraio 2021.

Sappiamo tutti che qualsiasi organizzazione che costruisce prodotti e servizi digitali raccoglierà dati. Sappiamo anche che la semplice raccolta di dati non è la stessa cosa che utilizzarli effettivamente in modo efficace. Anche se disponi di un piano di tracciamento straordinario, supportato da un solido toolkit, la tua strategia fallirà se non ti prendi il tempo per impegnarti in una cosa fondamentale: la collaborazione.

L'analisi tocca tutti in un'azienda guidata dai dati

Pensa a creare una nuova funzionalità per il tuo prodotto. Ci sono due considerazioni principali in gioco qui: quali nuovi punti dati porterà questa funzione e chi sono i destinatari di quei punti dati? Bene, se vuoi davvero prendere decisioni basate sui dati, più o meno tutti saranno un pubblico per i dati dei tuoi clienti.

Le principali parti interessate coinvolte nel monitoraggio dell'analisi porteranno tutte le loro idee e competenze uniche alla storia: una sana miscela di conoscenza del dominio e know-how tecnico. Abbiamo:

• Dirigenti/leadership
• Responsabili di prodotto
• Team di analisti/dati
• Sviluppatori

Ciascuno di questi team avrà i propri compiti e obiettivi distinti, ma alla fine lavoreranno sullo stesso piano di monitoraggio.

Suggerimento : avere troppi cuochi può essere un incubo: leggi questo post per saperne di più su chi dovrebbe possedere il piano di monitoraggio.

Come questi team (dovrebbero) collaborare tra loro sull'analisi.

Dirigenti/leadership

Iniziamo con i team che vorranno la visione più di alto livello del monitoraggio degli eventi. Durante la creazione di una nuova funzionalità, il dirigente si preoccuperà maggiormente di quali siano gli obiettivi di questa nuova funzionalità e quali metriche verranno utilizzate per misurare il successo.

Ciò significa che i team che lavorano sotto la leadership devono essere attrezzati per eseguire report di alta qualità. Un buon gruppo dirigente non vorrà prendere decisioni importanti sul futuro dell'azienda sulla base di intuizioni: vorrà una prova concreta di cosa funziona e cosa no.

Principali comportamenti collaborativi di questo team:

• La leadership dovrebbe impegnarsi al massimo per ispirare la collaborazione in tutta l'organizzazione e promuovere una cultura che comprenda il valore del processo decisionale basato sui dati.
• Festeggia i successi che sono nati prendendo decisioni basate sui dati.
• In parole povere, se il tuo manager non si preoccupa di un buon monitoraggio delle analisi, allora perché dovresti? ‍

Responsabili di prodotto

I product manager conoscono intimamente il tuo prodotto e come si colloca nel mercato/settore. Sono responsabili della distribuzione di questa nuova funzionalità e, in quanto tali, cercheranno di trasformare quelle metriche che interessano alla leadership in eventi reali che desiderano monitorare. Per creare rapporti affidabili su questa nuova funzionalità, il monitoraggio degli eventi deve essere integrato fin dall'inizio.

Sebbene un product manager sia dotato di una grande esperienza nel settore, potrebbe non avere le competenze tecniche necessarie per definire autonomamente il piano di monitoraggio. Ciò significa che devono collaborare con altri team per portare a termine il lavoro. È meno probabile che un buon product manager imponga un elenco di eventi che desidera monitorare e si aspetti che ne derivi un report perfetto. Potrebbero invece discutere e concordare ciò che è possibile fare con analisti e sviluppatori, poiché questi sono i team che implementeranno il piano di monitoraggio e costruiranno i report.

Quindi i product manager sapranno quali metriche sono importanti, ma possono fare affidamento su altri per trasformarle in eventi tracciabili. Saranno fondamentali per porre le domande giuste sui dati, decidere quando eseguire il test A/B e creare cicli di feedback appropriati: esaminare le prestazioni delle decisioni precedenti e iterare su quelle.

Principali comportamenti collaborativi di questo team:

• Controlli regolari con analisti che coprono quali eventi vengono monitorati e perché, e mantengono tutti sulla stessa pagina con tassonomie e convenzioni di denominazione
• Collaborare con gli sviluppatori per determinare quali modifiche al piano di monitoraggio devono essere implementate e se tali modifiche sono possibili data l'infrastruttura e quanto tempo ci vorrebbe per farlo
• Assicurarsi che forniscano feedback alla leadership con rapporti di alta qualità

Analisti

Il tuo team di analisti di dati è come l'hub centrale dell'azienda per il reporting. Molto probabilmente sono quelli che mettono le mani per primi sui dati grezzi (forse gli unici). Lavoreranno per unire, modellare e visualizzare i dati. Aiutano a trasformare i dati in insight.

Una nota importante sul team di analisti : non dovrebbero essere visti come una risorsa organizzativa, cioè le "persone a cui chiedere" quando hai bisogno di qualcosa relativo ai dati. Se questo è il caso, gli analisti potrebbero scoprire che la loro capacità è occupata dal soddisfare le richieste quotidiane di altri team, invece di costruire effettivamente approfondimenti e generare report significativi.

Parte del processo collaborativo dell'analista consiste nel consentire agli altri team di servirsi da soli il più possibile. Un esempio di base di ciò potrebbe essere la collaborazione con i product manager e gli esperti di marketing per creare query predefinite in uno strumento come Tableau, in modo che le domande più frequenti possano essere risolte con un clic di un pulsante. I team di prodotto e di marketing possono anche utilizzare una piattaforma di analisi digitale self-service come Amplitude per creare grafici e analizzare autonomamente il comportamento dei clienti.

Principali comportamenti collaborativi di questo team:

• Lavorare con i product manager per capire di più sulle persone dietro i dati: possono lavorare con dati astratti, senza sapere molto sugli utenti finali, ma saranno tanto più efficaci se avranno una maggiore comprensione del motivo per cui questi dati sono importanti
• Facilitare conversazioni stimolanti su quali domande è più utile porre ai dati e su ciò che gli altri team vogliono tenere traccia (ad es. sapere quando respingere se i team chiedono di raccogliere più dati del necessario)

Sviluppatori

Naturalmente, gli sviluppatori sono quelli che stanno effettivamente costruendo il prodotto e quindi implementando il tuo piano di tracciamento. Tecnicamente parlando, un ingegnere del software non deve sapere molto del settore in cui operi o del comportamento dell'utente finale. Questo non è vero su tutta la linea e ha portato a supporre che gli sviluppatori non si preoccupino dell'analisi.

In realtà, un team di ingegneri può avere difficoltà a entrare a far parte dell'analisi in modo significativo se non è in atto un processo collaborativo sistematizzato. Quando si crea una nuova funzionalità, ricevere un foglio di calcolo di quali eventi tenere traccia può essere frustrante perché rappresenta un'enorme interruzione del flusso di lavoro. Passare avanti e indietro tra un IDE, un foglio di calcolo e un ticket Jira è ingombrante e porta molto facilmente a errori e incoerenze.

È molto più probabile che i buoni sviluppatori si preoccupino delle prestazioni dei prodotti che creano: sanno anche più di chiunque altro come funziona effettivamente il prodotto, quindi sono meglio attrezzati per implementare il piano di monitoraggio nel modo più efficace.

Principali comportamenti collaborativi di questo team:

• Assicurarsi che i product manager comprendano i limiti dell'infrastruttura dei loro prodotti, quando e dove il monitoraggio è appropriato e quanto tempo potrebbe richiedere l'implementazione
• Lavorare a stretto contatto con gli analisti per creare pipeline di dati e analisi e assicurarsi che tutto vada dove dovrebbe andare
• Aiutare tutti gli altri team a capire che per monitorare gli eventi in modo efficace, hanno bisogno di tempo per integrare il monitoraggio nelle funzionalità fin dall'inizio, non come ripensamento

Promuovere la collaborazione sul monitoraggio dell'analisi

Con questa ampia comprensione di come i team possono lavorare insieme sul monitoraggio dell'analisi, dovrebbe essere più facile iniziare a sviluppare un processo collaborativo. È abbastanza chiaro che se tutti lavorano per costruire e mantenere lo stesso prodotto, la comunicazione tra i team sarà estremamente importante.

Inizia a pensare alla tua analisi come a un punto chiave di progettazione nel back-end del tuo prodotto. Non è solo qualcosa su cui aggiri una volta che hai spedito una funzionalità, ma è parte integrante dell'SDLC.

Molte aziende, in particolare nel settore tecnologico, si sentiranno già a loro agio nell'usare strumenti di collaborazione e condivisione delle conoscenze come Jira, Slack e, naturalmente, Amplitude. Se sei appassionato di adottare processi collaborativi più forti nella tua organizzazione, ti consigliamo di costruire il tuo caso per i disposti . Ottenere il buy-in per nuovi processi è spesso la parte più difficile.

Non c'è bisogno di reinventare la ruota. Applicare processi esistenti che già funzionano.

Molto spesso, l'adozione di nuovi processi (come la collaborazione efficace sull'analisi) non ha quasi nulla a che fare con la tecnologia e ha tutto a che fare con la cultura. Quando si tratta di analisi, la conoscenza non esisterà in una singola persona o in un team: tutti devono lavorare insieme per ottenere il massimo dai tuoi dati.

È importante notare che nessuno adotterà un nuovo processo (non importa quanto sia buono) a meno che non ne capisca il senso. In pratica, un ottimo modo per ottenere il consenso di tutta l'azienda su un nuovo processo è dimostrare il valore di quel processo, confrontandolo con altri preesistenti. Un paio di esempi:

GitHub: Non penso che esagererei se dicessi che praticamente ogni persona/azienda/organizzazione che sta creando software utilizza GitHub. È un processo molto elegante, ma hard-coded: ogni pezzo di codice scritto è soggetto a branch, commit e merge. Quindi Github in realtà è meno simile a uno strumento e più simile a un processo: semplicemente non funzionerebbe se tutti non lo usassero.

Figma: uno strumento che dimostra perfettamente la perfetta collaborazione tra team; Figma consente ai progettisti di prodotti di consegnare prototipi agli sviluppatori che mostrano chiaramente come tutti gli elementi si incastrano. Suggerimento: utilizzare l'Amplitude Event Planner in Figma.

Amplitude è qui per aiutarti a collaborare

È utile pensare alle funzionalità di governance dei dati di Amplitude come GitHub per le tue analisi. Amplitude facilita un processo trasparente e verificabile relativo alla pianificazione degli eventi in cui tutti i principali stakeholder possono essere coinvolti indipendentemente dalle capacità tecniche.

I processi migliori sono quelli che non noti nemmeno: disponiamo di strumenti per sviluppatori in modo che il flusso di lavoro di nessuno venga interrotto, consentendo agli ingegneri di implementare in modo semplice e accurato il monitoraggio dell'analisi con SDK indipendenti dai tipi e open source, una CLI e CI/CD integrazione.

Amplitude è prima di tutto una piattaforma collaborativa, che applica una fonte di verità affidabile per l'analisi. Ciò significa che coloro che consumano i dati sanno che possono fidarsi. Se hai ottenuto un consenso significativo per nuovi processi collaborativi, Amplitude può certamente svolgere un ruolo nel supportarlo. Richiedi una demo gratuita e inizia oggi la tua esplorazione.