Как упростить фильтр

Не каждый фильтр может посчитаться в реальном времени. В таких случаях выдаётся сообщение «Фильтр, который вы построили, работает долго. Попробуйте создать пересчитываемый сегмент».

Иногда запрос может быть настолько сложным, что и сегмент не может посчитаться. Вместо этого он падает с сообщением «Попробуйте упростить фильтр сегментации».
Как же упростить фильтр?

Практические советы:

• поиск клиентов с заказами: лучше задавать через «клиент-заказ-первое действие», а не «клиент-действие-заказ»:

Было	Стало

• поиск по категории шаблона действий задавайте через категорию, а не через имя-категория:

Было	Стало

• поиск действий, связанных с продуктом/категорией: лучше указать конкретные шаблоны действий:

Было	Стало

• поиск с количеством сложнее, чем просто «есть такие». Поэтому вместо «в количестве от 1» лучше указывать «есть такие»:

Было	Стало

• не считается фильтр по заказам с уточнением продукта — создайте пересчитываемый или статический сегмент по этим продуктам и подставьте его в фильтр:

Было	Стало

• поиск изменений баланса можно ускорить, добавив условия по балльному счету, шаблону действия и/или времени изменения. Для уточнения по имени/категории шаблона нужно знать, какие действия на вашем проекте приходят с изменением баланса на конкретном балльном счете:

Было	Стало

• поиск заказов за период на вкладке действий: лучше строить через «заказ-данные первого действия»:

Было	Стало

• не считается фильтр по действиям и его никак не упростить — ограничьте его пересчитываемым сегментом по клиентам с искомыми действиями:

Было	Стало

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

Если фильтр не может посчитаться в одиночку, условия надо упростить или создать пересчитываемый сегмент именно по этой части.

Больше информации по несчитающимся сегментам — в статье.

Подробнее о том, почему фильтр может не считаться

Возможность фильтра посчитаться зависит от трёх факторов:
— условия в фильтре
— объём данных по этим условиям
— нагрузка на базу в момент применения фильтра

Условия в фильтре.

Возьмём для примера:

Чтобы сформировать выборку по таким условиям, фильтр составит два списка: клиенты с заказами и клиенты с нужной подпиской, а потом сопоставит эти списки.

Чем больше в базе клиентов/заказов/тематик, тем больше данных надо будет просмотреть фильтру -> тем дольше он будет строиться.

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

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

Объём данных

Если фильтр, который раньше считался в реальном времени, стабильно предлагает построить пересчитываемый сегмент — на проекте накоплен большой объём данных.

Их можно удалить.
У действий это можно сделать автоматическим удалением, у остальных сущностей — вручную.

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

Нагрузка на базу

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