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

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

Минимизация объёма данных

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

Основные правила:

• Возвращайте только колонку с идентификатором профиля, по которому происходит поиск. Дополнительные колонки не нужны и только увеличивают объём передаваемых данных.
• По возможности добавляйте фильтрацию прямо в запрос или в URL API. Например, если вам нужны только активные клиенты, добавьте WHERE is_active = 1 в SQL-запрос. Это уменьшит объём данных, которые платформа получит от внешней базы, и ускорит расчёт сегмента.
• Для HTTP-запросов к API — внешний сервис должен возвращать только список идентификаторов, а не полные объекты с дополнительными полями.
• Для загружаемых файлов — файл должен содержать только нужную колонку с идентификаторами.
• Используйте параметр кэширования результата при создании SQL-запроса сегментации. Если данные меняются редко, кэширование значительно ускорит повторные расчёты сегмента.

Объединение условий в одном SQL-запросе

Когда вам нужно отфильтровать профили по нескольким условиям из одной внешней SQL-базы, лучше написать один запрос с объединёнными условиями, чем создавать несколько запросов и соединять их в сегменте через «И».

Каждый отдельный запрос сегментации — это отдельное обращение к внешней базе. Чем больше запросов, тем дольше расчёт сегмента.

Пример. Представьте, что вам нужно выбрать клиентов, у которых есть активный договор и которые находятся в нужном регионе.

Неэффективный вариант — два отдельных запроса сегментации:

1. Запрос «Договоры»: SELECT id FROM contracts WHERE status = 'active'
2. Запрос «Регионы»: SELECT id FROM customers WHERE region = 'Moscow'

Затем в сегменте эти два условия соединены через «И»:

В таблице данных (запрос "Договоры")
И
В таблице данных (запрос "Регионы")

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

Эффективный вариант — один запрос сегментации с объединёнными условиями:

SELECT customers.id
FROM contracts
JOIN customers ON customers.id = contracts.customer_id
WHERE contracts.status = 'active' AND customers.region = 'Moscow'

В сегменте — одно условие:

В таблице данных (запрос "Договоры и регионы")

Платформа выполнит один запрос, и пересечение произойдёт на стороне базы данных — это быстрее.

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

• Если условия относятся к одной внешней базе — объединяйте их в один SQL-запрос с помощью JOIN, подзапросов или UNION.
• Если условия относятся к разным базам — объединить их в один запрос невозможно, и платформа выполнит их последовательно. В этом случае постарайтесь, чтобы каждый запрос возвращал как можно меньше записей.
• Используйте параметры запросов, чтобы сделать один универсальный запрос вместо нескольких похожих. Например, один запрос с параметром {REGION} лучше, чем отдельные запросы для каждого региона.
• Старайтесь, чтобы все запросы в сегменте обращались к одному полю профиля (например, customer_id). Платформа может автоматически объединять запросы только если они привязаны к одному и тому же полю профиля и используют один коннектор.

Автоматическое объединение запросов

В платформе реализована оптимизация, которая позволяет объединять несколько запросов сегментации к одной внешней базе в единый SQL-запрос. Вместо того чтобы выполнять каждый запрос отдельно, выгружать результаты и пересекать их внутри платформы, платформа формирует один запрос с операциями INTERSECT (пересечение), UNION (объединение) или EXCEPT (исключение) — и выполняет его на стороне внешней базы.

Как это работает. Если в сегменте есть несколько условий «В таблице данных», которые обращаются к одному коннектору и привязаны к одному и тому же полю профиля, платформа может объединить их:

В таблице данных (запрос "Договоры")
И
В таблице данных (запрос "Регионы")

Вместо двух отдельных запросов платформа сформирует один:

(SELECT id FROM query1) INTERSECT (SELECT id FROM query2)

Если одно из условий — «Не в таблице данных», платформа использует EXCEPT:

(SELECT id FROM query1) EXCEPT (SELECT id FROM query2)

к сведению

Оптимизация включается администратором платформы (параметр SEGMENT_SQL_DATA_GROUP_OPTIMIZATION). Подробнее в документации администратора.

Ограничения:

• Объединяются только запросы одного коннектора и одного поля профиля.
• Если между запросами есть другие условия сегмента (не по внешней базе), объединение может не сработать. Например, конструкция вида Запрос И (Запрос ИЛИ Условие) не может быть объединена, потому что не-запросное условие «разрывает» группу.

