Нашел еще пару отчетов, но сегодня предлагаю отвлечься от количественных исследований на качественные.
В разработке сложного продукта высока вероятность столкнуться с необходимостью сортировки сущностей по различным критериям. Руководствуясь своим здравым смыслом мы структурируем их, как считаем логичным. Это зачастую порождает проблемы у пользователей, когда ЦА мыслит совсем категориями.
В статье от nngroup приводится пример с автомобилями на сайте, но и в геймдеве достаточно частая ситуация. К примеру возьмем квесты обычные, ивентовые, ачивки, какой-нибудь лор, подсказки и кучу другой специфической инфы, - всё это нужно рассортировать.
Суть метода состоит в том, чтобы делегировать эту задачу непосредственно на представителей ЦА.
Общий алгоритм:
1. Выписываются все сущности, которые необходимо структурировать
2. Этот набор карточек отдается выборке пользователей (обычно требуется человек 15-20)
3. Им ставится задача рассортировать карточки по группам
4. А затем назвать эти группы
5. Расспросить пользователей какими принципами руководствовались, что вызвало сложности, есть ли элементы, которые никуда не попали или попадают сразу в две категории
6. Проанализировать результаты и адаптировать для продукта, если потребуется
Изначально данное исследование делалось с помощью бумажных карточек, но сейчас можно использовать цифровую версию, чтобы убрать потребность в физическом контакте. Простым бюджетным вариантом выглядит trello - создать доску с карточками и пусть пользователи создают колонки и раскладывают.
Есть 2 подхода к исследованию по работе с именованием групп:
- открытый (чаще всего используется), категории придумывают сами пользователи
- закрытый, когда категории заданы изначально
И по обсуждению результатов с пользователями:
- модерируемый, когда мы узнаем чем руководствовались пользователи в сортировке (больше инфы)
- немодерируемый, когда не проводим этот этап (дешевле)
Плюсы метода:
- простой и недорогой в проведении
- не требователен к навыкам испытуемого
- ориентирован на потребности пользователя
Минусы:
- игнорирует задачи продукта и результат может быть нерелевантен
- результаты могут варьироваться в каждом конкретном случае
Источник (англ.): https://www.nngroup.com/articles/card-sorting-definition/
и еще немного https://www.interaction-design.org/literature/article/the-pros-and-cons-of-card-sorting-in-ux-research
В разработке сложного продукта высока вероятность столкнуться с необходимостью сортировки сущностей по различным критериям. Руководствуясь своим здравым смыслом мы структурируем их, как считаем логичным. Это зачастую порождает проблемы у пользователей, когда ЦА мыслит совсем категориями.
В статье от nngroup приводится пример с автомобилями на сайте, но и в геймдеве достаточно частая ситуация. К примеру возьмем квесты обычные, ивентовые, ачивки, какой-нибудь лор, подсказки и кучу другой специфической инфы, - всё это нужно рассортировать.
Суть метода состоит в том, чтобы делегировать эту задачу непосредственно на представителей ЦА.
Общий алгоритм:
1. Выписываются все сущности, которые необходимо структурировать
2. Этот набор карточек отдается выборке пользователей (обычно требуется человек 15-20)
3. Им ставится задача рассортировать карточки по группам
4. А затем назвать эти группы
5. Расспросить пользователей какими принципами руководствовались, что вызвало сложности, есть ли элементы, которые никуда не попали или попадают сразу в две категории
6. Проанализировать результаты и адаптировать для продукта, если потребуется
Изначально данное исследование делалось с помощью бумажных карточек, но сейчас можно использовать цифровую версию, чтобы убрать потребность в физическом контакте. Простым бюджетным вариантом выглядит trello - создать доску с карточками и пусть пользователи создают колонки и раскладывают.
Есть 2 подхода к исследованию по работе с именованием групп:
- открытый (чаще всего используется), категории придумывают сами пользователи
- закрытый, когда категории заданы изначально
И по обсуждению результатов с пользователями:
- модерируемый, когда мы узнаем чем руководствовались пользователи в сортировке (больше инфы)
- немодерируемый, когда не проводим этот этап (дешевле)
Плюсы метода:
- простой и недорогой в проведении
- не требователен к навыкам испытуемого
- ориентирован на потребности пользователя
Минусы:
- игнорирует задачи продукта и результат может быть нерелевантен
- результаты могут варьироваться в каждом конкретном случае
Источник (англ.): https://www.nngroup.com/articles/card-sorting-definition/
и еще немного https://www.interaction-design.org/literature/article/the-pros-and-cons-of-card-sorting-in-ux-research
Название статьи "How to Effectively Predict Launch Week Installs on Mobile" намекает, что сейчас мы выясним как по-быстрому предсказать подходящий момент выпуска продукта, чтобы обмазаться траффиком с фичеринга. На самом деле всё не так просто, статья скорее про возможности предиктивной аналитики и подход к решению данной проблемы.
Всегда сложно предсказать как пройдет фичеринг. На деконстракторе ребята выложили исследование вокруг гипотезы - "существуют взаимосвязь между неделей запуска игры, местом в фичеринге, жанром и графическим стилем игры".
Для её доказательства:
1. Изучили 150+ игр в промежутке 02.04-27.09.2018 на ios используя данные платформы и app annie. Платные игры и продукты по большим франшизам исключили из исследования
2. Отсортировали по месту в фичеринге, жанру и стилю
3. Использовали для тестирования гипотезы Kruskal-Wallis (KW) Hypothesis Test
4. Построили линейную регрессионную модель, на вход которой подавали 3 гипотетических параметра из прошлого пункта, а на выходе получали ожидаемый объем инсталлов в зависимости дат выхода
Подробнее по доказательству:
Сортировка по параметрам.
Место в фичеринге на протяжении недели:
big - "Игра дня", верхний баннер в разделе игры и 1-3 верхняя иконка в блоке New Games We Love"
medium-big - верхний баннер в разделе игры и 1-3 верхняя иконка в блоке "New Games We Love"
medium-small - 4-6 верхняя иконка в блоке "New Games We Love"
small - 4-6 верхняя иконка в блоке "New Games We Love"
Стиль арта:
Realistic - реалистичный визуал
Cartoon - мультипликационный
Manga - анимешный
Pixel/retro - пиксель арт и стилизация под старые игры
Жанр.
Использовалась таксономия, разработанная Game Refinery and Michail Katkoff, где Категорией являются сущности типа "Казуальный", "Мидкор", "Казино", "Спортивные". Их подмножеством являются Жанры к примеру возьмем Puzzle для категории казуальных игр. Их мы используем в данном исследовании. Более мелкие подмножества под-жанров ("Match3 puzzle", "Action puzzle" и т.д.) могут быть использованы при более крупных выборках данных.
Доказательство гипотезы
Используя критерия критерий Крускала-Уоллиса изучили статистическую значимость перечисленных выше параметров, составили таблицу на которой соотнесли их с неделями и месяцами. В итоге получили, что наименьшее влияние оказывает графический стиль, но всё равно статистически значим. Используя эти параметры реализовали модель, предсказывающую зависимость места в фичере, от жанра, стиля, месяца и недели запуска.
Проверка.
Логичным этапом будет проверить эту гипотезу на практических данных. Собственно на картинке выше прикрепил графики худших и лучших результатов. Да, погрешность есть и ощутимая, но с другой стороны с этим уже можно работать, а используя больший набор данных и более точную модель можно получить лучшие результаты.
Источник (англ.): https://www.deconstructoroffun.com/blog/2018/12/10/are-launch-week-installs-even-predictable-on-mobile
Всегда сложно предсказать как пройдет фичеринг. На деконстракторе ребята выложили исследование вокруг гипотезы - "существуют взаимосвязь между неделей запуска игры, местом в фичеринге, жанром и графическим стилем игры".
Для её доказательства:
1. Изучили 150+ игр в промежутке 02.04-27.09.2018 на ios используя данные платформы и app annie. Платные игры и продукты по большим франшизам исключили из исследования
2. Отсортировали по месту в фичеринге, жанру и стилю
3. Использовали для тестирования гипотезы Kruskal-Wallis (KW) Hypothesis Test
4. Построили линейную регрессионную модель, на вход которой подавали 3 гипотетических параметра из прошлого пункта, а на выходе получали ожидаемый объем инсталлов в зависимости дат выхода
Подробнее по доказательству:
Сортировка по параметрам.
Место в фичеринге на протяжении недели:
big - "Игра дня", верхний баннер в разделе игры и 1-3 верхняя иконка в блоке New Games We Love"
medium-big - верхний баннер в разделе игры и 1-3 верхняя иконка в блоке "New Games We Love"
medium-small - 4-6 верхняя иконка в блоке "New Games We Love"
small - 4-6 верхняя иконка в блоке "New Games We Love"
Стиль арта:
Realistic - реалистичный визуал
Cartoon - мультипликационный
Manga - анимешный
Pixel/retro - пиксель арт и стилизация под старые игры
Жанр.
Использовалась таксономия, разработанная Game Refinery and Michail Katkoff, где Категорией являются сущности типа "Казуальный", "Мидкор", "Казино", "Спортивные". Их подмножеством являются Жанры к примеру возьмем Puzzle для категории казуальных игр. Их мы используем в данном исследовании. Более мелкие подмножества под-жанров ("Match3 puzzle", "Action puzzle" и т.д.) могут быть использованы при более крупных выборках данных.
Доказательство гипотезы
Используя критерия критерий Крускала-Уоллиса изучили статистическую значимость перечисленных выше параметров, составили таблицу на которой соотнесли их с неделями и месяцами. В итоге получили, что наименьшее влияние оказывает графический стиль, но всё равно статистически значим. Используя эти параметры реализовали модель, предсказывающую зависимость места в фичере, от жанра, стиля, месяца и недели запуска.
Проверка.
Логичным этапом будет проверить эту гипотезу на практических данных. Собственно на картинке выше прикрепил графики худших и лучших результатов. Да, погрешность есть и ощутимая, но с другой стороны с этим уже можно работать, а используя больший набор данных и более точную модель можно получить лучшие результаты.
Источник (англ.): https://www.deconstructoroffun.com/blog/2018/12/10/are-launch-week-installs-even-predictable-on-mobile
UPD. Комментарий специалиста: "Когда идет речь про применения критерия, всегда указываются полученные значения p-value. В данном тесте ребята брали significance level = 0.1 = alpha, что дает достаточно низкую точность. Возможно это обусловлено данными, с которыми работали. Для большинства случаев это очень мало, обычно берут 0.95, в точных тестах стараются брать 0.99 или 0.999."
Лекцию писал по памяти и фото, некоторые моменты опустил (непосредственно обучение бота - оно достаточно поверхностное, для того чтобы взять и запилить у себя инфы будет мало).
Любопытные моменты.
- Если конкретный пользователь не справляется с уровнем за N попыток - ему высылается zip с корректировкой баланса выпадающих гемов. Наконец хоть кто-то официально подтвердил эту инфу
- Уровни не тестируются на субъективные критерии типа интересности, данный момент проверяется уже по отвалам на продакшне.
- Новые механики изначально тестируются на дочерних проектах, затем на небольшой части аудитории и только потом становятся доступны всем игрокам.
- Уровни передаются на ферму тестировщиков в Канаде, где 500 человек пытается их пройти
- Хорошим считается уровень, который смогли пройти 80% тестировщиков, если не попали в сложность - level-дизы переделывают
- Используют облачную платформу от google
Подходы к реализации бота:
Heuristics - эвристики, самый простой и быстрый способ, бот совершенно не похож на человека, но позволяет проверить потенциальную проходимость уровня
Исследование дерева по методу Монте-Карло (MCTS) - бот перебирает все возможные комбинации, что очень долго. Можно сравнить с тем, как проходит человек
Deep learning - берутся накопленные данные по сессиям игроков и на них обучаем бота, быстрый как эвристики, точнее чем MCTS
Reinforcement learning - в бота закладываются базовые принципы, а дальше он сам обучается проходить уровни, что имитирует поведение человека. Основная проблема в том, что в определенный момент бот начинает слишком хорошо играть и по скиллу выбивается за 80% игроков, на которых ориентируемся
Сложности в создании.
- Визуальные эффекты и анимации были интегрированы в логику, это замедляет обработку
- Вопрос ответственности за бота размазывается между разработчиками, QA и аналитиками
- Необходимо иметь наработанные данные по пользовательским сессиям, свои или купить
- Непросто воспроизвести поведение человека, быть не лучше и не хуже
Результаты.
- Уменьшилось количество проблем с уровнями, ловятся вылеты на большой скорости ходов
- Упростилось тестирование и производство новых уровней
Плэйтесты проводятся за минуты (требуется пара секунд на попытку)
- Улучшилось понимание поведения пользователей. К примеру при прочих равных они будут матчить наверху уровня или внизу и т.д.
Источник (нормального пока нет, "текстовый camrip" в моём исполнении): https://telegra.ph/Ispolzovanie-AI-dlya-sborki-urovnej-match3-12-26
Любопытные моменты.
- Если конкретный пользователь не справляется с уровнем за N попыток - ему высылается zip с корректировкой баланса выпадающих гемов. Наконец хоть кто-то официально подтвердил эту инфу
- Уровни не тестируются на субъективные критерии типа интересности, данный момент проверяется уже по отвалам на продакшне.
- Новые механики изначально тестируются на дочерних проектах, затем на небольшой части аудитории и только потом становятся доступны всем игрокам.
- Уровни передаются на ферму тестировщиков в Канаде, где 500 человек пытается их пройти
- Хорошим считается уровень, который смогли пройти 80% тестировщиков, если не попали в сложность - level-дизы переделывают
- Используют облачную платформу от google
Подходы к реализации бота:
Heuristics - эвристики, самый простой и быстрый способ, бот совершенно не похож на человека, но позволяет проверить потенциальную проходимость уровня
Исследование дерева по методу Монте-Карло (MCTS) - бот перебирает все возможные комбинации, что очень долго. Можно сравнить с тем, как проходит человек
Deep learning - берутся накопленные данные по сессиям игроков и на них обучаем бота, быстрый как эвристики, точнее чем MCTS
Reinforcement learning - в бота закладываются базовые принципы, а дальше он сам обучается проходить уровни, что имитирует поведение человека. Основная проблема в том, что в определенный момент бот начинает слишком хорошо играть и по скиллу выбивается за 80% игроков, на которых ориентируемся
Сложности в создании.
- Визуальные эффекты и анимации были интегрированы в логику, это замедляет обработку
- Вопрос ответственности за бота размазывается между разработчиками, QA и аналитиками
- Необходимо иметь наработанные данные по пользовательским сессиям, свои или купить
- Непросто воспроизвести поведение человека, быть не лучше и не хуже
Результаты.
- Уменьшилось количество проблем с уровнями, ловятся вылеты на большой скорости ходов
- Упростилось тестирование и производство новых уровней
Плэйтесты проводятся за минуты (требуется пара секунд на попытку)
- Улучшилось понимание поведения пользователей. К примеру при прочих равных они будут матчить наверху уровня или внизу и т.д.
Источник (нормального пока нет, "текстовый camrip" в моём исполнении): https://telegra.ph/Ispolzovanie-AI-dlya-sborki-urovnej-match3-12-26
Время для выжимки из статьи от приглашенного эксперта.
Для чего используется машинное обучение при оперировании играми:
• Расширение платежеспособной аудитории игры - Look-alike таргетинг, основанный на сегментировании по поведенческим паттернам.
• Удержание игроков и предсказание их ухода - выявление первых признаков скорого отвала (увеличение промежутков между сессиями, сокращение длительности сессий), адаптация контента для попытки удержания (выгодные акции, облегчение контента). Удержать игрока дешевле, чем купить нового
• Динамическое изменение цен на внутриигровые товары - Изменение цен на товары за реал в зависимости от платежеспособности и истории платежей.
• Индивидуальные предложения - в зависимости от предпочтений продаем игроку контент, отвечающий запросу.
• Конвертация в платящие - акции первого платежа. Причем дядя говорит обощенно, а на деле имеет в виду полностью сборные предложения, когда товар подставляется в акцию автоматически на основании паттернов, с весами.
• Оптимизация частоты появления рекламы - корректировка лимитов на показ в зависимости от поведения. Терпимым - больше, прочим - меньше.
• Борьба с мошенниками - Алгоритмы машинного обучения могут анализировать мошенническую активность, обучаясь вычислять её и блокировать оплату за поддельные установки. Тем самым они сэкономят разработчикам на рекламе миллионы или даже миллиарды долларов.
Вместо заключения
Один из самых масштабных тестов влияния машинного обучения на монетизацию (из тех, что были озвучены публично) провели разработчики сервиса Game of Whales, который специализируется на ML-монетизации. Сначала их алгоритмы 18 месяцев изучали поведение 18 млн игроков. Затем была выделена контрольная группа пользователей, с которыми и работал ИИ. Выяснилось, что в этой контрольной группе выручка от фритуплейных игр выросла на 25%, а отток пользователей сократился на 10%.
Источник: https://app2top.ru/marketing/kak-mashinnoe-obuchenie-pomogaet-gejmdevu-zarabaty-vat-i-e-konomit-rasskaz-playgendary-130592.html
Для чего используется машинное обучение при оперировании играми:
• Расширение платежеспособной аудитории игры - Look-alike таргетинг, основанный на сегментировании по поведенческим паттернам.
• Удержание игроков и предсказание их ухода - выявление первых признаков скорого отвала (увеличение промежутков между сессиями, сокращение длительности сессий), адаптация контента для попытки удержания (выгодные акции, облегчение контента). Удержать игрока дешевле, чем купить нового
• Динамическое изменение цен на внутриигровые товары - Изменение цен на товары за реал в зависимости от платежеспособности и истории платежей.
• Индивидуальные предложения - в зависимости от предпочтений продаем игроку контент, отвечающий запросу.
• Конвертация в платящие - акции первого платежа. Причем дядя говорит обощенно, а на деле имеет в виду полностью сборные предложения, когда товар подставляется в акцию автоматически на основании паттернов, с весами.
• Оптимизация частоты появления рекламы - корректировка лимитов на показ в зависимости от поведения. Терпимым - больше, прочим - меньше.
• Борьба с мошенниками - Алгоритмы машинного обучения могут анализировать мошенническую активность, обучаясь вычислять её и блокировать оплату за поддельные установки. Тем самым они сэкономят разработчикам на рекламе миллионы или даже миллиарды долларов.
Вместо заключения
Один из самых масштабных тестов влияния машинного обучения на монетизацию (из тех, что были озвучены публично) провели разработчики сервиса Game of Whales, который специализируется на ML-монетизации. Сначала их алгоритмы 18 месяцев изучали поведение 18 млн игроков. Затем была выделена контрольная группа пользователей, с которыми и работал ИИ. Выяснилось, что в этой контрольной группе выручка от фритуплейных игр выросла на 25%, а отток пользователей сократился на 10%.
Источник: https://app2top.ru/marketing/kak-mashinnoe-obuchenie-pomogaet-gejmdevu-zarabaty-vat-i-e-konomit-rasskaz-playgendary-130592.html
Основная тема:
Через микроанимации можно увеличить удовлетворенность пользователя продуктом и сгладить болезненные моменты взаимодействия.
Предложения:
1. Менять отображение элементов UI сразу после взаимодействия с ними пользователя, чтобы фидбэк был максимально быстрым и информативным. Пример нажатая кнопка залогиниться красится в красный если пароль не подошел или в зеленый, если всё ок
2. Запилить ненавязчивые хинты, особенно на онбординге. Хороший тон по мнению автора мягко пульсирующая и с переливанием иконка
3. На моментах с долгой подгрузкой добавить замысловатую анимацию. По исследованию Aberdeen 2008 года для веба цена одной секунды задержки 11% падение просмотров страницы. Решение - сложная анимация, в которую можно позалипать. Как пример иконка рисующаяся из линий
4. Нотификации о событиях, которые происходят без участия игрока. Ненавязчивые, но заметные. Как изменение счетчика писем с эффектом отлетающих от него плюсов
5. Навигация будет приятнее для пользователя, если переходы между разделами будут не мгновенными, а спокойными наплывами
6. Продолжительная анимация UI элементов во время нажатия и обрывающаяся в момент отпускания пальца повышает ощущение интерактивности интерфейса
6. Небольшие мотивационные анимации-награды за выполнение рутинных действий. По сути использование логики работы достижений из игр + анимация
7. Яркие и сложные анимации могут использоваться для улучшения узнаваемости бренда, но важно чтобы они не портили опыт взаимодействия пользователя с продуктом
Источник (англ.): https://anadea.info/blog/how-micro-animations-improve-ux
Через микроанимации можно увеличить удовлетворенность пользователя продуктом и сгладить болезненные моменты взаимодействия.
Предложения:
1. Менять отображение элементов UI сразу после взаимодействия с ними пользователя, чтобы фидбэк был максимально быстрым и информативным. Пример нажатая кнопка залогиниться красится в красный если пароль не подошел или в зеленый, если всё ок
2. Запилить ненавязчивые хинты, особенно на онбординге. Хороший тон по мнению автора мягко пульсирующая и с переливанием иконка
3. На моментах с долгой подгрузкой добавить замысловатую анимацию. По исследованию Aberdeen 2008 года для веба цена одной секунды задержки 11% падение просмотров страницы. Решение - сложная анимация, в которую можно позалипать. Как пример иконка рисующаяся из линий
4. Нотификации о событиях, которые происходят без участия игрока. Ненавязчивые, но заметные. Как изменение счетчика писем с эффектом отлетающих от него плюсов
5. Навигация будет приятнее для пользователя, если переходы между разделами будут не мгновенными, а спокойными наплывами
6. Продолжительная анимация UI элементов во время нажатия и обрывающаяся в момент отпускания пальца повышает ощущение интерактивности интерфейса
6. Небольшие мотивационные анимации-награды за выполнение рутинных действий. По сути использование логики работы достижений из игр + анимация
7. Яркие и сложные анимации могут использоваться для улучшения узнаваемости бренда, но важно чтобы они не портили опыт взаимодействия пользователя с продуктом
Источник (англ.): https://anadea.info/blog/how-micro-animations-improve-ux
Дорогие друзья! Время приближает нас к новому, 2019 году. Позади насыщенный, полный забот декабрь... Да и в принципе год выдался довольно бодрым. Для тех, кто полон сил и энергии, не хочет останавливаться на достигнутом и интересуется ML - вот пара подборок:
https://github.com/trekhleb/homemade-machine-learning
https://github.com/demidovakatya/vvedenie-mashinnoe-obuchenie
На праздниках подкоплю темы и продолжу постить. Спасибо всем, кто поддерживал данную тему с каналом, кто давал фидбэк и рекомендовал материалы для публикаций. С новым годом!
https://github.com/trekhleb/homemade-machine-learning
https://github.com/demidovakatya/vvedenie-mashinnoe-obuchenie
На праздниках подкоплю темы и продолжу постить. Спасибо всем, кто поддерживал данную тему с каналом, кто давал фидбэк и рекомендовал материалы для публикаций. С новым годом!
За праздники наконец добрался до докладов с конфы product sense, будут попадаться вещи довольно банальные для custdev'щиков со стажем, но остальным может пригодиться. И для начала небольшой доклад про Growth hacking.
Growth hacking - область на стыке маркетинга, UX и управления продуктом, основная цель - агрессивный рост продукта.
Задачи продуктивного growth hacking сводятся к созданию непрерывного процесса экспериментирования на всех этапах AAARRRR для поиска нестандартных путей роста.
В таблице наверху (см. заголовок), приложены расчеты, чтобы понимать насколько вы сконцентрированы на GH и результат за год, если отталкиваться от количества экспериментов в неделю.
Для того, чтобы оценить, насколько в текущий момент работа направлена на рост, стоит взять пул текущих задач, пометить задачи на улучшение каждой из AAARRRR метрик и те которые не способствуют.
AAARRRR метрики:
- awareness - информирование пользователя о своем существовании
- acquisition - получение контакта пользователя
- activation - привлечение пользователя в продукт, первый экспириенс
- retention - задачи на возврат
- revenue - задачи на конвертацию пользователя в плательщика и увеличение дохода
- referral - привлечение пользователей другими пользователями
- resurrection - возврат ушедших пользователей
Обычно работают над acquisition и revenue, упуская всё остальное, а прибыль по сути произведение всех метрик.
Aha moment - момент когда пользователь впервые достигает успеха с продуктом или понимает какие действия к нему привели.
Примеры нахождение aha момента по версии компаний:
AirBnb - красивые фотографии, зашли и сразу видите их
Uber - момент движения машин на карте,
Yelp - (приложение - каталог бизнесов) отрицательные отзывы, людям не нужно, чтобы было очень хорошо, а хотя бы чтобы не было очень плохо
Работа с aha моментом - берется customer journey map, определяется наиболее ценный для пользователя момент и передвигается как можно раньше. К примеру выкидывается всё перед этим.
Тестировать гипотезы дешевле на этапе рекламы, до разработки, сделав акцент на aha-моменте и посмотрев на конверсию.
Задачи growth hacking находятся между компетенциями маркетинга и product, для этого создаются growth team, которые объединяют всех причастных к задачам на aaarrrr метрики. Такие команды созданы в FB, LN, uber, amazon и т.д. Они генерят обоснованные гипотезы и затем их тестируют.
Источник (19 минут): https://www.youtube.com/watch?v=Ht11C6mj9AA
Growth hacking - область на стыке маркетинга, UX и управления продуктом, основная цель - агрессивный рост продукта.
Задачи продуктивного growth hacking сводятся к созданию непрерывного процесса экспериментирования на всех этапах AAARRRR для поиска нестандартных путей роста.
В таблице наверху (см. заголовок), приложены расчеты, чтобы понимать насколько вы сконцентрированы на GH и результат за год, если отталкиваться от количества экспериментов в неделю.
Для того, чтобы оценить, насколько в текущий момент работа направлена на рост, стоит взять пул текущих задач, пометить задачи на улучшение каждой из AAARRRR метрик и те которые не способствуют.
AAARRRR метрики:
- awareness - информирование пользователя о своем существовании
- acquisition - получение контакта пользователя
- activation - привлечение пользователя в продукт, первый экспириенс
- retention - задачи на возврат
- revenue - задачи на конвертацию пользователя в плательщика и увеличение дохода
- referral - привлечение пользователей другими пользователями
- resurrection - возврат ушедших пользователей
Обычно работают над acquisition и revenue, упуская всё остальное, а прибыль по сути произведение всех метрик.
Aha moment - момент когда пользователь впервые достигает успеха с продуктом или понимает какие действия к нему привели.
Примеры нахождение aha момента по версии компаний:
AirBnb - красивые фотографии, зашли и сразу видите их
Uber - момент движения машин на карте,
Yelp - (приложение - каталог бизнесов) отрицательные отзывы, людям не нужно, чтобы было очень хорошо, а хотя бы чтобы не было очень плохо
Работа с aha моментом - берется customer journey map, определяется наиболее ценный для пользователя момент и передвигается как можно раньше. К примеру выкидывается всё перед этим.
Тестировать гипотезы дешевле на этапе рекламы, до разработки, сделав акцент на aha-моменте и посмотрев на конверсию.
Задачи growth hacking находятся между компетенциями маркетинга и product, для этого создаются growth team, которые объединяют всех причастных к задачам на aaarrrr метрики. Такие команды созданы в FB, LN, uber, amazon и т.д. Они генерят обоснованные гипотезы и затем их тестируют.
Источник (19 минут): https://www.youtube.com/watch?v=Ht11C6mj9AA
Рассылки для вовлечения пользователей, уменьшения отвала и увеличения дохода
В одном из выступлений на product sense была упомянута статья от Baremetrics (B2B, занимаются аналитикой) про то, как они поднимали показатели за счет email рассылок. Спросите при чем тут геймдев? По сути они описывают своего рода механики неблокирующего тутора, пушей на возвраты и получения фидбэка от пользователя.
В мобильных приложениях получить имейл от пользователя сложнее чем в B2B сервисе, но способы есть. И ничто не мешает реализовать внутреннюю систему обмена сообщений с пользователем.
Лучше работает, если письма исходят от конкретных людей.
От первых писем максимальный эффект.
Рассылка по этапам:
Онбординг.
Основные задачи - показать ценность продукта для пользователя, а также рассказать про функционалы, о которых он может не знать. Данный момент отлично обвязывается сплит-тестами с целью улучшения возврата.
День 1 - приветственное письмо от основателя, дает канал для связи, подчеркивает что пользователь не безразличен
День 2 - приветственное письмо от саппорт, дает дополнительный канал связи, объясняет где найти мануалы, блог и всё такое (в случае с геймдевом есть смысл пытаться вовлечь в игровое комьюнити)
День 3 - письмо мотивирующее на привлечение других пользователей
День 5 - письмо про пользу от нотификаций, мотивация на включение пушей
День 6 - рассказ о тарифных планах, попытка повлиять на платежи
День 8, 10, 12 - рассказ про фичу
День 14 - прощание на этапе онбординга, суть та же, что у первого письма
Первые 3 месяца.
По одному письму в месяц провоцируем на фидбэк, каждый раз меняем отправителя письма.
В конце данного периода письмо чтобы сконвертировать в покупку годовой подписки с демонстрацией её выгоды.
Письма по событиям.
Уход из продукта - пытаемся получить фидбэк почему
Платеж - положительная закрепляющая мотивация и попытка получить дополнительный контакт
Первая неделя - мотивирующий подарочный стикерпак (можно использовать данный прием для получения нового канала связи с пользователем, например email, если раньше не получили).
Источник(англ.): https://baremetrics.com/blog/lifecycle-emails
В мобильных приложениях получить имейл от пользователя сложнее чем в B2B сервисе, но способы есть. И ничто не мешает реализовать внутреннюю систему обмена сообщений с пользователем.
Лучше работает, если письма исходят от конкретных людей.
От первых писем максимальный эффект.
Рассылка по этапам:
Онбординг.
Основные задачи - показать ценность продукта для пользователя, а также рассказать про функционалы, о которых он может не знать. Данный момент отлично обвязывается сплит-тестами с целью улучшения возврата.
День 1 - приветственное письмо от основателя, дает канал для связи, подчеркивает что пользователь не безразличен
День 2 - приветственное письмо от саппорт, дает дополнительный канал связи, объясняет где найти мануалы, блог и всё такое (в случае с геймдевом есть смысл пытаться вовлечь в игровое комьюнити)
День 3 - письмо мотивирующее на привлечение других пользователей
День 5 - письмо про пользу от нотификаций, мотивация на включение пушей
День 6 - рассказ о тарифных планах, попытка повлиять на платежи
День 8, 10, 12 - рассказ про фичу
День 14 - прощание на этапе онбординга, суть та же, что у первого письма
Первые 3 месяца.
По одному письму в месяц провоцируем на фидбэк, каждый раз меняем отправителя письма.
В конце данного периода письмо чтобы сконвертировать в покупку годовой подписки с демонстрацией её выгоды.
Письма по событиям.
Уход из продукта - пытаемся получить фидбэк почему
Платеж - положительная закрепляющая мотивация и попытка получить дополнительный контакт
Первая неделя - мотивирующий подарочный стикерпак (можно использовать данный прием для получения нового канала связи с пользователем, например email, если раньше не получили).
Источник(англ.): https://baremetrics.com/blog/lifecycle-emails
На скрине показаны результаты исследования ltv пользователей при использовании монетизации через подписки и через инапы. Хороших примеров внедрения подписок в играх не видел, за исключением баттлеров пожалуй. Но в теории подход имеет право на жизнь.
Начиная с wwdc16 apple продвигают переход к данной модели. Она приносит больше денег за счет инертности пользователей, которым лень отключить подписки.
По инфе спикера - в штатах при списаниях не приходит даже уведомление, лишь в конце месяца.
1. Trial делать необходимо, цель получать данные карты пользователя.
2. Хороший способ при транзакции предложить проапгрейдиться до подписки
3. Предлагать стартовать бесплатный триал можно после первого входа и после покупки инапа.
4. Годовую подписку отменяют реже, чем месячную, потому что не напоминает о себе лишний раз. По цене best practise нет, всё индивидуально.
5. Истекающая карта - не давать подписаться, если карта скоро истекает. Стор берет на себя часть проблем с обновлением данных карт, поскольку подписок зачастую больше одной поэтому данные обновляются регулярно.
Недостаточно средств - списывать в районе 5го числа, когда большинство получает заплату и ещё не сняли деньги. Сегментировать по регионам, списывать у тестовой группы, затем у всех остальных
6. Если пользователь не чувствует ценности и пытается прекратить подписку, то стоит сделать exit interview и узнать почему. А также предлагать даунгрейд подписки, если пользователю кажется, что он платит слишком много.
7. При переходе на подписочную модель падает выручка на первом этапе из-за trial и того, что однократный платеж по подписке обычно меньше, чем стоимость инапа.
Проблемы может вызывать антифрод защита у биллинговых систем.
От ретеншна растут подписки, а от подписок ретеншн.
В некоторых регионах подписываются хуже, там стоит комбинировать модели монетизации.
Источник (40 минут): https://youtu.be/IpUh0Eh4oFE
Начиная с wwdc16 apple продвигают переход к данной модели. Она приносит больше денег за счет инертности пользователей, которым лень отключить подписки.
По инфе спикера - в штатах при списаниях не приходит даже уведомление, лишь в конце месяца.
1. Trial делать необходимо, цель получать данные карты пользователя.
2. Хороший способ при транзакции предложить проапгрейдиться до подписки
3. Предлагать стартовать бесплатный триал можно после первого входа и после покупки инапа.
4. Годовую подписку отменяют реже, чем месячную, потому что не напоминает о себе лишний раз. По цене best practise нет, всё индивидуально.
5. Истекающая карта - не давать подписаться, если карта скоро истекает. Стор берет на себя часть проблем с обновлением данных карт, поскольку подписок зачастую больше одной поэтому данные обновляются регулярно.
Недостаточно средств - списывать в районе 5го числа, когда большинство получает заплату и ещё не сняли деньги. Сегментировать по регионам, списывать у тестовой группы, затем у всех остальных
6. Если пользователь не чувствует ценности и пытается прекратить подписку, то стоит сделать exit interview и узнать почему. А также предлагать даунгрейд подписки, если пользователю кажется, что он платит слишком много.
7. При переходе на подписочную модель падает выручка на первом этапе из-за trial и того, что однократный платеж по подписке обычно меньше, чем стоимость инапа.
Проблемы может вызывать антифрод защита у биллинговых систем.
От ретеншна растут подписки, а от подписок ретеншн.
В некоторых регионах подписываются хуже, там стоит комбинировать модели монетизации.
Источник (40 минут): https://youtu.be/IpUh0Eh4oFE
