Сегментация пользователей Яндекс.Навигатора

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

 

Для чего нужна сегментация

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

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

Особенности Яндекс.Навигатора

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

Частота использования приложения — важный показатель для сегментирования аудитории любого приложения. В случае Яндекс.Навигатора по нему к тому же можно сделать много предположений о роли автомобиля в жизни человека: является ли для него вождение в первую очередь частью работы, способом добраться до работы или способом съездить по делам, не связанным с работой.

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


Сегмент A. Профессиональные водители

Таксисты, курьеры, дальнобойщики и личные водители.

Критерий:

За неделю было хотя бы 3 дня, когда он совершил хотя бы 6 поездок или провёл в приложении хотя бы 5 часов*.

Особенности

  • Поскольку для них навигатор — это профессиональный инструмент, у них есть стимул пробовать приложения конкурентов.

  • Совершают много поездок; большинство пользователей из сегмента практически всегда ездит в места, не сохранённые в приложении и больше всех пользуются поиском по адресам.

  • Большинство никогда не использует веб-интерфейс Яндекс.Карт.

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

  • Специфичные конкуренты в борьбе за этих пользователей: собственные приложения такси и служб доставки, специализированные устройства-навигаторы.

Сегмент B. Продвинутые

Много пользуются Навигатором, но не являются профессиональными водителями.

Критерий:

Не входит в группу A и совершил больше 12 поездок за неделю*.

Особенности

  • Хорошо знают возможности приложения  и раньше других начинают использовать новые функции.

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

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

  • Много пользуются сохранением в избранное и поиском (не только по адресам в отличие от A).


Сегмент C. Комьютеры

Используют Навигатор в основном, чтобы ездить на работу и с работы. 


Критерий:
Не входит в A и B и хотя бы 3 дня в неделю есть поездки на работу или с работы*.

Особенности:

  • Значительная часть поездок по примерно фиксированному маршруту и примерно в одно и то же время.

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

  • Им важно построение дороги в объезд пробок (скорее всего по одному из маршрутов, которые они и так уже знают) и предупреждения обо авариях, ремонте и камерах.

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


Сегмент D. Непостоянные

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

Критерий:
Есть поездки за неделю, но не входит в A, В и С.


Особенности:

  • Меньше всего интересуются возможностями приложения, долго привыкают к изменениям.

  • Хотят, чтобы всё было максимально просто и «просто работало» (just works).

  • Могут не иметь собственную машину, а периодически пользоваться каршерингами или автомобилями других членов семьи.

  • Возможно, что пользуются автомобилем чаще, но не использует Яндекс.Навигатор при поездках по известному маршруту.

  • Главные конкуренты в борьбе за этих пользователей — карты, установленные в смартфоне по умолчанию (Google Maps и Apple Maps) и встроенные автомобильные навигаторы.

Сегмент O. Отлынивающие

Не знаю, что с ними не так, но за последнюю неделю, они ни разу не воспользовались Яндекс.Навигатором.
Возможно, они временно не водят, перестали ездить по навигатору или стали пользоваться приложением конкурентов.

Критерий:

Нет поездок за неделю.


Особенности:

  • Если пользователь находится в этом состоянии больше месяца, возможно, мы его потеряли. Полезно узнать, почему это произошло. Если это был залогиненный пользователь Яндекса, который до этого много пользовался Навигатором, можно отправить ему имейл, чтобы узнать, что случилось и что можно улучшить в продукте, чтобы он захотел вернуться.

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


* Примечание о критериях

Я старался использовать более простую модель для критериев сегментации; числовые значения «стартовые» их можно и нужно улучшать. 

A) 3 дня — это почти половина недели, при этом даже если водитель работает на пару сутки через сутки, он попадёт в этот сегмент.
6 поездок в день — это больше, чем делает непрофессиональный водитель, даже если он каждый день завозит перед работой детей в школу, а на обратном пути заезжает в пару мест.

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

B) 12 поездок — это больше чем, если человек ездит каждый будний день на работу и периодически заезжает на заправку.

