Подготовка к созданию CJM. Руководство по исследованию сервиса по работе с а/b-тестами
Представим ситуацию: ты попал в сервис по работе с а/b-тестами. Из материалов у тебя есть записи демо и обзорная часть, но т.к ранее ты не работал с этой тематикой, то и изучать её придётся с нуля. Подсказываем, с чего начать протаптывать тропинку ⬇️
Содержание
1. Тематика и потребность
2. Артефакты
3. Техническая структура сервиса
4. Кому продаем?
5. Конкуренты
Тематика и потребность
Выделим тематику нашего сервиса, чтобы понимать в какую сторону копать (a/b-test, split-test, analytics and a/b, server-side | client-side тесты).
Бизнес нанимает а/б-тесты для быстрой валидации своих идей и решений, чем больше тестов и вариантов пробуется, тем выше шанс найти что-то ценное (а именно — влияние на метрики).
💵 Используй принцип денежного сита ›
В процессе поиска информации можно столкнуться с поверхностным или даже посредственным представлением о возможностях рынка твоего сервиса. Убирай лишний булщит по типу «...а вот если поменять картинку или сделать цвет кнопочек, то будет зашибись...», бизнес - это в первую очередь о деньгах. Дело не в цвете кнопки, а в влиянии на ключевые метрики: меняются метрики -> деньги/пользователи либо приходят, либо уходят.
Артефакты
Изучи все доступные материалы от командой (если таковые имеются): miro, wiki, переписки в чатах поддержки (зачастую полезно промотать чатик в самое начало и тупо вычитывать всё, прям всё, после чего можно провести кластеризацию проблем, а далее вынести необходимое как артефакты). Иногда артефактами могут служить выступления на конференциях разных команд, связанных с решением болей.
Также артефакты можно набрать из:
а. Бэклог текущей разработки (действуй аккуратно и возьми кого-то из текущей команды для получения большего контекста);
b. Если аудитория активная и ее достаточно для проведения количественного теста, то сделай срез через опрос о текущем состоянии сервиса для конечного пользователя (заодно поймёшь кто является текущим пользователем);
В моем случае, именно такой подход привел к положительному результату. После проведения опроса и качественного исследования, выяснилось, что основным пользователем сервиса является разработчик, хотя изначально тематика выделяла аналитиков и продактов. Так пришло осознание, что из-за занимаемого положения на рынке (малая доля узнаваемости и проникновения в бизнесы) нашим сервисом пользовались только те, на ком изначально позиционировались предшественники.
с. Найди контактик на рынке. Таковыми могут быть профессиональные чатики и комьюнити, на которых ты хотел бы позиционироваться. Это позволит расширить зону поиска болей и решений для будущих пунктов;
d. Посмотри какой контент пользователи производят внутри системы. Например, в процессе своей работы я взял топ 50 тестов, использовал принцип их компановки, сделал выгрузку из базы и тупо глазками посмотрел как вообще все устроено. Попутно я выделил основные тематики, степень заполненности теста, примерные сроки и распределение.
Техническая структура сервиса
Как устроен ваш сервис? Работает ли он на основе SDK, когда вся работа и вычисления происходят на стороне клиента и апдейт информации зависит от частоты обращения к вашему сервису (в данном случае обновления отображаются не сразу)? Или же это rest-ручка, по которой клиенту необходимо ходить, что может замедлить скорость работы и создать очередь?
Также важно определить, с какой целью пользователи обращаются к вашему сервису: получить инфу, добавить инфу, обновить, рассчитать и т.п. Это влияет на количество запросов к вашему сервису (очередь), а также на нагрузку, которую ваш сервис может выдерживать.
Так как продукт может продаваться не только бизнесу, но проходит ещё и ревью технической стороной, может возникнуть проблема при сравнении с конкурентами (наш кейс про rest-ручку и конкурентов).
Кому продаём?
Выделяем уровень бизнеса (кому продаем и на какой рынок ориентируемся), т.к всегда важно понимать, на какой стадии находится покупатель (кто нанимает наш сервис) и кто будет пользоваться нашим сервисом.
Возможна ситуация, что легче окажется продавать старатпам (oh, no!), и всю цепочку работ с тестами проводит один единственный продакт. В таком случае уровень погружения в статистику и оценку влияния тестов на продукт будет хуже, чем если бы этим занимался непосредственно аналитик.
☑️ Уровни пользования сервисом >
Нанимающий бизнес - тот, кто приобретает твой продукт или сервис ради достижения своих глобальных целей (например, улучшения ключевых метрик)
Непосредственный пользователь - тот, кто будет непосредственно работать с твоей системой и чей опыт ты будешь стремиться улучшить, дополняя или расширяя текущее решение.
Косвенные пользователи - не являются целевыми, но также взаимодействуют с твоим сервисом. Например, основную деятельность может вести аналитик, в то время как продакт или владелец бизнеса активно смотрит на текущие значения метрик по тестам, т.е заходит в систему для осмотра состояния активностей по теме тестов.
Конкуренты
Бизнес может решать свою боль по-разному: крутить тесты не через спец. систему, а просто наблюдать эффект от крупных релизов (анализировать показатели и определять их приемлемость) или использовать более точечные решения (google optimize, a/b tests и пр.прямые конкуренты).
Важно выделять специфику рынка, на который ориентируешься. Например, у вас есть SDK и в основном вы работаете с backend, получается, что вы представляете server-side решение, и все изменения транслируются с backend'a, а есть еще и client-side и hybrid-test.
📁 Быстрый гайд по определению конкурента ›
Прямой - работают точно также, как и вы, возможно даже лучше и решают задачи эффективнее (google optimize, kameleoon)
Не прямой - является заменителем, решает часть потребностей, а может быть просто частью какой-либо системы побольше (комбинация умных фича-флагов и последующих расчётов по влиянию на метрики)
Косвенный (потенциальный) - у него нет цели решить потребность явным образом, но может использоваться в одном из шагов бизнеса (Amplitude или Яндекс Метрика, но и они идут не в прямую зону)
🧙🏻♂️
Это лишь начало нашего пути, нам предстоит построить CJM, наложить текущие задачи команды-продукта-бизнеса (все эти уровни важны для консистентности) и в конце пойти рассказать команде. Но об этом в следующий раз.
«Возникло странное свечение и силует, что молвил сей рассказ, вдруг испарился. Он исчез. Оставив лёгкую тоску и незаконченную мысль.»