Як передавати додаткові поведінкові дані з «Хорошоп» у SendPulse для складних автоматизацій

Для інтернет-магазину преміального посуду й сервірування на платформі «Хорошоп» ми розширили стандартну інтеграцію з SendPulse: додали передавання даних про перегляди товарів, стан кошика і персональні рекомендації. Це дало змогу запустити сценарії «Покинутий перегляд» і розширене «Відновлення кошика» без переходу на іншу CMS і без дорогої серверної інтеграції — за допомогою JavaScript, Google Apps Script і «Менеджера подій» в Automation 360.

Міні-глосарій

Щоб вам було простіше орієнтуватися у кейсі, зібрали на початку матеріалу термінологію, адже стаття доволі технічна:

• Browse Abandonment або покинутий перегляд — сценарій автоматизації, який запускається після перегляду товару, якщо користувач не перейшов до наступного етапу покупки.
• Advanced Cart Recovery або розширене відновлення кошика — сценарій повернення користувача до покупки, який враховує фактичний склад кошика та інші дані про його поведінку.
• Тригер — умова або подія, після якої автоматично запускається певний сценарій.
• Поведінкові дані — інформація про дії користувача на сайті: перегляди товарів, додавання до кошика, переходи між сторінками та інші взаємодії.
• Товарний контекст — набір даних про конкретні товари, пов’язані з дією користувача: назва, ціна, зображення, посилання, кількість та інші параметри.
• Кастомна подія — та, яку компанія створює самостійно для передачі в систему даних, не передбачених стандартною інтеграцією.
• Вебхук— механізм автоматичного передавання даних між сервісами після певної події. У цьому кейсі події надсилаються через HTTP-запити на спеціально створені адреси.
• Endpoint або кінцева точка — URL-адреса, на яку одна система надсилає дані іншій.
• API — інтерфейс, через який різні програми та сервіси можуть обмінюватися даними й командами.
• Валідація даних — перевірка отриманої інформації перед подальшою обробкою: наприклад, чи заповнені обов’язкові поля і чи відповідають дані потрібному формату.
• Дедуплікація — перевірка та усунення повторних даних або подій, щоб один і той самий сценарій не запускався кілька разів без потреби.
• Унікальний відбиток кошика — умовний ідентифікатор, сформований на основі складу кошика. Він допомагає визначити, чи надсилалася подія для такого набору товарів раніше.
• Checkout — етап оформлення замовлення, на якому покупець вводить контактні дані, обирає доставку та спосіб оплати.
• Динамічний контент — вміст листа, який автоматично змінюється залежно від даних конкретного отримувача.
• Масив даних — структурований список однотипних елементів. У цьому кейсі — список товарів, які користувач переглянув або залишив у кошику.
• Рекомендаційний блок — частина листа з товарами, які система пропонує додатково на основі доступних даних про поведінку користувача.
• Google Tag Manager — система керування тегами, яка дає змогу додавати та оновлювати скрипти на сайті без постійного редагування його основного коду.
• Web App — застосунок із власною URL-адресою, який може приймати та обробляти запити з інших систем.
• Квота — встановлений сервісом ліміт на кількість запитів або інших операцій за певний період.

Що вам знадобиться для повторення цього кейсу

Щоб повторити описаний підхід у своєму магазині, вам потрібні:

1. JS-розробник для скрипта на сайті та базові знання Google Apps Script для проміжного шару. Google Apps Script — це сервіс, який дає змогу написати невеликий скрипт і опублікувати його як окрему веб-адресу. На неї можна надсилати запити з будь-якого джерела.
2. Можливість додавати кастомний JavaScript на сторінки сайту: платформа «Хорошоп» це має.
3. Менеджер подій SendPulse: він доступний навіть на безкоштовному плані, але з лімітом в одну подію. Для двох сценаріїв одразу — Browse Abandonment і Advanced Cart Recovery — потрібен платний тариф Standard. Менеджер подій — це розділ SendPulse, де для кожного власного сценарію створюється окрема подія: унікальний URL і набір змінних, які ця подія прийматиме.

Зверніть увагу, чи не встановлений попередньо на сайті піксель SendPulse. Якщо одночасно тримати ввімкненими піксель і кастомну подію перегляду товару, є ризик подвійного трекінгу того самого перегляду. Щоб уникнути цього, розведіть, їхні ролі: піксель — для загальної аналітики й сценаріїв без товарного контексту, кастомні події — для Browse Abandonment і Advanced Cart Recovery.

