1. Имплементация
1.1. Построение гипотез.
1.2. Создание прототипа/мокапа на базе гипотез
1.3. Локальное тестирование и сбор фидбэка в свободной форме
1.4. Тьюнинг гипотез
1.5. Написание ТЗ на MVP (минимальный жизнеспособный продукт)
1.6. Определение KPI для MVP (возможно согласование с коммерческим отделом)
1.7. Разработка
1.7.1. Могу рассказать подробнее, но последнее время я работал в scrum/agile режиме из-за фриланса и специализации на стартапах. Уверен, что в Яндексе все равно свой процесс, наработанный годами, и я буду рад использовать этот опыт по максимуму.
1.8. Локальный запуск
1.9. Запуск тестирования по зпренее определенной методике (и юзабилити и баги)
1.10. Сбор метрик и проверка на соответствие плану KPI примерно 1 раз в неделю.
1.10.1. Если не ок, делаем еще одну итерацию.
1.11. Работа с коммерческим отделом по составлению KPI и определение плана проверок. Причем, проверок как метрик, так и валидность поставленных KPI.
1.12. Составление нового ТЗ на бету
1.12.1. Полноценный прототип
1.12.2. User-flows
1.12.3. Документы
1.13. Создание и запуск тизера/лэндинга для ранних последователей, сбор недостающих данных (соц.сети, телефоны, актуализация емэйлов)
1.14. Создание (если нет) фидбэк платформы (офф группы, емэйлы и т.д., настройка всего этого добра и назначение ответственных на процессинг)
1.15. Разработка
1.16. Тестирование по спекам (зависит от методов разработки)
1.17. ДЕПЛООООООЙЙЙ!!!
1.18. Активация собранной лэндингом базы, запуск для ранних последователей.
1.19. Запуск одной из методологий тестирования. Сплит, например. Мультивариативное почти не работает в рамках "одного острова", так как он является слишком маленькой, "атомарной" единицей, а в некоторых случаях может быть вообще CTA-элементом целиком.
1.20. Следим за полетом по плану и действуем по обстоятельствам. Улучшаем, делаем итерации как описано выше.
1.21. Если все плохо, смело режем гипотезы из продукта, и строим новые с оглядкой на вырезанные.
2. Общая концепция сайдбара
2.1. Это зона контекстных уведомлений с горизонтом в 3 часа
2.2. Блоки будут постоянно меняться в зависимости от контекста по времени. Например, в сайд баре может не быть никаких уведомлений. В данном случае он просто деактивирован.
2.3. Уведомления можно закрывать, что будет помечать их "прочитанными"
2.4. Данное расположение (справа внизу) так же как и механизм расхлопа при наведении позволит избежать падения CTR на главном банере. Так же иконки и их размер являются предметом для обсуждения и тестирования.
2.5. Так же данное расположение и механика сайдбара позволит получить кроссплатформенный паттерн - и на комьютерах и на планшетах. Они находятся аккурат под правым большим пальцем. Иконки в данный момент размером в 48dp, что соответствует минимальному эффективному размеру кнопки на тачкскрине.
2.6. Этот сайдбар может присутствовать не только на главной Яндекса, но так же существовать в виде экстеншена к хрому и собственно к хромиуму(Я.Браузеру), что позволит быть "релевантными" и "вовремя" прямо во время серфинга по целефым ресурсам.
3. Спорт
3.1. Общее видение
3.1.1. Этот блок позволит своевременно напомнить пользователю о предстоящем матче его любимой команды или этапе чемпионата, а также поставить напоминалку. Каналы доставки напоминалки могут быть разные, как мобильное устройство через пуш в любое из приложений яндекса, так и на стационарном компьютере через Я.Браузер, или даже на ТВ через SmartTV. Напоминалка до начала матча и трансляция счета вовремя, а так же просто результат в течении 24 часов после завершения матча.
3.2. Данные/Параметры
3.2.1. Если это спортивное событие честь цепочки спортивных событий, то можно показывать новое звено этой цепочки и оно будет релевантным
3.2.2. Данные о матче/этапе со sport.yandex.ru (которые он в свою очередь агригирует из других источников)
3.2.3. Какой спорт предпочитает. Итория серфа /поиска должна включать определенный набор сайтов/ключевых слов (параметров). Так же эти посещения/запросы должны совпадать по времени +-24ч. с событиями либо одной из команд, либо событиями объедененными в цепочку (ЧМ по футболу, например) из всей базы спортивных событий, т.к. это может быть как хокей так и керлинг.
3.2.4. Наличие в почте писем от тематических площадок (билеты, новости)
3.2.5. Если Пользователь будет часто просто закрывать этот блок, помечать его "прочитанным" то можно поинтересоваться о любимой команде в момент закрытия блока или даже о списке команд и в дальнейшем начать показывать события связанные только с ними.
3.2.6. У каждого вида спорта свой календарь чемпионатов. Матчи случаются примерно 1 раз в 1-4дня
3.2.7. По сути алгоритм чем-то похож на ретаргетинг, только контентный
3.3. Выбор ранних последователей (Early Adopters)
3.3.1. Заходил на sports.yandex.ru или на сайт-партнера c частотой достаточной для определения его как заинтересованного.
3.3.2. Играют в FIFA или други спорт игры.
3.3.3. Общие черты для всех "хороших" ранних адоптеров
3.3.3.1. Обладают наибольшим набором совпадающих параметров (данных)
3.3.3.2. Черты евангелиста (много активных соц. контактов)
3.3.3.3. Понимание наличия проблемы
3.3.3.4. Желание решить эту проблему
3.3.3.5. Технологически опережает основную массу людей на 6мес-1год в среднем. Об этом говорит наличие продвинутого на данный момент смартфона, и участие в других бета программах Яндекса.
3.4. Метрики успеха
3.4.1. на стадии MVP (минимальный жизнеспособный продукт) во время локального теста
3.4.1.1. Качество прямого фидбэка. Получим методом опроса
3.4.1.2. то-же что и на паблик бете
3.4.2. на паблик бете
3.4.2.1. Процент активации сайдбара относительно количества просмотров главной. При условии что это уведомление было в обоих случаях
3.4.2.2. Время до активаций сайдбара после появления конкретного уведомления (меньше-лучше)
3.4.2.3. Количество активаций сайдбара в неделю и месяц
3.4.2.4. Количество просмотров именно этого блока (он может находиться за "сгибом")
3.4.2.5. CTR относительно прогноза (если блок содержит интерактивные элементы)
4. Кино
4.1. Общее видение
4.1.1. Этот блок позволит предложить сходить в кино с друзьями, любимыми или одному в тот момент когда пользователь это уже планировал, и почти или уже принял положительное решение о походе. Как правило на экранах находится кино 3-х категорий. Блок поставит на первое место ту, которая больше подходит пользователю (если будет достаточно данных)
4.2. Данные/Параметры
4.2.1. Ходит в кино. Наличие купленных билетов в почте, чек-ины (возможно ли прикрутить инстаграм или 4sq?)
4.2.2. Данные о премьерах и расписаниях с кинопоиска и сайтов партнеров
4.2.3. Оценки поставленные фильмам на сайтах партнеров.
4.2.4. Просмотры трейлеров. (Делим на 2 группы - досмотрел, не досмотрел)
4.2.5. Опционально
4.2.5.1. Есть кошелек и привязанная к нему карта (чтобы можно было быть уверенным в возможности продажи билета онлайн)
4.3. Выбор ранних последователей (Early Adopters)
4.3.1. Покупал билеты онлайн.
4.3.2. Регулярно искал новинки кино
4.3.3. Ставил оценки и смотрел трейлеры
4.3.4. Пользовался мобильной версией Я.Афиши
4.3.5. Общие черты для всех "хороших" ранних адоптеров
4.3.5.1. Обладают наибольшим набором совпадающих параметров (данных)
4.3.5.2. Черты евангелиста (много активных соц. контактов)
4.3.5.3. Понимание наличия проблемы
4.3.5.4. Желание решить эту проблему
4.3.5.5. Технологически опережает основную массу людей на 6мес-1год в среднем. Об этом говорит наличие продвинутого на данный момент смартфона, и участие в других бета программах Яндекса.
4.4. Метрики успеха
4.4.1. на стадии MVP (минимальный жизнеспособный продукт) во время локального теста
4.4.1.1. Качество прямого фидбэка. Получим методом опроса
4.4.1.2. то-же что и на паблик бете
4.4.2. на паблик бете
4.4.2.1. Процент активации сайдбара относительно количества просмотров главной. При условии что это уведомление было в обоих случаях
4.4.2.2. Время до активаций сайдбара после появления конкретного уведомления (меньше-лучше)
4.4.2.3. Количество активаций сайдбара в неделю и месяц
4.4.2.4. Количество просмотров именно этого блока (он может находиться за "сгибом")
4.4.2.5. CTR относительно прогноза (если блок содержит интерактивные элементы)