Доказательство в цифрах: использование больших данных для достижения результатов

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

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

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

Используйте крупномасштабные данные

Применение науки о данных в управлении продуктами и продуктовой аналитике не является новой концепцией. Что нового, так это ошеломляющий объем данных, к которым предприятия имеют доступ, будь то через свои платформы, программное обеспечение для сбора данных или сами продукты. И все же в 2020 году Seagate Technology сообщила, что 68% данных, собранных компаниями, не используются. В официальном документе IBM 2014 года эти потери данных сравниваются с «фабрикой, где большое количество сырья лежит неиспользованным и разбросано в разных точках сборочной линии».

Менеджеры по продуктам с навыками работы с данными могут использовать эти данные, чтобы получить представление о ключевых показателях, таких как активация, охват, удержание, вовлеченность и монетизация. Эти показатели могут быть ориентированы на ряд типов продуктов, таких как электронная коммерция, контент, API, продукты SaaS и мобильные приложения.

Короче говоря, наука о данных — это не столько то, какие данные вы собираете, сколько то, как и когда вы их используете, особенно когда вы работаете с новыми числами и числами более высокого порядка.

Изучите данные, чтобы найти первопричины

Несколько лет назад я работал в компании-поставщике технологий для путешествий с более чем 50 000 активных клиентов в 180 странах, 3700 сотрудников и годовым доходом в 2,5 миллиарда долларов. В корпорации такого размера вы управляете большими командами и огромными объемами информации.

Когда я начал работать там, я столкнулся со следующей проблемой: несмотря на то, что у меня были актуальные дорожные карты и полные невыполненные работы, показатель NPS упал, а отток клиентов увеличился за два года. Затраты, связанные с поддержкой клиентов, значительно выросли, а отделы поддержки постоянно тушили пожары; за эти два года количество обращений в службу поддержки увеличилось в четыре раза.

За первые три месяца я изучил, как работает бизнес, от переговоров о поставках до разрешения жалоб. Я провел интервью с вице-президентом по продуктам и ее командой, связался с вице-президентами из отделов продаж и технологий и много общался с отделом поддержки клиентов. Эти усилия привели к полезным выводам и позволили моей команде разработать несколько гипотез, но не предоставили достоверных данных, подтверждающих их, или оснований для их отклонения. Возможные объяснения неудовлетворенности клиентов включали отсутствие функций, таких как возможность редактировать заказы после их размещения; потребность в дополнительных продуктах; недостаточная техническая помощь и/или информация о продукте. Но даже если бы мы могли определиться с единым курсом действий, для того, чтобы убедить различные отделы согласиться с ним, потребовалось бы что-то более твердое, чем возможность.

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

Заявки на поддержку за предыдущие шесть месяцев пришли ко мне в виде четырех столбцов, по 130 000 строк в каждом. Каждая строка представляла запрос клиента в службу поддержки, а каждый столбец был помечен проблемной областью клиента по мере того, как он продвигался в процессе обслуживания. Каждый столбец имел от 11 до 471 различных меток.

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

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

После применения выборки PPS мы выделили 2% основных причин, что составило примерно 25% от общего числа случаев. Это позволило нам применить алгоритм кумулятивной вероятности, который показал, что более 50% случаев связаны с 10% первопричин.

Этот вывод подтвердил одну из наших гипотез: клиенты обращались в колл-центр, потому что у них не было возможности изменить данные заказа после его размещения. Устранив одну проблему, клиент может сэкономить 7 миллионов долларов на расходах на поддержку и вернуть 200 миллионов долларов дохода, связанного с оттоком клиентов.

Выполнение анализа в режиме реального времени

Знание машинного обучения оказалось особенно полезным при решении задачи анализа данных в другой туристической компании аналогичного размера. Компания служила связующим звеном между отелями и туристическими агентствами по всему миру через веб-сайт и API. Из-за распространения метапоисковиков, таких как Trivago, Kayak и Skyscanner, трафик API вырос на три порядка. До распространения метапоиска соотношение look-to-book (общее количество поисковых запросов API к общему количеству заказов API) составляло 30:1; после начала метапоиска соотношение некоторых клиентов достигло 30 000:1. В часы пик компании приходилось обрабатывать до 15 000 запросов к API в секунду без ущерба для скорости обработки. Затраты на сервер, связанные с API, соответственно выросли. Но увеличение трафика с этих сервисов не привело к росту продаж; доходы оставались постоянными, что привело к огромным финансовым потерям для компании.

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