Раскрытие сегмента в сегменте

Если в условии сегмента используется другой сегмент (оператор «В сегменте»), платформа может раскрыть вложенный сегмент и включить его запросы к внешней базе в общую группировку для объединения.

Пример. Сегмент "VIP" содержит условие В таблице данных (запрос "VIP"). Родительский сегмент содержит:

В таблице данных (запрос "Активные клиенты")
И
В сегменте (сегмент "VIP")

Без раскрытия платформа выполнит запрос «Активные клиенты» отдельно, рассчитает сегмент "VIP" отдельно и пересечёт результаты.

С раскрытием платформа «увидит» запрос "VIP" из вложенного сегмента и объединит оба запроса в один SQL-запрос с INTERSECT.

Чтобы раскрытие сработало, должны выполняться все условия:

• Используется оператор «В сегменте». При использовании «Не в сегменте» стандартное раскрытие не сработает (см. Раскрытие «Не в сегменте»).
• Раскрытие работает только для динамических или обновляемых сегментов, так как они хранят условия сегментации. Для статических сегментов раскрытие не применяется — они содержат только готовый список профилей.
• Запросы вложенного и родительского сегмента обращаются к одному коннектору и привязаны к одному полю профиля.
• Операторы групп условий совпадают — если родитель использует «И», вложенный тоже должен использовать «И» (аналогично для «ИЛИ»).

к сведению

Раскрытие сегмента в сегменте включается администратором платформы (параметры SEGMENT_SQL_SIS_EXPANSION, SEGMENT_SQL_SIS_MAX_DEPTH). Подробнее в документации администратора.

Раскрытие «Не в сегменте»

Для условий с оператором «Не в сегменте» реализована отдельная оптимизация. Она позволяет раскрыть вложенный сегмент и преобразовать отрицание: каждый оператор внутри вложенного сегмента заменяется на противоположный («равно» → «не равно», «содержит» → «не содержит», «больше» → «меньше или равно» и так далее), после чего запросы можно объединить с родительским сегментом.

Чтобы раскрытие сработало, должны выполняться все условия:

• Условие использует оператор «Не в сегменте».
• Вложенный сегмент не является статическим — динамический или обновляемый.
• Запросы вложенного и родительского сегмента обращаются к одному коннектору и привязаны к одному полю профиля.
• Все операторы во вложенном сегменте имеют пару-инверсию (например, «равно» ↔ «не равно», «содержит» ↔ «не содержит»). Если хотя бы один оператор не имеет пары — раскрытие не сработает.

Операторы без инверсии

Статус подписки: «Отписан», "Hardbounced", «Жалобщик», «Не валиден», «Приостановлен», «Не подтверждён», «Не существует».

Сценарии автоматизации: «хотя бы раз был», «никогда не был», «сейчас в сценарии», «сейчас не в сценарии», «вышел с ошибкой».

Формы: «заполнял», «не заполнял», «заполнял за выбранный период», «заполнял за последние [x] дней относительно текущей даты».

Даты: «тот же что и сегодня».

Активность в каналах: «Как минимум [n] раз», «Ни одного раза».

Кампании и ЛКГ: «не в ЛКГ».

Лояльность и заказы: «в диапазоне».

Связи: «Наличие / отсутствие прямой связи», «Наличие / отсутствие обратной связи».

к сведению

Раскрытие «Не в сегменте» включается администратором платформы (параметры SEGMENT_SQL_SIS_NOT_EXPANSION, SEGMENT_GROUP_EXPANSION). Подробнее в документации администратора.

Условия с «НЕ» по внешним витринам

Условия сегментации по внешним витринам данных с оператором «НЕ» (например, «Не в таблице данных») приводят к сканированию всей базы профилей. Это происходит потому, что системе необходимо проверить каждый профиль на отсутствие во внешней выборке.

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

• Сведите количество условий с «НЕ» по внешним данным к минимуму.
• По возможности заменяйте отрицательные условия на позитивные. Например, вместо «Не в таблице данных» используйте «В таблице данных» с инвертированным запросом на стороне внешней базы.
• Если условие с «НЕ» необходимо, убедитесь, что внешняя витрина возвращает максимально компактный результат.

Подробнее об операторе «НЕ» в сегментах читайте в статье Рекомендации по работе с сегментами.