Проблема: стандартній інтеграції бракує даних

У SendPulse автоматизація будується навколо подій: щось відбулося на сайті — сценарій отримав сигнал і запустив ланцюжок листів. Але щоб сценарій був персоналізованим, потрібні дані про поведінку користувача: які товари він переглядав, що поклав до кошика, на якому кроці зупинився.

Стандартна інтеграція «Хорошоп» — SendPulse підключається без додаткового коду і передає дві події: реєстрацію в особистому кабінеті покупця та факт оформлення замовлення. Цього достатньо для базових транзакційних сценаріїв: вітального листа, підтвердження замовлення, запиту відгуку після покупки. Товарного контексту — а це перегляди, вміст кошика, рекомендації — вона не передає. Цю прогалину закриває підхід, описаний у статті. Детальний опис можливостей готової інтеграції — у базі знань SendPulse.

Перед командою стояло завдання реалізувати:

• Browse Abandonment — нагадування про товар, який переглянули, але не додали в кошик.
• Advanced Cart Recovery — розширене відновлення кошика з урахуванням його реального складу.
• Автоматичний вивід конкретних товарів у листі через API.
• Персональні рекомендації на основі поведінки конкретного користувача.

Перехід на іншу ecommerce-платформу не розглядався, а розроблення окремої серверної API-інтеграції суттєво збільшила б бюджет і терміни проєкту. Отже, потрібно було розширити наявну інтеграцію «Хорошоп» — SendPulse, не змінюючи кардинально те, що вже працює.

Що можна зробити без додаткового коду

Automation 360 — конструктор автоматизованих email-сценаріїв у SendPulse, який запускає ланцюжки листів у відповідь на події. Частину сценаріїв Automation 360 можна будувати і без скриптів — тільки на подіях, які вже передає готова інтеграція «Хорошоп», або на стандартному пікселі SendPulse, встановленому на сайті.

Наприклад, піксель SendPulse самостійно фіксує перегляди сторінок і базові дії на сайті, а подій «Реєстрація» та «Оформлення замовлення» вистачає для привітальних ланцюжків, підтвердження замовлення чи запиту відгуку після покупки — тобто для сценаріїв, яким не потрібен товарний контекст.

Радимо прочитати:

• «Вітальний лист: як мотивувати нового підписника до покупки»;
• «Відгуки клієнтів: як збирати, оформлювати та використовувати».

Коли ж сценарій має «пам’ятати» конкретні товари — показати саме ту тарілку, яку людина розглядала, або зібрати в листі вміст її кошика — стандартних подій уже не вистачає. У таких випадках у Менеджері подій Automation 360 можна створити власну подію та передавати в неї потрібні змінні.

Власна подія — це, по суті, форма для заповнення. Ви задаєте їй назву, унікальний URL і перелік змінних, які вона прийматиме: email, товари, ціни тощо. Після створення SendPulse видає POST-адресу цієї події, на яку потім надсилаються дані з сайту. Далі цю подію можна вибрати як тригер для сценарію в Automation 360 — так само, як стандартні події «Реєстрація» чи «Замовлення».

Цей формат описаний в інструкції «Як реалізувати передачу масиву даних» бази знань SendPulse.

Різниця в тому, звідки ці дані брати. Якщо їх не видно у стандартній інтеграції CMS, їх потрібно зібрати самостійно. Саме для цього ми й додали проміжний шар з JavaScript та Google Apps Script.

JavaScript — це код, який працює в браузері відвідувача і «бачить» усе, що відбувається на сторінці: який товар переглядають, що додають у кошик. В результаті JavaScript «бачить» дію користувача на сайті, а Google Apps Script приймає ці дані, перевіряє їх і передає далі в SendPulse.

Рішення: власний шар збору поведінкових подій

Щоб не чіпати інтеграцію «Хорошоп» — SendPulse і не будувати повноцінний бекенд, дані було вирішено збирати на стороні браузера і передавати їх у SendPulse напряму, в обхід стандартного механізму.

Якби розробляли окреме серверне API-рішення з такою самою логікою, за попередньою ринковою оцінкою це могло б коштувати близько 110–220 тис. грн, залежно від вимог до надійності, логування й подальшої підтримки. Крім вартості, це означало б окремий цикл розробки, тестування й супроводу. Водночас шар на JavaScript і Google Apps Script вдалося розгорнути значно швидше, без виділеного сервера, і при цьому централізовано керувати логікою в одному місці.

