Análise como um recurso: o processo de trabalhar com dados no Plesk

Olá pessoal, escrevemos recentemente sobre como aprendemos a ser orientados por dados com o GoPractice Simulator! Nesta edição, continuaremos o tópico de análise de dados e falaremos sobre a criação do processo de trabalho com análises na equipe Plesk.

O Plesk é um produto complexo com um histórico de 20 anos e nem sempre conseguimos coletar efetivamente as estatísticas necessárias. Durante muito tempo, analisamos os dados apenas em retrospecto e as decisões foram tomadas com base em sensações subjetivas "como deveriam ser". No passado, já tínhamos as tristes conseqüências dessa abordagem - em 2012, alteramos o design, querendo fazer o melhor, mas recebemos uma onda de feedback negativo, recusando-nos a atualizar para a versão mais recente do produto e a saída de clientes.

Tendo compreendido essa triste experiência, tiramos conclusões e decidimos avançar para o estabelecimento de uma empresa orientada a dados. Dessa maneira, dificuldades de natureza diferente nos aguardavam. Em larga escala, eles podem ser divididos em dois grupos principais - sistema e processo, e neste artigo vou focar na tarefa de criar o processo de trabalhar com análises.


Os problemas sistêmicos associados às especificidades do produto embalado merecem um artigo separado; portanto, não vou me debruçar sobre eles aqui em detalhes, apenas listarei os mais significativos.

1. Muitos eventos, altos volumes de uso. Se falarmos apenas sobre o rastreamento das ações do usuário no painel, de acordo com nossos cálculos, são 60 milhões de eventos por mês e é uma pena dar US $ 150 mil para o Google Analytics avançado. Outra dificuldade é que, para trabalhar com o GA, você precisa lidar explicitamente com cada ação personalizada, mas desejamos obter um mecanismo unificado que não exija a marcação manual de eventos ou ações para cada novo recurso.
2. Devido ao volume e formato da caixa (a implementação de qualquer alteração leva tempo), a análise não pode ser executada em tempo real. Os usuários estão sentados em 8 versões diferentes do produto, com 4 delas já com EOL. Mesmo nas versões mais recentes, apenas 60% dos usuários sofrem novas alterações nas duas primeiras semanas após o lançamento.
   
3. Produto complexo. O Plesk suporta 14 sistemas operacionais da família Linux, 4 OC Windows, um componente de 150 terceiros, vários servidores web, servidores de email, clientes de webmail, visualizadores de estatísticas, soluções antivírus, etc. Um grande número de configurações possíveis afeta principalmente a complexidade e o volume dos testes e torna quase impossível o uso de testes A / B.
   
4. Específicos do B2B2C. O tomador de decisão nem sempre é igual ao "usuário real do painel".
   
5. GDPR - a necessidade de cumprir a letra da lei exige esforços adicionais para anonimizar os dados e complica as tarefas de segmentação do usuário, além de nos privar da capacidade de entrar em contato com os clientes com facilidade e rapidez usando suas informações de contato.
   

Falaremos sobre dores de processo em mais detalhes. Até recentemente, o processo de coleta de análises conosco era completamente separado do processo de desenvolvimento - lembrávamos do rastreamento e das métricas no final, estragamos uma solução única e assim por diante até o próximo recurso. Além disso, ao longo dos anos, o Plesk acumulou várias fontes de dados - o que implicou os custos de manutenção da consistência, relevância dos dados, a necessidade de ter em mente de onde eles vêm, sob quais condições eles chegam ao banco de dados e por que as mesmas métricas em locais diferentes diferem (por exemplo, o número de chaves de licença e instalações físicas). Muitas informações foram gravadas nessas fontes (cortes mensais de um banco de dados de 270 mil chaves e relatórios chegando duas vezes mais que 300 mil servidores), mas apenas algumas pessoas conseguiram trabalhar com esses dados e encontraram tempo. Eu vim para o Plesk em 2015 e minhas primeiras tarefas foram apenas obter estatísticas heterogêneas do cubo OLAP e do banco de dados MongoDB. 'Como fazer' para esse banco de dados era uma página com um nome de usuário e senha do host e um arquivo de texto com um script js da última solicitação popular.