Мы проанализировали около 300 миллионов запросов к API по ряду параметров: время запроса, пункт назначения, даты заезда/выезда, список отелей, количество гостей и тип номера. На основе данных мы определили, что определенные закономерности связаны со скачками метапоискового трафика: время суток, количество запросов в единицу времени, поиск по алфавиту в пунктах назначения, упорядоченные списки отелей, конкретное окно поиска (даты заезда/выезда) и т.д. гостевая конфигурация.

Мы применили контролируемый подход к машинному обучению и создали алгоритм, похожий на логистическую регрессию: он рассчитывал вероятность для каждого запроса на основе тегов, отправленных клиентом, включая отметку дельта-времени, отметку времени, пункт назначения, отель(ы), даты заезда/отъезда и количество гостей, а также теги предыдущих запросов. В зависимости от заданных параметров алгоритм будет определять вероятность того, что запрос к серверу API был сгенерирован человеком или метапоисковиком. Алгоритм будет работать в режиме реального времени, когда клиент получит доступ к API. Если он определил достаточно высокую вероятность того, что запрос был инициирован человеком, запрос будет отправлен на высокоскоростной сервер. Если бы это был метапоиск, запрос был бы перенаправлен на сервер кэширования, который был бы менее затратным в эксплуатации. Использование обучения с учителем позволило нам обучить модель, что привело к большей точности в ходе разработки.

Эта модель обеспечивала гибкость, поскольку вероятность можно было адаптировать для каждого клиента на основе более конкретных бизнес-правил, чем те, которые мы использовали ранее (например, ожидаемое количество бронирований в день или уровень клиента). Для конкретного клиента запросы могут быть направлены в любую точку с вероятностью выше 50%, в то время как для более ценных клиентов мы можем потребовать большей определенности, направляя их, когда они преодолеют порог в 70% вероятности.

После внедрения алгоритма классификации компания перенаправила до 70% запросов в течение заданного периода времени на более дешевый стек и сэкономила примерно от 5 до 7 миллионов долларов в год на затратах на инфраструктуру. При этом компания удовлетворила клиентскую базу, не отклонив трафик. Это сохранило коэффициент бронирования, сохранив при этом доход.

Используйте правильные инструменты для работы

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

Программирование. Язык структурированных запросов, или SQL, является стандартным языком программирования для управления базами данных. Python — это стандартный язык для статистического анализа. Несмотря на то, что у них есть перекрывающиеся функции, в самом общем смысле SQL используется для извлечения и форматирования данных, тогда как Python используется для запуска анализа, чтобы узнать, что данные могут вам сказать. Excel, хотя и не такой мощный, как SQL и Python, может помочь вам достичь многих из тех же целей; вам, вероятно, будет предложено использовать его часто.

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

Машинное обучение. С развитием ИИ достижения в области машинного обучения открыли новые возможности для прогнозной аналитики. Использование прогнозной аналитики в бизнесе выросло с 23% в 2018 году до 59% в 2020 году, и ожидается, что совокупный ежегодный рост рынка составит 24,5% до 2026 года. Пришло время менеджерам по продуктам узнать, что возможно с этой технологией.

Визуализация данных. Недостаточно понять ваши анализы; вам нужны такие инструменты, как Tableau, Microsoft Power BI и Qlik Sense, чтобы передавать результаты в формате, понятном нетехническим специалистам.

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

Используйте силу, чтобы стимулировать возврат

Исследование NewVantage Partners 2022 Data and AI Leadership Executive Survey показывает, что более 90% участвующих организаций инвестируют в инициативы в области ИИ и данных. Доходы, получаемые от больших данных и бизнес-аналитики, выросли более чем вдвое с 2015 года. Анализ данных, который когда-то был особым навыком, теперь необходим для предоставления правильных ответов компаниям во всем мире.

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