Схематично шлях даних виглядає так:

П’ять компонентів по черзі роблять свою частину роботи:

• Платформа «Хорошоп» — сайт магазину, на якому відбуваються дії користувача: перегляд товару, додавання в кошик, оформлення замовлення.
• JavaScript на сайті — відстежує ці дії та збирає дані про товари: назву, ціну, посилання, зображення.
• Google Apps Script — проміжний сервіс, який приймає дані від скрипта, перевіряє їх і формує готовий JSON-запит. Це структурований пакет даних у текстовому форматі, зрозумілому й для програм, і для читання людиною. У ньому чітко прописано, де email, де масив товарів, де ціна кожного з них. Такий пакет Google Apps Script компонує з сирих даних і відправляє в SendPulse.
• Менеджер подій SendPulse — приймає POST-запит на URL конкретної події: Browse Abandonment або Advanced Cart Recovery. Це технічний спосіб передати дані у форматі JSON. Кожна подія має власну унікальну адресу, тому SendPulse одразу розуміє, який саме сценарій потрібно запустити.
• Automation 360 — запускає сценарій і підставляє отримані дані в лист.

1. JavaScript на сайті: що саме відстежується

Скрипт, розміщений на сторінках «Хорошоп», слідкує за діями, які потрібні для запуску сценаріїв:

• перегляд сторінки товару;
• додавання товару до кошика;
• бездіяльність на сторінці оформлення замовлення;
• вихід з сайту з непорожнім кошиком;
• перехід до завершення замовлення.

JavaScript не отримує всі дані з «Хорошоп» одним способом. Механіка залежить від конкретної дії.

Там, де платформа вже передає потрібну інформацію через callback-функції та JavaScript-об’єкти, скрипт використовує їх напряму. Наприклад, після успішного оформлення замовлення доступний callback checkout_success(order_id, cart, name, email, phone, eventId). Дані про товари в такому випадку можна отримати з cart.products — зокрема назву, ID, артикул, кількість, ціну та зображення.

Якщо для конкретної поведінкової події готового JS-об’єкта немає, дані збираються безпосередньо зі сторінки через DOM та відповідні CSS-селектори. Тому в цій інтеграції використовуються обидва підходи залежно від типу події.

Одночасно скрипт збирає інформацію про товари — назви, ціни, посилання, URL зображень — і формує з них масив: переглянуті позиції або товари в кошику, а також окремий масив рекомендованих товарів із блоку «Дивіться також».

Водночас перевіряються умови, за яких подію взагалі варто надсилати. Наприклад, подія «покинутий перегляд» не має спрацьовувати, якщо товар уже додано в кошик, — інакше користувач отримає два різні листи про той самий товар. А подія «покинутий кошик» не спрацьовує, якщо людина вже оформила замовлення.

Оскільки подію потрібно прив’язати до конкретного отримувача, скрипт також перевіряє, чи відомий email. Він може з’явитися після авторизації, реєстрації, входу в особистий кабінет, заповнення форми підписки, взаємодії з попапом або введення на сторінці оформлення замовлення.

Як формується список переглянутих товарів. Кожен товар перед відправкою треба привести до єдиної структури функцією normalizeViewedProduct(). Вона бере «сирі» дані зі сторінки товару і залишає тільки те, що знадобиться в листі: назву, посилання, зображення та ціни, приведені до числового формату.

function normalizeViewedProduct(product) {
  return {
    product_name: product.product_name,
    product_url: product.product_url,
    image_url: product.image_url,
    price: money(product.price),
    old_price: money(product.old_price) || money(product.price)
  };
}

Далі товар додається у масив переглянутих позицій — не більше шести. Якщо той самий товар переглянули повторно, старий запис прибирається, а новий піднімається на початок списку — так у листі завжди опиняються найсвіжіші перегляди.

function addViewedProduct(product) {
  const key = productKey(product); // унікальний ключ товару
 
  // прибираємо дублікат, якщо товар вже був у списку
  state.items = state.items.filter(item => productKey(item) !== key);
 
  // додаємо на початок і обмежуємо кількість
  state.items.unshift(product);
  state.items = state.items.slice(0, 6);
}

І нарешті — перевірка перед відправкою. Подія піде в SendPulse, лише якщо виконано одразу всі умови: товар не в кошику, оформлення не почалося, замовлення не завершено, є хоча б один переглянутий товар і відомий email або телефон.

