Os números significam muito para nós. Investimos em dados, ouvimos e entendemos. Somos guiados por eles ao tomar decisões. Apesar de ainda termos muito pela frente em termos de infraestrutura para trabalhar com dados, a abordagem orientada a dados sempre esteve conosco. Neste texto - uma história sobre o caminho que seguimos, que lições aprendemos e que rake coletamos.
Meu nome é Andrey Sytsko, sou o chefe da linha de produtos da empresa fintech ID Finance. Como eu disse, ainda temos um longo caminho a percorrer em termos de métodos e ferramentas para trabalhar com dados. O crescimento múltiplo que a empresa experimentou desde o início estabelece um ritmo inatingível para a infraestrutura analítica. No entanto, é provável que as expectativas de uma abordagem orientada a dados estejam simplesmente crescendo em um ritmo mais rápido. No final, como todos entendemos, não apenas ferramentas e tecnologias específicas são importantes, mas também a abordagem, a cultura e a visão de mundo.
O que é uma cultura orientada a dados?
O que queremos dizer com cultura baseada em dados em uma empresa? Na minha opinião, foi quando concordamos internamente que os dados podem dar uma boa resposta ou conselho no contexto de um dilema comercial específico. Existem várias consequências de tal arranjo:
- Estamos prontos para investir no trabalho com dados: extração, armazenamento, análise, interpretação, visualização e muito mais. Pronto para gastar dinheiro e tempo
- Estamos prontos para ouvir os dados. I.e. quando você precisa tomar uma decisão comercial, paramos e dizemos a nós mesmos - vamos ver os números.
- Nós podemos entender os dados. De fato, é aterrorizante simplesmente tirar a conclusão errada, com todos os números necessários à mão. Diga o que quiser, existem alguns requisitos mínimos para o pensamento analítico dos tomadores de decisão, a fim de extrair significado das tabelas, gráficos e tabelas.
- Confiamos nos dados e somos guiados por eles na tomada de decisões. Quando um gerente, olhando para um relatório analítico preparado, diz que se sairá melhor como a experiência diz, em vez de um relatório, ele não está necessariamente errado. E se os analistas não levassem em conta a sazonalidade, os resultados das próximas eleições ou qualquer outra coisa? O diálogo entre gerentes e analistas, a confiança um no outro é importante aqui.
Naturalmente, a cultura orientada a dados na empresa é mais fácil de construir quando os fundadores da empresa já são seus transportadores. O uso de dados na tomada de decisões torna esse processo mais demorado e caro. E sem convicção séria de que faz sentido fazê-lo, e não de outra forma, você não irá longe. Tivemos sorte neste caso - a base certa para o futuro edifício já estava lançada.
Primeiras etapas da infraestrutura
A primeira coisa que você encontrará no caminho para a tomada de decisão ideal orientada a dados é que você não possui dados suficientes. Em geral, eles sempre serão perdidos por razões objetivas, mas você precisa começar de algum lugar.
Para começar, você constrói a infraestrutura para coletar e armazenar métricas. Na grande maioria dos projetos de back-end de dados (para nós, por exemplo, informações sobre clientes, empréstimos e pagamentos a eles), a réplica da base de produção é simplesmente usada inicialmente. Nesse caso, você terá que aproveitar totalmente a estrutura de dados interna do seu software, que os desenvolvedores criaram sem o pensamento de tornar os dados convenientes para análise. Mas temos informações em primeira mão, por assim dizer. No início, geralmente há um banco de dados, e a estrutura de dados é relativamente simples, assim como as perguntas que você deseja fazer para esses dados, portanto, essa é uma opção de trabalho e investir em algo mais complicado não faz sentido.
Para dados de front-end (visualizações de página, interação com controles, rolagem, cliques, entrada), você pode usar ferramentas clássicas como Google Analytics ou Yandex.Metrica e, por exemplo, HotJar para gravar sessões. Há funcionalidade básica suficiente para tarefas de marketing e, para relatórios de produtos em funis e testes a / b, mudamos rapidamente o suficiente para trabalhar com a API de relatórios do Google. Já falamos sobre isso em Habré.
Aqui e
aqui .
Depois de criar a infraestrutura básica e começar a coletar estatísticas básicas, é necessário garantir que o produto seja desenvolvido de forma síncrona com suas métricas.
I.e. ao implementar um novo recurso em um produto, você precisa responder aproximadamente às seguintes perguntas:
- Quais métricas-chave de negócios isso afetará?
- Quais alterações serão feitas na jornada do cliente ou nos algoritmos de back-end? E como isso afetará as métricas existentes?
- Quais estágios / componentes posso decompor a nova funcionalidade para que, coletando métricas para cada um deles, eu possa olhar para dentro e analisar o trabalho do recurso
Agora pense se a capacidade de coletar todas as métricas acima faz parte da declaração do problema. E como exatamente você os coletará quando a funcionalidade for implementada?
Em seguida, você precisa garantir que o subsistema para coletar e armazenar estatísticas seja de importância suficiente para sua equipe de desenvolvimento e equipe de TI. Sua importância deve ser quase igual à importância do sistema de produção. Por exemplo, no começo, tínhamos um problema constante com o rastreamento do Google Analytics desaparecendo de páginas diferentes, até discutirmos a importância dessas coisas com os desenvolvedores. Depois disso, as bibliotecas comuns necessárias, as diretrizes de controle de qualidade etc. apareceram.
Análise para analistas
A disponibilidade de dados não significa seu uso efetivo. Os seguintes problemas / tarefas geralmente ocorrem:
- Onde conseguir essa ou aquela métrica? Como tirá-la de lá?
- Ela está indo certo? (de repente, tudo não funciona como planejado)
- Que relatório devo elaborar para tirar conclusões?
- Existe alguma significância estatística?
- É possível desenterrar mais dados para entender melhor o que está acontecendo ou verificar as métricas coletadas de uma maneira / em um local por outras métricas.
Acontece que este é um trabalho bastante volumoso que requer habilidades especiais e, mais importante, tempo. Portanto, é necessário criar um departamento de análise.
Nosso departamento de análise é bastante grande, em termos de número de pessoas, é quase igual à gerência intermediária. Ele contém os alunos de ontem com um bom conhecimento de SQL e profissionais que entendem bem como e quais dados precisam ser obtidos para tomar decisões de negócios. O fluxo de solicitações para eles tradicionalmente excede seus recursos.
Lagos e data warehouses
Um dos problemas que você provavelmente encontrará quando houver mais e mais dados é que eles estão em lugares diferentes e alguns analistas são capazes de trabalhar com alguns repositórios, outros com outros. E com alguns bancos de dados, provavelmente, ninguém sabe trabalhar imediatamente. Também fica difícil comparar esses dados entre si.
A solução para esse problema pode ser um sistema como o data warehouse (DWH). No nosso caso, pensamos nisso pela primeira vez, quando queríamos combinar dados sobre o comportamento do usuário no site e dados sobre o comportamento dele como um mutuário. Os princípios de construção do DWH estão muito além do escopo deste artigo, apenas direi quais dificuldades / recursos foram no nosso caso:
- Para cada um dos nossos projetos (agora existem 9 em 6 países), a estrutura dos dados é um pouco diferente e, portanto, foi necessário desenvolver princípios para a sua unificação.
- Era necessário pensar em como unir dados heterogêneos em um armazenamento.
Por exemplo:
- comportamento do usuário no site - transições entre páginas, interação com controles
- registro de trabalho da política de crédito - a implementação das regras e seus resultados, a transição ao longo dos ramos da lógica
- comportamento do mutuário - pagamentos de empréstimos, vendas cruzadas
Agora que aprendemos mais ou menos como integrar dados entre si e os mesclamos em um Data Lake, passamos a criar fachadas de lojas - conjuntos de dados, relatórios e visualizações pré-preparados - para os quais se tratava. Na saída, esperamos receber uma redução significativa nos requisitos de qualificação e custos trabalhistas de nossos analistas.
Geralmente, nesse estágio, uma função dedicada de engenheiro de dados aparece na empresa - ou seja, responsáveis pela infraestrutura de dados. Eles são encarregados da tarefa de manter e desenvolver DWH.
É melhor contratar as pessoas certas imediatamente.
Com o crescimento da empresa, verifica-se que nem todos os funcionários entendem imediatamente a importância dos dados e são capazes de trabalhar com eles. Duas questões surgem: promoção interna e contratação das pessoas certas.
Quanto à promoção interna, como mencionado acima, se os fundadores da empresa são portadores de uma cultura de dados, ela passa para a alta gerência, a gerência intermediária e assim por diante. Por exemplo, exijo de meus gerentes de produto que calculem o efeito potencial em dinheiro ou alterem as principais métricas antes da implementação e vejam o fato do plano após a implementação da nova funcionalidade. Ou, digamos, para priorizar o trabalho, seja guiado pelas mesmas avaliações de "valor comercial".
Abordamos o plantio de uma cultura baseada em dados de dois lados. Nosso departamento de TI pode exigir que os gerentes de negócios definam uma estimativa do efeito em dinheiro na declaração de tarefas. E isso se aplica a todos os departamentos: marketing, suporte, contabilidade. Para isso, adicionamos recentemente o requisito de que a empresa descreva explicitamente as métricas pelas quais rastreará os resultados das alterações implementadas, e a TI deve garantir que essas métricas possam ser acessadas de maneira compreensível.
É importante, é claro, verificar imediatamente ao contratar pessoas se elas estão acostumadas a se concentrar nos números de seu trabalho ou não, se sabem como fazê-lo. Minhas perguntas favoritas durante a entrevista, quando discutimos a experiência do candidato: como você calculou qual efeito o recurso dará, como você mediu qual efeito ele realmente deu e por que você acha que esse efeito deve ser atribuído a esse recurso, e não para outra coisa. Um bom candidato sempre será capaz de justificar logicamente por que o fez e não o contrário.
Com o crescimento dos volumes de negócios e dados, torna-se significativo o uso de técnicas estatísticas mais avançadas e bibliotecas de aplicativos mais avançadas - algumas das que agora são chamadas de ciência de dados.
Se falamos sobre ciência de dados em um sentido mais amplo do que redes neurais e aprendizado de máquina, por exemplo, tivemos uma experiência bem-sucedida na mudança de pacotes clássicos como SAS para criar regressão logística para ferramentas python auto-escritas. Isso
reduziu o tempo para o desenvolvimento de pontuação de crédito em 5 vezes.
Em algum momento, percebemos que a regressão logística e a análise de cluster em determinados volumes justificam seu uso no gerenciamento de marketing e produto para tarefas relacionadas à segmentação de clientes e na determinação da estratégia ideal de produto ou desconto individualmente para cada cliente.
Aprendendo a prever o futuro
A peculiaridade do negócio de empréstimos é que não basta vender um produto - dinheiro a crédito, você precisa gerenciar o fluxo de caixa futuro. Conseqüentemente, o papel de vários modelos preditivos e sua integração na previsão do futuro P&L vem à tona. Exemplos de tais modelos: taxas futuras baseadas em dados de atrasados antecipados, fatura média baseada em dados de segmentação de clientes, número de empréstimos baseados em dados de retorno e similares.
Isso geralmente é muito inspirador quando há um kit de ferramentas que permite avaliar o impacto do seu recurso em várias métricas de negócios importantes e prever o aumento da receita da empresa.
Para desenvolver, manter e implementar essas ferramentas, agora estamos desenvolvendo um departamento de planejamento e análise financeira (FP&A), cuja tarefa será tornar a tomada de decisões de negócios ainda mais suportada por dados, análise e modelagem.
À nossa frente ainda há muitas coisas interessantes: o desenvolvimento adicional da infraestrutura de BI, a criação de departamentos que a suportam e os processos que a utilizam.
Para resumir, podemos distinguir os seguintes princípios para o desenvolvimento de uma abordagem orientada a dados, à qual eu aderiria:
- O retorno esperado do investimento (por exemplo, economizando tempo da equipe, aumentando a precisão / velocidade da tomada de decisões etc.) é adequado aos recursos gastos.
- Gerenciamento interno de produtos: ao criar e desenvolver a infraestrutura, a "Lista de desejos" e o feedback dos clientes internos são investigados. E levado em conta.
- O desenvolvimento da infraestrutura deve acompanhar o desenvolvimento de processos e metodologias. E todos juntos - para não ficar para trás e não superar o desenvolvimento da empresa em termos de suas necessidades analíticas.