Как упростить фильтр
Не каждый фильтр может посчитаться в реальном времени. В таких случаях выдаётся сообщение «Фильтр, который вы построили, работает долго. Попробуйте создать пересчитываемый сегмент».
Иногда запрос может быть настолько сложным, что и сегмент не может посчитаться. Вместо этого он падает с сообщением «Попробуйте упростить фильтр сегментации».
Как же упростить фильтр?
Практические советы:
- поиск клиентов с заказами: лучше задавать через «клиент-заказ-первое действие», а не «клиент-действие-заказ»:
Было | Стало |
---|---|
- поиск по категории шаблона действий задавайте через категорию, а не через имя-категория:
Было | Стало |
---|---|
- поиск действий, связанных с продуктом/категорией: лучше указать конкретные шаблоны действий:
Было | Стало |
---|---|
- поиск с количеством сложнее, чем просто «есть такие». Поэтому вместо «в количестве от 1» лучше указывать «есть такие»:
Было | Стало |
---|---|
- не считается фильтр по заказам с уточнением продукта — создайте пересчитываемый или статический сегмент по этим продуктам и подставьте его в фильтр:
Было | Стало |
---|---|
- поиск изменений баланса можно ускорить, добавив условия по балльному счету, шаблону действия и/или времени изменения. Для уточнения по имени/категории шаблона нужно знать, какие действия на вашем проекте приходят с изменением баланса на конкретном балльном счете:
Было | Стало |
---|---|
- поиск заказов за период на вкладке действий: лучше строить через «заказ-данные первого действия»:
Было | Стало |
---|---|
- не считается фильтр по действиям и его никак не упростить — ограничьте его пересчитываемым сегментом по клиентам с искомыми действиями:
Было | Стало |
---|---|
-
сегмент не пересчитывается: если в фильтре есть несколько условий, определите, есть ли среди них особенно тяжёлые запросы. Для этого применяйте условия по одному:
Если фильтр не может посчитаться в одиночку, условия надо упростить или создать пересчитываемый сегмент именно по этой части.
Больше информации по несчитающимся сегментам — в статье.
Подробнее о том, почему фильтр может не считаться
Возможность фильтра посчитаться зависит от трёх факторов:
— условия в фильтре
— объём данных по этим условиям
— нагрузка на базу в момент применения фильтра
Условия в фильтре.
Возьмём для примера:
Чтобы сформировать выборку по таким условиям, фильтр составит два списка: клиенты с заказами и клиенты с нужной подпиской, а потом сопоставит эти списки.
Чем больше в базе клиентов/заказов/тематик, тем больше данных надо будет просмотреть фильтру → тем дольше он будет строиться.
Добавление нового условия, например, по первому действию в заказе усложнит фильтр, т.к. ему нужно будет просмотреть еще список действий и объединить их с остальными данными.
То есть фильтр тем сложнее, чем больше в нём сущностей и чем больше в базе данных по этим сущностям.
Объём данных
Если фильтр, который раньше считался в реальном времени, стабильно предлагает построить пересчитываемый сегмент — на проекте накоплен большой объём данных.
Их можно удалить.
У действий это можно сделать автоматическим удалением, у остальных сущностей — вручную.
А если не удалять?
Нужно быть готовыми к тому, что фильтры будут работать медленнее. Некоторые перестанут строиться и их надо будет заменить пересчитываемыми сегментами.
Нагрузка на базу
Ресурсы базы ограничены, и фильтры делят их с другими механиками. Рассылки, импорты и экспорты больших объемов, многочисленные вызовы операций и т.д. — всё это создает нагрузку и может негативно влиять на работу фильтров. Фильтр может медленнее строиться в часы пик и быстрее в периоды низкой активности.