Existem centenas de artigos na Internet sobre os benefícios da análise do comportamento do cliente. Na maioria das vezes, isto diz respeito ao setor retalhista. Desde análise de cesta de alimentos, análise ABC e XYZ até marketing de retenção e ofertas pessoais. Várias técnicas foram usadas durante décadas, os algoritmos foram pensados, o código foi escrito e depurado - pegue-o e use-o. No nosso caso, surgiu um problema fundamental - nós da ISPsystem estamos envolvidos no desenvolvimento de software, não no varejo.
Meu nome é Denis e atualmente sou responsável pelo backend de sistemas analíticos na ISPsystem. E esta é a história de como meu colega e eu — os responsáveis pela visualização de dados — tentaram olhar para os nossos produtos de software através do prisma deste conhecimento. Comecemos, como sempre, pela história.
No início havia uma palavra, e a palavra era “Vamos tentar?”
Naquele momento eu trabalhava como desenvolvedor no departamento de P&D. Tudo começou quando Danil leu aqui no Habré — uma ferramenta para analisar transições de usuários em aplicativos. Fiquei um tanto cético quanto à ideia de usá-lo aqui. Como exemplos, os desenvolvedores da biblioteca citaram uma análise de aplicativos onde o objetivo da ação estava claramente definido – fazer um pedido ou alguma outra variação de como pagar a empresa proprietária. Nossos produtos são fornecidos no local. Ou seja, o usuário primeiro compra uma licença, e só então inicia sua jornada no aplicativo. Sim, temos versões demo. Você pode experimentar o produto lá para não ter um porco em uma armadilha.
Mas a maior parte dos nossos produtos é voltada para o mercado de hospedagem. São clientes grandes e o departamento de desenvolvimento de negócios os aconselha sobre os recursos do produto. Conclui-se também que no momento da compra nossos clientes já sabem quais problemas nosso software os ajudará a resolver. Suas rotas no aplicativo devem coincidir com o CJM incorporado no produto, e as soluções UX os ajudarão a permanecer no caminho certo. Spoiler: isso nem sempre acontece. A introdução à biblioteca foi adiada... mas não por muito tempo.
Tudo mudou com o lançamento da nossa startup - — plataformas para criar uma loja online a partir de uma conta Instagram. Neste aplicativo, o usuário teve um prazo de duas semanas para utilizar todas as funcionalidades gratuitamente. Então você teve que decidir se iria se inscrever. E isso se encaixa perfeitamente no conceito de “ação rota-alvo”. Estava decidido: vamos tentar!
Primeiros resultados ou de onde tirar ideias
A equipe de desenvolvimento e eu conectamos o produto ao sistema de coleta de eventos literalmente em um dia. Direi desde já que o ISPsystem utiliza um sistema próprio de coleta de eventos sobre visitas de páginas, mas nada impede que você utilize o Yandex.Metrica para os mesmos fins, que permite baixar dados brutos gratuitamente. Foram estudados exemplos de utilização da biblioteca e após uma semana de coleta de dados recebemos um gráfico de transição.
Gráfico de transição. Funcionalidade básica, outras transições removidas para maior clareza
Ficou exatamente como no exemplo: plano, claro, bonito. A partir deste gráfico conseguimos identificar os percursos e travessias mais frequentes onde as pessoas passam mais tempo. Isso nos permitiu entender o seguinte:
- Em vez de um grande CJM, que abrange uma dúzia de entidades, apenas duas são ativamente utilizadas. É necessário adicionalmente direcionar os usuários aos locais de que necessitamos por meio de soluções UX.
- Algumas páginas, projetadas por designers de UX para serem de ponta a ponta, acabam com as pessoas gastando uma quantidade excessiva de tempo nelas. Você precisa descobrir quais são os elementos de parada em uma página específica e ajustá-los.
- Após 10 transições, 20% das pessoas começaram a se cansar e desistiram da sessão no aplicativo. E isso levando em consideração o fato de termos até 5 páginas de onboarding no aplicativo! Você precisa identificar as páginas onde os usuários abandonam regularmente as sessões e encurtar o caminho até elas. Melhor ainda: identifique quaisquer rotas regulares e permita uma transição rápida da página de origem para a página de destino. Algo em comum com a análise ABC e a análise de carrinho abandonado, não acha?
E aqui reconsideramos nossa atitude em relação à aplicabilidade desta ferramenta para produtos on-premise. Decidiu-se analisar um produto vendido e usado ativamente - . É muito mais complexo, há uma ordem de grandeza de mais entidades. Estávamos esperando ansiosamente para ver como seria o gráfico de transição.
Sobre decepções e inspirações
Decepção #1
Era fim de jornada útil, fim de mês e fim de ano ao mesmo tempo - 27 de dezembro. Os dados foram acumulados, as consultas foram escritas. Faltavam alguns segundos para que tudo fosse processado e pudéssemos olhar o resultado do nosso trabalho para saber onde começaria o próximo ano de trabalho. O departamento de P&D, gerente de produto, designers de UX, líder de equipe e desenvolvedores se reuniram em frente ao monitor para ver como são os caminhos do usuário em seu produto, mas... vimos o seguinte:
Gráfico de transição construído pela biblioteca Retentioneering
Inspiração #1
Fortemente conectados, dezenas de entidades, cenários não óbvios. Ficou claro que o novo ano de trabalho não começaria com uma análise, mas com a invenção de uma forma de simplificar o trabalho com tal gráfico. Mas não conseguia afastar a sensação de que tudo era muito mais simples do que parecia. E depois de quinze minutos estudando o código-fonte do Retentioneering, conseguimos exportar o gráfico construído para o formato de pontos. Isso possibilitou o upload do gráfico para outra ferramenta - Gephi. E já há espaço para análise de gráficos: layouts, filtros, estatísticas - basta configurar os parâmetros necessários na interface. Com esse pensamento em mente partimos para o fim de semana de Ano Novo.
Decepção #2
Depois de voltar ao trabalho, descobrimos que enquanto todos descansavam, nossos clientes estudavam o produto. Sim, tão difícil que apareceram no armazenamento eventos que não existiam antes. Isso significava que as consultas precisavam ser atualizadas.
Um pouco de contexto para entender a tristeza desse fato. Transmitimos tanto os eventos que marcamos (por exemplo, cliques em alguns botões) como as URLs das páginas que o usuário visitou. No caso do Cartbee, o modelo “uma ação – uma página” funcionou. Mas com o VMmanager a situação era completamente diferente: várias janelas modais podiam abrir em uma página. Neles o usuário poderia resolver diversos problemas. Por exemplo, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
significa que na página “Endereços IP” o usuário adicionou um endereço IP. E aqui dois problemas são visíveis ao mesmo tempo:
- A URL contém algum tipo de parâmetro de caminho - o ID da máquina virtual. Precisa ser excluído.
- A URL contém o ID da janela modal. Você precisa de alguma forma “descompactar” esses URLs.
Outro problema foi que os próprios eventos que marcamos tinham parâmetros. Por exemplo, havia cinco maneiras diferentes de acessar a página com informações sobre uma máquina virtual da lista. Dessa forma, foi enviado um evento, mas com um parâmetro que indicava por qual método o usuário fez a transição. Houve muitos desses eventos e todos os parâmetros eram diferentes. E temos toda a lógica de recuperação de dados no dialeto SQL para Clickhouse. Consultas de 150 a 200 linhas estavam começando a parecer um tanto comuns. Problemas nos cercaram.
Inspiração #2
Certa manhã, Danil, percorrendo tristemente a solicitação do segundo minuto, sugeriu-me: “Vamos escrever pipelines de processamento de dados?” Pensamos nisso e decidimos que se fôssemos fazer isso seria algo como ETL. Para que filtre imediatamente e extraia os dados necessários de outras fontes. Foi assim que nasceu nosso primeiro serviço analítico com backend completo. Ele implementa cinco etapas principais de processamento de dados:
- Descarregar eventos do armazenamento de dados brutos e prepará-los para processamento.
- Esclarecimento é a “descompactação” desses mesmos identificadores de janelas modais, parâmetros de evento e outros detalhes que esclarecem o evento.
- Enriquecimento (da palavra “ficar rico”) é a adição de eventos com dados de fontes de terceiros. Naquela época, isso incluía apenas nosso sistema de faturamento BILLmanager.
- Filtragem é o processo de filtrar eventos que distorcem os resultados da análise (eventos de arquibancadas internas, outliers, etc.).
- Carregando eventos recebidos no armazenamento, que chamamos de dados limpos.
Agora era possível manter a relevância adicionando regras para processamento de um evento ou mesmo grupos de eventos semelhantes. Por exemplo, desde então nunca atualizamos a descompactação de URL. Embora, durante esse período, várias novas variações de URL tenham sido adicionadas. Cumprem as regras já previstas no serviço e são processados corretamente.
Decepção #3
Assim que começamos a analisar, percebemos porque o gráfico era tão coerente. O fato é que quase todos os N-gramas continham transições que não podiam ser realizadas através da interface.
Uma pequena investigação começou. Fiquei confuso porque não havia transições impossíveis dentro de uma entidade. Isso significa que não se trata de um bug no sistema de coleta de eventos ou em nosso serviço ETL. Havia a sensação de que o usuário trabalhava simultaneamente em diversas entidades, sem passar de uma para outra. Como conseguir isso? Usando diferentes guias no navegador.
Ao analisar o Cartbee, fomos salvos pela sua especificidade. O aplicativo foi utilizado em dispositivos móveis, onde trabalhar em várias abas é simplesmente inconveniente. Aqui temos um desktop e enquanto uma tarefa está sendo executada em uma entidade, é razoável querer gastar esse tempo configurando ou monitorando o status em outra. E para não perder o progresso, basta abrir outra aba.
Inspiração #3
Colegas do desenvolvimento front-end ensinaram o sistema de coleta de eventos a distinguir entre guias. A análise poderia começar. E começamos. Como esperado, o CJM não correspondia aos caminhos reais: os usuários passavam muito tempo nas páginas do diretório, abandonavam sessões e abas nos locais mais inesperados. Usando a análise de transição, conseguimos encontrar problemas em algumas compilações do Mozilla. Neles, por características de implementação, desapareceram elementos de navegação ou foram exibidas páginas meio vazias, que deveriam ser acessíveis apenas ao administrador. A página foi aberta, mas nenhum conteúdo veio do backend. A contagem das transições possibilitou avaliar quais recursos foram realmente utilizados. As cadeias permitiram entender como o usuário recebeu este ou aquele erro. Os dados permitiram testes com base no comportamento do usuário. Foi um sucesso, a ideia não foi em vão.
Automação analítica
Em uma das demonstrações de resultados, mostramos como o Gephi é utilizado para análise de gráficos. Nesta ferramenta, os dados de conversão podem ser exibidos em uma tabela. E o chefe do departamento de UX disse um pensamento muito importante que influenciou o desenvolvimento de toda a direção de análise comportamental na empresa: “Vamos fazer o mesmo, mas no Tableau e com filtros - será mais conveniente”.
Aí pensei: por que não, o Retentioneering armazena todos os dados em uma estrutura pandas.DataFrame. E esta é, em geral, uma mesa. Foi assim que surgiu outro serviço: Data Provider. Ele não apenas fez uma tabela a partir do gráfico, mas também calculou a popularidade da página e a funcionalidade associada a ela, como isso afeta a retenção de usuários, quanto tempo os usuários permanecem nela e quais páginas os usuários saem com mais frequência. E o uso da visualização no Tableau reduziu tanto o custo de estudo do gráfico que o tempo de iteração para análise do comportamento no produto foi reduzido quase pela metade.
Danil falará sobre como essa visualização é utilizada e quais conclusões ela permite tirar.
Mais mesas para o deus da mesa!
De forma simplificada, a tarefa foi formulada da seguinte forma: exibir o gráfico de transição no Tableau, fornecer a capacidade de filtrar e torná-lo o mais claro e conveniente possível.
Eu realmente não queria desenhar um gráfico direcionado no Tableau. E mesmo que tenha sido bem sucedido, o ganho, comparado ao Gephi, não parecia óbvio. Precisávamos de algo muito mais simples e acessível. Mesa! Afinal, o gráfico pode ser facilmente representado na forma de linhas de tabela, onde cada linha é uma aresta do tipo “origem-destino”. Além disso, já preparamos cuidadosamente essa tabela usando ferramentas de Retenção e Provedor de Dados. Tudo o que faltou fazer foi exibir a tabela no Tableau e vasculhar o relatório.
Falando em como todo mundo adora mesas.
Contudo, aqui nos deparamos com outro problema. O que fazer com a fonte de dados? Não foi possível conectar o pandas.DataFrame; o Tableau não possui esse conector. Criar uma base separada para armazenar o gráfico parecia uma solução muito radical com perspectivas vagas. E as opções de descarga local não eram adequadas devido à necessidade de constantes operações manuais. Examinamos a lista de conectores disponíveis e nosso olhar recaiu sobre o item , que se encolheu desamparadamente bem no fundo.
O Tableau possui uma ampla seleção de conectores. Encontramos um que resolveu nosso problema
Que tipo de animal? Algumas novas abas abertas no navegador - e ficou claro que esse conector permite receber dados ao acessar uma URL. O backend para cálculo dos dados em si estava quase pronto, só faltava fazer amizade com o WDC. Durante vários dias, Denis estudou a documentação e lutou com os mecanismos do Tableau, e depois me enviou um link que colei na janela de conexão.
Formulário de conexão ao nosso WDC. Denis fez sua frente e cuidou da segurança
Após alguns minutos de espera (os dados são calculados dinamicamente quando solicitados), a tabela apareceu:
Esta é a aparência de uma matriz de dados brutos na interface do Tableau
Conforme prometido, cada linha dessa tabela representava uma borda do gráfico, ou seja, uma transição direcionada do usuário. Também continha várias características adicionais. Por exemplo, o número de usuários únicos, o número total de transições e outros.
Seria possível exibir esta tabela no relatório como está, polvilhar generosamente os filtros e enviar a ferramenta para navegar. Parece lógico. O que você pode fazer com a mesa? Mas esse não é o nosso caminho, pois estamos fazendo não apenas uma tabela, mas uma ferramenta de análise e tomada de decisão sobre produtos.
Normalmente, ao analisar dados, uma pessoa deseja obter respostas para perguntas. Ótimo. Vamos começar com eles.
- Quais são as transições mais frequentes?
- Para onde eles vão em páginas específicas?
- Quanto tempo você passa em média nesta página antes de sair?
- Com que frequência você faz a transição de A para B?
- Em quais páginas a sessão termina?
Cada um dos relatórios ou uma combinação deles deve permitir ao usuário encontrar respostas para essas perguntas de forma independente. A estratégia principal aqui é fornecer as ferramentas para você fazer isso sozinho. Isso é útil tanto para diminuir a carga do departamento de analytics quanto para diminuir o tempo de tomada de decisões - afinal, você não precisa mais ir ao Youtrack e criar uma tarefa para o analista, basta abrir o relatório.
O que conseguimos?
Onde as pessoas divergem com mais frequência do painel?
Fragmento do nosso relatório. Após o painel, todos foram para a lista de VMs ou para a lista de nós
Vamos pegar uma tabela geral com transições e filtrar por página de origem. Na maioria das vezes, eles vão do painel para a lista de máquinas virtuais. Além disso, a coluna Regularidade sugere que esta é uma ação repetitiva.
De onde eles vêm na lista de clusters?
Os filtros nos relatórios funcionam em ambas as direções: você pode descobrir onde saiu ou para onde foi
A partir dos exemplos fica claro que mesmo a presença de dois filtros simples e a classificação das linhas por valores permitem obter informações rapidamente.
Vamos perguntar algo mais difícil.
Onde os usuários abandonam com mais frequência a sessão?
Os usuários do VMmanager geralmente trabalham em guias separadas
Para fazer isso, precisamos de um relatório cujos dados sejam agregados por fontes de referência. E os chamados pontos de interrupção foram tomados como atribuições - eventos que serviram como fim da cadeia de transições.
É importante ressaltar aqui que pode ser tanto o final da sessão quanto a abertura de uma nova aba. O exemplo mostra que a cadeia geralmente termina em uma tabela com uma lista de máquinas virtuais. Nesse caso, o comportamento característico é a mudança para outra aba, que é consistente com o padrão esperado.
Em primeiro lugar, testámos a utilidade destes relatórios em nós próprios quando realizámos a análise de forma semelhante , outro de nossos produtos. Com o advento das tabelas e dos filtros, as hipóteses foram testadas mais rapidamente e os olhos ficaram menos cansados.
Ao desenvolver relatórios, não esquecemos do design visual. Ao trabalhar com tabelas deste tamanho, este é um fator importante. Por exemplo, usamos uma gama de cores calmas e fáceis de perceber para números, destaque colorido das linhas de acordo com os valores numéricos das características. Esses detalhes melhoram a experiência do usuário e aumentam a probabilidade de a ferramenta decolar com sucesso dentro da empresa.
A tabela acabou por ser bastante volumosa, mas esperamos que não tenha deixado de ser legível
Vale mencionar separadamente a formação dos nossos clientes internos: especialistas de produto e designers de UX. Manuais com exemplos de análises e dicas para trabalhar com filtros foram preparados especialmente para eles. Inserimos links para manuais diretamente nas páginas do relatório.
Fizemos o manual simplesmente como uma apresentação no Google Docs. As ferramentas do Tableau permitem exibir páginas da Web diretamente em uma pasta de trabalho de relatório.
em vez de um epílogo
O que está no resultado final? Conseguimos obter uma ferramenta para todos os dias de forma relativamente rápida e barata. Sim, definitivamente não substitui o gráfico em si, o mapa de calor de cliques ou o visualizador da web. Mas esses relatórios complementam significativamente as ferramentas listadas e fornecem ideias para reflexão e novas hipóteses de produtos e interfaces.
Essa história serviu apenas como começo para o desenvolvimento de análises no sistema ISP. Nos últimos seis meses, surgiram mais sete novos serviços, incluindo retratos digitais do usuário no produto e um serviço de criação de bancos de dados para segmentação por Lookalike, mas falaremos sobre eles nos episódios seguintes.
Fonte: habr.com