Онбординг — быстрый старт с реальными данными
Как убрать миграцию из первого запуска и дать рабочий аккаунт за пару действий
Команда
Product Designer (я), Product Manager, Front‑End, Back‑End, QA
Результат
+70% новых пользователей начали создавать сущности в системе
+25% удержание на второй неделе
0,5–3 ч вместо недель — время миграции в систему
+25% удержание на второй неделе
0,5–3 ч вместо недель — время миграции в систему
Контекст
Пользователь попадал в пустую систему
До этого основным продуктом учёта был МойСклад, а Connect связывал его с маркетплейсами. Новая система переносила учёт непосредственно в Hub
К моменту первого публичного релиза основные сущности и логика уже были готовы, но пользователь открывал Hub без своих данных: товары, остатки, заказы, возвраты, платежи, документы — всё нужно было перенести самому
Барьер первого запуска
01
Путь: настроить Connect → связать с Hub → перенести данные → дополнить вручную → проверить результат → начать работу
02
По данным поддержки, перенос клиентов мог занимать 2–4 недели
03
Старая система уже работала, а чтобы просто попробовать Hub, нужно было сначала перенести бизне
Основная задача
Упростить миграцию пользователей в систему для повышения вовлеченности в продукт
Проблема была раньше, чем казалось
Изначально задача включала в себя проектирование первого пути в системе и внедрения системы обучения в продукте (по аналогии с онбордингом МойСклад)
Однако, в начале задачи я изучил причины, почему конверсия в подписку показывала низкие значения. Анализ первых действий новых пользователей показал: большинство зарегистрировавшихся не импортировали даже товары. Открывали пустой Hub и уходили.
Задача изменилась
Сократить путь от регистрации до первого рабочего состояния
Как исследование повлияло на гипотезы
Гипотеза
Научить пользователя: контекстные подсказки по образцу МойСклад, шаг за шагом
Ограничения гипотезы
Подсказки объясняют, как настроить систему, но саму настройку не убирают. Пользователь всё равно тратит время на перенос данных
Финальная гипотеза
Вопрос сместился с «как научить» на «что можно сделать за пользователя». У Connect уже была инфраструктура для данных маркетплейсов — её можно использовать как точку автоматического переноса, через один API-ключ
3 варианта: как запустить перенос данных
Вручную
Проще для инфраструктуры
Почти не сокращает работу пользователя
Полная автоматическая миграция
Минимум работы для пользователя
Крупные клиенты переносят десятки тысяч товаров разом — растёт нагрузка на серверы
Импорт 1 маркетплейса
Пользователь сразу получает реальные данные
Первый перенос дешевле для инфраструктуры
Остальные источники — подскажет онбординг
Почему это было верно
Компромисс между скоростью запуска, стоимостью переноса и нагрузкой на систему
Решение #1
Один API-ключ вместо сложной настройки
Пользователь получает подсказку, где найти ключ маркетплейса, вводит его в Hub — и перенос запускается автоматически
Connect переносит товары, заказы, возвраты, остатки, платежи и другие данные
Моя зона — концепция и пользовательский сценарий, от ввода ключа до работы с данными. Техническую реализацию делала команда Connect
Решение #2
Автоматизация не должна была быть обязательной
На фокус-группе часть пользователей сказала, что хочет сама определить, как организовать учёт. Аргумент: «Никто не знает лучше, как мне оцифровать свой бизнес»
Быстрый старт: ключ → автоматический перенос → работа с готовыми данными. Самостоятельная настройка: настройка с нуля → подсказки → импорт данных позже
Решение #3
Перенос не должен был останавливать пользователя
Импорт запускался в фоне: пока Connect обрабатывал данные, пользователь знакомился с Hub через контекстные подсказки.
На экране видно состояние переноса: сколько товаров и документов перенесено, текущий статус, результат после завершения
Решение #4
Предложение импорта для тех, кто начал не с автоматического импорта
Появляется, если пользователь выбрал тестовые данные или старт с нуля
Также автоматический перенос не блокирует остальные действия. Ручная настройка остаётся доступной
Ограничения
Нагрузка на инфраструктуру
Полный перенос всего бизнеса рассматривали, но отказались: крупные клиенты переносили бы десятки тысяч товаров одновременно, и это увеличило бы нагрузку на серверы
Проверка и итерация
Проверили
Кликабельный прототип внутри команд Hub и Connect, несколько раз
Нашли
Лишний этап для отдела продаж оказался не нужен для старта работы — убрали
Нашли
Уведомления не совпадали с реальными статусами API Connect — переработали
Нашли
На интервью появился запрос на настройку с нуля — добавили второй путь запуска
Результат
+70% начали создавать сущности после регистрации
Основной сигнал, что пользователь реально начал работать, а не ушёл из пустого аккаунта
+25% — удержание на второй неделе
Сравнение с периодом до релиза, первые 4 недели
Ограничение интерпретации
A/B-теста не было, параллельно выходили хотфиксы внутри продукта — весь эффект удержания приписывать онбордингу некорректно
0,5–3 ч — вместо 2–4 недель
Время по журналам Connect против данных поддержки о старой миграции
Ограничение интерпретации
Это разные источники и методы измерения. Значения показывают масштаб изменения, а не результат эксперимента
Что сделал бы иначе
Первый запуск как вход в экосистему
Вокруг EPR-системы строилась экосистема микросервисов. Например, товары появились в Hub → их можно продвигать через Ads → данные между сервисами синхронизируются автоматически
Больше контроля над переносом
Выбор источника данных, объёма и состава переноса для первого запуска. От полного переноса отказались раньше — из-за нагрузки на инфраструктуру
+7(927)623-11-14
t.me/balladdesign
balladdesign@gmail.com
