Життєвий цикл (серверний)
Передавайте посилання відтворення до ActiveCampaign, Mailchimp, Iterable або Klaviyo з нашого сервера тієї миті, коли сеанс отримує ваш власний ідентифікатор клієнта.
1. Навіщо це поряд із мостом браузера
MousePlayer уже має міст життєвого циклу, який записує дані в SDK на вашій сторінці: Klaviyo, Braze, Customer.io та ще шість. Цей виконує ту саму роботу з нашого сервера. Він існує тому, що для двох найбільших платформ шлях через браузер просто недоступний:
- ActiveCampaign узагалі не має браузерного API для подій. Його
vgo()дає змогу задати обліковий запис та електронну адресу й почати відстеження, але не надіслати подію. Події проходять через Event Tracking API з окремим ключем подій, лише на сервері. - Mailchimp має його, але із закритим набором назв. Його піксель відстеження сайту приймає
PAGE_VIEWED,PRODUCT_VIEWED,PURCHASEDта кілька інших наперед визначених назв. Місця для власної події немає, а втиснути наші дані вPAGE_VIEWEDозначало б створити неправду у вашій моделі даних.
Для Iterable і Klaviyo серверний шлях просто надійніший: немає блокувальника реклами, SDK, який міг завантажитися чи ні, або завчасного закриття вкладки.
2. Що потрібно
Три поля, і заповнювати їх слід залежно від платформи.
| Платформа | Поле облікового запису | Ключ |
|---|---|---|
| ActiveCampaign | actid | Вебсайт → Відстеження сайту, поруч із ключем подій |
| Mailchimp | Ідентифікатор аудиторії | Ключ API — збережіть його суфікс на кшталт -us14, за яким визначається центр обробки даних |
| Iterable | не потрібне — залиште порожнім | Ключ із дозволом «Дозволити виклики відстеження подій» |
| Klaviyo | не потрібне — залиште порожнім | Використовуйте приватний ключ API |
Третє поле — назва, під якою з’явиться подія. Вона має бути короткою: щонайбільше 32 символи. Це обмеження API, а не наше. Ми скорочуємо назву під час збереження, а не надсилання, щоб форма не показувала щось відмінне від того, що надходить.
Mailchimp: зберігайте суфікс ключа API. Частина після останнього дефіса (-us14) позначає центр обробки даних, де міститься ваш обліковий запис, і з неї будується адреса. Ключ без неї відхиляється з чітким повідомленням замість прихованого збою.
3. Коли міст спрацьовує, а коли ні
У момент ідентифікації сеансу: коли ваш сайт викликає MousePlayer.setUserId(), коли наш міст аналітики зчитує унікальний ідентифікатор або коли ваш сервер викликає кінцеву точку ідентифікації. До цього ми не знаємо, кому належить запис.
Лише з електронною адресою
Усі чотири платформи звертаються до контакту за електронною адресою. Якщо ваш ідентифікатор клієнта — номер договору, нічого не надсилається: ставити в чергу завдання, яке може лише завершитися помилкою, означало б засмічувати журнал.
Контакт уже має існувати. Жодна із цих платформ не створює його з події; ActiveCampaign повністю відкидає подію, якщо не впізнає адресу. Цей міст доповнює наявні контакти, а не створює ваш список.
Кожна подія містить ідентифікатор
Тому той самий сеанс не можна порахувати двічі, навіть за повторного виконання завдання.
4. Що надходить на інший бік
Одна подія, що містить посилання відтворення у властивості з назвою mouseplayer_session_url. Відкрийте його — і ви в записі саме того сеансу.
Далі працює логіка вашої платформи: використовуйте подію як тригер автоматизації, умову сегмента або просто дайте команді відкривати запис із контакту.
Ключ ніколи не залишає наш сервер
Він зберігається зашифрованим AES-256-GCM, більше не показується після збереження й навмисно не потрапляє у внутрішню чергу завдань: обробник сам отримує його з бази даних.
HTTP 200 не означає доставку
Коли ActiveCampaign відхиляє подію, він відповідає статусом 200 і {"success":0}. Ми читаємо тіло відповіді, а не лише статус, тому відхилення показується як збій у журналі доставки, а не як мовчазний успіх.
5. Braze, Customer.io та Brevo
Ще три платформи на серверному шляху. Двом із них потрібне те, чого не потребують інші: місце.
| Ви задаєте | Ідентифікується за | |
|---|---|---|
| Braze | кінцеву точку REST і ключ API | електронною адресою |
| Customer.io | ідентифікатор сайту, ключ API та свій регіон | вашим власним ідентифікатором клієнта |
| Brevo | лише ключ відстеження | електронною адресою |
Дві з них розташовані в конкретному місці
Braze використовує кінцеві точки REST, прив’язані до екземпляра; Customer.io має два окремі регіони з різними хостами. Жодне з цих місць не можна визначити за ключем, а неправильний вибір дає відповідь 401, через що ви починаєте шукати проблему в ключі. Обидва поля існують саме з цієї причини.
Customer.io — єдина, якій не потрібна електронна адреса
Вона знає людей за тим самим ідентифікатором, який ви їм призначаєте, тож вимога електронної адреси була б вигаданою перешкодою. Решта шість справді зіставляють за електронною адресою, і для них сеанс, ідентифікований номером договору, нічого не створює — цілком правильно.
Без нових профілів
Виклик Braze містить _update_existing_only. Це те саме рішення, що й у мосту CRM: сеанс браузера не є надійним підтвердженням того, хто ваші клієнти, а платформа життєвого циклу, яка створює профіль для кожного анонімного відвідувача, гірша за відсутність інтеграції.
Brevo відповідає 204, Braze — 201 із нюансом
Brevo взагалі не повертає тіла відповіді: тут 2xx справді містить усю відповідь. Braze повертає "message": "success" і може додавати поруч масив errors: критичні проблеми з’являються в message, а допустимі втрати полів — лише в errors. Читання лише одного з них призводить до хибного висновку в той чи інший бік.
Усі згадані тут торговельні марки належать їхнім відповідним власникам. MousePlayer не має ділових відносин із цими постачальниками.