Цифры много значат для нас. Мы инвестируем в данные, слушаем и понимаем их. Мы руководствуемся ими при принятии решений. Несмотря на то, что в плане инфраструктуры работы с данными у нас еще многое впереди, сам data driven подход был с нами всегда. В этом тексте — рассказ о том, какой путь мы прошли, какие уроки выучили и какие грабли собрали.
Меня зовут Андрей Сыцко, я руководитель продуктового направления в финтех-компании ID Finance. Как я уже сказал, нам еще предстоит пройти большой путь с точки зрения методов и инструментов работы с данными. Кратный рост, который компания переживает с момента своего основания, задает недостижимый темп для аналитической инфраструктуры. Однако, вполне вероятно, что ожидания от data driven подхода просто растут опережающими темпами. В конечном итоге, как мы все понимаем, важны не какие-то конкретные инструменты и технологии, а подход, культура и мировоззрение.
Что мы понимаем под data-driven культурой в компании? На мой взгляд, это когда мы внутри договорились о том, что данные могут дать хороший ответ или совет в рамках той или иной бизнес-дилеммы. Можно выделить несколько следствий такой договоренности:
Естественно, data driven культуру в компании проще всего построить, когда основатели компании уже являются ее носителям. Использование данных при принятии решений делает этот процесс более трудоемким и дорогим. А без серьезной убежденности, что есть смысл делать так, а не иначе, далеко не уедешь. Нам в этом случае повезло — правильный фундамент будущему зданию уже был заложен.
Первое, с чем вы столкнетесь на пути к своему идеалу data driven decision making — это то, что у вас не хватает данных. В целом, их всегда будет не хватать по объективным причинам, но с чего-то надо начинать.
Для начала вы строите инфраструктуру по сбору и хранению метрик. В подавляющем большинстве проектов для бекенд данных (а у нас это, например, информация о клиентах, их кредитах и платежам по ним) сначала просто используется реплика продакшн базы. При этом придется всецело насладиться внутренней структурой данных вашего софта, которую разработчики создали без мысли о том, чтобы данные было удобно анализировать. Но зато имеем информацию, так сказать, из первых рук. В начале, обычно есть одна база данных, а структура данных относительно проста, так же как и вопросы, которые к этим данным вы захотите задать, так что это вполне рабочий вариант и инвестировать во что-то более сложное не имеет смысла.
Для фронтенд данных (просмотры страниц, взаимодействие с контролам, скроллинг, клики, ввод) можно использовать классические инструменты типа Google Analytics или Яндекс.Метрика и, например, HotJar для записи сессий. Базового функционала хватает для задач маркетинга, а для продуктовых отчетов по воронкам и а/б тестам мы достаточно быстро перешли на работу через Google Reporting API. Мы уже раньше рассказывали об этом на Хабре. Здесь и здесь.
После того, как вы выстроили базовую инфраструктуру и начали собирать основную статистику необходимо убедиться, что продукт будет развиваться синхронно с его метриками.
Т.е. когда вы собираетесь реализовать новую фичу в продукте вам нужно ответить примерно на такие вопросы:
А теперь подумайте, является ли частью постановки задачи возможность собрать все вышеперечисленные метрики? И как именно вы будете их собирать когда функционал будет реализован?
Дальше нужно убедиться, что подсистема сбора и хранения статистики имеет достаточную важность для вашей команды разработки и IT команды. Ее важность должна быть практически равна важности продакшн системы. Например, у нас в начале была постоянная проблема с пропаданием трекинга Google Analytics с разных страниц, пока мы не обсудили важность этих вещей с разработчиками. После чего появились необходимые общие библиотеки, QA гайдлайны и т.п.
Наличие данных еще не означает их эффективное использование. Обычно возникают следующие проблемы/задачи:
Оказывается, что это достаточно объемная работа, требующая специальных навыков и умений, а, главное, времени. Так возникает потребность в создании отдела аналитики.
Наш отдел аналитики достаточно большой, по количеству людей он почти равен мидл-менеджменту. В нем есть как вчерашние студенты с хорошим знанием SQL, так и профессионалы, которые хорошо понимают, как и какие данные нужно достать, чтобы можно было принимать бизнес-решения. Поток запросов к ним традиционно превосходит их возможности.
Одна из проблем, с которой вы наверняка столкнетесь, когда данных будет становиться все больше, это то, что они лежат в разных местах и одни аналитики умеют работать с одними хранилищами, другие — с другими. А с какими-то БД, возможно, сходу никто не умеет работать. Также становится сложно сопоставлять эти данные между собой.
Решением этой задачи могут стать системы типа data warehouse (DWH). В нашем случае, мы задумались об этом в первый раз, когда нам захотелось объединить данные о поведении пользователя на сайте и данные о его поведении как заемщика. Принципы построения DWH далеко выходят за рамки данной статьи, скажу только, какие в нашем случае были сложности/особенности:
Например:
Сейчас, когда мы более-менее научились интегрировать данные между собой и слили их в один Data Lake, мы перешли к созданию витрин – предподготовленных датасетов, отчетов и визуалиций — то, ради чего это все и затевалось. На выходе мы ожидаем получить существенное снижение требований к скилам и трудозатратам наших аналитиков.
Обычно на этом этапе в компании появляется выделенная роль data engineers — т.е. людей, отвечающих за инфраструктуру по работе с данными. На них возлагается задача поддержания и развития DWH.
С ростом компании выясняется, что не все сотрудники сходу понимают важность данных и умеют с ними работать. Возникает два вопроса: внутренний промоушн и найм правильных людей.
Что касается внутреннего промоушна, то, как говорилось выше, если основатели компании являются носителями дата-культуры, то дальше это спускается на топ-менеджемент, миддл-менеджмент и так далее. Я, например, требую от своих продакт-менеджеров рассчитать потенциальный эффект в деньгах или изменении ключевых метрик до реализации, и посмотреть план факт после реализации нового функционала. Или, скажем, для приоритизации работы, руководствоваться этими же оценками “business value”.
К насаждению data-driven культуры мы подходим с двух сторон. Наше IT подразделение может требовать от бизнес-менеджеров, чтобы в постановке задач была указана оценка эффекта в деньгах. Причем это относится ко всем подразделениям: маркетинг, саппорт, бухгалтерия. К этому мы недавно добавили требование, чтобы бизнес явно описывал метрики, по которым он будет отслеживать результаты внедряемых изменений, а IT должно проследить, чтобы эти метрики можно было достать понятным образом.
Важно, конечно, сразу при найме людей проверять, привыкли ли они ориентироваться на цифры в своей работе или нет, умеют ли они это делать. Мои любимые вопросы на собеседовании, когда мы обсуждаем опыт кандидата: как вы рассчитывали, какой эффект даст фича, как вы померили, какой эффект она по факту дала, и почему вы считаете, что этот эффект нужно отнести именно к этой фиче, а не к чему-то еще. Хороший кандидат всегда сможет логически обосновать почему он делал так, а не иначе.
С ростом бизнеса и объемов данных становится осмысленным применение более продвинутых статистических методик и более продвинутых прикладных библиотек — что-то из того, что сейчас принято называть data science.
Если говорить о data science в более широком смысле нежели нейросети и machine learning, то у нас, например, был успешный опыт перехода от классических пакетов типа SAS для построения логистической регрессии на самописный инструментарий на питоне. Это сократило время на разработку кредитного скоринга в 5 раз.
В какой-то момент поняли, что логистическая регрессия и кластерный анализ на определенных объемах так же оправдывают свое применение в маркетинге и продакт-менеджменте для задач связанных с сегментацией клиентов и определением оптимальной продуктовой или скидочной стратегии индивидуально под каждого клиента.
Особенность кредитного бизнеса заключается в том, что мало продать товар — деньги в кредит, нужно управлять будущим денежным потоком. Соответственно, роль различных предсказательных моделей и их объединение в прогноз будущего P&L выходит на первый план. Примеры таких моделей: будущие сборы исходя из ранних данных о просрочке, средний чек исходя из данных о сегментации клиентов, количество кредитов исходя из данных о возврате и тому подобное.
Это вообще очень вдохновляет, когда есть инструментарий, который позволяет оценить влияние твоей фичи на различные ключевые метрики бизнеса и предсказать увеличение выручки компании.
Для разработки, поддержания и внедрения подобных инструментов мы сейчас развиваем отдел финансового планирования и анализа (FP&A), задачей которого будет сделать принятие бизнес-решений еще более подкрепленным данными, анализом и моделированием.
Впереди нам предстоит еще много всего интересного: дальнейшее развитие BI инфраструктуры, создание отделов, которые ее поддерживают и процессов, которые ее используют.
Подытоживая, можно выделить следующие принципы развития data-driven подхода, которых я бы придерживался:
Меня зовут Андрей Сыцко, я руководитель продуктового направления в финтех-компании ID Finance. Как я уже сказал, нам еще предстоит пройти большой путь с точки зрения методов и инструментов работы с данными. Кратный рост, который компания переживает с момента своего основания, задает недостижимый темп для аналитической инфраструктуры. Однако, вполне вероятно, что ожидания от data driven подхода просто растут опережающими темпами. В конечном итоге, как мы все понимаем, важны не какие-то конкретные инструменты и технологии, а подход, культура и мировоззрение.
Что такое data driven культура?
Что мы понимаем под data-driven культурой в компании? На мой взгляд, это когда мы внутри договорились о том, что данные могут дать хороший ответ или совет в рамках той или иной бизнес-дилеммы. Можно выделить несколько следствий такой договоренности:
- Мы готовы инвестировать в работу с данными: извлечение, хранение, анализ, интерпретацию, визуализацию и прочее. Готовы тратить деньги и время
- Мы готовы слушать данные. Т.е. когда нужно принять бизнес-решение мы останавливаемся и говорим сами себе — давайте посмотрим на числа.
- Мы умеем понимать данные. Действительно, бывает ужасающе просто сделать неправильный вывод, имея на руках все необходимые цифры. Как ни крути, есть некоторые минимальные требования к аналитическому мышлению лиц, принимающих решения, чтобы извлечь смысл из таблиц, графиков и диаграмм.
- Мы доверяем данным и руководствуемся ими при принятии решений. Когда менеджер, глядя на подготовленный аналитический отчет, говорит, что он лучше сделает так, как ему подсказывает опыт, а не отчет, то он необязательно не прав. А вдруг аналитики не учли сезональность, результаты грядущих выборов или еще что-то? Тут важен диалог между менеджерами и аналитиками, доверие друг к другу.
Естественно, data driven культуру в компании проще всего построить, когда основатели компании уже являются ее носителям. Использование данных при принятии решений делает этот процесс более трудоемким и дорогим. А без серьезной убежденности, что есть смысл делать так, а не иначе, далеко не уедешь. Нам в этом случае повезло — правильный фундамент будущему зданию уже был заложен.
Первые инфраструктурные шаги
Первое, с чем вы столкнетесь на пути к своему идеалу data driven decision making — это то, что у вас не хватает данных. В целом, их всегда будет не хватать по объективным причинам, но с чего-то надо начинать.
Для начала вы строите инфраструктуру по сбору и хранению метрик. В подавляющем большинстве проектов для бекенд данных (а у нас это, например, информация о клиентах, их кредитах и платежам по ним) сначала просто используется реплика продакшн базы. При этом придется всецело насладиться внутренней структурой данных вашего софта, которую разработчики создали без мысли о том, чтобы данные было удобно анализировать. Но зато имеем информацию, так сказать, из первых рук. В начале, обычно есть одна база данных, а структура данных относительно проста, так же как и вопросы, которые к этим данным вы захотите задать, так что это вполне рабочий вариант и инвестировать во что-то более сложное не имеет смысла.
Для фронтенд данных (просмотры страниц, взаимодействие с контролам, скроллинг, клики, ввод) можно использовать классические инструменты типа Google Analytics или Яндекс.Метрика и, например, HotJar для записи сессий. Базового функционала хватает для задач маркетинга, а для продуктовых отчетов по воронкам и а/б тестам мы достаточно быстро перешли на работу через Google Reporting API. Мы уже раньше рассказывали об этом на Хабре. Здесь и здесь.
После того, как вы выстроили базовую инфраструктуру и начали собирать основную статистику необходимо убедиться, что продукт будет развиваться синхронно с его метриками.
Т.е. когда вы собираетесь реализовать новую фичу в продукте вам нужно ответить примерно на такие вопросы:
- На какие ключевые бизнес метрики это повлияет?
- Какие изменения в customer journey или в бекенд алгоритмы будут привнесены? И как это повлияет на уже имеющиеся метрики?
- На какие этапы/составляющие я могу разбить новый функционал, чтобы собрав метрики по каждому из них, я смог бы заглянуть внутрь и проанализировать работу фичи
А теперь подумайте, является ли частью постановки задачи возможность собрать все вышеперечисленные метрики? И как именно вы будете их собирать когда функционал будет реализован?
Дальше нужно убедиться, что подсистема сбора и хранения статистики имеет достаточную важность для вашей команды разработки и IT команды. Ее важность должна быть практически равна важности продакшн системы. Например, у нас в начале была постоянная проблема с пропаданием трекинга Google Analytics с разных страниц, пока мы не обсудили важность этих вещей с разработчиками. После чего появились необходимые общие библиотеки, QA гайдлайны и т.п.
Аналитика для аналитиков
Наличие данных еще не означает их эффективное использование. Обычно возникают следующие проблемы/задачи:
- Где взять ту или иную метрику? Как ее оттуда достать?
- А правильно ли она собирается? (вдруг все работает не так, как предполагалось)
- Какой надо сделать отчет, чтобы можно было делать какие-то выводы?
- Есть ли статистическая значимость?
- Можно ли накопать еще данных, чтобы получше понять, что происходит или же проверить метрики, собранные одним способом/в одном месте другими метрикам.
Оказывается, что это достаточно объемная работа, требующая специальных навыков и умений, а, главное, времени. Так возникает потребность в создании отдела аналитики.
Наш отдел аналитики достаточно большой, по количеству людей он почти равен мидл-менеджменту. В нем есть как вчерашние студенты с хорошим знанием SQL, так и профессионалы, которые хорошо понимают, как и какие данные нужно достать, чтобы можно было принимать бизнес-решения. Поток запросов к ним традиционно превосходит их возможности.
Озера и склады данных
Одна из проблем, с которой вы наверняка столкнетесь, когда данных будет становиться все больше, это то, что они лежат в разных местах и одни аналитики умеют работать с одними хранилищами, другие — с другими. А с какими-то БД, возможно, сходу никто не умеет работать. Также становится сложно сопоставлять эти данные между собой.
Решением этой задачи могут стать системы типа data warehouse (DWH). В нашем случае, мы задумались об этом в первый раз, когда нам захотелось объединить данные о поведении пользователя на сайте и данные о его поведении как заемщика. Принципы построения DWH далеко выходят за рамки данной статьи, скажу только, какие в нашем случае были сложности/особенности:
- у каждого из наших проектов (сейчас их 9 в 6 странах) структура данных немного отличается и, соответственно, необходимо было выработать принципы их унификации
- необходимо было придумать, как объединить разнородные данные в одном хранилище.
Например:
- поведение пользователя на сайте – переходы между страницам, взаимодействие с управляющими элементами
- лог работы кредитной политики – выполнение правил и их результат, переход по веткам логики
- поведение заемщика – платежи по кредиту, кросс-продажи
Сейчас, когда мы более-менее научились интегрировать данные между собой и слили их в один Data Lake, мы перешли к созданию витрин – предподготовленных датасетов, отчетов и визуалиций — то, ради чего это все и затевалось. На выходе мы ожидаем получить существенное снижение требований к скилам и трудозатратам наших аналитиков.
Обычно на этом этапе в компании появляется выделенная роль data engineers — т.е. людей, отвечающих за инфраструктуру по работе с данными. На них возлагается задача поддержания и развития DWH.
Лучше сразу нанять правильных людей
С ростом компании выясняется, что не все сотрудники сходу понимают важность данных и умеют с ними работать. Возникает два вопроса: внутренний промоушн и найм правильных людей.
Что касается внутреннего промоушна, то, как говорилось выше, если основатели компании являются носителями дата-культуры, то дальше это спускается на топ-менеджемент, миддл-менеджмент и так далее. Я, например, требую от своих продакт-менеджеров рассчитать потенциальный эффект в деньгах или изменении ключевых метрик до реализации, и посмотреть план факт после реализации нового функционала. Или, скажем, для приоритизации работы, руководствоваться этими же оценками “business value”.
К насаждению data-driven культуры мы подходим с двух сторон. Наше IT подразделение может требовать от бизнес-менеджеров, чтобы в постановке задач была указана оценка эффекта в деньгах. Причем это относится ко всем подразделениям: маркетинг, саппорт, бухгалтерия. К этому мы недавно добавили требование, чтобы бизнес явно описывал метрики, по которым он будет отслеживать результаты внедряемых изменений, а IT должно проследить, чтобы эти метрики можно было достать понятным образом.
Важно, конечно, сразу при найме людей проверять, привыкли ли они ориентироваться на цифры в своей работе или нет, умеют ли они это делать. Мои любимые вопросы на собеседовании, когда мы обсуждаем опыт кандидата: как вы рассчитывали, какой эффект даст фича, как вы померили, какой эффект она по факту дала, и почему вы считаете, что этот эффект нужно отнести именно к этой фиче, а не к чему-то еще. Хороший кандидат всегда сможет логически обосновать почему он делал так, а не иначе.
С ростом бизнеса и объемов данных становится осмысленным применение более продвинутых статистических методик и более продвинутых прикладных библиотек — что-то из того, что сейчас принято называть data science.
Если говорить о data science в более широком смысле нежели нейросети и machine learning, то у нас, например, был успешный опыт перехода от классических пакетов типа SAS для построения логистической регрессии на самописный инструментарий на питоне. Это сократило время на разработку кредитного скоринга в 5 раз.
В какой-то момент поняли, что логистическая регрессия и кластерный анализ на определенных объемах так же оправдывают свое применение в маркетинге и продакт-менеджменте для задач связанных с сегментацией клиентов и определением оптимальной продуктовой или скидочной стратегии индивидуально под каждого клиента.
Учиться предсказывать будущее
Особенность кредитного бизнеса заключается в том, что мало продать товар — деньги в кредит, нужно управлять будущим денежным потоком. Соответственно, роль различных предсказательных моделей и их объединение в прогноз будущего P&L выходит на первый план. Примеры таких моделей: будущие сборы исходя из ранних данных о просрочке, средний чек исходя из данных о сегментации клиентов, количество кредитов исходя из данных о возврате и тому подобное.
Это вообще очень вдохновляет, когда есть инструментарий, который позволяет оценить влияние твоей фичи на различные ключевые метрики бизнеса и предсказать увеличение выручки компании.
Для разработки, поддержания и внедрения подобных инструментов мы сейчас развиваем отдел финансового планирования и анализа (FP&A), задачей которого будет сделать принятие бизнес-решений еще более подкрепленным данными, анализом и моделированием.
Впереди нам предстоит еще много всего интересного: дальнейшее развитие BI инфраструктуры, создание отделов, которые ее поддерживают и процессов, которые ее используют.
Подытоживая, можно выделить следующие принципы развития data-driven подхода, которых я бы придерживался:
- Ожидаемый возврат инвестиций (например, в экономии времени персонала, повышения точности/скорости принятия решений и тп.) адекватен затрачиваемым ресурсам.
- Внутренний продакт-менеджмент: при создании и развитии инфраструктуры исследуются «хотелки» и фидбек внутренних заказчиков. И принимаются во внимание.
- Развитие инфраструктуры должно идти в ногу с развитием процессов и методологий. А все вместе — не отставать и не опережать развитие компании в плане ее потребностей в аналитике.