Olá pessoal!
No Halloween, participei de uma conferência em Budapeste ( Data Crunch ) e ouvi várias apresentações interessantes. Um deles era do Uber, que falou sobre as abordagens nas quais eles organizaram sua plataforma de gerenciamento de dados. Este relatório não era tão técnico quanto gerencial e de mercearia.
O Uber faz amplo uso dos dados coletados como resultado de interações com passageiros e motoristas. Eles calculam o custo da viagem, avaliam o fluxo de pessoas, alteram os algoritmos de preços, dão recomendações aos motoristas sobre como eles podem ganhar mais dinheiro e tudo isso com base nos dados coletados. Em uma empresa assim, todo o trabalho com dados não pode ser concentrado nas mãos de um grupo de analistas e DS, porque caso contrário, eles terão que contratar muitos e, além disso, eles nem sempre estão imersos no contexto comercial.
Desde o início, a empresa adotou o caminho de criar uma plataforma de gerenciamento de dados que permitisse o uso de ferramentas analíticas bastante avançadas para uma ampla gama de usuários. Eles identificaram 4 grupos principais:
- Usuários comuns - eles conhecem SQL básico, basicamente precisam apenas de tabelas de dados, painéis)
- Gerentes regionais - eles conhecem um pouco mais de SQL, analisam dados em diferentes seções, há uma grande necessidade de fatia e dados
- Analistas de dados - SQL avançado, criar painéis, pesquisar, procurar informações sobre dados
- Ciência de dados - o nível máximo de entendimento de como trabalhar com dados, criar modelos, realizar experimentos, testes A / B, etc.
À margem, também aprendi com eles que, na verdade, existe um 5º nível - gerentes de topo que usam principalmente relatórios e painéis de nível superior.
Curiosamente, no Uber, as pessoas que trabalham de alguma forma com dados devem conhecer SQL pelo menos no nível mínimo.
Como exemplo do produto que eles criaram com base em sua plataforma, eles citaram a automação dos testes A / B. A empresa gasta uma quantidade enorme de A / B e aloca para cada Cientista de Dados, para que ele organize um experimento e faça uma avaliação dos testes - novamente, não um luxo permitido. Portanto, eles gostariam de dar aos usuários comuns a oportunidade de interpretar e usar A / B corretamente e sem erros, sem carregar o Data Scientist.
A construção deste produto começou com um trabalho profundo com a Data Scientist, como se esses caras não tiverem certeza de que tudo é considerado correto, nenhum produto Data será lançado. De fato, eles começaram a automatizar o lançamento e a avaliação dos testes A / B, oferecendo ao Data Scientist uma ferramenta para facilitar sua vida. Depois disso, eles criaram uma interface nessa ferramenta que mostraria os resultados do teste de forma simples (o que foi lançado, que diferença, se a diferença é significativa). Ao mesmo tempo, eles ocultaram "sob o capô" o número máximo de nuances inerentes aos testes A / B, para que o usuário não precisasse se aprofundar em matemática e estatística.
Curiosamente, a maioria das pessoas com quem conversei sobre coffee breaks disse que não tem nenhum teste A / B em sua prática, que usa muita pesquisa e intuição qualitativa ao tomar decisões. Assim como em outros lugares, uma vez que você pensa, você precisa cortar!