function canSend() {
  return (
    !state.cart_started &&      // товар не додано в кошик
    !state.checkout_started &&  // користувач не перейшов до оформлення
    !state.order_completed &&   // замовлення не завершено
    state.items.length > 0 &&   // є хоча б один переглянутий товар
    (state.email || state.phone) // контакт відомий
  );
}

Якщо хоч одна умова не виконується — подія не формується, і дані до SendPulse не надходять.

2. Google Apps Script: проміжний шар між сайтом і SendPulse

Такий проміжний шар вирішує одразу кілька завдань:

• приводить дані з різних сторінок сайту до єдиного формату;
• перевіряє наявність обов’язкових полів перед відправкою;
• формує товарні масиви у структурі, яку розуміє Automation 360;
• дає змогу централізовано змінювати логіку передавання даних в одному місці;
• приховує URL подій SendPulse від відкритого коду сайту — вони залишаються тільки в Google Apps Script.

Після обробки Google Apps Script надсилає POST-запит — тобто запит, яким одна система передає дані іншій, — на адресу відповідної події, заздалегідь створеної в Менеджері подій SendPulse. Ось як виглядає такий запит для сценарію Browse Abandonment.

POST https://events.sendpulse.com/events/id/{event_id}/{contact_list_id}
Content-Type: application/json
 
{
  "email": "customer@example.com",
  "phone": "+38050...",
  "event_date": "2026-07-24",
  "first_name": "Олена",
  "last_name": "Бойко",
  "city": "Київ",
  "items": [
    {
      "product_name": "Тарілка для хліба Villeroy & Boch Manufacture Rock 15,5 см",
      "product_id": "1111",
      "brand": "Villeroy & Boch",
      "category": "Тарілки",
      "product_url": "https://site.com.ua/...",
      "image_url": "https://site.com.ua/content/images/...",
      "price": 1429,
      "old_price": 2156
    }
  ],
  "recommended_products": [
    {
      "product_name": "Набір із 2 блюдець Villeroy & Boch Manufacture Rock 15,5 см",
      "product_url": "https://site.com.ua/...",
      "image_url": "https://site.com.ua/content/images/...",
      "price": 2090,
      "brand": "Villeroy & Boch",
      "category": "Тарілки"
    }
  ]
}

У цій структурі варто звернути увагу на три моменти:

1. Масив items містить до шести переглянутих товарів, а recommended_products — до дванадцяти рекомендованих, які потім можна підставити в окремий блок листа.
2. Перед відправкою Google Apps Script перевіряє обов’язкові поля — якщо немає email/phone або items порожній, запит до SendPulse взагалі не йде.
3. Ціни додатково нормалізуються до числового формату — незалежно від того, як вони записані на сайті: через кому чи крапку.

Як Google Apps Script приймає та передає дані. На стороні Google Apps Script запит приймає функція doPost(e). Вона отримує тіло запиту, перевіряє обов’язкові поля, формує структуру даних для SendPulse і надсилає її через UrlFetchApp.fetch().

function doPost(e) {
  const body = JSON.parse(e.postData.contents);

  if (!body.order_id) {
    return response(false, "No order_id");
  }

  if (!body.email) {
    return response(false, "No email");
  }

  const payload = {
    email: body.email,
    phone: body.phone || "",
    order_id: body.order_id,
    total_sum: Number(body.total_sum || 0),
    items: body.items || []
  };

  const options = {
    method: "post",
    contentType: "application/json",
    payload: JSON.stringify(payload),
    muteHttpExceptions: true
  };

  return UrlFetchApp.fetch(SENDPULSE_URL, options);
}

3. Менеджер подій Automation 360

Для цього кейсу створили дві події — Browse Abandonment і Advanced Cart Recovery.

Разом з кожною подією в SendPulse передаються:

• email як ідентифікатор контакту, номер телефону — за наявності;
• масив основних товарів і масив рекомендованих товарів;
• назви, кількість, актуальні й попередні ціни;
• посилання на сторінки товарів та URL зображень;
• додаткові параметри, специфічні для конкретного сценарію.

Отримавши запит, SendPulse пов’язує подію з контактом за email або телефоном і передає дані у відповідний автоматизований ланцюжок: так само, як це відбувається зі стандартними подіями «Реєстрація» чи «Замовлення», тільки з більшим товарним контекстом.