Um monte de fontes significava um monte de ferramentas e serviços, cada um dos quais todo gerente de programa deveria poder usar. A sensação nos primeiros dias de trabalho era algo assim:



O que fizemos?

A solução foi a seguinte: há cerca de um ano e meio, iniciamos uma revisão completa do processo de coleta de dados - agora desenvolvemos análises da mesma maneira que o próprio recurso, em cada estágio de toda a equipe (equipe de recursos) envolvida, desde PM e desenvolvimento até engenheiro de controle de qualidade.

Hipótese

Tudo começa no estágio de planejamento de recursos: o PM formula uma hipótese com base na qual a métrica será selecionada na próxima etapa. Por exemplo: O Plesk possui um sistema de recomendação do Advisor que ajuda o usuário a melhorar o estado do servidor seguindo as etapas propostas (adicione um certificado ssl, habilite atualizações, atualize a versão do PHP etc.). Ao liberar o Advisor, assumimos que o usuário seguirá as recomendações, a classificação de "saúde" do servidor aumentará e, graças a "conquistas" gamificadas, o usuário estará envolvido na interação com o Advisor continuamente.

Métrica

Na próxima etapa, uma métrica é selecionada para cada hipótese: para o Advisor, esse é o número de cliques nas recomendações, a porcentagem de sites protegidos por certificados, pontuação de classificação etc. Toda essa informação (hipótese + métrica) é inserida no documento Visão - com os requisitos para os recursos. Nesse ponto, os analistas de dados estão envolvidos no processo - sua tarefa é ajudar a tornar a métrica mensurável, fácil de coletar e inequívoca. Mesmo detalhes como a estrutura do campo futuro no banco de dados ou no relatório são importantes - como o gerente responsável pelo recurso geralmente acessa essas informações, é do seu interesse determinar como é mais conveniente fazer isso, até a estrutura desejada da solicitação do banco de dados. Graças a essa abordagem, a propósito, ficou mais fácil para todos, no sentido de que a necessidade de subir para 100.500 fontes diminuiu significativamente - agora você decide em qual formato os dados serão coletados e como prefere obtê-los. Ao fixar a lógica da contagem em uma exibição, o MP também tem a oportunidade de retornar ao documento a qualquer momento e recordar por quais critérios o banco de dados entra / aumenta o contador / o fato de enviar, etc. Isso resolve o problema de entender a lógica dos relatórios.

Implementação

Quando uma hipótese é formulada e uma métrica é selecionada, é a vez da implementação. Os desenvolvedores implementam ao mesmo tempo o próprio recurso e o mecanismo para coletar suas estatísticas. Como já mencionado, o uso de soluções prontas como o GA é difícil para nós por várias razões; portanto, há dois anos, nossos engenheiros implementaram seu próprio mecanismo para rastrear as ações dos usuários no painel. Além das ações do usuário, vários detalhes técnicos, definições de configuração etc. também podem ser interessantes. - tudo isso é enviado ao banco de dados MongoDB já mencionado.

Testes e visualizações

Como qualquer produto, o mecanismo de coleta de dados deve ser testado - no nosso caso, o engenheiro de controle de qualidade verifica se as recomendações são mostradas e abertas, a classificação é monitorada e as informações sobre todos esses eventos são coletadas no banco de dados. Freqüentemente, os casos de uso selecionados para rastreamento e análise tornam-se novos casos de teste para testar a funcionalidade do próprio recurso.

Depois que o engenheiro de controle de qualidade verificou todos os cenários, o gerente de recursos humanos juntamente com o desenvolvedor analisou os primeiros dados e certificou-se de que o recurso 1) não quebrasse nada e 2) funcionasse conforme o esperado, e as estatísticas coletassem o que lhe interessa - tudo está pronto para lançamento lançamento.

