Данные и аналитика до первого вопроса
Прежде чем придумывать игру, решите, что воронка должна узнать о каждом игроке и как вы будете считать её эффективность. Это первый документ проекта: на нём потом проверяют и скелет, и тексты, и готового бота.
Зачем это делать раньше сценария
Если сначала написать сценарий, а потом вспомнить про данные, вопросы окажутся пришитыми сбоку и будут читаться как анкета. Если сначала решить, что нужно узнать, сценарий можно построить так, что каждая развилка сама собирает нужное поле.
Вторая причина: без точек отсчёта вы не узнаете, где застревают люди. Ведущая говорит, что за годы работы с воронками именно этого чаще всего не хватало. А дорабатывать воронку придётся почти наверняка.
Три группы данных
Для каждого поля в документе нужно записать:
- что узнаём и зачем;
- какое решение примем на основе этого;
- откуда возьмём: из действия, технического события или ответа;
- обязательно ли поле и как отмечаем отсутствие ответа.
Поле без понятного применения удаляется. Список нужен для решений, а не для полноты.
Как устроен документ
На эфире Claude разложил данные по слоям: события, которые пишет бот; конверсии воронки; маркетинг; продажи. В итоговом документе у ChatGPT были разделы «что собирается без вопросов», «кастдев внутри игры», «что можно спросить по желанию» и «что собираем в финале».
Что собирать без вопросов
Многое бот узнаёт сам: откуда человек пришёл, на каком шаге остановился, сколько времени прошло между шагами, вернулся ли после напоминания, открыл ли предложение. Об этом спрашивать не нужно, это технические события. Чем больше данных приходит из действий, тем короче список вопросов.
Остальное делится на две части: то, что спросим внутри сюжета (калибровка, выборы героя), и то, что можно спросить только по желанию. Вопросы после результата ведущая оставляет на пробу: скорее всего, отвечать на них будут немногие.
Как это выглядело на эфире
Промпты этапа
Определить данные и аналитику
- когда брать
- После брифа, до игровых вопросов и написания сценария.
- что подготовить
- Согласованный бриф 00_brief.md.
Используй согласованный бриф. Пока не придумывай игровые вопросы, диалоги и тексты. Сначала определи, какую информацию мы должны получать из воронки.
Раздели ее на три группы:
1. Маркетинг: источник входа, площадка, прохождение этапов, остановки, время между шагами, возвраты, переходы к предложению и конверсии.
2. Продажи: какой продукт интересен, какой следующий шаг нужен человеку, его предпочтения по формату помощи, готовность обсуждать покупку и причины отказа, если это уместно для нашей задачи.
3. Кастдев: ситуация на входе, основной запрос, предыдущие попытки, желаемое изменение и обратная связь о полученной пользе.
Для каждого поля укажи: что узнаем; зачем нам это; какое решение на основе этого примем; откуда получим данные — из действия, технического события или ответа; обязательно ли поле; как обозначаем отсутствие ответа.
Не превращай примерный список в обязательную анкету. Удали поля без понятного применения. Отдельно покажи, что собирается без вопросов, что должно появиться внутри сюжета, а что можно спросить только по желанию.
Добавь события, которые должен записывать бот, и формулы ключевых конверсий с понятными числителем и знаменателем. Раздели показ предложения, нажатие кнопки оплаты и подтвержденную оплату. Если событие нельзя достоверно наблюдать, не называй его измеренным.
Результат оформи как спецификацию 01_data_and_analytics.md. В конце перечисли решения, которые надо согласовать. Формулировки вопросов для игрока пока не пиши.Что получится: Первый основной артефакт: 01_data_and_analytics.md.
Основание в вебинаре: 00:46:14–00:46:52; 00:53:57–00:56:36; 01:02:57–01:11:57.
Оговорка: Структура трех групп — из вебинара; разделение клика и подтвержденной оплаты и проверка наблюдаемости — добавленные уточнения.
Проверить полезность собираемых данных
- когда брать
- Когда список данных уже составлен, но еще не встроен в игру.
- что подготовить
- Бриф и 01_data_and_analytics.md.
Оцени нашу спецификацию данных от 1 до 100 в двух ролях: маркетолог и руководитель отдела продаж. Это экспертная оценка проекта, а не прогноз конверсии.
Как маркетолог проверь: поймем ли мы, кто пришел, откуда пришел, на каком шаге остановился, получил ли результат и вернулся ли после напоминания? Сможем ли сравнить прохождение и покупки у разных сегментов и источников?
Как руководитель отдела продаж проверь: поможет ли собранное понять запрос клиента, подходящий продукт, предпочтительный формат помощи и препятствие перед следующим шагом? Какие сведения сотрудник сможет использовать в разговоре, а какие будут лишь догадкой?
Для каждого замечания укажи: чего не хватает или что лишнее; почему это важно; какое поле или событие нужно изменить. Не расширяй список ради полноты. Не делай вывод о реальной платежеспособности только по одному игровому выбору.
Отдельно проверь нагрузку на участника: что можно понять без вопроса, что оставить в сюжете, что убрать или сделать необязательным. Нам нужна игра с полезной обратной связью, а не длинное интервью.
Сначала выдай оценки с обоснованием и предложенные изменения. Не пиши формулировки вопросов для игрока. После моего согласования обнови 01_data_and_analytics.md и покажи, что именно изменилось.Что получится: Уточненный первый артефакт без лишних вопросов и пропущенных измерений.
Основание в вебинаре: 00:56:43–01:01:45; 01:04:34–01:07:48; 01:08:22–01:10:45.
Оговорка: Оценка в двух ролях — по вебинару. Ограничения интерпретации оценок и ответов добавлены для ясности.
Когда этап закончен
- у каждого поля есть решение, которое вы по нему примете;
- видно, что собирается без вопросов, что внутри сюжета, а что по желанию;
- есть список событий бота и формулы конверсий с понятными знаменателями;
- показ предложения, нажатие оплаты и подтверждённая оплата записаны отдельно;
- оценка в двух ролях пройдена, правки внесены, формулировок вопросов в документе нет.