• Сэмплирование и точность вычислений

      Ряд моих коллег сталкиваются с проблемой, что для расчета какой-то метрики, например, коэффициента конверсии, приходится кверить всю базу данных. Или нужно провести детальное исследование по каждому клиенту, где клиентов миллионы. Такого рода квери могут работать довольно долго, даже в специально сделанных для этого хранилищах. Не очень-то прикольно ждать по 5-15-40 минут, пока считается простая метрика, чтобы выяснить, что тебе нужно посчитать что-то другое или добавить что-то еще.


      Одним из решений этой проблемы является сэмплирование: мы не пытаемся вычислить нашу метрику на всем массиве данных, а берем подмножество, которое репрезентативно представляет нам нужные метрики. Это сэмпл может быть в 1000 раз меньше нашего массива данных, но при этом достаточно хорошо показывать нужные нам цифры.


      В этой статье я решил продемонстрировать, как размеры выборки сэмплирования влияют на ошибку конечной метрики.

      Читать дальше →
      • +13
      • 7.4k
      • 4
    • Сравнение BI систем (Tableau, Power BI, Oracle, Qlik)

        Привет, Хабр!

        В прошлом году я проводил небольшой конкурс на выбор BI для нашего проекта. Я руковожу направлением BI и аналитики Питерской клинике «Скандинавия». Никакого BI до этого в нашей клинике не было и одна из моих задач была в его создании. Я попросил представителей 4-х известных вендоров (Tableau, Power BI, Qlik, Oracle) провести для меня презентацию. Ниже я собрал в кучу то, что они они мне рассказали про свои системы и краткое субъективное впечатление от каждой из них. Почему субьективное? Потому что я не поставил все системе себе и не проработал с ними пару лет (хотя с Tableau я до этого работал), чтобы составить более полное представление, а скорее опирался на то, как представили мне все менеджеры. Ну а менеджеры бывают разные, презентации бывают разные. Так что смотрите, что вышло:
        Читать дальше →
      • Конференция в Будапеште (29-31 октября) Data Crunch

          В этом году я побывал на конференции Data Crunch в Будапеште посвященной аналитике данных и Data Engeneering. На эту конференцию приглашают спикеров из Linkedin, Uber, Github и множества компаний "второго эшелона", где люди делятся своим опытом или же рассказывают об инструментах по работе с данными. Ну и что мне так же интересно — это пообщаться с участниками конференции по понять, насколько наша российская действительность отличается от Европы и США.


          Из того, чтобы я отметил это:


          1. Full Stack Data Sceince — 2 доклада были посвящены примерно той же теме, что я писал раньше. Сделайте DS/DA человеком, кто может решать задачи от начала и до конца. Не делите работу по "функциям", а делите DS по "топикам". Т.е. работа с данными это не разделение на части между теми, кто готовит, обрабатывает, анализирует, строит модели и визуализирует, а это разделение "топиков" между специалистами, кто может сделать все полностью.
          2. From zero to hero — ребята рассказывали по то, как строили свой отдел DS с нуля. В целом как обычно, обычные здравые идеи работают:
          Читать дальше →
        • Демократизация данных в убере

            Всем привет!


            Под хеллоувин я побывал на конференции в Будапеште (Data Crunch) и послушал там ряд интересных докладов. Один из них был от Uber, которые рассказывали о том, на каких подходах они организовали свою платформу управления данными. Этот доклад был не столько технический, сколько менеджерский и продуктовый.


            Uber обширно используется данные, которые собирает в результате взаимодействия с пассажирами и водителями. Они рассчитывают стоимость поездки, оценивают потоки людей, меняют алгоритмы цены, дают рекомендации водителям, как им больше заработать и все это основываясь на собранных данных. В такой компании вся работа с данными не может быть сконцентрирована в руках группы аналитиков и DS, т.к. иначе придется нанять их слишком много, да к тому же они не всегда погружены в бизнес контекст.

            Читать дальше →
          • Full stack Data analyst

              "Анализ данных" часто организован так: вот у нас разработчики хранилища, а вот у нас аналитики. В DWH (data warehouse, хранилище) умеют SQL, а аналитики у нас умеют работать c экселем. Если нам нужно что-то проанализировать, то идете к аналитикам, а они идут за данными к DWH за данными. Вроде бы логично. И многие воспринимают, что это нормальное разделение труда. В этой статье я хочу донести мысль, что это разделение труда ошибочное и грандиозно снижает эффективность и производительность труда всего процесса анализа данных.


              Типичный цикл работы по аналитической задаче выглядит так:


              1. Бизнес приходит с проблемой и просит получить ответ.
              2. Аналитики обсуждают с бизнесом, что надо сделать.
              3. Аналитики поняли, что от них хочет бизнес и понимают, что им примерно нужно в данных.
              4. Аналитики пишут запрос в DWH, чтобы получить данные.
              5. DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
              6. Аналитики понимают, что взяли не все или их неверно поняли, они пишут снова запрос в DWH, чтобы получить данные.
              7. DWH берет запрос, читает, спрашивает, уточняет, извлекают данные, отдают.
              Читать дальше →
            • Что было интереснго на DataVizDay в Минске

                В четверг 4 октября я побывал на конференции DataVizDay в Минске в качестве спикера. Поделюсь самыми интересными идеями и впечатлением от Миснка.


                Ключевые идеи:


                1. 80% ваших усилий будет до BI и визуализации, потому что данные бывают или плохие или очень плохие и в основном вы будете тратить время на подготовку и сбор данных.
                  2.Тем не менее визуализация создает ценность вашего дата продукта. Без визуализации получается просто куча цифр.
                2. К сожалению очень часто визуализация плохая, используют плохие подходы, типы графиков и гистограмм, перегружают представления деталями. В итоге часто мы видим Kill by powerpoint и обилие данные не добавляет прозрачности в аналитике.
                3. Эксель продолжает занимать значительную роль в процессах. И часто компании не готовы перейти на что-то продвинутое. Но даже на экселе можно построить много чего интересного, потому что хорошая аналитика скорее начинается с чистоты и подготовки данных, а не с красивых дашбордов.
                Читать дальше →
              • Как мы переделывали плохое прогнозирование на чуть более хорошее (продолжение)

                  В прошлой статье я рассказал как для целей прогнозирования выручки люди построили большой и сложный excel файл (можете почитать тут). Мы решили вмешаться в этот стыд и предложили переделать модель прогноза так, чтобы было меньше ошибок, проще эксплуатация, появилась гибкость в настройке.


                  Какие ключевые проблемы в описанной модели:


                  1. Данные, модель и представления смешаны в одну сущность. Из-за этого изменение хотя бы в одном элементы разрушает весь этот монолит.
                  2. Чрезмерный расчет на ручную обработку, что плодит ошибки и опечатки в огромных количествах.

                  Что мы предложили:


                  1. В начальной модели нигде не фигурировали исходные данные на которых она была построена. Мы предложили внести эти данные в формате 2-ой нормальной формы в сам файл Excel на 2 отдельных листа (продажи и кол-во клиентов). Благо, данные по продажам в нашей агрегации по месяцам — это всего лишь десятки тысяч строк, а не миллионы. Так же мы настроили получение этих данных при помощи Power Query напрямую из базы данных.
                  Читать дальше →
                • Как мы переделывали плохое прогнозирование на чуть более хорошее

                    Каждая компания это не звездные технологии и супер крутые программисты, а огромная гора bottleneck, неэффективностей и сумма плохих решений, которая как-то да едет и делает свою работу. Но вот вы решили сделать какие-то изменения и сразу начинаете сталкиваться с тем, что в огромном кол-ве бизнес процессов у вас проблемы. Ну и эти проблемы, конечно, нужно решать не идеальным способом, а оптимальным по трудозатратам.


                    Хочу поделится одним таким примером, связанных с моей темой анализа данных и управления данными. Во многих организациях существует финансовые службы, основная цель которых предоставлять финансовую информацию руководству о состоянии предприятия. Среди многих работ этих людей есть одна такая задача: составление прогноза выручки на следующий период (год, квартал у кого как). Этот прогноз выручки часто бывает первым этапов в согласовании планов на следующий период и составлении общего прогноза по прибылям и убыткам предприятия.


                    Все, кто занимается такого рода прогнозированием, понимают, что в этом вопросе важна не столько точность прогнозов, сколько правильные взаимосвязи между вашими предпосылками и результатами. Ведь что мы хотим от прогноза? Мы хотим узнать, что будет, если делать все как обычно (AS IS) и что будет, если мы что-то поменяем (сценарии). Для того, чтобы сделать эту работу финансовая служба должна придумать какую-то модель предприятия, которой она может легко управлять, легко объяснять бизнесу как она работает и легко предоставлять данные в различных разрезах, в которых бизнес захочет это дело посмотреть.


                    Это все отличные намерения, но тут мы сталкиваемся с суровой реальностью: методологические и технические навыки для выполнения этих задач в конкретных предприятиях откровенно слабы. Модели неудобные, быстро не изменяемые, не обновляемые, легко ничего не объясняется, файлы не удобные, а разрезы получить невозможно или очень долго. Давайте посмотрим конкретный пример, где всё плохо и как это можно исправить.

                    Читать дальше →
                  • Как и какие кластеры можно выделять в клиентской базе

                      Сегодня мы добавим в анализе еще один аспект — сегментацию и кластеризацию клиентской базы. Как я уже не раз писал, анализ клиентской базы остается не полным, если мы смотрим на наших клиентов, как на большую кучу одинаковых людей. Клиенты разделяются на типы и по-разному потребяют продукт. Кто-то покупает часто, но не много, кто-то быстро уходит, кто-то покупает много и часто. Для увеличения эффективности стоит выяснить, какие есть группы клиентов и затем разобраться, как ваши действия позволят вам привлечь нужных вам клиентов. Используют два основных способа разобраться в группам ваших клиентов: эвристики и кластеризация


                      Метод 1: Эвристики и экспертные оценки


                      В рамках этого подхода вы на основе опыта, логики использования вашего продукта и клиентских историй, придумываете различные портреты потребителей и затем оцениваете, сколько у вас клиентов попадают под эти определения. Или же можете использовать более численные подходы, основанные на анализе показателей клиентов. Несколько популярных численным эвристик подходов это:


                      ABC-XYZ


                      Основная идея разделить клиентов по общему вкладу в вашу выручку и по динамике роста показателей. ABC отвечает за вклад в выручку, XYZ отвечает за стабильность выручки. Это формирует 9 сегментов


                      Читать дальше →
                    • Фиксированные и переменные издержки в разработке софта

                        Разработка программного обеспечения и эксплуатация уже реализованного софта (например, приложения) находится в особом положении в контексте анализа расходов. Особенность в том, что типичный цикл производства товара и его продажи не существует в ИТ отрасли. Вместо этого мы имеем фактически бесплатно размножаемые копии продукта, но высокие издержки на само создание этого продукта и его поддержание. По этой причине экономика ИТ компании сильно отличается от экономики “свечного завода” или магазина.


                        Давайте детальнее рассмотрим ситуацию с издержками в ИТ компании. К сожалению не получится обобщить все ИТ компании в одну схему. Я попробую выделить несколько распространенных схем работы и рассмотреть их. Возможно кто-то из читателей добавит еще какие-то схемы, интересные для рассмотрения.


                        Я хочу выделить следующие типы ИТ компаний, хотя этот список, конечно, не полный:


                        1. Аутсорсинговая разработка — команда пишет софт под заказ и под требования заказчика. В дальнейшем софт чаще сопровождается самим заказчиком. Отношения фокусируются только на разработке и по сути продажи часов работников (как в форме прямой продажи часов, так и fix price, когда риски изменения сроков проекта ложатся на разработчика)
                        2. Вендор B2B софта — команда пишет софт для дистрибуции B2B, осуществляет внедрение, поддержку и разработку нового функционала.
                        3. B2C продукты — сюда я отнесу все компании, занимающиеся созданием B2C приложений и продуктов, работающих с массовым клиентом.
                        4. Провайдеры инфраструктуры — хостеры, дата центры, серверные мощности, сервисы обработки транзакций и т.п.

                        Какие расходы имеет первый тип компании? Давайте разделим на разные кучки расходы по основным типам, которые не зависят от предприятия:

                        Читать дальше →
                        • +19
                        • 4.9k
                        • 1
                      • Когда расходы — это не расходы, как верно понимать финансовые данные по компании

                          В финансах существует большая разница между “расходами” в финансовом смысле и “расходами” в бытовом. Финансисты разделяют понятия расходов и расходования денежных средств. Расходами называются события, которые:


                          1. Являются тратой денег или у вас появляются обязательства по их уплате.
                          2. Относятся к текущему финансовому периоду.
                          3. Относятся к использованию ресурсов компанией.

                          При этом расходом денежных средств является фактическая операция списания средств со счета или кассы. И такое списание не всегда может означать расходы(в обозначенном смысле) для компании. Например:


                          1. Вы дали в долг. Списание есть, это не расход (у вас не появилось обязательств, наоборот, должны вам), а превращение денег в актив — долг, который должны вернуть.
                          2. Вы купили сервер. Т.к. Сервер штука долгосрочного функционирования, то расходы на него нельзя отнести только к текущему финансовому периоду, поэтому сумма расходов на сервер не является полностью расходами этого периода. Расходы на сервер считаются в составе т.н. амортизации — оценки износа оборудования, степени, с который вы “употребили” сервер в текущем периоде.
                          Читать дальше →
                        • MPRU, выручка и как это связано с выручкой и динамикой клиентской базы

                            В этой статье давайте посмотрим на MRPU, разберемся какие есть особенности его подсчета и что он нам может дать.


                            MRPU — monthly revenue per unit, ежемесячная выручка на единицу. Это широкое понятие включающее в себя и средний чек, и среднюю выручку на пользователя/клиента/продажу. Гибкость слова unit позволяет дать нужное вам определение.


                            Для чего нам это нужно? Вся цель анализа продукта состоит в том, чтобы изолировать причины и выявить факторы, которое влияют на финансовые показатели. Динамика клиентской базы (см. статью тут) определяют в основном факторы связанные с вашей работой по привлечению и удержанию. MRPU же затрагивает ваши цены, набор услуг и полноту предоставляемых сервисов. Хотя ваш успех по части привлечения зависит от цен и набора услуг, MRPU в нашем уравнении выручки отвечает непосредственно за сами деньги.


                            Мы можем варьировать понятие MRPU в зависимости от вашего контекста. Идеология этой метрики:


                            • Период — Monthly
                            • Показатель — Revenue
                            • За — Per
                            • Единицу — Unit
                            Читать дальше →
                          • Аналитика воронки продаж

                              Рассмотрев когорты в целом, теперь мы можем перейти к их изучению в части привлечения новых клиентов. Привлечение новых клиентов одна из ключевых дисциплин в управлении и развитии продукта, т.к. Именно от потока входящих клиентов зависит вся ваша выручка и способность контролировать рынок и побеждать конкурентов.



                              Поток новых клиентов не появляется из воздуха, его количество зависит от ваших маркетинговых усилий. Привлечение клиентов это корректный процессинг потенциальных клиентов со стадии контактов до стадии продаж. Входящие в когорты новые клиенты на самом деле финальный этап воронки продаж. Костяк этапов в воронке продаж выглядит так:



                              В чем состоит главная цель ваших маркетинговых усилий? Вы должны на правильном рынке, обратится к правильным людям, чтобы они с наименьшими усилиями купили наибольшее число ваших товаров и услуг и стали ваши постоянными клиентами. Воронка продаж показывает, насколько успешно вы проходите по этим этапам взаимоотношений и на каком этапе теряете больше всего потенциальных клиентов.

                              Читать дальше →
                              • +12
                              • 15.4k
                              • 6
                            • Top-Down approach. Экономика продукта. Gross Profit

                                Более 5 лет я занимаюсь анализом продуктов, маркетинга, управленческих решений в ИТ компаниях или компаниях с большой опорой на ИТ. Я решил систематизировать свои знания и написать серию статей об организации и проведении анализа продукта. Я затрону темы оценки экономики, эффективности фич, обустройстве взаимоотношений с маркетингом, базами данных, оценке клиентского поведения и всего такого.


                                Ключевая задача — пройтись по всем инструментам управления и оценки продукта, обсудить используемые управленческие, маркетинговые и аналитические инструменты. Погрузится в применении Big Data и Machine Learning в развитии продукта, определить возможности этих решений и их применимость. Эта статья открывает серию статей по анализу продуктов.


                                Экономика продукта


                                Чтобы не заблудится в хитростях оценки продуктов и эффектов в них, лучше всего начать с общей картины. Для этого и используется подход Top-down, когда мы спускаемся от самых общих экономических характеристик до атомарных событий, происходящих в продукте. Такой подход позволяет всегда понимать, как каждая характеристики продукта связана между собой и всегда иметь полную картину продукта.


                                Определение контура для анализа является ключевой задачей. Экономика продукта исключает множество финансовых явлений, характерных для экономики предприятия. Мы начнем с ядра формирования прибыли постепенно нарастим на него “мясо”.


                                Финансы продукта начинаются с простой формулы:


                                Читать дальше →
                                • +12
                                • 3.5k
                                • 3
                              • Собираем когортный анализ/анализ потоков на примере Excel

                                  В прошлой статье я описал использование когортного анализа для выяснения причин динамики клиентской базы. Сегодня пришло время поговорить про трюки подготовки данных для когортного анализа.


                                  Легко рисовать картинки, но для того, чтобы они считались и отображались правильно “под капотом” нужно проделать немало работы. В этой статье мы поговорим о том, как реализовать когортный анализ. Я расскажу про реализацию при помощи Excel, а в другой статье при помощи R.


                                  Хотим мы этого или нет, но по факту Excel это инструмент анализа данных. Более “высокомерные” аналитики будут считать, что это слабый и не удобный инструмент. С другой стороны по факту сотни тысяч людей делают анализ данных в Excel и в этом отношении он легко побьет R / python. Конечно, когда мы говорим о advances analytics и машинном обучении, мы будем работать на R / python. И я был бы за то, чтобы большая часть аналитики делалась именно этими инструментами. Но стоит признать факты, в Excel обрабатывают и представляют данные подавляющее большинство компаний и именно этим инструментом пользуются обычные аналитики, менеджеры и product owners. Вдобавок Excel трудно победить в части простоты и наглядности процесса, т.к. вы мастерите свои расчеты и модельки буквально руками.


                                  И так, как же нам сделать когортный анализ в Excel? Для того, чтобы решать подобные задачи нужно определить 2 вещи:


                                  1. Какие данные у нас в начале процесса


                                  2. Как должны выглядеть наши данные в конце процесса.

                                  Читать дальше →
                                • Погружаемся в динамику клиентской базы: когортный анализ и анализ потоков

                                  Продолжаю цикл статей по анализу продукта (начало)


                                  В прошлой статье я погрузился в анализ выручки и разбил ее на 2 компоненты — MRPU и кол-во клиентов. Сегодня рассмотрим дальнейшие шаги в анализе и разложим на составляющие кол-во клиентов и их динамику.


                                  Теперь общая схема анализа выглядит так:



                                  Когортный анализ позволяет объяснить тенденции, протекающие в клиентской базе и пробрасывает прямой мост в воронку продаж и действия по удержанию и возвращению клиентов.

                                  Читать дальше →