C) 3 дня, чтобы учесть людей, которые в какие-то дни не ездят на работу на машине из-за пробок, погоды или не используют каждый раз навигатор. В самом простом варианте для выявления поездки с работы и на работу нужно использовать данные о сохранённых местах, а в более сложном нужно будет для каждого пользователя, не вошедшего в A, B и O,  проверять, были ли у него хотя бы 3 дня с поездками между двумя одинаковыми точками.

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

Вместо оценки размера сегментов можно еженедельно высчитывать их точные значения, используя логи Яндекс.Навигатора.

 

Продуктовые требования и MVP

Опишите процесс формулирования продуктовых требований и выделения из них MVP. Выберите проект из своего опыта и используйте его как пример.

 

Современный подход к созданию ИТ-продуктов рассматривает создание продукта как проведение эксперимента и подразумевает, что нужно как можно быстрее дать пользователям самую базовую версию продукта, решающую их задачи — minimum viable product (MVP) — и использовать обратную связь и статистику использования продукта, чтобы проверять гипотезы, дальше развивать продукт, менять концепцию или совсем отказаться от продукта. Такой подход позволяет быстрее выходить на рынок, лучше адаптироваться к потребностям пользователей и изменениям на рынке и уменьшать стоимость эксперимента (что, в свою очередь, позволяет проводить больше экспериментов, делать более смелые эксперименты и легче отказываться от неудачных, не попадая в ловушку sunk cost fallacy).

В декабре 2013 года, компания B2B-Center, решила сделать мобильное приложение. Им занимался Антон Иванов как руководитель проекта и я как аналитик. 


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

Первый этап. Определение направления

Для формулирования продуктовых требований нужно сначала определиться с ответами на три основные вопроса:

  1. Зачем делается продукт?

  2. Для кого?

  3. Какую задачу он решает?

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

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


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


Этот этап позволит зафиксировать направление, в котором все задействованные люди будут думать о приложении, и не позволит «прыгать» между несколькими взаимоисключающими направлениями.



Второй этап. Создание продуктовых требований

На этом этапу нужно создать пул функции, которые может иметь приложение и записать их в виде user stories.


Для этого мы использовали сессии design thinking, на которые позвали коллегу из QA и арт-директора.


У нашего design thinking были следующие этапы:

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


  2. Записать, с какими проблема сталкиваются пользователи. На этом этапе важно не начать придумывать решения для этих проблем.
Мы обнаружили такие проблемы, как «боится пропустить оповещение и проиграть торги», «не знает, когда закончатся торги».


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


  4. Отобрать лучшие идеи
Для каждой проблемы мы отобрали самые простые и удобные решения и записали их, как user stories в виде
«A хочет сделать B, чтобы C», например, 
«Менеджер по продажам хочет посмотреть список своих текущих торгов, чтобы будь в курсе своих торгов».

По итогам design thinking, мы придумали несколько функций, которых не было на сайте, но которые были актуальны на мобильных устройствах (например, «Поделиться ссылкой на торги через почту или SMS») и записали требования, которые подразумевались, но не были зафиксированы до этого (например, «Авторизоваться в приложении»).

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

Третий этап. Выделение MVP

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

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


Сначала мы убрали все сложно реализуемые функции (например, участие в торгах, поскольку оно требует электронную подпись) и функционал, нереализованный ещё на сайте (например, планировщик задач). От других функций было сложно отказаться. Например, нам казалось, что площадка не мыслима без каталога торгов и поиска. Мы много сомневались и обдумывали разные варианты, пока не убрали разом почти всё кроме возможности просматривать торги, в которых участвует компания. И тогда всё встало на свои места и стало понятно, что это единственный возможный вариант MVP.

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

Возвращаемость в Пробках

Предположим, что вы руководите Пробками в Яндекс.Картах. Вы увидели, что показатель возвращаемости пользователей к этой функциональности на веб-сервисе maps.yandex.ru снизился с 50% до 28%. Приведите список гипотез, объясняющих, с чем может быть связано такое изменение, и механику, по которой вы будете их проверять.

Если при выполнении задания вам нужно опереться на какую-то дополнительную статистику сервиса – укажите, какие именно показатели вы бы смотрели и почему, а также какие выводы вы бы получили при том или ином значении.

 