4. Automation 360: від події до листа

Отримана подія стає стартовою умовою сценарію. Передані змінні та товарні масиви використовуються для формування динамічного вмісту листа.

Це працює так: шаблон листа в Automation 360 не «знає» заздалегідь, які саме товари туди потраплять. Натомість він містить цикл, який під час відправки підставляє реальні дані з отриманої події. Тому один і той самий шаблон автоматично показує різний набір товарів для кожного отримувача.

Це реалізовано циклом, який перебирає масив items і для кожного товару підставляє картинку, назву, ціну та кнопку переходу на сторінку товару.

|[ for item in items[:4] ]|
  <img src="{{item.image_url}}" alt="{{item.product_name}}">
  <p>{{item.product_name}}</p>
  |[ if item.old_price > item.price ]|
    <span>{{item.old_price}} ₴</span>
  |[ endif ]|
  <span>{{item.price}} ₴</span>
  <a href="{{item.product_url}}">Детальніше</a>
|[ endfor ]|

Завдяки цьому один шаблон листа автоматично показує різну кількість товарів для кожного отримувача — від одного до шести, залежно від того, скільки позицій реально переглянув чи додав у кошик користувач. Так виглядає готовий блок у листі про покинутий перегляд.

А поруч, окремим блоком, — персональні рекомендації з масиву recommended_products.

Як протестувати інтеграцію перед запуском

1. Перевірте шлях даних поетапно

Тестувати таку інтеграцію зручніше як послідовність окремих етапів:

«Хорошоп» — Google Apps Script — Менеджер подій SendPulse — Automation 360 — email.

2. Надішліть тестовий POST

Можна окремо протестувати doPost(e) тестовим JSON.

3. Перевірте «Останні дані» події

Після тестового запиту перевірте конкретну подію в Менеджері подій SendPulse: чи отримані email, order_id, items та інші змінні в очікуваному форматі. Успішний POST сам по собі ще не гарантує, що Automation 360 зможе коректно використати дані.

4. Використовуйте логи GAS

console.log(JSON.stringify(body));

console.log(JSON.stringify(payload));

const response = UrlFetchApp.fetch(SENDPULSE_URL, options);

console.log(response.getResponseCode());

console.log(response.getContentText());

5. Якщо лист не надходить

Перевірте запуск Automation 360 і прив’язку події до контакту. Особливу увагу варто приділити формату email і phone: проблема може бути в ідентифікації отримувача або умовах самого сценарію.

Типові помилки

• порожнє тіло POST-запиту;
• некоректний JSON;
• відсутність обов’язкового email або іншого ідентифікатора;
• неправильні назви змінних у payload;
• невідповідність типів даних;
• неправильний URL події SendPulse;
• повторне надсилання тієї самої події.

Сценарій «Покинутий перегляд товару»

Покинутий перегляд — сценарій для тих, хто вже зацікавився товаром, але ще не дійшов до кошика. Це більш ранній етап взаємодії, ніж покинутий кошик, тож він охоплює ширшу аудиторію потенційних покупців — тих, хто ще навіть не почав оформлення.

Для реалізації потрібно було виконати три завдання: визначити, що перегляд товару можна вважати «змістовним», переконатися, що користувач не пішов далі кошиком, і передати в SendPulse усе необхідне для персоналізованого листа.

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

Перегляд фіксується як покинутий, якщо одночасно виконані три умови:

• користувач перебував на сторінці товару щонайменше одну хвилину або залишив її;
• товар не додано в кошик;
• email або телефон користувача вже відомий.

Користувач після додавання товару до кошика переходить у описаний вище сценарій Advanced Cart Recovery. Подія Browse Abandonment для цього товару більше не формується, а весь подальший трекінг веде кошик.

Хвилина бездіяльності — це клієнтська JavaScript-логіка. На сторінці запускається таймер на 60 секунд. Він скидається щоразу, коли користувач рухає мишкою, скролить сторінку, натискає клавіші, клікає або взаємодіє з touch-екраном. Якщо протягом хвилини активності немає, виконується перевірка умов для формування поведінкової події.

var inactivityTimer;

function resetTimer() {
  clearTimeout(inactivityTimer);

  inactivityTimer = setTimeout(function() {
    // trigger event
  }, 60000);
}

['mousemove', 'keydown', 'scroll', 'touchstart', 'click']
  .forEach(function(eventName) {
    document.addEventListener(eventName, resetTimer);
  });

