Как собрать реалистичные тестовые данные для демо: генерация клиентов, задач и операций, маскирование, контроль утечек и короткий чеклист.
Реальные данные в демо и пресейле кажутся самым быстрым способом доказать, что продукт "живой". Но цена такой скорости часто слишком высокая: вы показываете не функциональность, а чужую приватную информацию. Даже если аудитория "своя", демо почти всегда выходит за пределы комнаты.
Главный риск - персональные данные (ПДн). ФИО, телефоны, email, адреса, паспортные поля, история обращений, даже комментарии менеджеров - все это может считаться ПДн. Второй слой - коммерческая тайна: цены, скидки, условия договоров, маржа, список ключевых клиентов, объемы закупок. Третий - репутация: один скрин с "не теми" цифрами или фамилиями может ударить сильнее любого бага.
Утечка в демо редко выглядит как "взлом". Обычно это бытовые каналы: скриншоты, запись созвона (у клиента, у подрядчика, в CRM звонков), демонстрация через проектор или общий экран в переговорке, гостевой доступ или тестовый аккаунт, который забыли отключить, экспорт данных (CSV/Excel) "чтобы потом посмотреть".
Если вам нужны правдоподобные данные для показа, лучше сразу исходить из того, что любой фрагмент демо может стать публичным.
Когда достаточно синтетики? Почти всегда, если цель - показать путь пользователя и основные сценарии: создание клиента, постановка задачи, проведение операции, отчет. Реальные данные нужны гораздо реже - обычно только для проверки крайних случаев (нетипичные форматы, редкие комбинации полей, сложная сегментация). И даже тогда правильнее использовать маскирование или агрегирование, а не прямую копию.
Простое правило: если данные могут кого-то идентифицировать или раскрыть условия работы с клиентом, им не место в демо.
Чтобы демо выглядело живым, нужен не "заполненный экран", а понятная история: кто клиент, что он просил, что вы сделали и чем это закончилось. Обычно хватает трех слоев: клиенты, задачи и операции, плюс несколько справочников.
Минимальный набор сущностей:
Убедительность дают не "много полей", а правильные поля. Для клиента важны сегмент, город или регион, дата создания, источник (сайт, рекомендация) и 1-2 реалистичных атрибута вроде "тариф" или "уровень риска". Для задачи - понятное название, статус (новая, в работе, завершена), срок и короткий комментарий. Для операции - дата и время, сумма или количество, валюта, результат (успех/отказ) и причина отказа, если она бывает в вашем продукте.
Не тяните в демо лишнее: паспортные данные, точные адреса, реальные телефоны, реквизиты, внутренние заметки и любые поля, которые можно случайно принять за настоящие.
Связность важнее объема: у одного клиента должно быть несколько задач, часть задач должна порождать операции, а статусы должны меняться логично. Например, задача "Согласовать счет" приводит к операции "Оплата", а затем к статусу "Закрыто".
По объему часто достаточно 30-80 клиентов, 100-300 задач и 300-1000 операций: этого хватает, чтобы поиск, фильтры, ленты событий и отчеты выглядели естественно.
Хороший демо-набор ощущается живым: в нем есть привычные форматы, ожидаемые перекосы и немного "грязи". Тогда зритель смотрит на продукт, а не на странные записи вроде "Клиент 1" и "1111111111".
Первое, что бросается в глаза, - формат полей. Имена, адреса, телефоны и реквизиты должны выглядеть правдоподобно, но не совпадать с реальными людьми и компаниями. Помогают маски и генераторы: телефон в формате +7 (9XX) XXX-XX-XX, адрес с улицей и домом, ИНН как корректная по длине строка. Важно, чтобы значения проходили ваши же проверки и маски в интерфейсе, иначе демо ломается на валидации.
Второй слой реализма - распределения. В реальности обычно много небольших клиентов и несколько крупных, которые дают основную выручку и больше операций. Если сделать всех одинаковыми, отчеты и фильтры выглядят неправдоподобно. То же касается задач: много типовых обращений и редкие "особые" кейсы.
Третий слой - время. Даты создания, активности и операций должны складываться в понятную историю: клиент зарегистрировался, через пару дней появилась первая задача, затем счета, оплаты, возвраты. Добавьте сезонность и ритм недели, чтобы графики не были ровной линией.
Наконец, реализм появляется из ошибок и исключений. Без них демо похоже на учебник: часть операций отменена, часть в статусе "в обработке"; есть возвраты, просрочки и недоплаты на копейки; встречаются пустые поля там, где их часто не заполняют; попадаются дубли (например, два похожих контакта); есть редкие, но важные статусы (блокировка, спор, ручная проверка).
Для демо почти всегда важнее показать поведение продукта, чем "настоящие" фамилии и суммы. Поэтому выбор метода начинается с вопроса: вам нужны отдельные строки (клиенты, заявки, операции) или достаточно общих цифр и графиков?
Самый безопасный вариант. Вы описываете правила (какие статусы бывают, какие суммы типичны, какие ошибки встречаются) и генерируете набор с нуля. Риски утечки персональных данных почти исчезают, а данные можно спокойно отдавать подрядчикам и использовать в видео.
Подходит только если у вас есть строгие правила и контроль: кто имеет доступ, где хранится копия, как удаляется. Маскирование часто кажется простым, но здесь больше всего сюрпризов: редкие значения могут "выдать" человека, а поля вроде комментариев, адресов доставки или "назначение платежа" почти всегда содержат куски реальности.
Если в демо важны отчеты, а не конкретные записи, используйте агрегаты: продажи по неделям, доля статусов, средний чек, топ-5 причин отказа. Так вы показываете динамику и логику продукта, не храня ни одной строки с клиентом.
На практике часто выигрывает гибрид: синтетика для массы данных и несколько вручную прописанных кейсов для сюжета. Например, "клиент оформляет заказ, затем делает возврат, и появляется спорная операция".
Чтобы выбрать подход быстро, ответьте себе на четыре вопроса: нужно ли в кадре открывать карточки клиентов и операций; есть ли право делать копию прод-данных; насколько важны редкие случаи (спорные платежи, частичные отгрузки); будете ли вы делиться демо-средой или записывать публичное видео.
Начните с инвентаризации полей и сразу разделите их по риску. Это убережет от случайного попадания ПДн в демо и сэкономит время на переделках.
Простая схема классификации: ПДн (ФИО, телефон, email, адрес), коммерческие (тариф, скидки, выручка, себестоимость), технические (ID, даты, версии, служебные флаги), публичные (город, отрасль, тип компании). Если сомневаетесь - относите поле к более чувствительной категории.
Дальше соберите словари и справочники, которые задают структуру: статусы задач, типы клиентов, категории операций, причины отмен, валюты, каналы продаж. Чем стабильнее эти списки, тем правдоподобнее выглядят экраны и фильтры.
Сформулируйте правила генерации до запуска: диапазоны сумм, обязательность полей, уникальность (например, уникальный номер договора) и зависимости (операция возможна только для активного клиента).
Дальше двигайтесь сверху вниз по связям:
Короткий пример: если клиент зарегистрирован вчера, не создавайте для него годовую историю операций. А если задача в статусе "Отменена", у нее не должно быть операции "Успешно завершена".
Когда набор готов, сохраните его как артефакт: файл экспорта, описание правил и дату.
Связность в демо-данных важнее объема. Даже небольшой набор выглядит убедительно, если сущности сцеплены и ведут себя как в жизни: один и тот же клиент встречается в задачах, сделках, счетах и операциях, а не существует в виде разрозненных строк.
Начните с простого правила: у каждой записи есть "родитель". Client_id повторяется в задачах и операциях, у задач есть понятные причины появления. Если создаете сделку, у нее должен быть источник (лид или входящий запрос), ответственное лицо и история статусов. Если есть оплата, перед ней логично появляются счет и согласование.
Хорошо работает схема "лид - контакт - задача - сделка - оплата". Например: новый лид пришел 3 дня назад, менеджер создал задачу "созвониться", после звонка сделка перешла в "КП отправлено", бухгалтер выставил счет, клиент оплатил частично, и появилась задача "дособрать документы". Временные метки должны идти по порядку, а статусы меняться без скачков.
Чтобы набор выглядел живым, добавьте роли и разные привычки работы. Один менеджер закрывает задачи быстро, другой держит хвост из просрочек. Руководитель видит сводку и комментарии к рискам, бухгалтер работает со счетами и актами.
Комментарии и описания часто выдают реальные данные. Пишите их как шаблонные, но человеческие: без фамилий, телефонов, адресов и цитат из переписок. Лучше короткие нейтральные формулировки: "Уточнить реквизиты", "Клиент просит перенос срока", "Ждем подтверждение оплаты".
Быстрый контроль связности:
Для демо почти всегда хочется "живых" деталей. Но реальная база клиентов, заявки и платежи быстро превращаются в риск: утечки, скриншоты, выгрузки, случайная отправка файла не тому адресату. Базовое правило простое: показывайте только то, без чего демо не работает.
Правило минимизации помогает отрезать лишнее. Если для сценария важны статусы, суммы, сроки и связность сущностей, то ФИО, телефон, адрес, паспортные данные и реальный e-mail не нужны. Используйте вымышленные значения и нейтральные домены, а поля, которые не участвуют в показе, скрывайте в демо-аккаунте.
Отдельная демо-среда и отдельные учетные записи обязательны. Не проводите показ в той же среде, где работают сотрудники, и не используйте "временные" логины на продакшене.
Даже идеальная синтетика ломается из-за человеческого фактора. Зафиксируйте короткую процедуру и повторяйте ее:
Частая ловушка: вы показываете чистый интерфейс, но в логах, выгрузках или автозаполнении остаются реальные значения. Контролируйте, что попадает в экспорт, что хранится в логах, какие поля выводятся в уведомлениях и на экране "история действий".
Простой пример: в демо CRM можно оставить реалистичные суммы и статусы сделок, но заменить все контакты на "+7 900 000-00-00" и "client123@example.test", а экспорт по умолчанию ограничить колонками без идентификаторов человека.
Самая частая проблема - "случайные хвосты" от продакшена. Кажется, что вы все обезличили, но в интерфейсе всплывают реальные номера договоров, счета, ИНН, внутренние ID или примечания менеджеров. Для зрителя это выглядит как утечка, даже если вы уверены, что "ничего страшного".
Вторая ловушка - копирование прод-базы "для скорости". Обычно забывают про вложения: сканы документов, фото, файлы из задач, аудио, комментарии в карточках и историю изменений. Эти данные часто не проходят маскирование, потому что лежат отдельно от таблиц.
Еще одна ошибка - слишком "идеальные" данные. Если все клиенты идеальны, все оплаты вовремя, нет возвратов, дублей, опечаток и спорных статусов, демо выглядит постановочно. А на вопрос "что бывает, если платеж не прошел?" отвечать нечем.
Отдельный класс проблем - сломанная связность. Операции без привязки к клиенту, задачи без ответственного, сделки без этапа, транзакции без валюты или даты. Это ломает сценарий прямо во время показа: фильтры пустые, отчеты не сходятся, карточки открываются с ошибками.
Перед записью видео или созвоном проверьте пять точек: нет ли форматов, похожих на реальные (ИНН, паспорта, телефоны, номера счетов и договоров); не подтянулись ли вложения и комментарии из боевой среды; есть ли "неудобные" кейсы (отмены, возвраты, просрочки, дубли, пустые поля); кликабельна ли цепочка "клиент -> задача -> операция"; настроены ли роли и права так, чтобы на экране не показывалось лишнее.
Перед демо полезно сделать один быстрый прогон и относиться к нему как к проверке безопасности и качества одновременно.
Пройдитесь по приложению глазами зрителя: откройте карточки, таблицы, фильтры, поиск, детали операции, экспорт, печатные формы. Затем сделайте точечные проверки:
Представьте отдел продаж, который ведет три типа клиентов: новые лиды (малый бизнес), клиенты на согласовании (средний бизнес) и действующие аккаунты (крупные компании). По каждому контакту менеджеры ставят задачи, а по договорам фиксируют оплаты и возвраты. Такой сюжет легко показать за 5 минут, и он понятен почти любому зрителю.
Для правдоподобия возьмите небольшой, но насыщенный набор: около 200 клиентов, 600 задач и примерно 1500 операций за последние 6 месяцев. Даты должны совпадать: задачи идут до выставления счета, платежи идут после, возвраты не появляются раньше оплаты.
Добавьте пару кейсов, которые часто спрашивают на демо. Например, один клиент оплатил счет частично и потом доплатил через неделю. Другой ушел в просрочку на 14 дней, и менеджер получил напоминание. Третий оплатил, а потом оформил возврат на 20% из-за уменьшения объема.
Заполните данными ключевые экраны: список клиентов (с сегментами и статусами), карточку клиента (контакты, история задач, счета), список операций (оплаты и возвраты), отчет за период (выручка, дебиторка), а также фильтры по дате, менеджеру, статусу и типу операции.
Короткий сценарий показа:
Один удачный набор быстро устаревает: меняются фичи, тексты в интерфейсе, логика статусов, отчеты. Поэтому цель - не "один раз сделать данные", а наладить процесс, чтобы набор можно было пересобрать за час и получить тот же уровень правдоподобия.
Начните с шаблона: какие сущности есть и как они связаны, какие статусы и жизненный цикл, какие типовые задачи и операции, какие распределения (например, 70% мелких операций, 25% средних, 5% крупных). Дальше зафиксируйте ритм пересборки: перед важными демо, записью видео и заметными релизами.
Чтобы это не превратилось в ручную боль, договоритесь о простом регламенте: где лежит шаблон и генераторы (или промпты), когда пересобираете набор, кто утверждает результат и кто проверяет безопасность, где хранятся версии и кто может их публиковать.
Версионирование важно не меньше генерации. Держите несколько "золотых" выпусков демо-данных, чтобы быстро откатиться, если в новой версии всплыли странные фамилии, слишком ровные суммы или сломались связи.
Назначьте владельца демо-данных как роль, а не "самого свободного человека". Он следит за обновлениями, ведет журнал изменений и проверяет, что в наборе нет реальных персональных данных и следов продакшена.
Если вы делаете демо-приложение через TakProsto (takprosto.ai), удобно описывать правила набора в режиме планирования, а затем фиксировать удачное состояние снапшотом и быстро откатываться перед каждым показом. Это помогает держать демо стабильным и не возвращаться к идее "подлить настоящую базу" ради скорости.
Потому что в демо очень легко устроить утечку без всякого «взлома»: скриншот, запись созвона, экспорт в Excel, общий экран. Даже если вы показываете «своим», материал почти всегда может уйти дальше. Цена ошибки — претензии по ПДн, раскрытие коммерческой тайны и репутационный удар.
Если данные позволяют идентифицировать человека или раскрывают условия работы с клиентом, их лучше не показывать. Под риск обычно попадают ФИО, телефоны, почты, адреса, комментарии менеджеров, а также цены, скидки, маржа, список ключевых клиентов. Безопаснее исходить из правила: любой фрагмент демо может стать публичным.
Чаще всего достаточно синтетики, если вы показываете путь пользователя и ключевые сценарии: создание клиента, постановку задачи, проведение операции, отчет. Реальные данные обычно нужны только для редких крайних случаев, где важны сложные форматы и комбинации полей. Даже тогда лучше маскировать или агрегировать, чем копировать «как есть».
Минимально нужны клиенты, задачи и операции, плюс несколько справочников статусов и типов, чтобы интерфейс и фильтры выглядели живыми. Для правдоподобия важнее связность: у клиента есть несколько задач, задачи приводят к операциям, статусы меняются логично. Лишние чувствительные поля лучше вообще не добавлять, чтобы их случайно не вывести на экран.
Дайте данным привычные форматы и распределения: телефоны и даты выглядят корректно, суммы проходят валидации, а в отчетах есть перекос «много мелких, мало крупных». Добавьте реалистичное время: история не должна начинаться «вчера» и сразу содержать год операций. И обязательно оставьте немного «грязи» — отмены, просрочки, пустые поля и редкие статусы, иначе демо выглядит постановочно.
Синтетика безопаснее всего и обычно быстрее в поддержке: можно спокойно записывать видео и делиться средой. Маскирование копии прод-данных рискованнее, потому что редкие значения, комментарии и вложения часто выдают реальность. Агрегирование подходит, когда важны отчеты и динамика, а не карточки конкретных клиентов: вы показываете цифры без строк с людьми.
Начните с инвентаризации полей и разделите их по риску, чтобы не тащить в демо лишнее. Затем зафиксируйте правила генерации: обязательность, уникальность, диапазоны, зависимости между сущностями. Генерируйте сверху вниз по связям и после этого проверьте статистику и логичность дат, а также «заморозьте» версию набора, чтобы его можно было повторить.
Сделайте так, чтобы у каждой записи был «родитель»: задачи и операции привязаны к одному и тому же клиенту, а события идут по времени без скачков. В сценариях должно быть объяснение причин: счет появляется после согласования, возврат — после оплаты, спор — после проблемной операции. Если связность ломается, на демо это проявится пустыми фильтрами, странными отчетами и ошибками в карточках.
Используйте отдельную демо-среду и отдельные учетные записи, а не «временные» логины в рабочей системе. Скрывайте поля, которые не нужны для показа, и ограничивайте экспорт так, чтобы он не содержал идентификаторов человека. Перед записью проверьте не только экраны, но и «хвосты»: логи, уведомления, автозаполнение, комментарии и вложения.
Опишите правила данных в режиме планирования, чтобы заранее зафиксировать сущности, статусы, распределения и крайние случаи, которые вы хотите показать. Затем сохраните удачное состояние снапшотом и откатывайтесь перед каждым показом, чтобы демо было стабильным. Если нужно обновить набор под новые фичи, пересобирайте его по тем же правилам, не «подливая» реальную базу ради скорости.
