Ситуация с долгой загрузкой дашборда связана с “тяжелыми” условиями, которые используются в сегментах, составляющих этот дашборд – в данном случае речь идет об условии “Находится в сегменте” → [https://skr.sh/sUbVS5hRAb2](https://skr.sh/sUbVS5hRAb2) . Это условие является одним из наиболее “тяжелых” для системы, в связи с чем подсчет результатов может занимать дополнительное время. Чем больше подобных условий в запросе, тем сложнее системе его обработать. По возможности мы рекомендуем избегать «сложных» или вложенных друг в друга сегментов, “перекрестных” условий, когда обращение к одному объекту происходит через сегмент по другому (например, “Принадлежит пользователю” / “Имеет заказ”/”Имеет предыдущий заказ” и т.д), а также условий с инвертированием (“НЕ”). Это связано с тем, что чем больше подобных условий используется, тем большую нагрузку они оказывают. Чтобы подобные ситуации возникали реже, мы со своей стороны проводим оптимизацию условий и их связок. Работа по указанному вопросу уже ведется, однако назвать определенные сроки решения на текущий момент возможности нет. Дополнительно я передала информацию по данному вопросу разработчикам для анализа. Для оптимизации времени загрузки дашборда можно делать разделение одного большого дашборда на несколько дашбордов поменьше — это поможет быстрее проводить подсчет сегментов в отдельно взятом дашборде.
### Условный оператор "не"