Интеграция Mindbox с кастомными событиями в приложении на Flutter

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

4 августа 2026 Технологии 11 мин чтения

---

---

Что такое кастомные события Mindbox

Событие в Mindbox — это факт того, что покупатель что-то сделал: посмотрел товар, положил его в корзину, оформил заказ. Приложение сообщает об этом платформе, платформа записывает событие в профиль клиента и на его основе строит сегменты и запускает коммуникации. Стандартная модель Mindbox уже содержит набор типовых событий, которых хватает для базовой маркетинг-автоматизации розницы.

Кастомное событие — это действие, которого в стандартном наборе нет, и магазин описывает его сам под свои сценарии. Технически это отдельная операция с собственным названием и набором параметров: например, событие preorder_started с параметрами «идентификатор товара» и «ожидаемая дата поступления». Название и структуру определяет команда разработки вместе с маркетологом, а дальше приложение отправляет это событие в Mindbox наравне со стандартными.

Бизнес-перевод: зачем это нужно на человеческом языке

Если стандартные события отвечают на вопрос «что покупатель делает по общему пути покупки», то кастомные отвечают на вопрос «что покупатель делает именно в вашем приложении и именно с вашими механиками». Магазин детской одежды хочет ловить момент, когда родитель ждёт поступления размера; магазин с бонусной программой — момент, когда покупатель почти потратил баллы. Ни то, ни другое из стандартного набора не собрать. Кастомные события переводят особенности продукта в данные, на которых работает маркетинг.

Зачем интернет-магазину кастомные события

Ценность кастомных событий раскрывается в двух связанных задачах маркетинга: точная сегментация и точный триггер. Разберём обе.

Сегментация по реальному поведению

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

Триггеры, которые нельзя собрать из стандартных событий

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

По данным Data Insight и АКИТ, доля мобильных покупок в российской онлайн-рознице устойчиво растёт, а значит и точность работы с покупателем в приложении становится всё более значимой. Собственное мобильное приложение для интернет-магазина даёт контроль над тем, какие события и в какой момент фиксируются, — в отличие от канала, где набор данных задан платформой.

Как устроена передача событий из приложения на Flutter

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

От действия покупателя до профиля в Mindbox

• Действие в интерфейсе. Покупатель совершает действие — открывает карточку варианта, нажимает на рекомендацию, доходит до шага оплаты. В коде на Flutter этому действию соответствует конкретное место, где можно поймать факт события.
• Слой аналитики и событий приложения. Приложение не разбрасывает вызовы Mindbox по всему коду, а объединяет их в едином слое событий. Так проще менять параметры, не трогая экраны, и не дублировать логику.
• Запрос в Mindbox. Слой формирует операцию: название события (например bonus_widget_engaged), идентификатор покупателя и параметры (баланс бонусов, экран, где произошло действие). Запрос уходит по защищённому соединению в формате, который принимает платформа.
• Обработка на стороне платформы. Mindbox записывает событие в профиль клиента, обновляет сегменты и, если настроен триггер, запускает коммуникацию — push, сообщение в приложении или письмо.

Обратное направление тоже важно: Mindbox может инициировать отправку push-уведомления, а приложение — доставить его покупателю. Для этого приложение регистрирует токен устройства и связывает его с профилем клиента. На Dart и Flutter такой двусторонний обмен реализуется на серверной части и в клиенте без обходных решений — это часть нашей практики по разработке e-commerce-приложений на Flutter.

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

Чтобы событие из приложения попало в тот же профиль, что и заказы с сайта, нужен общий идентификатор покупателя. Обычно это связка телефона или email с внутренним идентификатором клиента. Аккуратная привязка приложения к общему профилю — базовое условие: без неё события приложения живут отдельно от истории покупателя, и сегментация теряет смысл. Этот же принцип единого профиля лежит в основе связки сайта и приложения на одной кодовой базе, где данные покупателя не раздваиваются между каналами.

Пять кастомных событий и триггерные сценарии

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

Для наглядности сведём события, их смысл и триггеры в одну таблицу:

Эти пять событий работают в связке: например, покупатель начал предзаказ (preorder_started), а через неделю товар поступил — триггер зовёт его завершить оформление, а событие checkout_step_n показывает, довёл ли он заказ до оплаты. Так события складываются в понятную картину поведения, а не в набор разрозненных отметок.

Шаблонное решение и кастомная разработка: где граница

Отдельный практический вопрос — что из этого доступно на готовом шаблонном решении, а что требует разработки на стороне кода. Граница проходит не по «Mindbox или не Mindbox», а по тому, насколько точно нужно привязать событие к поведению в приложении.

Что закрывается на шаблонных решениях

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

Что требует кастомной разработки

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

Разницу удобно свести в таблицу:

Честный вывод: если магазину хватает стандартных триггеров, шаблон — оправданный выбор на старте. Если маркетинг упирается в потолок стандартных событий и хочет ловить поведение точнее, задача переходит в разработку приложения на заказ. Промежуточный вариант — доработать уже существующее приложение: если оно есть, начать стоит с аудита мобильного приложения, чтобы понять, какой объём событий реально добавить в текущий код.

Типичные ошибки при интеграции событий

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

Событие срабатывает не в тот момент

Если variant_inspected отправляется при любом касании карточки, а не при реальном просмотре варианта, сегмент раздувается ложными срабатываниями. Момент срабатывания нужно проектировать: не «экран открылся», а «покупатель выбрал размер и задержался на нём». Точка вызова события — это проектное решение, а не техническая мелочь.

Нет единого идентификатора покупателя

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

Параметры события не согласованы с маркетингом