Vida útil

Quando um recurso é lançado em um release, a parte mais interessante começa - sua "vida" no produto. Não é mais necessário: “você sabe qual campo do nosso banco de dados armazena informações sobre a exibição de recomendações? não? blin ... ". O analista de dados não recebe mensagens com folga: "você pode contar novamente quantas impressões há na versão mais recente?" - para isso, existem gráficos em painéis com alertas configurados que enviam cartas se o valor monitorado caiu acentuadamente / aumentou / mudou / nenhum registro foi encontrado no banco de dados. Mas isso não é tudo. Entender que o contador aumentou ou diminuiu n% nem sempre é suficiente para dizer com confiança que se trata de uma mudança significativa e não de um salto ou flutuação sazonal dentro da margem de erro. Um dos membros da nossa equipe está desenvolvendo uma estrutura para medir a significância estatística das alterações métricas. Usando o aparato de estatística matemática, ele calcula a amostra mínima (o número de usuários / instalações / eventos) necessária para avaliar a importância das mudanças, seleciona segmentos entre os quais você pode comparar e determina o intervalo de confiança que provavelmente contém o valor real da métrica de interesse para nós. Essa estrutura já foi testada e deu resultados interessantes na semana passada: descobrimos que, depois que começamos a exibir preços no catálogo de extensões dentro do painel Plesk, as pessoas começaram a comprar menos chaves de licença anuais e mais frequentemente mensais para esses produtos. No momento, nossos colegas estão calculando a previsão do LTV, após o que ficará claro que essas mudanças são para nós a longo prazo e que opção devemos promover na lógica de mostrar preços.

Rescisão do suporte

O resultado da vida útil de qualquer produto ou recurso é a rescisão do seu suporte no caso de falta de demanda ou outros motivos (por exemplo, considerações de segurança no caso de rescisão do suporte a um sistema operacional ou versão desatualizada do PHP). Aqui, a análise também ajuda: por exemplo, quando decidimos incentivar os usuários a mudar para novas versões do PHP, a primeira coisa que fizemos foi coletar estatísticas de uso da versão entre os usuários do Plesk. Aprendemos que a porcentagem de uso do PHP 7 atinge apenas 20% dos usuários e percebemos que os custos potenciais de comutação forçada na forma de milhões de sites danificados superam os riscos de possíveis vulnerabilidades de versões mais antigas. Como resultado, decidimos medidas de influência mais leves e começamos com uma notificação sobre a conveniência de uma atualização no painel. Outro exemplo pode ser inúmeras histórias com a descontinuação do suporte a sistemas operacionais - no caso em que descobrimos que um dos maiores clientes com dezenas de milhares de instalações do Plesk está usando um determinado sistema operacional, nos comunicamos de forma direcionada com esse parceiro e, em caso de impossibilidade de uma transição rápida, oferecemos a ele a chamada queda lenta - o término do suporte para novas instalações e a capacidade de continuar trabalhando nas existentes após a atualização para a versão mais recente do Plesk.

Conclusão

Para resumir, quero mais uma vez expressar o que consideramos mais importante - agora, trabalhar com análises para nós é parte integrante do trabalho em todos os recursos. Mas o processo construído não é o fim. Por experiência própria, estávamos convencidos de que o controle da qualidade dos dados não é menos importante que o próprio processo. Tudo não faz sentido se, em qualquer estágio da coleta, os dados forem perdidos ou distorcidos. Para evitar que isso aconteça, em cada estágio, esforçamo-nos por adicionar verificações de integridade e correção dos dados, além de registrar cada etapa do processamento.



E o último. Não se pese com as métricas simplesmente porque você pode :) indicar claramente o que essas informações são para você e, quando recebidas, pergunte a si mesmo se traz alguma conclusão que leve à ação. Afinal, entender o que fazer é exatamente para o que tudo foi iniciado :)