Hi ha centenars d'articles a Internet sobre els avantatges d'analitzar el comportament dels clients. Sovint això es refereix al sector minorista. Des d'anàlisi de cistella d'aliments, anàlisi ABC i XYZ fins a màrqueting de retenció i ofertes personals. Durant dècades s'han utilitzat diverses tècniques, s'han pensat els algorismes, s'ha escrit i depurat el codi: preneu-lo i utilitzeu-lo. En el nostre cas, va sorgir un problema fonamental: nosaltres a ISPsystem ens dediquem al desenvolupament de programari, no al detall.
Em dic Denis i actualment sóc responsable del backend dels sistemes analítics a ISPsystem. I aquesta és la història de com el meu company i jo —els responsables de la visualització de dades— van intentar mirar els nostres productes de programari a través del prisma d'aquest coneixement. Comencem, com és habitual, per la història.
Al principi hi havia una paraula, i la paraula era "Ho intentem?"
En aquell moment estava treballant com a desenvolupador al departament d'R+D. Tot va començar quan Danil va llegir aquí a Habré — una eina per analitzar les transicions dels usuaris a les aplicacions. Jo era una mica escèptic sobre la idea d'utilitzar-lo aquí. Com a exemples, els desenvolupadors de la biblioteca van citar una anàlisi d'aplicacions on l'acció objectiu estava clarament definida: fer una comanda o alguna altra variació de com pagar a l'empresa propietaria. Els nostres productes es subministren on-premise. És a dir, l'usuari compra primer una llicència i només llavors comença el seu viatge a l'aplicació. Sí, tenim versions de demostració. Podeu provar el producte allà per no tenir un porc a la boca.
Però la majoria dels nostres productes estan dirigits al mercat d'allotjament. Es tracta de grans clients i el departament de desenvolupament empresarial els assessora sobre les capacitats del producte. També es dedueix que en el moment de la compra, els nostres clients ja saben quins problemes els ajudarà a resoldre el nostre programari. Les seves rutes a l'aplicació han de coincidir amb el CJM incrustat al producte, i les solucions d'UX els ajudaran a mantenir-se en el bon camí. Spoiler: això no sempre passa. La presentació a la biblioteca es va ajornar... però no per molt de temps.
Tot va canviar amb el llançament de la nostra startup: — plataformes per crear una botiga en línia des d'un compte d'Instagram. En aquesta aplicació, l'usuari tenia un període de dues setmanes per utilitzar totes les funcionalitats de forma gratuïta. Llavors vau haver de decidir si us subscriviu. I això encaixa perfectament en el concepte d'acció "ruta-objectiu". Es va decidir: ho intentem!
Primers resultats o d'on treure idees
L'equip de desenvolupament i jo vam connectar el producte al sistema de recollida d'esdeveniments literalment en un dia. De seguida diré que ISPsystem utilitza el seu propi sistema per recopilar esdeveniments sobre visites a la pàgina, però res no us impedeix utilitzar Yandex.Metrica per a les mateixes finalitats, la qual cosa us permet descarregar dades en brut de forma gratuïta. Es van estudiar exemples d'ús de la biblioteca i després d'una setmana de recollida de dades vam rebre un gràfic de transició.
Gràfic de transició. Funcionalitat bàsica, altres transicions eliminades per a més claredat
Va resultar igual que a l'exemple: pla, clar, bonic. A partir d'aquest gràfic hem pogut identificar les rutes i travessies més freqüents on la gent passa més temps. Això ens va permetre entendre el següent:
- En lloc d'un gran CJM, que cobreix una dotzena d'entitats, només s'utilitzen dues de manera activa. També cal dirigir els usuaris als llocs que necessitem mitjançant solucions UX.
- Algunes pàgines, dissenyades per dissenyadors d'UX per ser d'extrem a extrem, acaben amb la gent que hi passa una quantitat de temps no raonable. Heu d'esbrinar quins són els elements de parada en una pàgina específica i ajustar-los.
- Després de 10 transicions, el 20% de la gent va començar a cansar-se i va abandonar la sessió a l'aplicació. I això és tenint en compte el fet que teníem fins a 5 pàgines d'incorporació a l'aplicació! Heu d'identificar pàgines on els usuaris abandonen les sessions regularment i escurçar-hi el camí. Encara millor: identifiqueu les rutes habituals i permeteu una transició ràpida de la pàgina d'origen a la pàgina de destinació. Alguna cosa en comú amb l'anàlisi ABC i l'anàlisi del carro abandonat, no creieu?
I aquí vam reconsiderar la nostra actitud davant l'aplicabilitat d'aquesta eina per als productes locals. Es va decidir analitzar un producte venut i utilitzat activament - . És molt més complex, hi ha un ordre de magnitud més d'entitats. Estàvem esperant amb il·lusió veure quin seria el gràfic de transició.
Sobre decepcions i inspiracions
Decepció #1
Era el final de la jornada laboral, el final de mes i el final de l'any alhora, el 27 de desembre. S'han acumulat dades, s'han escrit consultes. Quedaven uns segons perquè tot es processés i vam poder veure el resultat de la nostra feina per saber on començaria el proper any laboral. El departament d'R+D, el responsable de producte, els dissenyadors d'UX, el cap d'equip, els desenvolupadors es van reunir davant del monitor per veure com són els camins dels usuaris al seu producte, però... vam veure això:
Gràfic de transició construït per la biblioteca Retentioneering
Inspiració #1
Fortament connectat, desenes d'entitats, escenaris no evidents. Només estava clar que el nou any laboral començaria no amb l'anàlisi, sinó amb la invenció d'una manera de simplificar el treball amb un gràfic d'aquest tipus. Però no vaig poder desfer la sensació que tot era molt més senzill del que semblava. I després de quinze minuts d'estudiar el codi font de Retentioneering, vam poder exportar el gràfic construït a format de punt. Això va permetre carregar el gràfic a una altra eina: Gephi. I ja hi ha marge per analitzar gràfics: dissenys, filtres, estadístiques: tot el que heu de fer és configurar els paràmetres necessaris a la interfície. Amb aquesta idea en ment, vam marxar per cap de setmana de Cap d'Any.
Decepció #2
Després de tornar a la feina, va resultar que mentre tothom descansava, els nostres clients estaven estudiant el producte. Sí, tan dur que van aparèixer esdeveniments a l'emmagatzematge que abans no existien. Això significava que les consultes s'havien d'actualitzar.
Un petit antecedent per entendre la tristesa d'aquest fet. Transmetem tant els esdeveniments que hem marcat (per exemple, clics en alguns botons) com els URL de les pàgines que l'usuari ha visitat. En el cas de Cartbee, el model "una acció - una pàgina" va funcionar. Però amb VMmanager la situació era completament diferent: es podien obrir diverses finestres modals en una pàgina. En ells l'usuari podria resoldre diversos problemes. Per exemple, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
significa que a la pàgina "Adreces IP" l'usuari ha afegit una adreça IP. I aquí es veuen dos problemes alhora:
- L'URL conté algun tipus de paràmetre de ruta: l'ID de la màquina virtual. Cal excloure'l.
- L'URL conté l'ID de la finestra modal. Heu de "descomprimir" aquests URL d'alguna manera.
Un altre problema va ser que els mateixos esdeveniments que vam marcar tenien paràmetres. Per exemple, hi havia cinc maneres diferents d'arribar a la pàgina amb informació sobre una màquina virtual de la llista. En conseqüència, es va enviar un esdeveniment, però amb un paràmetre que indicava quin mètode l'usuari va fer la transició. Hi va haver molts esdeveniments d'aquest tipus, i tots els paràmetres eren diferents. I tenim tota la lògica de recuperació de dades en el dialecte SQL per a Clickhouse. Les consultes de 150-200 línies començaven a semblar una mica habituals. Els problemes ens envoltaven.
Inspiració #2
Un matí d'hora, Danil, desplaçant-se tristament per la sol·licitud durant el segon minut, em va suggerir: "Anem a escriure canalitzacions de processament de dades?" Ho vam pensar i vam decidir que, si ho faríem, seria una cosa així com ETL. De manera que es filtra immediatament i extreu les dades necessàries d'altres fonts. Així és com va néixer el nostre primer servei analític amb un backend complet. Implementa cinc etapes principals del processament de dades:
- Descàrrega d'esdeveniments de l'emmagatzematge de dades en brut i preparant-los per al seu processament.
- L'aclariment és el "desempaquetament" d'aquests mateixos identificadors de finestres modals, paràmetres d'esdeveniment i altres detalls que aclareixen l'esdeveniment.
- L'enriquiment (de la paraula "fer-se ric") és l'addició d'esdeveniments amb dades de fonts de tercers. En aquell moment, això només incloïa el nostre sistema de facturació BILLmanager.
- El filtratge és el procés de filtració d'esdeveniments que distorsionen els resultats de l'anàlisi (esdeveniments de l'estand intern, valors atípics, etc.).
- Càrrega d'esdeveniments rebuts a l'emmagatzematge, que hem anomenat dades netes.
Ara era possible mantenir la rellevància afegint regles per processar un esdeveniment o fins i tot grups d'esdeveniments similars. Per exemple, des de llavors no hem actualitzat mai el desempaquetat d'URL. Tot i que, durant aquest temps s'han afegit diverses variacions d'URL noves. Compleixen les normes ja establertes en el servei i es tracten correctament.
Decepció #3
Un cop vam començar a analitzar, ens vam adonar per què el gràfic era tan coherent. El fet és que gairebé tots els N-gram contenien transicions que no es podien dur a terme mitjançant la interfície.
Va començar una petita investigació. Estava confós que no hi hagués transicions impossibles dins d'una entitat. Això vol dir que no es tracta d'un error al sistema de recollida d'esdeveniments o al nostre servei ETL. Hi havia la sensació que l'usuari treballava simultàniament en diverses entitats, sense passar d'una a l'altra. Com aconseguir-ho? Ús de diferents pestanyes al navegador.
Quan vam analitzar Cartbee, ens va salvar la seva especificitat. L'aplicació es va utilitzar des de dispositius mòbils, on treballar des de diverses pestanyes és simplement inconvenient. Aquí tenim un escriptori i mentre s'està realitzant una tasca en una entitat, és raonable voler passar aquest temps configurant o supervisant l'estat en una altra. I per no perdre el progrés, només cal que obriu una altra pestanya.
Inspiració #3
Els companys del desenvolupament frontal van ensenyar el sistema de recollida d'esdeveniments per distingir entre pestanyes. L'anàlisi podria començar. I vam començar. Com era d'esperar, CJM no coincidia amb camins reals: els usuaris passaven molt de temps a pàgines de directoris, sessions abandonades i pestanyes als llocs més inesperats. Mitjançant l'anàlisi de transicions, vam poder trobar problemes en algunes compilacions de Mozilla. En ells, per característiques d'implementació, van desaparèixer elements de navegació o es mostraven pàgines mig buides, que només haurien de ser accessibles per l'administrador. S'ha obert la pàgina, però no ha arribat cap contingut del backend. El recompte de transicions va permetre avaluar quines característiques s'utilitzaven realment. Les cadenes van permetre entendre com l'usuari va rebre aquest o aquell error. Les dades permeten fer proves en funció del comportament de l'usuari. Va ser un èxit, la idea no va ser en va.
Automatització analítica
En una de les demostracions de resultats, vam mostrar com s'utilitza Gephi per a l'anàlisi de gràfics. En aquesta eina, les dades de conversió es poden mostrar en una taula. I el cap del departament d'UX va dir un pensament molt important que va influir en el desenvolupament de tota la direcció d'anàlisi del comportament a l'empresa: "Fem el mateix, però a Tableau i amb filtres, serà més convenient".
Aleshores vaig pensar: per què no, Retentioneering emmagatzema totes les dades en una estructura pandas.DataFrame. I això és, en general, una taula. Així va aparèixer un altre servei: Proveïdor de dades. No només va fer una taula a partir del gràfic, sinó que també va calcular la popularitat de la pàgina i la funcionalitat associada a ella, com afecta la retenció dels usuaris, quant de temps hi romanen els usuaris i quines pàgines surten amb més freqüència. I l'ús de la visualització a Tableau va reduir tant el cost d'estudiar el gràfic que el temps d'iteració per a l'anàlisi del comportament del producte es va reduir gairebé a la meitat.
En Danil parlarà de com s'utilitza aquesta visualització i quines conclusions permet treure.
Més taules per al déu de la taula!
D'una forma simplificada, la tasca es va formular de la següent manera: mostrar el gràfic de transició a Tableau, proporcionar la capacitat de filtrar i fer-lo el més clar i còmode possible.
Realment no volia dibuixar un gràfic dirigit al Tableau. I encara que tingués èxit, el guany, en comparació amb Gephi, no semblava obvi. Necessitàvem una cosa molt més senzilla i accessible. Taula! Després de tot, el gràfic es pot representar fàcilment en forma de files de taula, on cada fila és una vora del tipus "font-destinació". A més, ja hem preparat acuradament una taula d'aquest tipus mitjançant eines de retenció i proveïdors de dades. Tot el que quedava per fer era mostrar la taula a Tableau i remenar l'informe.
Parlant de com a tothom li agraden les taules.
No obstant això, aquí ens trobem davant d'un altre problema. Què fer amb la font de dades? Era impossible connectar pandas.DataFrame; Tableau no té aquest connector. Aixecar una base separada per emmagatzemar el gràfic semblava una solució massa radical amb perspectives vagues. I les opcions de descàrrega local no eren adequades a causa de la necessitat d'operacions manuals constants. Vam mirar la llista de connectors disponibles i la nostra mirada va caure sobre l'element , que s'amuntegava desesperadament al fons.
Tableau té una àmplia selecció de connectors. Vam trobar un que va resoldre el nostre problema
Quin tipus d'animal? Unes quantes pestanyes obertes noves al navegador, i va quedar clar que aquest connector us permet rebre dades en accedir a una URL. El backend per calcular les dades en si ja estava gairebé a punt, només quedava fer-ho amistat amb WDC. Durant uns quants dies, el Denis va estudiar la documentació i va lluitar amb els mecanismes de Tableau, i després em va enviar un enllaç que vaig enganxar a la finestra de connexió.
Formulari de connexió al nostre WDC. Denis va fer el seu front i es va ocupar de la seguretat
Després d'un parell de minuts d'espera (les dades es calculen dinàmicament quan se'ls demana), va aparèixer la taula:
Així es veu una matriu de dades en brut a la interfície de Tableau
Tal com s'havia promès, cada fila d'aquesta taula representava una vora del gràfic, és a dir, una transició dirigida de l'usuari. També contenia diverses característiques addicionals. Per exemple, el nombre d'usuaris únics, el nombre total de transicions i altres.
Seria possible mostrar aquesta taula a l'informe tal qual, ruixar generosos filtres i enviar l'eina navegant. Sona lògic. Què pots fer amb la taula? Però aquesta no és la nostra manera, perquè no estem fent només una taula, sinó una eina per analitzar i prendre decisions de producte.
Normalment, quan s'analitza dades, una persona vol obtenir respostes a les preguntes. Genial. Comencem per ells.
- Quines són les transicions més freqüents?
- On van de pàgines concretes?
- Quant de temps passes de mitjana en aquesta pàgina abans de marxar?
- Amb quina freqüència fas la transició d'A a B?
- En quines pàgines acaba la sessió?
Cadascun dels informes o una combinació d'ells ha de permetre a l'usuari trobar respostes a aquestes preguntes de manera independent. L'estratègia clau aquí és donar-vos les eines per fer-ho vosaltres mateixos. Això és útil tant per reduir la càrrega del departament d'anàlisi com per reduir el temps per prendre decisions; després de tot, ja no cal que aneu a Youtrack i creeu una tasca per a l'analista, només cal que obriu l'informe.
Què hem aconseguit?
On divergeixen la gent amb més freqüència del tauler?
Fragment del nostre informe. Després del tauler, tothom va anar a la llista de màquines virtuals o a la llista de nodes
Prenguem una taula general amb transicions i filtrem per pàgina d'origen. Molt sovint, passen del tauler de control a la llista de màquines virtuals. A més, la columna Regularitat suggereix que es tracta d'una acció repetida.
D'on surten a la llista de clústers?
Els filtres dels informes funcionen en ambdues direccions: podeu esbrinar on heu sortit o on heu anat
A partir dels exemples és evident que fins i tot la presència de dos filtres senzills i files de classificació per valors permeten obtenir informació ràpidament.
Demanem una cosa més complicada.
On abandonen la sessió amb més freqüència els usuaris?
Els usuaris de VMmanager sovint treballen en pestanyes separades
Per fer-ho, necessitem un informe les dades del qual s'agreguin per fonts de referència. I els anomenats punts de ruptura es van prendre com a assignacions, esdeveniments que van servir com a final de la cadena de transicions.
És important tenir en compte aquí que pot ser el final de la sessió o l'obertura d'una pestanya nova. L'exemple mostra que la cadena més sovint acaba en una taula amb una llista de màquines virtuals. En aquest cas, el comportament característic és canviar a una altra pestanya, que és coherent amb el patró esperat.
En primer lloc vam comprovar la utilitat d'aquests informes sobre nosaltres mateixos quan vam fer l'anàlisi d'una manera similar. , un altre dels nostres productes. Amb l'aparició de taules i filtres, les hipòtesis es van provar més ràpidament i els ulls estaven menys cansats.
En desenvolupar informes, no ens hem oblidat del disseny visual. Quan es treballa amb taules d'aquesta mida, aquest és un factor important. Per exemple, hem utilitzat una gamma de colors tranquil·la, fàcil de percebre per als números, ressaltat en color de les línies d'acord amb els valors numèrics de les característiques. Aquests detalls milloren l'experiència de l'usuari i augmenten la probabilitat que l'eina surti amb èxit dins de l'empresa.
La taula va resultar ser força voluminosa, però esperem que no hagi deixat de ser llegible
Val la pena esmentar per separat la formació dels nostres clients interns: especialistes de producte i dissenyadors UX. Es van preparar manuals amb exemples d'anàlisi i consells per treballar amb filtres especialment per a ells. Hem inserit enllaços a manuals directament a les pàgines dels informes.
Hem fet el manual simplement com a presentació a Google Docs. Les eines del quadre us permeten mostrar pàgines web directament dins d'un llibre de treball d'informes.
En lloc d'un terme final
Què hi ha al fons? Hem pogut aconseguir una eina per a cada dia de manera relativament ràpida i econòmica. Sí, definitivament no substitueix el gràfic en si, el mapa de calor de clics o el visor web. Però aquests informes complementen significativament les eines enumerades i proporcionen elements per pensar i hipòtesis de nous productes i interfícies.
Aquesta història només va servir com a principi per al desenvolupament de l'anàlisi al sistema ISP. Durant els darrers sis mesos, han aparegut set serveis nous més, entre els quals hi ha retrats digitals de l'usuari al producte i un servei de creació de bases de dades per a l'orientació semblant, però en parlarem en els següents episodis.
Font: www.habr.com