CRM-аналитика
Как назначить сроки хранения событий, если маркетингу «может понадобиться всё»
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
События просмотров, открытия писем и история изменения профиля накапливаются годами. На вопрос о сроке хранения команда отвечает: «Вдруг понадобится модель». Но неограниченная история увеличивает стоимость инфраструктуры, затрудняет исполнение запросов клиентов и не обязательно делает решения точнее.
Срок хранения — период, в течение которого конкретные данные сохраняют обоснованное назначение. Он не равен горизонту одного отчёта: данные могут использоваться для нескольких задач с разными основаниями. Поэтому назначать один срок всем CRM-событиям так же неудобно, как хранить всё бессрочно.
Начните с решений, для которых нужна история
Составьте список действующих сценариев и анализов. Напоминанию о незавершённой покупке может требоваться короткая история действий; оценке сезонных повторных покупок — несколько сопоставимых циклов; расследованию разрешений — собственный режим хранения доказательств.
Статья 5 российского 152-ФЗ связывает обработку с заранее определёнными целями и ограничивает хранение сроком, необходимым для этих целей, если иной срок не предусмотрен применимым основанием. Избыточный состав данных также противоречит этому принципу.
Практическая задача команды — для каждой категории объяснить, какое решение перестанет работать при её удалении. Ответ «аналитика вообще» слишком широк: он не позволяет выбрать ни поля, ни детализацию, ни срок.
Разделите сырые события и производные показатели
Сырое событие — отдельная запись о действии: кто, когда и что сделал. Производный показатель — рассчитанный результат, например число покупок за год. Для текущего сценария часто нужен второй, а подробная последовательность действий используется только при разборе ошибки.
Но агрегирование не равно обезличиванию. Годовая сумма покупок в профиле конкретного клиента остаётся связанной с человеком. Настоящий обезличенный итог по большой группе и индивидуальный признак требуют разного обращения; это нужно отражать в реестре.
| Категория | Для чего нужна | Вопрос перед выбором срока |
|---|---|---|
| События просмотра | Краткосрочный интерес и проверка сценария | Как быстро сигнал теряет пользу? |
| Заказы и возвраты | Экономика и обслуживание | Какие обязанности и циклы анализа действуют? |
| Технические журналы | Расследование и восстановление | За какой период реально обнаруживаются ошибки? |
| История разрешений | Восстановление основания контакта | Какие подтверждения и сроки требуются? |
| Агрегаты по группам | Долгосрочная аналитика | Сохраняется ли возможность определить человека? |
Условный пример: сколько стоит лишняя детализация
Предположим, система получает 10 млн событий в месяц. Средний размер одной записи после измерения составляет 0,5 КБ. Это около 5 ГБ исходных данных в месяц или 120 ГБ за два года при десятичном пересчёте. Это учебный расчёт, без индексов, копий, служебных данных и стоимости запросов.
Если сценариям достаточно трёх месяцев подробной истории, в оперативном контуре остаётся около 15 ГБ таких записей. Однако разница в 105 ГБ ещё не равна денежной экономии: тариф может зависеть от числа событий, профилей, операций или минимального оплачиваемого объёма.
Полную стоимость платформы рассчитывают по договору и фактическим счётчикам. Сначала проверьте, какой расход уменьшит политика хранения, а затем оценивайте финансовый эффект. Иначе красивое сокращение таблицы не изменит счёт поставщика.
Проверьте, не ломаете ли вы расчёт
Перед сокращением срока сохраните определения ключевых показателей и воспроизведите их на двух наборах данных. Изменение «покупал когда-либо» на «покупал за последние 90 дней» должно быть явным бизнес-решением, а не скрытым следствием очистки истории.
Обратите внимание на окна наблюдения. Если клиент пришёл раньше доступной истории, отсутствие покупки в таблице не доказывает, что он никогда не покупал. Для таких профилей полезен признак полноты истории. Иначе сегментация начнёт считать старых покупателей новыми.
Срок хранения интересов клиента также не должен превращаться в срок их безусловной актуальности. Можно хранить событие для объяснения модели и одновременно снижать его вес в персонализации по мере старения.
Опишите удаление как регулярную операцию
Для каждой категории нужны владелец, основание, срок, точка отсчёта, зависимые расчёты и действие по окончании. Точка отсчёта особенно важна: дата события, прекращение договора и закрытие обращения дают разные результаты.
Проверьте удаление во всех производных витринах и экспортных копиях. Если задача очистки упала, мониторинг должен показать просроченный объём, а не только состояние ежедневного запуска. Архив с неограниченным доступом маркетолога не решает проблему избыточного хранения.
Исключения оформляйте с причиной и датой пересмотра. Нельзя автоматически продлевать всю историю из-за одного спорного заказа. Если необходимо сохранить конкретные данные для законной цели, выделите именно их и ограничьте дальнейшее использование.
Как принять политику хранения
Попросите владельца сценария показать расчёт на сокращённой истории, инженера — фактическое удаление, а ответственного за данные — обоснование сроков. Затем проверьте восстановление из резервной копии: истёкшие ограничения должны применяться до возврата системы в работу.
Рабочая политика не обещает хранить как можно меньше любой ценой. Она объясняет, какие данные нужны, сколько времени, кому и для какого действия. Это делает рост CRM предсказуемым и с точки зрения затрат, и с точки зрения управляемости.
Источники
Российская Федерация. Федеральный закон от 27.07.2006 № 152-ФЗ, статья 5. Действующая редакция; текст нормы в СПС «КонсультантПлюс». Проверено 22.09.2026.