Данные решают: что такое data driven decisions и зачем оно вам
Чтобы бизнес жил, нужно каждый день принимать решения: кого нанять, кого уволить, какую рекламу купить и что сделать, чтобы клиенты вернулись хотя бы еще раз.
И если неправильный выбор, скажем, новогоднего подарка партнерам, скорее всего, не скажется на финансовых показателях компании, то от решения на какой рекламный канал потратить бюджет или какой бизнес-процесс стоит изменить зависит порой очень многое.
Data Driven Decisions в переводе на русский – «решения, основанные на данных».
Казалось бы, все серьезные решения и так принимаются на основе каких-то данных, зачем придумать новый термин. Но основная идея подхода Data Driven Decisions заключается именно в понимании того, как каждое конкретное решение влияет на конечную цель компании.
Не просто какому количеству пользователей показали рекламу или сколько получили кликов, а сколько прибыли получила компания на каждый вложенный рубль именно в этот конкретный рекламный канал.
Прежде всего необходимо сформулировать ключевую бизнес-цель компании на текущей стадии. Чаще всего это рост прибыли или доли рынка. Далее исходя из цели определить правильные метрики, оптимизация которых будет напрямую способствовать достижению заявленной цели.
Например, для достижения цели «рост прибыли», метриками могут быть (один или несколько из списка): количество новых клиентов, уровень оттока пользователей на определенном этапе, средний чек, стоимость привлечения клиентов, уровень маржинальности продуктов, уровень конверсии.
При определении метрик важно не поддаться соблазну поставить в качестве цели «улучшить все возможные варианты», а остановиться максимум на 2–3 наиболее важных показателях. Это позволит в краткосрочном периоде сфокусировать усилия по их улучшению, а не распыляться по всем направлениям.
После того как ты определился с метриками, становится значительно проще оценивать каждое бизнес-решение с точки зрения его реализации и впоследствии работать над оптимизацией самих метрик.
Вот несколько характеристик, которые отличают хорошие метрики от плохих:
1) Хорошая метрика сравнительна
Метрику можно сравнивать между временными периодами, рекламными каналами или группами пользователей. «Повышение уровня конверсии по сравнению с прошлым месяцем», более полезна чем «уровень конверсии равен 2%»
Если большинство в команде не может запомнить, что она значит, будет намного сложнее использовать ее для достижения целей компании
3) Хорошая метрика выражена в относительных показателях
Есть несколько причин, почему относительные показатели чаще всего лучшие метрики:
Дальше дисциплинировано работать над их улучшением. Попробую рассказать, что имею ввиду, на примере 2-х совершенно разных бизнесов: онлайн-сервис бронирования отелей Ostrovok.ru и продавец пластиковых окон «Фабрика окон».
Бизнес-модель Ostrovok.ru построена на получении комиссии от отелей за каждое бронирование. Фактически Ostrovok.ru осуществляет маркетинг для отелей, получая за это вознаграждение по факту привлечения клиента. Компания отслеживает огромное количество операционных и финансовых метрик (как минимум, чтобы отчитываться перед советом директоров и инвесторами), но 3 из них ключевые для бизнеса компании: количество бронирований до отмен, средний чек и собственная метрика Cost-Revenue Efficiency (CRE)*.
* CRE вычисляется делением суммы денег, вложенных в маркетинг, на сумму заработка с каждого заказа, с учетом отмен и cost of sales.
В первые годы CRE компании был в разы выше 1, т.е. только на маркетинг компания тратила в разы больше, чем зарабатывала, но уже 2014 году показатель стал ниже 1, а в 2015 году компания вышла на операционную окупаемость.
Для достижения этих результатов команда работала над повышением уровня конверсии (за счет лучшего выбора отелей, правильного контента и удобного интерфейса), над увеличением среднего чека (за счет роста доли продаж отелей за рубежом) и над увеличением комиссии с каждого заказа (за счет работы с большим количеством поставщиком отелей и оптимизации маркетинга). В маркетинге оптимизировались и даже выключались неэффективные каналы, а также развивались новые направления дистрибуции.
В любой компании можно придумать бесконечное количество метрик, но важно найти несколько ключевых, которые напрямую будут отражать здоровье и динамику вашего бизнеса.
Эти советы не серебряная пуля, но они сразу же подсветят, где у вас проблемные точки, негативные тренды и многие вопросы по приоритизация задач станут намного более очевидными.
Как быть data driven. С самого начала
Цифры много значат для нас. Мы инвестируем в данные, слушаем и понимаем их. Мы руководствуемся ими при принятии решений. Несмотря на то, что в плане инфраструктуры работы с данными у нас еще многое впереди, сам 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 engineers — т.е. людей, отвечающих за инфраструктуру по работе с данными. На них возлагается задача поддержания и развития DWH.
Лучше сразу нанять правильных людей
С ростом компании выясняется, что не все сотрудники сходу понимают важность данных и умеют с ними работать. Возникает два вопроса: внутренний промоушн и найм правильных людей.
Что касается внутреннего промоушна, то, как говорилось выше, если основатели компании являются носителями дата-культуры, то дальше это спускается на топ-менеджемент, миддл-менеджмент и так далее. Я, например, требую от своих продакт-менеджеров рассчитать потенциальный эффект в деньгах или изменении ключевых метрик до реализации, и посмотреть план факт после реализации нового функционала. Или, скажем, для приоритизации работы, руководствоваться этими же оценками “business value”.
К насаждению data-driven культуры мы подходим с двух сторон. Наше IT подразделение может требовать от бизнес-менеджеров, чтобы в постановке задач была указана оценка эффекта в деньгах. Причем это относится ко всем подразделениям: маркетинг, саппорт, бухгалтерия. К этому мы недавно добавили требование, чтобы бизнес явно описывал метрики, по которым он будет отслеживать результаты внедряемых изменений, а IT должно проследить, чтобы эти метрики можно было достать понятным образом.
Важно, конечно, сразу при найме людей проверять, привыкли ли они ориентироваться на цифры в своей работе или нет, умеют ли они это делать. Мои любимые вопросы на собеседовании, когда мы обсуждаем опыт кандидата: как вы рассчитывали, какой эффект даст фича, как вы померили, какой эффект она по факту дала, и почему вы считаете, что этот эффект нужно отнести именно к этой фиче, а не к чему-то еще. Хороший кандидат всегда сможет логически обосновать почему он делал так, а не иначе.
С ростом бизнеса и объемов данных становится осмысленным применение более продвинутых статистических методик и более продвинутых прикладных библиотек — что-то из того, что сейчас принято называть data science.
Если говорить о data science в более широком смысле нежели нейросети и machine learning, то у нас, например, был успешный опыт перехода от классических пакетов типа SAS для построения логистической регрессии на самописный инструментарий на питоне. Это сократило время на разработку кредитного скоринга в 5 раз.
В какой-то момент поняли, что логистическая регрессия и кластерный анализ на определенных объемах так же оправдывают свое применение в маркетинге и продакт-менеджменте для задач связанных с сегментацией клиентов и определением оптимальной продуктовой или скидочной стратегии индивидуально под каждого клиента.
Учиться предсказывать будущее
Особенность кредитного бизнеса заключается в том, что мало продать товар — деньги в кредит, нужно управлять будущим денежным потоком. Соответственно, роль различных предсказательных моделей и их объединение в прогноз будущего P&L выходит на первый план. Примеры таких моделей: будущие сборы исходя из ранних данных о просрочке, средний чек исходя из данных о сегментации клиентов, количество кредитов исходя из данных о возврате и тому подобное.
Это вообще очень вдохновляет, когда есть инструментарий, который позволяет оценить влияние твоей фичи на различные ключевые метрики бизнеса и предсказать увеличение выручки компании.
Для разработки, поддержания и внедрения подобных инструментов мы сейчас развиваем отдел финансового планирования и анализа (FP&A), задачей которого будет сделать принятие бизнес-решений еще более подкрепленным данными, анализом и моделированием.
Впереди нам предстоит еще много всего интересного: дальнейшее развитие BI инфраструктуры, создание отделов, которые ее поддерживают и процессов, которые ее используют.
Подытоживая, можно выделить следующие принципы развития data-driven подхода, которых я бы придерживался:
Data-Driven подход в маркетинге: что это такое и как построить стратегию
Здравствуйте. Меня зовут Людмила, я маркетолог в компании Altcraft. Сегодня я хочу поговорить с вами о data-driven подходе в маркетинге. В статье рассказываю, что это такое, зачем использовать и какие существуют метрики в data-driven маркетинге. Приятного чтения.
В последние годы маркетологи проводят совещания, где раз за разом принимают избитые решения, заводящие их в тупик. Модели потребления постоянно меняются, а лояльность к бренду эфемерна как никогда раньше. От этих и других неприятностей, терзающих отдел маркетинга, эксперты проповедуют одно решение — data-driven подход в маркетинге.
Data-driven подход — это использование информации о клиентах для оптимизации бизнес-рекламы и маркетинговых коммуникаций. Маркетологи собирают данные и обрабатывают их с помощью аналитических инструментов. Так они предугадывают желания покупателей и понимают, зачем им нужен тот или иной продукт и где и как они хотят его получить.
Примеры использования data driven подхода вы найдете повсюду. Например, такие сервисы как YouTube и Netflix непрерывно анализируют предпочтения пользователей и рекомендуют им те видео, фильмы и сериалы, которые их заинтересуют.
Многие компании используют подход, основанный на данных, для лучшей сегментации целевой аудитории. Владея нужными данными, можно точно определить потребителей, заинтересованных в продукте, установить эффективные каналы для взаимодействия с клиентами или узнать, в какое время дня аудитория наиболее восприимчива к коммуникации.
С помощью A/B тестирования — одного из методов data-driven маркетинга — маркетологи сравнивают эффективность двух вариантов одного письма и выбирают тот, что вызывает наибольший отклик клиента. В долгосрочной перспективе этот подход экономит компании немало денег, а также повышает ROI.
Ключевым же преимуществом data-driven маркетинга является персонализация. Бренд разрабатывает персонализированную маркетинговую стратегию на основе данных, полученных в результате взаимодействия с клиентом.
Data-driven стратегия помогает компаниям принимать обоснованные бизнес-решения. Чтобы ее разработать, соберите нужные данные и найдите правильное решение для их использования. Привлеките к работе команду профессионалов, специализирующихся на расширении аудитории или прогнозной аналитике.
Основные действия при разработке data-driven стратегии:
Оценить результаты. Подход, основанный на данных, требует регулярного и тщательного измерения результатов. Отслеживание поведения ваших клиентов — единственный способ адаптировать вашу стратегию к их потребностям. Продолжайте тестирование даже после обработки первых результатов и при необходимости изменяйте маркетинговую кампанию.
Для успешного внедрения data-driven стратегии, важно выбрать ключевые показатели эффективности (KPI).
Поскольку посетители сайта — это потенциальные клиенты компании, мониторить трафик сайта надо регулярно. Маркетологи должны понимать, с каких именно ресурсов пользователи переходят на сайт и какой тип рекламы дает наилучшие результаты. Органический поиск, ссылки в соцсетях, email-рассылки, переходы с других сайтов или медийная реклама — сфокусируйтесь на наиболее эффективных каналах трафика и, опираясь на полученные данные, грамотно распределите бюджет.
В какой бы тип рекламы вы ни инвестировали, необходимо знать, как это отражается на доходах компании. Здесь на помощь приходит коэффициент окупаемости инвестиций. Простыми словами, ROI — это ответ на вопрос «Получили ли мы прибыль после всех расходов на маркетинговую кампанию?». Вычтите из полученной прибыли расходы на маркетинг, а остаток разделите на те же расходы.
LTV — это вся прибыль от клиента за период, пока вы с ним работаете. Если потратить на привлечение клиента больше, чем вы позже на нем заработаете, вы потеряете деньги. Вот почему так важно отслеживать LTV. Так, вы сможете решить, сколько денег вложить в привлечение клиентов.
CAC — это общая сумма, которая требуется бизнесу, чтобы привлечь одного клиента. Она включает в себя время, потраченное вашими торговыми представителями, а также расходы на маркетинг и рекламу. Если показатель CAC больше показателя LTV, значит, ваши затраты на привлечение клиента больше, чем получаемая от него прибыль, а это повод изменить свою маркетинговую стратегию.
Показатель оттока клиентов показывает количество клиентов, прекративших сотрудничество с компаний. Для маркетологов крайне важно отслеживать этот показатель, поскольку это что-то вроде лакмусовой бумажки: клиенты уходят, если ваш продукт потерял для них ценность, а значит надо срочно понять причину и предпринять меры.
Индекс удовлетворенности клиентов показывает, насколько клиенты довольны продуктами и услугами компании. Имея эти данные под рукой, маркетологи могут улучшить качество обслуживания клиентов. Лучший способ узнать, доволен ли покупатель приобретенным товаром — спросить его напрямую. Вот почему так важно уметь правильно собирать отзывы клиентов.
Данные — самый ценный маркетинговый ресурс, но не все маркетологи понимают, как выжать из него максимум. Data-driven маркетинг позволит компаниям оптимизировать эффективность маркетинговых каналов, разработать персонализированные маркетинговые стратегии и улучшить качество обслуживания клиентов, что, в конечном счете, не может не привести к увеличению прибыли.
Парадигмы программирования. Data Driven vs Domain Driven
Информационные технологии развиваются семимильными шагами, появляются новые устройства, платформы, операционные системы, и вместе с этим растет спектр задач, который приходится решать разработчикам. Но, не все так плохо — на помощь программистам спешат новые средства разработки, ide’шки, новые языки программирования, методологии и т.д. Один только список парадигм программирования впечатляет, а с учетом современных мультипарадигменных ЯП (например, C#) резонно встает вопрос: «Как с этим всем быть? Что выбрать?».
Попробуем немного разобраться.
Откуда взялось так много парадигм?
На самом деле ответ уже прозвучал в этом посте — разные типы задач легче и быстрее решать, используя подходящие парадигмы. Соответственно, с развитием ИТ появлялись новые виды задач (или старые становились актуальными), а решать их используя старые подходы было неудобно, что влекло за собой переосмысление и появление новых методик.
Что выбрать?
Все зависит от того, что требуется сделать. Стоит отметить, что все средства разработки отличаются, одни поддерживают одно, другие — другое. К примеру, PHP со «стандартным» набором модулей не поддерживает аспектно-ориентированное программирование. Поэтому выбор методологии довольно тесно связан с платформой разработки. Ну, и не стоит забывать, что можно комбинировать разные подходы, что приводит нас к выбору стека парадигм.
Можно пойти дальше и углубиться в эту идею: придумать качественные характеристики для данных четырех мер, добавить строгие правила и немного математики, но это, пожалуй, тема для отдельного поста. Я думаю, большинство системных архитекторов определяют данные характеристики для конкретной задачи на основе своих знаний и опыта.
После того, как вы проанализируете свою задачу по этим 4 измерениям, то, скорее всего, увидите, что определенное измерение выражено сильнее остальных. А это в свою очередь позволит определиться с парадигмой программирования, так как обычно они нацелены на какое-то одно измерение.
А, что на практике?
В нашей компании мы занимаемся разработкой бизнес приложений (стартапы, веб-сервисы, сайты, прикладные программы и т.п.) поэтому далее поговорим о парадигмах программирования, которые встречаются как в нашей практике, так и у других команд работающих в этой области.
На основе моего опыта могу сказать, что в данной сфере превалируют два подхода: ориентация на данные (Data Driven) и ориентация на логику (Domain Driven). По сути, они являются конкурирующими методологиями, но на практике могут объединяться в симбиозы, которые часто являются известными анти-паттернами.
Одним из преимуществ Data Driven в сравнении с Domain Driven является простота использования и внедрения. Поэтому Data Driven начинают использовать там, где надо применить Domain Driven (причем часто это происходит бессознательно). Проблемы же возникают с тем, что Data Driven плохо совместим с концепциями объектно-ориентированного программирования (конечно, если вы вообще используете ООП). На небольших приложениях эти проблемы почти незаметны. На средних по размеру приложениях эти проблемы уже заметны и начинают приводить к анти-паттернам, ну, а на крупных проектах проблемы становятся серьезными и требуют соответствующих мер.
В свою очередь Domain Driven выигрышен на крупных проектах, а на небольших — приводит к усложнению решения и требует больше ресурсов для разработки, что часто бывает критичным с точки зрения бизнес требований (вывести проект на рынок «asap», за небольшой бюджет).
Решив, что контекстная область у нас как на ладони, мы начинаем проектировать базу данных. Создаем соответствующие таблицы, запускаем ORM-ку, генерируем сущностные классы (ну, или в случае «умной» orm-ки прописываем схему где-то отдельно, например, в хml, и уже по ней генерируем и базу и сущностные классы). В итоге получаем на каждую сущность отдельный, независимый класс. Радуемся жизни, работать с объектами легко и просто.
Проходит время, и нам требуется добавить дополнительную логику в программу — например, находить у ордера товар с самой высокой ценой. Здесь уже могут возникнуть проблемы, если ваша orm не поддерживает внешние связи (т.е. сущностные классы ничего не знаю о контексте данных), в этом случае, придется создавать сервис, в котором будет метод — по ордеру вернуть нужный продукт. Но, наша orm хорошая, умеет работать с внешними связями, и мы просто добавляем метод в класс ордера. Снова радуемся жизни, цель достигнута, в класс добавлен метод, у нас почти настоящее ООП.
Проходит время, и нам надо добавить такой же метод и для квоты, и для инвойса и для других аналогичных сущностей. Что делать? Мы можем просто прописать во все классы этот метод, но это будет, по сути, дублирование кода и аукнется при поддержке и тестировании. Мы не хотим усложнять и просто копируем метод во все классы. Потом появляются аналогичные методы, сущностные классы начинают распухать одинаковым кодом.
Проходит время, и появляется логика, которую не описать внешними связами в бд, и поэтому разместить ее в сущностных классах нет возможности. Мы начинаем создавать сервисы, которые выполняют эти функции. В итоге получаем, что бизнес логика разбросана по сущностным классам и сервисам, понять, где искать нужный метод становится все сложнее. Решаем провести рефакторинг и вынести, к примеру, повторяющейся код в сервисы — выделяем общий функционал в интерфейс (например, делаем интерфейс — IProductable, т.е. нечто, что содержит продукты), сервисы могут работать с этими интерфейсами, за счет чего немного выигрываем в абстракции. Но кардинально это не решает проблему, получаем больше методов в сервисах и решаем для единства картины перенести все методы из сущностных классов в сервисы. Теперь мы знаем, где искать методы, но наши сущностные классы лишись всякой логики, и мы получили так называемую «Анемичную модель» (Anemic Model).
На этом этапе мы полностью ушли от концепции ООП — объекты хранят только данные, вся логика находится в отдельных классах, ни инкапсуляции, ни наследования.
Стоит отметить, что это не так плохо, как может показаться — ничего не мешает внедрять юнит тестирование, да и вообще разработку через тестирование, внедрять паттерны управления зависимостями и т.п., в общем, с этим можно жить. Проблемы возникнут, когда приложение перерастет в большое, когда сущностей станет так много, что их нереально удержать в голове, а о взаимодействии и говорить не приходится. В этом случае поддержка и развитие такого приложения станет проблемой.
Как вы наверно догадались, этот сценарий описывает использование Data Driven подхода и его проблемы.
В случае с Domain Driven мы бы поступили следующим образом. Во-первых, ни о каком проектировании бд на первом этапе речи бы не шло. Нам потребовалось бы тщательно проанализировали контекстную область задачи, смоделировать ее и перенести на язык ООП.
Например, мы можем создать модель абстрактного документа, у которого был бы набор базовых свойств. От него наследовать документ, у которого есть продукты, от него наследовать «платежный» документ, с ценой и биллинг адресом и так далее. При таком подходе добавить метод, получающий самый дорогой продукт, не составляет труда — мы просто добавим его в соответствующий базовый класс.
В итоге, контекстная область задачи будет описана используя ООП на полную катушку.
Но появляются очевидные проблемы: как сохранять данные в бд? Собственно, для этого потребуется создавать функционал для меппирования данных из наших моделей на поля в бд. Такие мепперы могут быть довольно сложными, и при изменении моделей придется изменять и мепперы.
Более того, вы не застрахованы от ошибки при моделировании, что может привести к сложному рефакторингу.