resetTimer();

Що передається в SendPulse

У подію Browse Abandonment потрапляє до шести переглянутих товарів — з назвою, посиланням, зображенням, актуальною і попередньою ціною, — а також окремий масив рекомендацій із блоку «Дивіться також»: теж до шести позицій.

У Automation 360 сценарій показує в листі самі переглянуті товари з актуальними цінами й зображеннями, кнопки переходу на сторінки товарів і блок рекомендацій — без ручного наповнення для кожного отримувача окремо.

За перший тиждень після запуску сценарій відпрацював стабільно, без помилок.

Сценарій «Покинутий кошик»

Покинутий кошик — один з найпоширеніших сценаріїв в ecommerce. Але тут потрібна розширена механіка, яка враховує реальний склад кошика, поведінку користувача на сайті й факт переходу до оформлення.

Коли кошик вважається покинутим

Подія Advanced Cart Recovery формується, якщо одночасно:

• у кошику залишається хоча б один товар;
• email користувача вже відомий системі;
• користувач не проявляє активності на сторінці оформлення протягом хвилини або йде із сайту з непорожнім кошиком;
• оформлення замовлення не завершене.

Для десктопної версії намір залишити сайт можна додатково визначати за рухом курсора. Якщо курсор виходить за верхню межу вікна браузера, скрипт отримує сигнал exit-intent і перевіряє, чи виконані інші умови для формування події.

document.addEventListener('mouseout', function(e) {
  if (!e.relatedTarget && e.clientY <= 0) {
    // exit-intent signal
  }
});

Кошик визнається покинутим і тоді, коли людина просто пішла на іншу сторінку сайту.

Важливі нюанси

Якщо на сайті скрипти зазвичай додаються через Google Tag Manager, цей підхід можна реалізувати і так: JavaScript, що відстежує поведінкові події, публікувати як користувацький тег GTM, а не вшивати напряму в код сторінок. Логіка збору даних від цього не змінюється — змінюється лише спосіб розгортання й керування версіями скрипта.

Email — не єдиний канал для цих подій. Ті самі Browse Abandonment і Advanced Cart Recovery можна доповнити web push-сповіщеннями через SendPulse: вони працюють за тією самою логікою подій, лише в іншому каналі комунікації.

Як відрізнити завершення замовлення від проміжних кроків

На сайті «Хорошоп» додавання товару в кошик відкриває проміжний попап з вмістом кошика й рекомендаціями. Взаємодія з цим вікном — ще не покупка, тож вона не має скасовувати сценарій. Завершеною дією вважається лише натискання кнопки «Оформити замовлення» безпосередньо на сторінці checkout — тільки після цього подія покинутого кошика не формується.

Що передається в SendPulse

У подію може входити до шести товарів з кошика — з назвою, кількістю, актуальною й попередньою ціною, посиланням і зображенням, — а також окремий масив рекомендованих товарів, показаних користувачу в попапі після додавання в кошик.

Захист від дублів

Користувач може кілька разів відкривати сторінку оформлення чи повертатись до кошика — без додаткового контролю кожна така дія повторно запускала б той самий сценарій. Щоб цього уникнути, для кошика формується унікальний «відбиток» на основі його складу: перед відправкою система перевіряє, чи вже надсилалась подія для такого самого набору товарів.

В Automation 360 сценарій показує товари, залишені без оформлення, їхню кількість і ціни, зображення, кнопки переходу на сторінки товарів, блок рекомендацій і заклик повернутися до покупки — знову ж таки, без ручного наповнення для кожного отримувача.

Статистика за перший тиждень показала стабільну роботу і на цьому сценарії.

За звітом SendPulse за серпень 2026 року обидва сценарії вже працювали:

• «Покинутий кошик»: 189 доставлених листів, Open Rate — 41,26%, CTR — 6,34%.
• «Покинутий перегляд»: 289 доставлених листів, Open Rate — 32,52%, CTR — 1,73%.

Що дає передавання власних подій в ecommerce

Стандартні інтеграції зазвичай передають лише заздалегідь визначений набір даних — його достатньо для базових транзакційних повідомлень, але не для сценаріїв, які мають враховувати поведінку користувача до й після покупки.

Власні події в Менеджері подій Automation 360 дають змогу доповнити готову інтеграцію: передавати в SendPulse весь пов’язаний з дією контекст — контакти, товари, ціни, кількість, зображення, посилання, рекомендації. У цьому проєкті це дало змогу:

