Esistono centinaia di articoli su Internet sui vantaggi dell'analisi del comportamento dei clienti. Molto spesso ciò riguarda il settore della vendita al dettaglio. Dall'analisi del paniere alimentare, analisi ABC e XYZ al marketing di fidelizzazione e alle offerte personali. Per decenni sono state utilizzate varie tecniche, gli algoritmi sono stati pensati, il codice è stato scritto ed è stato eseguito il debug: prendilo e usalo. Nel nostro caso è sorto un problema fondamentale: noi di ISPsystem siamo impegnati nello sviluppo di software, non nella vendita al dettaglio.
Mi chiamo Denis e attualmente sono responsabile del backend dei sistemi analitici presso ISPsystem. E questa è la storia di come io e il mio collega - i responsabili della visualizzazione dei dati - hanno provato a guardare i nostri prodotti software attraverso il prisma di questa conoscenza. Cominciamo, come al solito, dalla storia.
All’inizio c’era una parola, e la parola era “Ci proviamo?”
In quel momento lavoravo come sviluppatore nel dipartimento di ricerca e sviluppo. Tutto è iniziato quando Danil ha letto qui su Habré — uno strumento per analizzare le transizioni degli utenti nelle applicazioni. Ero un po' scettico sull'idea di usarlo qui. Come esempio, gli sviluppatori della libreria hanno citato un'analisi di applicazioni in cui l'azione target era chiaramente definita: effettuare un ordine o qualche altra variazione su come pagare l'azienda proprietaria. I nostri prodotti vengono forniti in sede. Cioè, l'utente acquista prima una licenza e solo dopo inizia il suo viaggio nell'applicazione. Sì, abbiamo versioni demo. Puoi provare il prodotto lì in modo da non avere un maiale in un colpo.
Ma la maggior parte dei nostri prodotti sono rivolti al mercato dell’hosting. Si tratta di grandi clienti e il dipartimento di sviluppo aziendale fornisce loro consulenza sulle capacità del prodotto. Ne consegue inoltre che al momento dell'acquisto i nostri clienti sanno già quali problemi il nostro software li aiuterà a risolvere. I loro percorsi nell'applicazione devono coincidere con il CJM incorporato nel prodotto e le soluzioni UX li aiuteranno a rimanere sulla strada giusta. Spoiler: non sempre succede. L'introduzione alla biblioteca è stata rinviata... ma non per molto.
Tutto è cambiato con il rilascio della nostra startup - — piattaforme per la creazione di un negozio online da un account Instagram. In questa applicazione, all'utente veniva concesso un periodo di due settimane per utilizzare tutte le funzionalità gratuitamente. Poi dovevi decidere se iscriverti. E questo rientra perfettamente nel concetto di “azione-bersaglio percorso”. Si è deciso: proviamoci!
Primi risultati o da dove prendere idee
Io e il team di sviluppo abbiamo collegato il prodotto al sistema di raccolta eventi letteralmente in un giorno. Dirò subito che ISPsystem utilizza il proprio sistema per raccogliere eventi sulle visite alle pagine, ma nulla ti impedisce di utilizzare Yandex.Metrica per gli stessi scopi, che ti consente di scaricare gratuitamente i dati grezzi. Sono stati studiati esempi di utilizzo della libreria e dopo una settimana di raccolta dati abbiamo ricevuto un grafico di transizione.
Grafico di transizione. Funzionalità di base, altre transizioni rimosse per chiarezza
Il risultato è proprio come nell'esempio: planare, chiaro, bello. Da questo grafico siamo stati in grado di identificare i percorsi e gli incroci più frequenti dove le persone trascorrono più tempo. Ciò ci ha permesso di comprendere quanto segue:
- Invece di un ampio CJM, che copre una dozzina di entità, solo due vengono utilizzate attivamente. È necessario indirizzare ulteriormente gli utenti verso i luoghi di cui abbiamo bisogno utilizzando soluzioni UX.
- Alcune pagine, progettate dai progettisti UX per essere end-to-end, finiscono con il fatto che le persone trascorrono su di esse una quantità irragionevole di tempo. Devi capire quali sono gli elementi di arresto su una pagina specifica e modificarli.
- Dopo 10 transizioni, il 20% delle persone ha iniziato a stancarsi e ha abbandonato la sessione nell'applicazione. E questo tenendo conto del fatto che nell'applicazione avevamo ben 5 pagine di onboarding! È necessario identificare le pagine in cui gli utenti abbandonano regolarmente le sessioni e abbreviare il percorso verso di esse. Ancora meglio: identifica eventuali percorsi regolari e consenti una rapida transizione dalla pagina di origine alla pagina di destinazione. Qualcosa in comune con l’analisi ABC e l’analisi dei carrelli abbandonati, non credi?
E qui abbiamo riconsiderato il nostro atteggiamento nei confronti dell'applicabilità di questo strumento per i prodotti on-premise. Si è deciso di analizzare un prodotto venduto e utilizzato attivamente: . È molto più complesso, ci sono un ordine di grandezza in più di entità. Stavamo aspettando con entusiasmo di vedere quale sarebbe stato il grafico di transizione.
A proposito di delusioni e ispirazioni
Delusione n. 1
Era la fine della giornata lavorativa, la fine del mese e la fine dell'anno allo stesso tempo: il 27 dicembre. I dati sono stati accumulati, le query sono state scritte. Mancavano pochi secondi prima che tutto fosse elaborato e potessimo guardare il risultato del nostro lavoro per scoprire dove sarebbe iniziato il prossimo anno lavorativo. Il dipartimento di ricerca e sviluppo, il product manager, i progettisti UX, il team leader e gli sviluppatori si sono riuniti davanti al monitor per vedere come appaiono i percorsi degli utenti nel loro prodotto, ma... abbiamo visto questo:
Grafico di transizione costruito dalla libreria Retentioneering
Ispirazione n.1
Fortemente connesse, decine di entità, scenari non ovvi. Era solo chiaro che il nuovo anno lavorativo non sarebbe iniziato con l'analisi, ma con l'invenzione di un modo per semplificare il lavoro con un grafico del genere. Ma non potevo liberarmi della sensazione che tutto fosse molto più semplice di quanto sembrasse. E dopo quindici minuti di studio del codice sorgente di Retentioneering, siamo stati in grado di esportare il grafico costruito in formato punto. Ciò ha permesso di caricare il grafico su un altro strumento: Gephi. E c'è già spazio per analizzare i grafici: layout, filtri, statistiche: tutto ciò che devi fare è configurare i parametri necessari nell'interfaccia. Con questo pensiero in mente siamo partiti per il week-end di Capodanno.
Delusione n. 2
Dopo essere tornati al lavoro, si è scoperto che mentre tutti riposavano, i nostri clienti stavano studiando il prodotto. Sì, così difficile che nella memoria siano comparsi eventi che prima non esistevano. Ciò significava che le query dovevano essere aggiornate.
Un piccolo retroscena per comprendere la tristezza di questo fatto. Trasmettiamo sia gli eventi che abbiamo contrassegnato (ad esempio, i clic su alcuni pulsanti) sia gli URL delle pagine che l'utente ha visitato. Nel caso di Cartbee, il modello “un’azione – una pagina” ha funzionato. Ma con VMManager la situazione era completamente diversa: su una pagina si potevano aprire più finestre modali. In essi l'utente potrebbe risolvere vari problemi. Ad esempio, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
significa che nella pagina “Indirizzi IP” l'utente ha aggiunto un indirizzo IP. E qui due problemi sono visibili contemporaneamente:
- L'URL contiene una sorta di parametro di percorso: l'ID della macchina virtuale. È necessario escluderlo.
- L'URL contiene l'ID della finestra modale. È necessario in qualche modo “decomprimere” tali URL.
Un altro problema era che gli stessi eventi che contrassegnavamo avevano dei parametri. Ad esempio, esistevano cinque modi diversi per accedere alla pagina con le informazioni su una macchina virtuale dall'elenco. Di conseguenza, è stato inviato un evento, ma con un parametro che indicava quale metodo l'utente ha effettuato la transizione. Ci sono stati molti di questi eventi e tutti i parametri erano diversi. E abbiamo tutta la logica di recupero dei dati nel dialetto SQL per Clickhouse. Le query di 150-200 righe cominciavano a sembrare piuttosto comuni. I problemi ci circondavano.
Ispirazione n.2
Una mattina presto, Danil, scorrendo tristemente la richiesta per il secondo minuto, mi ha suggerito: "Scriviamo pipeline di elaborazione dati?" Ci abbiamo pensato e abbiamo deciso che, se lo avessimo fatto, sarebbe stato qualcosa di simile a ETL. In questo modo filtra immediatamente e recupera i dati necessari da altre fonti. È così che è nato il nostro primo servizio analitico con un backend completo. Implementa cinque fasi principali del trattamento dei dati:
- Scaricare gli eventi dall'archivio dei dati grezzi e prepararli per l'elaborazione.
- La chiarificazione è il "disimballaggio" di quegli stessi identificatori di finestre modali, parametri di evento e altri dettagli che chiariscono l'evento.
- L'arricchimento (dalla parola “diventare ricchi”) è l'aggiunta di eventi con dati provenienti da fonti terze. All'epoca questo includeva solo il nostro sistema di fatturazione BILLmanager.
- Il filtraggio è il processo di filtraggio degli eventi che distorcono i risultati dell'analisi (eventi provenienti da stand interni, valori anomali, ecc.).
- Caricamento degli eventi ricevuti nell'archivio, che abbiamo chiamato dati puliti.
Ora era possibile mantenere la pertinenza aggiungendo regole per l'elaborazione di un evento o anche di gruppi di eventi simili. Ad esempio, da allora non abbiamo mai aggiornato il decompressione degli URL. Tuttavia, durante questo periodo sono state aggiunte diverse nuove varianti di URL. Rispettano le regole già previste nel servizio e sono trattati correttamente.
Delusione n. 3
Una volta iniziata l'analisi, abbiamo capito perché il grafico era così coerente. Il fatto è che quasi ogni N-grammo conteneva transizioni che non potevano essere eseguite attraverso l'interfaccia.
È iniziata una piccola indagine. Ero confuso dal fatto che non esistessero transizioni impossibili all'interno di un'entità. Ciò significa che non si tratta di un bug nel sistema di raccolta eventi o nel nostro servizio ETL. C'era la sensazione che l'utente lavorasse contemporaneamente in più entità, senza spostarsi dall'una all'altra. Come raggiungere questo obiettivo? Utilizzando diverse schede nel browser.
Analizzando Cartbee, siamo stati salvati dalla sua specificità. L'applicazione è stata utilizzata da dispositivi mobili, dove lavorare da più schede è semplicemente scomodo. Qui abbiamo un desktop e mentre un'attività viene eseguita in un'entità, è ragionevole voler dedicare questo tempo alla configurazione o al monitoraggio dello stato in un'altra. E per non perdere i progressi, basta aprire un'altra scheda.
Ispirazione n.3
I colleghi dello sviluppo front-end hanno insegnato al sistema di raccolta eventi a distinguere tra le schede. L'analisi potrebbe iniziare. E abbiamo iniziato. Come previsto, CJM non corrispondeva a percorsi reali: gli utenti trascorrevano molto tempo su pagine di directory, sessioni abbandonate e schede nei luoghi più inaspettati. Usando l'analisi delle transizioni, siamo riusciti a trovare problemi in alcune build di Mozilla. In essi, a causa delle funzionalità di implementazione, gli elementi di navigazione sono scomparsi o sono state visualizzate pagine semivuote, che dovrebbero essere accessibili solo all'amministratore. La pagina si è aperta, ma dal backend non è arrivato alcun contenuto. Il conteggio delle transizioni ha permesso di valutare quali funzionalità sono state effettivamente utilizzate. Le catene hanno permesso di capire come l'utente ha ricevuto questo o quell'errore. I dati consentiti per il test in base al comportamento dell'utente. È stato un successo, l'idea non è stata vana.
Automazione dell'analisi
In una delle dimostrazioni dei risultati, abbiamo mostrato come Gephi viene utilizzato per l'analisi dei grafici. In questo strumento, i dati di conversione possono essere visualizzati in una tabella. E il capo del dipartimento UX ha affermato un pensiero molto importante che ha influenzato lo sviluppo dell'intera direzione dell'analisi comportamentale nell'azienda: "Facciamo lo stesso, ma in Tableau e con i filtri: sarà più conveniente".
Poi ho pensato: perché no, Retentioneering memorizza tutti i dati in una struttura pandas.DataFrame. E questo è, in generale, un tavolo. Ecco come è apparso un altro servizio: Data Provider. Non solo ha creato una tabella dal grafico, ma ha anche calcolato quanto sono popolari la pagina e le funzionalità ad essa associate, come influisce sulla fidelizzazione degli utenti, per quanto tempo gli utenti rimangono su di essa e quali pagine gli utenti lasciano più spesso. Inoltre, l'uso della visualizzazione in Tableau ha ridotto così tanto i costi di studio del grafico che il tempo di iterazione per l'analisi del comportamento nel prodotto è stato quasi dimezzato.
Danil parlerà di come viene utilizzata questa visualizzazione e quali conclusioni consente di trarre.
Più tavoli per il dio della tavola!
In una forma semplificata, l'attività è stata formulata come segue: visualizzare il grafico di transizione in Tableau, fornire la possibilità di filtrare e renderlo il più chiaro e conveniente possibile.
Non volevo davvero disegnare un grafico diretto in Tableau. E anche in caso di successo, il guadagno, rispetto a Gephi, non sembrava evidente. Avevamo bisogno di qualcosa di molto più semplice e accessibile. Tavolo! Dopotutto, il grafico può essere facilmente rappresentato sotto forma di righe di tabella, dove ogni riga è un bordo del tipo “sorgente-destinazione”. Inoltre, abbiamo già preparato attentamente tale tabella utilizzando gli strumenti di Retentioneering e Data Provider. Non restava che visualizzare la tabella in Tableau e frugare nel report.
A proposito di come tutti amano i tavoli.
Qui però ci troviamo di fronte ad un altro problema. Cosa fare con l'origine dati? Era impossibile connettere pandas.DataFrame; Tableau non dispone di tale connettore. Creare una base separata per la memorizzazione del grafico sembrava una soluzione troppo radicale con prospettive vaghe. Inoltre, le opzioni di scarico locale non erano adatte a causa della necessità di operazioni manuali costanti. Abbiamo sfogliato l'elenco dei connettori disponibili e il nostro sguardo è caduto sull'oggetto , che si rannicchiava tristemente in fondo.
Tableau dispone di una ricca selezione di connettori. Ne abbiamo trovato uno che ha risolto il nostro problema
Che tipo di animale? Alcune nuove schede aperte nel browser - ed è diventato chiaro che questo connettore ti consente di ricevere dati quando accedi a un URL. Il backend per il calcolo dei dati stesso era quasi pronto, non restava che renderlo amico del WDC. Per diversi giorni Denis ha studiato la documentazione e ha lottato con i meccanismi di Tableau, per poi inviarmi un link che ho incollato nella finestra di connessione.
Modulo di connessione al nostro WDC. Denis ha fatto il suo ingresso e si è preso cura della sicurezza
Dopo un paio di minuti di attesa (i dati vengono calcolati dinamicamente quando richiesti), è apparsa la tabella:
Ecco come appare un array di dati grezzi nell'interfaccia di Tableau
Come promesso, ciascuna riga di tale tabella rappresentava un bordo del grafico, ovvero una transizione diretta dall'utente. Conteneva anche diverse caratteristiche aggiuntive. Ad esempio, il numero di utenti unici, il numero totale di transizioni e altri.
Sarebbe possibile visualizzare questa tabella nel report così com'è, cospargere generosamente filtri e inviare lo strumento in navigazione. Sembra logico. Cosa puoi fare con il tavolo? Ma questo non è il nostro percorso, perché non stiamo realizzando solo una tabella, ma uno strumento per analizzare e prendere decisioni sui prodotti.
In genere, quando si analizzano i dati, una persona desidera ottenere risposte alle domande. Grande. Cominciamo con loro.
- Quali sono le transizioni più frequenti?
- Dove vanno da pagine specifiche?
- Quanto tempo trascorri in media su questa pagina prima di uscire?
- Quanto spesso effettui il passaggio da A a B?
- Su quali pagine termina la sessione?
Ciascuno dei rapporti o una combinazione di essi dovrebbe consentire all'utente di trovare autonomamente le risposte a queste domande. La strategia chiave qui è darti gli strumenti per farlo da solo. Ciò è utile sia per ridurre il carico sul reparto di analisi sia per ridurre i tempi di presa delle decisioni: dopotutto, non è più necessario andare su Youtrack e creare un'attività per l'analista, basta solo aprire il report.
Cosa abbiamo ottenuto?
Dove le persone si discostano più spesso dal dashboard?
Frammento del nostro rapporto. Dopo la dashboard, tutti sono andati all'elenco delle VM o all'elenco dei nodi
Prendiamo una tabella generale con le transizioni e filtriamo per pagina di origine. Molto spesso vanno dalla dashboard all'elenco delle macchine virtuali. Inoltre, la colonna Regolarità suggerisce che si tratta di un'azione ripetitiva.
Da dove provengono all'elenco dei cluster?
I filtri nei rapporti funzionano in entrambe le direzioni: puoi scoprire dove sei partito o dove sei andato
Dagli esempi è chiaro che anche la presenza di due semplici filtri e la classificazione delle righe per valori permette di ottenere velocemente informazioni.
Chiediamo qualcosa di più difficile.
Dove gli utenti abbandonano più spesso la sessione?
Gli utenti VMManager spesso lavorano in schede separate
Per fare ciò, abbiamo bisogno di un rapporto i cui dati siano aggregati per fonti di riferimento. E i cosiddetti punti di interruzione venivano presi come incarichi: eventi che servivano come fine della catena di transizioni.
È importante notare qui che questa può essere la fine della sessione o l'apertura di una nuova scheda. L'esempio mostra che la catena termina molto spesso con una tabella con un elenco di macchine virtuali. In questo caso, il comportamento caratteristico è il passaggio a un'altra scheda, che è coerente con il modello previsto.
Abbiamo innanzitutto testato su noi stessi l’utilità di questi report effettuando l’analisi in modo simile , un altro dei nostri prodotti. Con l'avvento delle tabelle e dei filtri, le ipotesi venivano testate più velocemente e gli occhi si stancavano meno.
Durante lo sviluppo dei report, non abbiamo dimenticato il design visivo. Quando si lavora con tabelle di queste dimensioni, questo è un fattore importante. Ad esempio, abbiamo utilizzato una gamma di colori calma, facile da percepire per i numeri, evidenziazione colorata delle linee in base ai valori numerici delle caratteristiche. Tali dettagli migliorano l'esperienza dell'utente e aumentano le probabilità che lo strumento decolli con successo all'interno dell'azienda.
La tabella si è rivelata piuttosto voluminosa, ma speriamo che non abbia cessato di essere leggibile
Vale la pena menzionare separatamente la formazione dei nostri clienti interni: specialisti di prodotto e progettisti UX. Per loro sono stati preparati appositamente manuali con esempi di analisi e suggerimenti per lavorare con i filtri. Abbiamo inserito collegamenti ai manuali direttamente nelle pagine dei report.
Abbiamo realizzato il manuale semplicemente come presentazione in Google Docs. Gli strumenti di Tableau ti consentono di visualizzare le pagine Web direttamente all'interno di una cartella di lavoro del report.
Invece di una postfazione
Cosa c'è in fondo? Siamo riusciti a ottenere uno strumento per ogni giorno in modo relativamente rapido ed economico. Sì, questo non sostituisce sicuramente il grafico stesso, la mappa termica dei clic o il visualizzatore web. Ma tali rapporti completano in modo significativo gli strumenti elencati e forniscono spunti di riflessione e ipotesi su nuovi prodotti e interfacce.
Questa storia è servita solo come inizio per lo sviluppo dell'analisi nel sistema ISP. Negli ultimi sei mesi sono apparsi altri sette nuovi servizi, tra cui i ritratti digitali dell'utente nel prodotto e un servizio per la creazione di database per il targeting Look-alike, ma di questi parleremo nelle puntate successive.
Fonte: habr.com