Разработчик передаёт то, что удобно достать из кода, а маркетологу для сегмента нужно другое — например, не «идентификатор товара», а «категория» и «бренд». Если состав параметров не обсудить заранее, событие приходит бесполезным, и его переделывают после запуска. Список параметров каждого события фиксируют совместно на этапе технического задания.

Как измерить эффект в связке с конверсией

Кастомные события ценны не сами по себе, а тем, что двигают измеримые показатели. Чтобы интеграция не превратилась в набор данных ради данных, эффект стоит мерить с самого начала.

Что смотреть

• Конверсия из события в заказ. Доля покупателей, которые после срабатывания триггера дошли до покупки: например, сколько из начавших предзаказ завершили его после напоминания о поступлении.
• Возвращаемость. Доля покупателей, которые вернулись в приложение через неделю и через месяц после установки, — здесь видно влияние триггерных коммуникаций на удержание.
• Доход с покупателя за всё время. Насколько точные коммуникации повышают суммарную выручку с одного клиента по сравнению с сегментом без триггеров.
• Отклик на коммуникацию. Доля открытий и переходов по push и сообщениям — на узких сегментах она обычно выше, чем на широких рассылках.

Как отделить эффект событий

Чтобы понять, что рост дали именно триггеры, а не сезон или реклама, сравнивают две группы покупателей: с включённой триггерной коммуникацией и контрольную без неё. Разница между ними и есть вклад события. Такое сравнение настраивается в Mindbox на уровне сегментов, а данные для него поставляют как раз аккуратно спроектированные события. Без чистой передачи событий любой замер превращается в гадание.

Чек-лист внедрения кастомных событий

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

• Сценарии маркетинга. Начать с вопроса «какие триггеры и сегменты нужны», а не «какие события отправлять». События выводятся из сценариев, а не наоборот.
• Список событий и параметров. Для каждого сценария зафиксировать название события, момент срабатывания и состав параметров — совместно разработчик и маркетолог.
• Единый профиль покупателя. Заложить общий идентификатор, связывающий приложение, сайт и историю заказов в один профиль.
• Слой событий в коде. Собрать вызовы Mindbox в едином слое приложения, а не разбрасывать по экранам.
• Проверка на реальных сценариях. Прогнать каждое событие вручную и убедиться, что оно приходит в нужный момент с верными параметрами.
• Триггеры и сегменты на стороне Mindbox. Настроить коммуникации и сегменты, проверить их на тестовом профиле до запуска на всех покупателей.
• Замер эффекта. С первого дня вести контрольную группу, чтобы отделить вклад триггеров от прочих факторов.

Опыт FITTIN

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

Общий знаменатель этих проектов — не сам факт подключения Mindbox, а аккуратно выстроенная передача данных: единый профиль покупателя, события под маркетинговые сценарии и сохранность истории при миграции. Mindbox — один из наших технологических партнёров в маркетинге, наряду с RetailCRM, Maxma и Retail Rocket. Другие проекты команды в электронной коммерции — в портфолио, а близкий по теме разбор перехода на собственное приложение — в статье о росте конверсии при миграции fashion-ритейлера.

Итог: с чего начать

Кастомные события Mindbox переводят особенности вашего приложения — предзаказы, бонусы, шаги оформления — в данные, на которых маркетинг строит точные сегменты и триггеры. Технически это защищённая передача событий из приложения на Flutter в Mindbox через единый слой и общий профиль покупателя. Стандартные события и типовые триггеры доступны и на шаблонных решениях; кастомные события с точной привязкой к поведению — задача разработки на стороне кода. А главный фактор результата — не сам факт подключения, а аккуратно спроектированный момент срабатывания события и состав его параметров, согласованный с маркетингом.

Дальнейший шаг зависит от того, на каком этапе ваш проект:

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

Частые вопросы

Что такое кастомные события в Mindbox?

Кастомные события — это действия покупателя в приложении, которых нет в стандартном наборе Mindbox (просмотр товара, добавление в корзину, заказ). Магазин описывает их сам под свои сценарии: начало предзаказа, просмотр конкретного варианта товара, клик по рекомендации в корзине, открытие виджета бонусов, прохождение конкретного шага оформления. Каждое такое событие приложение передаёт в Mindbox через операцию с набором параметров, а маркетолог строит на нём сегменты и триггерные рассылки.

Можно ли передавать события в Mindbox из приложения на Flutter?

Да. Приложение на Flutter отправляет события в Mindbox через его API: код формирует запрос с названием операции и параметрами события и отправляет его по защищённому соединению. Mindbox обновляет профиль клиента и запускает связанный триггер. Отдельного ограничения на Flutter нет — важно аккуратно спроектировать, в какой момент кода срабатывает событие и какие данные оно несёт. В наших проектах приложения на Flutter передают события в Mindbox именно так.

Чем кастомные события отличаются от стандартных в Mindbox?

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

Какие события нужны для триггерных рассылок в мобильном приложении?

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

Что можно настроить на шаблонном решении, а что требует кастомной разработки?

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

Как передать данные программы лояльности в Mindbox?

Взаимодействие покупателя с программой лояльности — открытие виджета бонусов, просмотр баланса, применение баллов — передаётся в Mindbox отдельными событиями с параметрами: текущий баланс, доступная к списанию сумма, срок сгорания. На этих данных маркетолог строит сегменты (например, «баллы скоро сгорают») и триггерные напоминания. Сами баллы при этом ведёт система лояльности, а Mindbox получает события о взаимодействии с ней для коммуникаций.

Сколько стоит интеграция Mindbox в мобильное приложение?

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

Материал носит информационно-справочный характер и отражает оценку команды FITTIN на дату публикации 4 августа 2026 года. Актуальные тарифы и почасовые ставки — на странице тарифов.