Для того, чтобы было проще придумывать гипотезы и не оставлять слепых пятен, разобьём все возможные причины в зависимости от их источника:

  1. Данные — ошибки в данных или их интерпретации.

  2. Компания — действия нашей компании.

  3. Другие агенты — действия конкурентов, СМИ и других компаний и людей.

  4. Среда — события и изменения в среде: обществе, погоде, экономической ситуации, законодательстве и прочем.

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

Данные

  1. Отчётный период ещё не закончился, ещё не все пользователи успели зайти на сайт. Посмотреть, какой период имеется в виду и закончился ли он.

  2. Счётчики не работали какое-то время или функционал был недоступен. Проверить, были ли жалобы на недоступность сервиса; нет ли аномальных падений в статистике просмотра пробок.

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

  4. Был заблокирован доступ с ряда IP-адресов, так как пользователи с этих адресов вели себя как боты. Узнать у коллег, не было ли подобных блокировок и были ли они достаточно массовые, что объяснит это падение.

Компания

  1. На сайте поменялся интерфейс или изменилось поведение сайта:

    • Например, кнопка «показать пробки» переместилась и стала менее заметной.

    • Или раньше при открытии Яндекс.Карт пробки отображались или не отображались как в прошлую сессию, а теперь их нужно каждый раз включать.

    Узнать, были ли изменения и, если да, совпадает ли падение в использовании пробок со временем, когда изменения были введены.

  2. Канибализация другим продуктом Яндекса

    • На главной Яндекса или на табло в Яндекс.Браузере теперь размещается больше информации о пробках и люди меньше заходят за ней на сайт Яндекс.Карт.

    • У мобильных приложений Яндекс.Карт появились виджеты или сильно упростился доступ к информации о пробкам по пути домой или на работу.

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


Другие агенты

  1. Часть пользователей попадает на maps.yandex.ru введя в поиске «пробки»; в интернете появился сайт, который обходит Яндекс.Карты в поиске Яндекса или Гугла (и возможно выдаёт себя за сайт Яндекса); вместо сайта Яндекс.Карт люди стали смотреть пробки через этот сайт.

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

Среда

  1. Возможно это была праздничная неделя, следовательно:

  • Люди меньше ездили на автомобилях (и соответственно, меньше проверяли пробки)

  • Те, кто ездили, меньше проверяли пробки, так как рассчитывали, что их не будет

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


Проверить, не было ли праздников, было ли меньше пробок и как изменилось использование Яндекс.Навигатора. Подождать неделю несколько недель и посмотреть, не вернулась ли ситуация в норму.

Примечания

  • Заранее выписать все гипотезы и проверять только их — не лучшая стратегия. Сначала лучше погрузиться в контекст.

    • Насколько аномальная величина 50%?

    • Давно ли она на таком уровне и насколько резко стала такой?

    • Насколько аномальное значение 28%?

    • Был ли показатель когда-либо на таком уровне и когда?

    • Были ли подобные падения раньше?

    • Какое самое сильное падение было до этого и чем оно было обусловлено?

    • Наблюдались ли падения ранее (возможно, менее сильные) в этом же сезоне (например, если это неделя после Нового года) или при похожих обстоятельствах (например, при аномальной метели и пробок)?

    • В каких регионах изменение было наиболее сильное и какие проценты от общих изменений пришлись на них?

    • С каких источников чаще всего попадают на сайт и как изменилось возвращаемость для каждой из них?

    • Как изменялась частота просмотра пробок в течение рассматриваемого периода; был ли какой-то заметный провал или момент после которого использование стало снижаться?

    • Что пишут пользователи в службу поддержки и в социальных сетях?

    • Какие в последнее время были изменения в продуктах Яндекса, связанных с Яндекс.Картами?

    • Какие были новости у конкурентов?

    • Как изменялась ситуация стране?

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

  • Если ни одна гипотеза не подтвердится, можно пойти на крайнюю меру и попытаться найти решение через краудсорсинг, создав вакансию с соответствующим вопросом в тестовом задании.