Hai centos de artigos en Internet sobre os beneficios de analizar o comportamento dos clientes. Na maioría das veces, isto afecta ao sector de venda polo miúdo. Desde análise de cestas de alimentos, análises ABC e XYZ ata mercadotecnia de retención e ofertas persoais. Utilizáronse varias técnicas durante décadas, pensáronse os algoritmos, escribiuse e depurouse o código: tómao e utilízao. No noso caso, xurdiu un problema fundamental: nós en ISPsystem dedicámonos ao desenvolvemento de software, non á venda polo miúdo.
Chámome Denis e actualmente son o responsable do backend dos sistemas analíticos en ISPsystem. E esta é a historia de como o meu compañeiro e eu — os responsables da visualización de datos — tentaron mirar os nosos produtos de software a través do prisma deste coñecemento. Comecemos, como é habitual, coa historia.
Ao principio había unha palabra, e a palabra era "Intentamos?"
Nese momento traballaba como programador no departamento de I+D. Todo comezou cando Danil leu aquí en Habré — unha ferramenta para analizar as transicións dos usuarios nas aplicacións. Eu era algo escéptico sobre a idea de usalo aquí. Como exemplos, os desenvolvedores da biblioteca citaron unha análise de aplicacións onde a acción obxectivo estaba claramente definida: facer un pedido ou algunha outra variación de como pagar á empresa propietaria. Os nosos produtos ofrécense no local. É dicir, o usuario compra primeiro unha licenza e só entón comeza a súa viaxe na aplicación. Si, temos versións de demostración. Podes probar o produto alí para que non teñas un porco nun pico.
Pero a maioría dos nosos produtos están dirixidos ao mercado de hospedaxe. Estes son grandes clientes e o departamento de desenvolvemento empresarial aconséllalles sobre as capacidades do produto. Tamén se desprende que no momento da compra, os nosos clientes xa saben que problemas lles axudará a resolver o noso software. As súas rutas na aplicación deben coincidir co CJM incorporado no produto, e as solucións de UX axudarán a manter o camiño correcto. Spoiler: isto non sempre ocorre. A introdución á biblioteca aprazouse... pero non por moito tempo.
Todo cambiou co lanzamento da nosa startup - — plataformas para crear unha tenda en liña desde unha conta de Instagram. Nesta aplicación, o usuario recibiu un período de dúas semanas para usar todas as funcións de forma gratuíta. Despois tiñas que decidir se te subscribías. E isto encaixa perfectamente no concepto de "acción ruta-obxectivo". Decidiuse: imos probar!
Primeiros resultados ou de onde sacar ideas
O equipo de desenvolvemento e eu conectamos o produto ao sistema de recollida de eventos literalmente nun día. Direi de inmediato que ISPsystem usa o seu propio sistema para recoller eventos sobre visitas á páxina, pero nada che impide usar Yandex.Metrica para os mesmos fins, o que che permite descargar datos en bruto de balde. Estudáronse exemplos de uso da biblioteca e despois dunha semana de recollida de datos recibimos un gráfico de transición.
Gráfico de transición. Funcionalidade básica, outras transicións eliminadas para claridade
Resultou igual que no exemplo: plano, claro, fermoso. A partir deste gráfico, puidemos identificar as rutas e travesías máis frecuentes nas que a xente pasa máis tempo. Isto permitiunos comprender o seguinte:
- En lugar dun gran CJM, que abrangue unha ducia de entidades, só se utilizan activamente dúas. É necesario dirixir adicionalmente aos usuarios aos lugares que necesitamos mediante solucións de UX.
- Algunhas páxinas, deseñadas por deseñadores de UX para ser de extremo a extremo, acaban coas persoas que pasan un tempo razoable nelas. Debes descubrir cales son os elementos de parada nunha páxina específica e axustala.
- Despois de 10 transicións, o 20% das persoas comezou a cansarse e abandonar a sesión na aplicación. E isto está tendo en conta o feito de que tiñamos ata 5 páxinas de incorporación na aplicación. Debe identificar páxinas nas que os usuarios abandonan sesións regularmente e acurtar o camiño cara a elas. Aínda mellor: identifica as rutas habituais e permite unha transición rápida da páxina de orixe á páxina de destino. Algo en común coa análise ABC e coa análise do carro abandonado, non cres?
E aquí reconsideramos a nosa actitude ante a aplicabilidade desta ferramenta para produtos locais. Decidiuse analizar un produto vendido e usado activamente - . É moito máis complexo, hai unha orde de magnitude máis entidades. Esperabamos con ilusión ver cal sería o gráfico de transición.
Sobre decepcións e inspiracións
Decepción #1
Era o fin da xornada laboral, o final do mes e o final do ano ao mesmo tempo - o 27 de decembro. Acumuláronse datos, escribiuse consultas. Quedaban segundos para que todo se tramitase e puidemos ver o resultado do noso traballo para saber onde comezaría o seguinte ano laboral. O departamento de I+D, o xefe de produto, os deseñadores de UX, o xefe de equipo, os desenvolvedores reuníronse diante do monitor para ver como son os camiños dos usuarios no seu produto, pero... vimos isto:
Gráfico de transición construído pola biblioteca Retentioneering
Inspiración #1
Fortemente conectado, ducias de entidades, escenarios non obvios. Só estaba claro que o novo ano de traballo comezaría non coa análise, senón coa invención dunha forma de simplificar o traballo con tal gráfico. Pero non podía deixar de pensar que todo era moito máis sinxelo do que parecía. E despois de quince minutos de estudar o código fonte de Retentioneering, puidemos exportar o gráfico construído ao formato de puntos. Isto permitiu cargar o gráfico a outra ferramenta: Gephi. E xa hai espazo para analizar gráficos: esquemas, filtros, estatísticas: todo o que tes que facer é configurar os parámetros necesarios na interface. Con este pensamento, marchamos para a fin de semana de Aninovo.
Decepción #2
Despois de volver ao traballo, resultou que mentres todos descansaban, os nosos clientes estudaban o produto. Si, tan duro que apareceron eventos no almacenamento que antes non existían. Isto significaba que as consultas debían actualizarse.
Un pequeno antecedente para entender a tristeza deste feito. Transmitimos tanto os eventos que marcamos (por exemplo, clics nalgúns botóns) como os URL das páxinas que visitou o usuario. No caso de Cartbee, o modelo "unha acción - unha páxina" funcionou. Pero con VMmanager a situación era completamente diferente: podían abrirse varias fiestras modais nunha mesma páxina. Neles o usuario podería resolver diversos problemas. Por exemplo, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
significa que na páxina "Enderezos IP" o usuario engadiu un enderezo IP. E aquí son visibles dous problemas á vez:
- O URL contén algún tipo de parámetro de ruta: o ID da máquina virtual. Hai que excluír.
- O URL contén o ID da xanela modal. Debes "descomprimir" dalgún xeito tales URL.
Outro problema foi que os mesmos eventos que marcamos tiñan parámetros. Por exemplo, había cinco formas diferentes de acceder á páxina con información sobre unha máquina virtual da lista. En consecuencia, enviouse un evento, pero cun parámetro que indicaba que método fixo o usuario a transición. Houbo moitos eventos deste tipo, e todos os parámetros eran diferentes. E temos toda a lóxica de recuperación de datos no dialecto SQL para Clickhouse. As consultas de 150-200 liñas comezaban a parecer algo habituais. Os problemas rodeáronnos.
Inspiración #2
Unha mañá cedo, Danil, desprazándose tristemente pola solicitude durante un segundo minuto, suxeriume: "¿Escribamos canalizacións de procesamento de datos?" Pensámolo e decidimos que, se o iamos facer, sería algo así como ETL. De xeito que filtra inmediatamente e extrae os datos necesarios doutras fontes. Así naceu o noso primeiro servizo analítico cun backend completo. Implementa cinco etapas principais de tratamento de datos:
- Descarga de eventos do almacenamento de datos brutos e preparalos para o seu procesamento.
- A aclaración é a "descompresión" deses mesmos identificadores das fiestras modais, parámetros do evento e outros detalles que aclaran o evento.
- O enriquecemento (da palabra "facerse rico") é a adición de eventos con datos de fontes de terceiros. Nese momento, só incluía o noso sistema de facturación BILLmanager.
- O filtrado é o proceso de filtrar eventos que distorsionan os resultados da análise (eventos de stands internos, valores atípicos, etc.).
- Cargando eventos recibidos no almacenamento, que chamamos datos limpos.
Agora era posible manter a relevancia engadindo regras para procesar un evento ou mesmo grupos de eventos similares. Por exemplo, desde entón nunca actualizamos o desempaquetado de URL. Aínda que durante este tempo engadíronse varias variacións de URL novas. Cumpre as normas xa establecidas no servizo e tramítanse correctamente.
Decepción #3
Unha vez que comezamos a analizar, decatámonos de por que o gráfico era tan coherente. O feito é que case todos os N-gramas contiñan transicións que non se podían realizar a través da interface.
Comezou unha pequena investigación. Estaba confuso de que non houbese transicións imposibles dentro dunha entidade. Isto significa que non se trata dun erro no sistema de recollida de eventos nin no noso servizo ETL. Había a sensación de que o usuario traballaba simultaneamente en varias entidades, sen pasar dunha a outra. Como conseguir isto? Usando diferentes pestanas no navegador.
Ao analizar Cartbee, salvounos a súa especificidade. A aplicación utilizouse desde dispositivos móbiles, onde traballar desde varias pestanas é simplemente un inconveniente. Aquí temos un escritorio e mentres se está a realizar unha tarefa nunha entidade, é razoable querer pasar este tempo configurando ou supervisando o estado noutra. E para non perder o progreso, só tes que abrir outra pestana.
Inspiración #3
Os compañeiros de desenvolvemento front-end ensinaron o sistema de recollida de eventos a distinguir entre pestanas. A análise podería comezar. E comezamos. Como era de esperar, CJM non coincidía con camiños reais: os usuarios pasaban moito tempo en páxinas de directorios, sesións abandonadas e pestanas nos lugares máis inesperados. Usando a análise de transicións, puidemos atopar problemas nalgunhas compilacións de Mozilla. Neles, debido a funcións de implantación, desapareceron elementos de navegación ou mostráronse páxinas medio baleiras, que só deberían ser accesibles para o administrador. A páxina abriuse, pero non chegou ningún contido do backend. O reconto de transicións permitiu avaliar cales son as características que realmente se utilizaron. As cadeas permitiron comprender como o usuario recibía tal ou cal erro. Os datos permitidos para probar en función do comportamento do usuario. Foi un éxito, a idea non foi en balde.
Automatización analítica
Nunha das demostracións de resultados, mostramos como se usa Gephi para a análise de gráficos. Nesta ferramenta, os datos de conversión pódense mostrar nunha táboa. E o xefe do departamento de UX dixo que un pensamento moi importante que influíu no desenvolvemento de toda a dirección de análise de comportamento na empresa: "Fagamos o mesmo, pero en Tableau e con filtros, será máis conveniente".
Entón pensei: por que non, Retentioneering almacena todos os datos nunha estrutura pandas.DataFrame. E esta é, en xeral, unha mesa. Así apareceu outro servizo: Data Provider. Non só fixo unha táboa a partir do gráfico, senón que tamén calculou o popular que é a páxina e a funcionalidade asociada a ela, como afecta á retención dos usuarios, canto tempo permanecen nela e que páxinas abandonan os usuarios con máis frecuencia. E o uso da visualización en Tableau reduciu o custo de estudar o gráfico tanto que o tempo de iteración para a análise de comportamento no produto case se reduciu á metade.
Danil falará sobre como se utiliza esta visualización e que conclusións permite sacar.
Máis mesas para o deus da mesa!
Nunha forma simplificada, a tarefa formulouse do seguinte xeito: mostrar o gráfico de transición en Tableau, proporcionar a capacidade de filtrar e facelo o máis claro e cómodo posible.
Realmente non quería debuxar un gráfico dirixido en Tableau. E aínda que teña éxito, a ganancia, en comparación con Gephi, non parecía obvia. Necesitabamos algo moito máis sinxelo e accesible. Mesa! Despois de todo, o gráfico pódese representar facilmente en forma de filas de táboa, onde cada fila é un bordo do tipo "fonte-destino". Ademais, xa preparamos coidadosamente unha táboa deste tipo utilizando ferramentas Retentioneering e Data Provider. Todo o que quedaba por facer era mostrar a táboa en Tableau e rebuscar no informe.
Falando de como a todo o mundo lle gustan as mesas.
Porén, aquí estamos ante outro problema. Que facer coa fonte de datos? Era imposible conectar pandas.DataFrame; Tableau non ten ese conector. Crear unha base separada para almacenar o gráfico parecía unha solución demasiado radical con perspectivas vagas. E as opcións de descarga local non eran adecuadas debido á necesidade de constantes operacións manuais. Miramos a lista de conectores dispoñibles e a nosa mirada caeu sobre o elemento , que se apiñaba tristemente no fondo.
Tableau ten unha rica selección de conectores. Atopamos un que resolveu o noso problema
Que tipo de animal? Algunhas pestanas novas abertas no navegador e quedou claro que este conector permítelle recibir datos ao acceder a un URL. O back-end para calcular os datos en si estaba case listo, só quedaba facelo amigo de WDC. Durante varios días Denis estudou a documentación e loitou cos mecanismos de Tableau, e despois envioume unha ligazón que peguei na xanela de conexión.
Formulario de conexión ao noso WDC. Denis fixo a súa fronte e ocupouse da seguridade
Despois dun par de minutos de espera (os datos calcúlanse de forma dinámica cando se solicitan), apareceu a táboa:
Este é o aspecto dunha matriz de datos en bruto na interface de Tableau
Como prometeu, cada fila desta táboa representaba un bordo do gráfico, é dicir, unha transición dirixida do usuario. Tamén contiña varias características adicionais. Por exemplo, o número de usuarios únicos, o número total de transicións e outros.
Sería posible mostrar esta táboa no informe tal e como está, espolvorear xenerosamente os filtros e enviar a ferramenta navegando. Parece lóxico. Que podes facer coa mesa? Pero este non é o noso camiño, porque non estamos a facer só unha táboa, senón unha ferramenta para a análise e a toma de decisións de produtos.
Normalmente, ao analizar datos, unha persoa quere obter respostas ás preguntas. Genial. Comecemos con eles.
- Cales son as transicións máis frecuentes?
- Onde van desde páxinas específicas?
- Canto tempo pasas de media nesta páxina antes de saír?
- Cantas veces fai a transición de A a B?
- En que páxinas remata a sesión?
Cada un dos informes ou unha combinación deles debería permitir ao usuario atopar de forma independente respostas a estas preguntas. A estratexia fundamental aquí é darche as ferramentas para facelo ti mesmo. Isto é útil tanto para reducir a carga do departamento de análise como para reducir o tempo de toma de decisións; despois de todo, xa non necesitas ir a Youtrack e crear unha tarefa para o analista, só tes que abrir o informe.
Que conseguimos?
Onde a xente diverxe con máis frecuencia do panel?
Fragmento do noso informe. Despois do panel, todos foron á lista de máquinas virtuales ou á lista de nós
Tomemos unha táboa xeral con transicións e filtremos por páxina de orixe. Na maioría das veces, van desde o panel de control á lista de máquinas virtuais. Ademais, a columna Regularidade suxire que se trata dunha acción que se repite.
De onde veñen á lista de clusters?
Os filtros dos informes funcionan en ambas direccións: podes saber onde deixaches ou onde fuches
Dos exemplos é evidente que incluso a presenza de dous filtros sinxelos e filas de clasificación por valores permítelle obter información rapidamente.
Imos preguntar algo máis complicado.
Onde adoitan abandonar a sesión os usuarios?
Os usuarios de VMmanager adoitan traballar en pestanas separadas
Para iso, necesitamos un informe cuxos datos estean agregados por fontes de referencia. E os chamados puntos de ruptura foron tomados como asignacións, eventos que serviron como fin da cadea de transicións.
É importante ter en conta que isto pode ser o final da sesión ou a apertura dunha nova pestana. O exemplo mostra que a cadea remata a maioría das veces nunha táboa cunha lista de máquinas virtuais. Neste caso, o comportamento característico é cambiar a outra pestana, que é coherente co patrón esperado.
En primeiro lugar, comprobamos a utilidade destes informes sobre nós mesmos cando realizamos a análise dun xeito similar , outro dos nosos produtos. Coa aparición das táboas e dos filtros, as hipóteses foron probadas máis rápido e os ollos estaban menos cansos.
Ao desenvolver informes, non nos esquecemos do deseño visual. Cando se traballa con táboas deste tamaño, este é un factor importante. Por exemplo, utilizamos unha gama de cores tranquilas, fáciles de percibir para os números, resaltado en cor das liñas de acordo cos valores numéricos das características. Estes detalles melloran a experiencia do usuario e aumentan a probabilidade de que a ferramenta despegue con éxito dentro da empresa.
A táboa resultou ser bastante voluminosa, pero esperamos que non deixe de ser lexible
Cabe mencionar por separado a formación dos nosos clientes internos: especialistas en produtos e deseñadores UX. Elaboráronse especialmente para eles manuais con exemplos de análise e consellos para traballar con filtros. Inserimos ligazóns a manuais directamente nas páxinas dos informes.
Fixemos o manual simplemente como presentación en Google Docs. As ferramentas de Tableau permítenche mostrar páxinas web directamente dentro dun libro de traballo de informes.
No canto dunha palabra final
Que hai no fondo? Puidemos conseguir unha ferramenta para todos os días de forma relativamente rápida e barata. Si, definitivamente non é un substituto para o gráfico en si, o mapa térmico de clics ou o visor web. Pero estes informes complementan significativamente as ferramentas enumeradas e proporcionan elementos de reflexión e hipóteses de novos produtos e interfaces.
Esta historia serviu só como comezo para o desenvolvemento de análises no ISPsystem. Durante os últimos seis meses apareceron sete novos servizos máis, incluíndo retratos dixitais do usuario no produto e un servizo de creación de bases de datos para a orientación por Look-alike, pero deles falaremos nos seguintes episodios.
Fonte: www.habr.com