Los números significan mucho para nosotros. Invertimos en datos, los escuchamos y los entendemos. Nos guiamos por ellos al tomar decisiones. A pesar de que todavía tenemos mucho por delante en términos de infraestructura para trabajar con datos, el enfoque basado en datos siempre ha estado con nosotros. En este texto, una historia sobre qué camino tomamos, qué lecciones aprendimos y qué rastrillo recolectamos.
Mi nombre es Andrey Sytsko, soy el jefe de la línea de productos en la empresa fintech ID Finance. Como dije, todavía tenemos un largo camino por recorrer en términos de métodos y herramientas para trabajar con datos. El crecimiento múltiple que la compañía ha experimentado desde su inicio establece un ritmo inalcanzable para la infraestructura analítica. Sin embargo, es probable que las expectativas de un enfoque basado en datos simplemente estén creciendo a un ritmo más rápido. Al final, como todos entendemos, no solo las herramientas y tecnologías específicas son importantes, sino también el enfoque, la cultura y la visión del mundo.
¿Qué es una cultura basada en datos?
¿Qué queremos decir con una cultura basada en datos en una empresa? En mi opinión, esto es cuando acordamos internamente que los datos pueden dar una buena respuesta o consejo en el marco de un dilema comercial particular. Hay varias consecuencias de tal arreglo:
- Estamos listos para invertir en trabajar con datos: extracción, almacenamiento, análisis, interpretación, visualización y más. Listo para gastar dinero y tiempo
- Estamos listos para escuchar los datos. Es decir cuando necesita tomar una decisión comercial, nos detenemos y nos decimos: veamos los números.
- Podemos entender los datos. De hecho, es aterrador simplemente sacar la conclusión equivocada, teniendo a mano todos los números necesarios. Diga lo que quiera, hay algunos requisitos mínimos para el pensamiento analítico de los tomadores de decisiones con el fin de extraer el significado de las tablas, gráficos y cuadros.
- Confiamos en los datos y nos guiamos al tomar decisiones. Cuando un gerente, mirando un informe analítico preparado, dice que le irá mejor como le dice la experiencia, en lugar de un informe, entonces no está necesariamente equivocado. ¿Qué pasaría si los analistas no tuvieran en cuenta la estacionalidad, los resultados de las próximas elecciones o algo más? El diálogo entre gerentes y analistas, la confianza mutua es importante aquí.
Naturalmente, la cultura basada en datos en la compañía es más fácil de construir cuando los fundadores de la compañía ya son sus operadores. El uso de datos en la toma de decisiones hace que este proceso sea más lento y costoso. Y sin una convicción seria de que tiene sentido hacerlo, y de lo contrario, no irás lejos. Tuvimos suerte en este caso: ya se sentaron las bases correctas para el futuro edificio.
Primeros pasos de infraestructura
Lo primero que encontrará en el camino hacia la toma de decisiones ideal basada en datos es que no tiene suficientes datos. En general, siempre se los echará de menos por razones objetivas, pero debe comenzar por algún lado.
Para comenzar, construye la infraestructura para recopilar y almacenar métricas. En la gran mayoría de los proyectos de backends de datos (para nosotros, por ejemplo, información sobre clientes, sus préstamos y pagos para ellos), la réplica de la base de producción simplemente se usa al principio. En este caso, tendrá que disfrutar plenamente de la estructura interna de datos de su software, que los desarrolladores crearon sin pensar en hacer que los datos sean convenientes para analizar. Pero tenemos información de primera mano, por así decirlo. Al principio, generalmente hay una base de datos, y la estructura de datos es relativamente simple, así como las preguntas que desea hacer para estos datos, por lo que esta es una opción completamente funcional e invertir en algo más complicado no tiene sentido.
Para datos de front-end (vistas de página, interacción con controles, desplazamiento, clics, entrada), puede usar herramientas clásicas como Google Analytics o Yandex.Metrica y, por ejemplo, HotJar para grabar sesiones. Existe suficiente funcionalidad básica para las tareas de marketing, y para los informes de productos en embudos y pruebas a / b, cambiamos lo suficientemente rápido como para trabajar a través de la API de informes de Google. Ya lo contamos en Habré.
Aquí y
aquí
Una vez que haya creado la infraestructura básica y haya comenzado a recopilar estadísticas básicas, debe asegurarse de que el producto se desarrolle sincrónicamente con sus métricas.
Es decir Cuando vaya a implementar una nueva característica en un producto, debe responder aproximadamente las siguientes preguntas:
- ¿Qué métricas comerciales clave afectará esto?
- ¿Qué cambios se realizarán en el viaje del cliente o en los algoritmos de backend? ¿Y cómo afectará esto a las métricas existentes?
- ¿En qué etapas / componentes puedo desglosar la nueva funcionalidad para que al recopilar métricas para cada uno de ellos, pueda mirar dentro y analizar el trabajo de la función?
Ahora piense si la capacidad de recopilar todas las métricas anteriores es parte de la declaración del problema. ¿Y cómo los recogerá exactamente cuando se implemente la funcionalidad?
A continuación, debe asegurarse de que el subsistema para recopilar y almacenar estadísticas sea lo suficientemente importante para su equipo de desarrollo y su equipo de TI. Su importancia debería ser casi igual a la importancia del sistema de producción. Por ejemplo, al principio tuvimos un problema constante con el seguimiento de Google Analytics que desaparecía de diferentes páginas, hasta que discutimos la importancia de estas cosas con los desarrolladores. Después de eso, aparecieron las bibliotecas comunes necesarias, las pautas de control de calidad, etc.
Analítica para analistas
La disponibilidad de datos no significa su uso efectivo. Los siguientes problemas / tareas generalmente ocurren:
- ¿Dónde obtener esta o aquella métrica? ¿Cómo sacarla de allí?
- ¿Ella va bien? (De repente, todo no funciona según lo previsto)
- ¿Qué informe debo sacar para poder sacar conclusiones?
- ¿Hay alguna significación estadística?
- ¿Es posible desenterrar más datos para comprender mejor lo que está sucediendo o verificar las métricas recopiladas de una manera / en un lugar por otras métricas?
Resulta que este es un trabajo bastante voluminoso que requiere habilidades especiales y, lo más importante, tiempo. Por lo tanto, es necesario crear un departamento de análisis.
Nuestro departamento de análisis es bastante grande, en términos de la cantidad de personas es casi igual a la gerencia media. Contiene tanto estudiantes de ayer con buen conocimiento de SQL como profesionales que entienden bien cómo y qué datos deben obtenerse para tomar decisiones comerciales. El flujo de solicitudes a ellos tradicionalmente excede sus capacidades.
Lagos y almacenes de datos
Uno de los problemas que puede encontrar cuando haya más y más datos es que se encuentran en diferentes lugares y algunos analistas pueden trabajar con algunos repositorios, otros con otros. Y con algunas bases de datos, probablemente, nadie sabe cómo trabajar de inmediato. También se hace difícil comparar estos datos entre sí.
La solución a este problema puede ser un sistema como el almacén de datos (DWH). En nuestro caso, pensamos en esto por primera vez, cuando queríamos combinar datos sobre el comportamiento del usuario en el sitio y datos sobre su comportamiento como prestatario. Los principios de la construcción de DWH están mucho más allá del alcance de este artículo, solo diré qué dificultades / características fueron en nuestro caso:
- Cada uno de nuestros proyectos (ahora hay 9 en 6 países) la estructura de datos es ligeramente diferente y, en consecuencia, fue necesario desarrollar principios para su unificación
- Era necesario pensar cómo unir datos heterogéneos en un almacenamiento.
Por ejemplo:
- comportamiento del usuario en el sitio: transiciones entre páginas, interacción con controles
- registro de trabajo de política crediticia: la implementación de las reglas y sus resultados, la transición a lo largo de las ramas de la lógica
- comportamiento del prestatario - pagos de préstamos, venta cruzada
Ahora que hemos aprendido más o menos cómo integrar datos entre sí y fusionarlos en un Data Lake, procedimos a crear escaparates (conjuntos de datos, informes y visualizaciones previamente preparados) de los que se trataba. A la salida, esperamos recibir una reducción significativa en los requisitos de habilidades y costos laborales de nuestros analistas.
Por lo general, en esta etapa, aparece un rol dedicado de ingenieros de datos en la empresa, es decir personas a cargo de la infraestructura de datos. Se les confía la tarea de mantener y desarrollar DWH.
Es mejor contratar a las personas adecuadas de inmediato.
Con el crecimiento de la empresa, resulta que no todos los empleados comprenden de inmediato la importancia de los datos y pueden trabajar con ellos. Surgen dos preguntas: promoción interna y contratación de las personas adecuadas.
En cuanto a la promoción interna, entonces, como se mencionó anteriormente, si los fundadores de la compañía son portadores de una cultura de datos, entonces se reduce a la alta gerencia, la gerencia media, etc. Por ejemplo, exijo a mis gerentes de producto que calculen el efecto potencial en dinero o cambien las métricas clave antes de la implementación, y vean el hecho del plan después de la implementación de la nueva funcionalidad. O, por ejemplo, para priorizar el trabajo, guíese por las mismas evaluaciones de "valor comercial".
Nos acercamos a la plantación de una cultura basada en datos desde dos lados. Nuestro departamento de TI puede requerir que los gerentes de negocios establezcan una estimación del efecto en el dinero en el estado de las tareas. Y esto se aplica a todos los departamentos: marketing, soporte, contabilidad. A esto, recientemente agregamos el requisito de que la empresa describa explícitamente las métricas mediante las cuales hará un seguimiento de los resultados de los cambios implementados, y TI debe garantizar que se pueda acceder a estas métricas de una manera comprensible.
Es importante, por supuesto, verificar inmediatamente al contratar personas si están acostumbrados a centrarse en los números en su trabajo o no, si saben cómo hacerlo. Mis preguntas favoritas durante la entrevista, cuando discutimos la experiencia del candidato: ¿cómo calculó qué efecto le dará la característica, cómo midió qué efecto realmente dio, y por qué cree que este efecto debería atribuirse a esta característica, y no a otra cosa Un buen candidato siempre podrá justificar lógicamente por qué lo hizo y no de otra manera.
Con el crecimiento de los volúmenes comerciales y de datos, resulta significativo usar técnicas estadísticas más avanzadas y bibliotecas de aplicaciones más avanzadas, algunas de las que ahora se llaman ciencia de datos.
Si hablamos de ciencia de datos en un sentido más amplio que las redes neuronales y el aprendizaje automático, entonces, por ejemplo, tuvimos una experiencia exitosa en pasar de paquetes clásicos como SAS para construir regresión logística a herramientas de Python auto escritas. Esto
redujo el tiempo para desarrollar la calificación crediticia en 5 veces.
En algún momento, nos dimos cuenta de que la regresión logística y el análisis de conglomerados en ciertos volúmenes justifican su uso en marketing y gestión de productos para tareas relacionadas con la segmentación de clientes y determinar el producto óptimo o la estrategia de descuento individualmente para cada cliente.
Aprendiendo a predecir el futuro
La peculiaridad del negocio de préstamos es que no es suficiente vender un producto: dinero a crédito, debe administrar el flujo de caja futuro. En consecuencia, el papel de varios modelos predictivos y su integración en el pronóstico del futuro P&L se destaca. Ejemplos de tales modelos: tarifas futuras basadas en datos de morosidad anticipada, factura promedio basada en datos de segmentación de clientes, número de préstamos basados en datos de devolución y similares.
Esto generalmente es muy inspirador cuando hay un conjunto de herramientas que le permite evaluar el impacto de su función en varias métricas comerciales clave y predecir el aumento de los ingresos de la empresa.
Para desarrollar, mantener e implementar tales herramientas, ahora estamos desarrollando un departamento de planificación y análisis financiero (FP&A), cuya tarea será hacer que la toma de decisiones comerciales sea aún más respaldada por datos, análisis y modelado.
Aún tenemos muchas cosas interesantes por delante: el desarrollo adicional de la infraestructura de BI, la creación de departamentos que lo respaldan y los procesos que la utilizan.
Para resumir, podemos distinguir los siguientes principios para el desarrollo de un enfoque basado en datos, al que me adheriría:
- El rendimiento esperado de la inversión (por ejemplo, en ahorrar tiempo al personal, aumentar la precisión / velocidad de la toma de decisiones, etc.) es adecuado para los recursos gastados.
- Gestión interna del producto: cuando se crea y desarrolla la infraestructura, se investigan las "Lista de deseos" y los comentarios de los clientes internos. Y tomado en cuenta.
- El desarrollo de la infraestructura debe mantenerse al día con el desarrollo de procesos y metodologías. Y todo junto: no quedarse atrás y no superar el desarrollo de la empresa en términos de sus necesidades analíticas.