• Запускати автоматизацію після покинутого перегляду і передавати до шести переглянутих товарів.
• Визначати покинутий кошик за бездіяльністю або виходом із сайту й передавати його актуальний склад.
• Автоматично відображати товари в листі без ручного наповнення.
• Додавати персоналізовані товарні рекомендації.
• Контролювати повторне надсилання однакових подій.
• Коректно скасовувати сценарій, коли користувач перейшов на наступний крок покупки.

Той самий принцип працює і для інших дій

Тригером для власної події може стати будь-яка значуща дія, яку сайт здатний зафіксувати: перегляд категорії без переходу до покупки, пошук товару, додавання до списку бажань, зниження ціни на переглянутий товар, запит відгуку після покупки. Для кожного такого сценарію окремо визначаються умови запуску, перелік даних, спосіб ідентифікації контакту та дія, яка сценарій скасовує.

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

Правова основа

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

У першу чергу на сайт треба додати консент-банер, який буде попередньо запитувати згоду на збір та обробку поведінкових даних: cookie, трекінг переглядів і вмісту кошика. Банер має з’являтись ще до того, як буде активований будь-який зі скриптів для збирання інформації.

Тригерні листи на основі власних подій — це маркетингова комунікація, тому для них потрібна згода та обов’язкове посилання чи кнопка для відписки в кожному листі.

Чеклист впровадження

Тепер коротко та чітко щодо впровадження цього кейсу:

1. Перевірте, чи дає змогу ваша CMS додавати кастомний JavaScript на сторінки сайту.
2. Переконайтеся, що тариф SendPulse підтримує потрібну кількість власних подій..
3. У Менеджері подій SendPulse створіть окрему подію для кожного сценарію — Browse Abandonment, Advanced Cart Recovery — і скопіюйте її POST-URL.
4. Опублікуйте Google Apps Script як Web App і збережіть його URL.
5. Додайте на сайт JavaScript, який відстежує потрібні дії — перегляд товару, додавання в кошик, бездіяльність на checkout, вихід із сайту.
6. Налаштуйте в JS перевірку умов відправки canSend і надсилання POST-запиту на GAS.
7. У Google Apps Script реалізуйте doPost(e): валідацію обов’язкових полів і UrlFetchApp.fetch() до SendPulse.
8. Протестуйте ланцюжок тестовим POST-запитом і перевірте «Останні дані» події в SendPulse.
9. У Automation 360 побудуйте сценарій і шаблон листа з циклом по масиву товарів.
10. Запустіть сценарій на невеликій аудиторії й простежте статистику виконань у Google Apps Script — Executions протягом перших днів.

Обмеження підходу

Google Apps Script свідомо обрали як «золоту середину» між JavaScript на сайті та SendPulse: для поточного обсягу подій магазину цього достатньо. Але в GAS є технічні обмеження: квота UrlFetchApp — 20 тис. запитів на добу для звичайного акаунта Gmail та 100 тисяч для Google Workspace. Обмеження виконання скрипта — 6 хвилин, до 30 одночасних виконань.

GAS відносно повільніший, тому при різких сплесках трафіку можливі затримки. Для великого магазину з високим навантаженням у пік це може стати проблемою. Тож якщо потрібно масштабуватися, варто розглянути Cloudflare Workers, Google Cloud Run або Cloud Functions, AWS Lambda або Vercel/Netlify Functions.

Однак для магазину, який не має навантажень на рівні великого маркетплейсу, описаного у кейсі рішення цілком вистачає.

Висновок

У цьому кейсі обмеження закрили без переносу магазину з «Хорошоп» і без окремої серверної інтеграції: JavaScript на сайті фіксує потрібні дії й збирає дані про товари, Google Apps Script обробляє їх і надсилає в SendPulse, а власні події в Automation 360 запускають відповідні сценарії.

Такий підхід працює на будь-якій CMS чи ecommerce-платформі, яка дає змогу додати власний JavaScript на сторінки сайту. За наявності такої можливості можна зібрати поведінкові дані, створити власні події й передавати їх у SendPulse для запуску персоналізованих сценаріїв Automation 360.

Додатковий шар збору й обробки поведінкових даних розширює функціональність готової інтеграції без зміни платформи. І що повніший контекст отримує Automation 360, то точнішими і релевантнішими будуть повідомлення для кожного користувача.