Жизненный цикл (сервер)

1. Зачем рядом с браузерным мостом

У MousePlayer уже есть мост жизненного цикла для SDK на странице: Klaviyo, Braze, Customer.io и шести других. Этот работает с сервера, потому что у двух крупнейших платформ браузерный путь недоступен:

• У ActiveCampaign нет браузерного API событий. Его vgo() задаёт аккаунт, почту и запускает отслеживание, но не отправляет событие. События идут через Event Tracking API с отдельным ключом, только с сервера.
• У Mailchimp есть API, но закрытый словарь. Пиксель сайта принимает PAGE_VIEWED, PRODUCT_VIEWED и PURCHASED , а также несколько других заданных имён. Своего события нет; втиснуть наши данные в PAGE_VIEWED значило бы исказить собственную модель данных.

2. Что нужно

Три поля, заполнение зависит от платформы.

Третье поле — имя события. Кратко: максимум 32 символа. Это предел API, не наш; сокращаем при сохранении, а не отправке, чтобы форма соответствовала результату.

3. Когда срабатывает

В момент идентификации сеанса: при вызове сайтом MousePlayer.setUserId(), чтении ID нашим аналитическим мостом или вызове identify сервером. До этого мы не знаем, кому принадлежит запись.

Только с электронной почтой

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

Каждое событие содержит ID

Поэтому сеанс не учитывается дважды даже при повторе задачи.

4. Что приходит

Одно событие со ссылкой на запись в свойстве mouseplayer_session_url. Откройте — попадёте в запись именно этого сеанса.

Далее логика платформы: триггер автоматизации, условие сегмента или просмотр записи командой из контакта.

Ключ не покидает сервер

Хранится с шифрованием AES-256-GCM, не показывается после сохранения и намеренно не попадает во внутреннюю очередь задачи: обработчик получает его из базы сам.

HTTP 200 не означает доставку

ActiveCampaign отвечает статусом 200 и {"success":0} при отклонении. Мы читаем тело, чтобы отказ стал сбоем в журнале, а не молчаливым успехом.