Владелец интернет-магазина кофе в Алматы смотрит демонстрацию новой платформы аналитики. На экране выручка, воронка и кнопка запуска теста. А у него вопрос попроще: где в этом отчёте оплаченный заказ O42 на 15 000 ₸ и какой вариант страницы видел покупатель? Менеджер платформы предлагает сначала оплатить подписку, а интеграцию обсудить потом.
С этого заказа выбор и начните. Магазин и O42 вы уже видели, когда передавали оплаченную покупку с сервера. Цифры сравнения дальше условные. Вы пройдёте путь покупки на тестовых записях и посчитаете, во что обойдётся поддерживать две разные связки.
Запишите задачу до встречи с поставщиком
Магазин хочет сравнить два варианта оформления заказа. Каждый подходящий посетитель получает свой вариант до покупки и остаётся с ним по правилам эксперимента. Вам как аналитику нужен результат по всем, кому назначили вариант, включая тех, кто ничего не купил. Список оплат даст числитель конверсии, а знаменатель по нему не восстановить.
Требование к инструменту укладывается в одну фразу: «По участнику и эксперименту восстановить назначенный вариант, факт показа, последующие заказы и оплаты в выбранном окне». Допишите к ней, кто владеет данными и как их выгрузить. С такой фразой вы приходите на демонстрацию со своей задачей, и менеджеру придётся показать её решение вместо обзора всех функций.
Связь записей в тесте
Оформление заказа
Вариант Б
- Запись оплаты
- O42, 15 000 ₸, KZT
Строка результата
- Заказ
O42
- Вариант
Б
- Оплата
Учтена
ID участника нужен отдельно. Для сравнения групп нужны все назначенные участники, включая не купивших.
Проведите O42 от назначения до отчёта
Order ID - это номер заказа. Для участника нужен свой ID: у человека бывает несколько заказов, а у назначенного участника может не быть ни одного. Если сохранить только O42 и метку «Б», группы не сравнить, потому что тех, кто не купил, в данных просто нет.
В тестовой среде команда проходит такую цепочку:
| Шаг | Что должно остаться в данных |
|---|---|
| Участник получил вариант | ID участника, ID эксперимента, вариант и время назначения |
| Страница с вариантом показана | Запись воздействия по заранее выбранному правилу |
| Создан заказ O42 | Связь заказа с участником и нужным экспериментом |
| Подтверждена оплата | O42, сумма 15 000 ₸, валюта KZT и время оплаты |
| Данные дошли до аналитики | Время получения и одна учтённая оплата |
| Получен возврат | Отдельная операция и изменение результата по правилу метрики |
Назначение и показ иногда разнесены во времени. Кого брать в основной расчёт, решают в плане заранее. Оставить в нём только покупателей или только тех, кто дошёл до удобного шага, значит подогнать группы под результат.
Чтобы проверить передачу, отправьте запись об оплате ещё раз. По O42 должно остаться 15 000 ₸, хотя в журнале доставки две попытки. Контакт, сделка и платёж связываются разными ключами: по контакту покупателя номер его покупки не найти.
Тестовые записи помечайте и держите в стороне от рабочих. Иначе во время приёмки они попадут в финансовый отчёт или уйдут в рекламный кабинет как настоящие конверсии. Один прошедший заказ подтверждает только обычный путь, сбои и остальные варианты ещё впереди.
У каждой части связки своя работа
В маленьком проекте часть задач закроют таблица, CRM и небольшой обработчик. Когда источников больше, могут понадобиться хранилище и система экспериментов. Размер компании мало что подскажет, пока у вас нет списка задач.
| Работа | Что просить показать |
|---|---|
| События и поведение | Исходные записи, сегмент и нужную единицу анализа |
| Продажи | Заказ, подтверждённый платёж и историю исправлений |
| Распределение вариантов | Стабильное назначение и журнал воздействия |
| Обмен между системами | Повторы, задержки, ошибки и восстановление |
| Сообщения | Отписку, исключение после заказа и ограничение частоты |
| Отчёт | Определения метрик и расчёт, который можно повторить |
Один продукт может закрыть несколько строк. Но у каждой строки есть человек, который за неё отвечает: продавец аналитики не станет владельцем статуса оплаты в вашей CRM.
Переключатель функции (feature flag) умеет включить вариант. Но чтобы по сравнению можно было сказать, что сработал именно вариант, к нему нужны правильное распределение, единица эксперимента, метрики и план анализа. Если в понедельник страница одна, а в пятницу другая, эффект варианта смешается со всем, что ещё поменялось за неделю.
Документация GrowthBook о результатах эксперимента описывает проверки баланса групп и других проблем с данными. На демонстрации попросите показать предупреждение на нарочно испорченной выгрузке. Так вы узнаете, какие проверки работают в предложенной конфигурации и какие данные придётся подключать самим. Если оплат в системе нет, название платформы их не добавит.
Приёмка продолжается на сбоях
После обычного пути начинайте ломать: отключите тестовый получатель, задержите оплату, поменяйте порядок, в котором приходят записи. В протокол пишите, что получилось, как это заметили и что сделал ответственный.
У O42 два времени: когда покупатель заплатил и когда сведения дошли до отчёта. Если оплата пришла в аналитику с опозданием, покупка не должна тихо переехать в другой период. Часовой пояс и окно расчёта входят в определение метрики.
Смену устройства проверяйте так, как поставщик обещает узнавать одного человека на разных устройствах. Если платформа не связывает анонимный телефон с ноутбуком, так и напишите в описании результата. Склеивать записи по похожему имени, чтобы таблица сошлась, нельзя: так в одного покупателя сливаются разные люди.
Для сообщений нужен свой тест: человек отозвал согласие, уже заказал или превысил лимит частоты. Система должна пропустить отправку и записать причину. Проверка актуального состояния перед отправкой входит в приёмку всей связки.
Получите данные, с которыми можно уйти
Попросите выгрузку небольшого набора: участники, назначения, доступные события, заказы и определения метрик. По ней другой специалист должен получить то же число участников и оплат. Скриншот с итоговой конверсией для этого не годится.
До покупки выясните, есть ли нужные поля и история, какие права и ограничения API, как выгрузить данные после окончания подписки. Точные условия берите из коммерческого предложения и документации выбранного тарифа. Выгрузка списка контактов не переносит историю экспериментов, про неё спросите прямо.
Записи сессий тоже проходят приёмку. Введите тестовый текст в закрытые поля и убедитесь, что в записи его не видно. Проверьте, что права доступа работают, а срок хранения и удаление настроены. Настоящие пароли и платёжные данные для этого не вводите. Проверяйте ту конфигурацию, которую выбрали, и повторите проверку, когда после обновления в форме появятся новые поля.
Подписка и рабочее время в одной смете
В нашем сравнении первая связка стоит 30 000 ₸ в месяц за сервисы и требует 20 часов сопровождения. Вторая стоит 90 000 ₸ и требует четыре часа. Час работы команда для этой сметы оценивает в 5 000 ₸. Это расчёт проекта, к тарифам каких-либо сервисов он не привязан.
| Расход | Первая связка | Вторая связка |
|---|---|---|
| Сервисы за месяц | 30 000 ₸ | 90 000 ₸ |
| Сопровождение | 20 × 5 000 = 100 000 ₸ | 4 × 5 000 = 20 000 ₸ |
| Итого за месяц | 130 000 ₸ | 110 000 ₸ |
| Разовое внедрение | 60 000 ₸ | 180 000 ₸ |
| Внедрение и шесть месяцев работы | 840 000 ₸ | 840 000 ₸ |
Каждый месяц вторая связка обходится на 20 000 ₸ дешевле, зато внедрение у неё дороже на 120 000 ₸. При этих условиях разница окупается за шесть месяцев. Если проект закончится раньше, этот довод в пользу второй связки исчезает.
В обе оценки включите обучение, перенос данных, хранение, поддержку и будущий уход из системы. Уточните, что уже посчитано, иначе одну и ту же работу легко сложить дважды. Когда нагрузка растёт, пересчитывайте ту единицу, за которую платите: события, контакты, сообщения или вычисления. Часы сопровождения измерьте на пилоте: обещание продавца замером не считается.
Задание: выбор после пилота
Составьте для своего клиента таблицу задач и проведите один заказ через обе связки. Сохраните подтверждения так, чтобы их мог перепроверить другой специалист.
Выполнено 0 из 6
Допустим, пилот показал, что первой связке хватает 12 часов в месяц. Тогда она стоит 30 000 + 12 × 5 000 = 90 000 ₸. Вторая по-прежнему обходится в 110 000 ₸ и дороже во внедрении. Если обе одинаково выполняют требования, экономия труда, на которой держался прежний расчёт, пропала. Чтобы всё-таки купить вторую, нужна другая причина, и её тоже надо подтвердить.
А если ни одна связка не смогла соединить участника с O42, выбор панели подождёт, пока не исправят данные. Клиенту больше пользы от найденного разрыва и сметы на его устранение, чем от нового интерфейса со старой ошибкой.
Что открыть при подготовке выбора
Принципы, процесс и тактики Брайана Бэлфура помогают описать работу до выбора инструмента. На встречу с поставщиком возьмите свой сценарий O42, требования к выгрузке и смету: по ним вы примете или отклоните предложение.