Рекомендации по работе с сегментами

Сегменты — ключевой инструмент работы с данными в CDP-платформе. От их корректной настройки зависит качество выборок, аналитики и запуска маркетинговых рассылок.

Сегментация — один из самых ресурсоёмких процессов в платформе. Не все сегменты будут работать быстро, и во многом это зависит от того, как они спроектированы: какие условия используются, какие поля задействованы, как настроены внешние источники данных.

В этой статье собраны рекомендации по построению эффективных сегментов — от выбора типа сегмента до настройки индексов и внешних запросов.

Типы сегментов и скорость расчёта

Разные типы сегментов по-разному влияют на производительность:

• Статические сегменты — рассчитываются один раз при создании или ручном обновлении. После расчёта список профилей фиксирован, и последующее использование сегмента не требует пересчёта.
• Динамические сегменты — пересчитываются каждый раз при использовании (запуске рассылки, кампании и т.д.). Сложные динамические сегменты могут замедлять запуск рассылок.
• Обновляемые сегменты — пересчитываются по расписанию. Нагрузка распределяется во времени, но при большом количестве обновляемых сегментов с частым расписанием общая нагрузка может быть значительной.

Сегментация по событиям (история профиля)

При сегментации по событиям — открытиям писем, кликам, достижениям целей, переходам по ссылкам — платформа сканирует историю действий каждого профиля.

Обязательно указывайте период дат. Без ограничения по дате система будет проверять всю историю профиля, что значительно замедляет расчёт.

Чем больше период, тем дольше будет считаться сегмент:

• Сегмент "открыл письмо за последние 7 дней" — рассчитается быстро.
• Сегмент "открыл письмо за последний год" — потребует значительно больше времени.
• Сегмент "открыл письмо" без ограничения по дате — будет сканировать всю историю, что может занять очень много времени.

Рекомендации:

• Всегда ограничивайте диапазон дат. По возможности используйте относительные периоды ("последние N дней").
• Для регулярных сегментов обычно достаточно диапазона 30–90 дней.
• Вместо проверки событий за всё время используйте атрибуты профиля, которые не требуют сканирования истории. Например, "дата последнего заказа" вместо "был хотя бы один заказ".

Сегментация по данным профиля

Индексы и пользовательские поля

Индексы — это внутренние структуры базы данных, которые ускоряют поиск профилей по значениям полей. Без индекса система вынуждена перебирать все профили последовательно — сегмент строится медленно, особенно на больших базах.

Часть индексов создаётся автоматически при запуске платформы. Это системные индексы, необходимые для работы платформы — управлять ими пользователь не может.

Для быстрой сегментации по пользовательским полям обязательно создавайте индекс по этому полю в базе данных. На больших базах отсутствие индекса может увеличить время расчёта сегмента в разы.

предупреждение

Всего на аккаунт можно создать не более 64 индексов. Подробнее про индексы баз данных — в документации администратора.

Рекомендации:

• Проанализируйте, по каким полям вы чаще всего строите сегменты.
• Передайте список этих полей администратору для создания индексов.
• Учитывайте лимит в 64 индекса и приоритизируйте наиболее важные поля.

Составные индексы для больших баз

Для баз данных, содержащих от миллиона профилей и более, производительность сегментации зависит от сложности условий и наличия индексов ещё сильнее.

В MongoDB поддерживаются составные индексы, которые позволяют ускорить сегментацию по нескольким полям одновременно. Например, если вы часто строите сегменты по комбинации "город + статус клиента", составной индекс по этим двум полям значительно ускорит расчёт.

предупреждение

Количество индексов на одной базе профилей ограничено лимитами MongoDB. Перед созданием составных индексов необходимо оценить, какие комбинации полей используются чаще всего, и приоритизировать их. Каждый дополнительный индекс увеличивает время записи и обновления данных в базе.

Хранение списков значений

Если в сегменте нужно отобрать профили по конкретному значению из списка (например, интересы, категории, метки), такие списки стоит хранить в поле типа "теги", а не в строке.

Например, поле interests содержит tennis, football, chess. Если требуется выбрать всех, кому интересен теннис, при хранении в строке процесс сегментации займёт больше времени, чем при хранении в поле типа "теги".

Сегментация по внешним данным

Сегментация по внешним источникам (SQL-запросы, API, файлы) имеет свои особенности производительности. Подробные рекомендации — в отдельной статье:

Рекомендации по сегментации по внешним данным

Основные тезисы:

• Проектируйте запросы так, чтобы они возвращали минимум данных.
• Объединяйте условия из одной внешней базы в один SQL-запрос.
• Условия с "НЕ" по внешним данным приводят к сканированию всей базы профилей — сводите их количество к минимуму.
• Платформа может автоматически объединять запросы к одной внешней базе в единый SQL-запрос (через пересечение и объединение результатов), но только если запросы обращаются к одному коннектору и привязаны к одному и тому же полю профиля.

Оператор "НЕ"

Слишком большое количество условий с "НЕ"

Чрезмерное использование отрицаний, особенно оператора НЕ В СЕГМЕНТЕ, сильно усложняет логику и снижает производительность.

Оператор "НЕ В СЕГМЕНТЕ".
Это самый тяжёлый с точки зрения производительности оператор. При его использовании система выгружает всю базу профилей, чтобы выполнить пересечение с исключаемым сегментом. Это очень долго.

Пример проблемной конструкции:

НЕ В (сегмент A)
И НЕ В (сегмент B)
И НЕ В (сегмент C)
...

Рекомендации:

• По возможности избегайте оператора "НЕ В СЕГМЕНТЕ". Вместо него продублируйте условия из исключаемого сегмента, но с обратным знаком.

Например, нужно отобрать профили, которые не входят в сегмент "Не состоит в ГКГ". Вместо НЕ СОСТОИТ (сегмент "Не состоит в ГКГ") используйте условие Состоит в ГКГ. Результат будет тот же, а производительность — выше.

• Не используйте более 2–3 условий с "НЕ" (любых) подряд без веской причины.
• Заменяйте набор условий с "НЕ" на одно позитивное правило. Вместо перечисления, где объект не должен находиться, лучше описать, где он должен находиться.
• Документируйте правила сегментации: указывайте, зачем добавлено каждое отрицание. Это поможет избежать ситуации, когда одно из условий становится неактуальным, а логика остаётся избыточно сложной.
• Применяйте "НЕ В СЕГМЕНТЕ" только тогда, когда без него действительно не обойтись (например, исключаемый сегмент динамически обновляется другой командой).

Использование условия с "НЕ" через "ИЛИ"

Часто при построении сегмента задаётся условие вида:

НЕ (имеет активный договор) ИЛИ НЕ (прошёл верификацию)

На первый взгляд может показаться, что такое условие исключит всех клиентов без договора и без верификации. На практике оно работает иначе: в сегмент попадут все клиенты, кроме тех, у кого одновременно есть и активный договор, и пройдена верификация.

Это значит, что условие исключает только тех, у кого оба признака выполняются одновременно, а не всех, кто обладает хотя бы одним из признаков.

Рекомендации:

• Избегайте длинных выражений с чередованием НЕ и ИЛИ.
• Если требуется отобрать только клиентов, у которых нет договора и нет верификации, используйте:

НЕ (имеет активный договор) И НЕ (прошёл верификацию)