Перші кроки
Дані користувача
- Огляд адаптивного email-редактора
- Cтворення оформлення для листа
- Створення синхронізованих модулів
- Налаштування адаптивності
- Налаштування smart-контейнерів
- Оформлення промовкладки для Gmail
- Додавання Ролловера
- Додавання анкорних посилань
- Бібліотека модулів
- Додавання таблиці до листа
- Додавання кастомних шрифтів
- Створення кнопки СТA
- Робота з блоком "Зображення"
- Робота з блоком “Таймер"
- Використання ШІ в email-редакторі
- Підтримка месенджер-протоколів поштовими клієнтами та платформами
Омніканальність
- SDK для мобільних застосунків
- Керування ключами доступу до мобільного SDK
- Підключення мобільного застосунку
- Створення та завантаження ключа Firebase
- Створення мобільних push-повідомлень
- Налаштування аналітики доставлень та кліків
- Планування мобільних push-повідомлень
- Типи діплінків
- Надсилання тестових повідомлень із налагодження запитів
- Налаштування віджетів для сайту
- Гейміфікація віджетів
- Виклик віджета
- Налаштування геоданих для правил виклику віджетів
- Збереження даних із віджетів у поля контактів
- Захист від роздратування
- Дії після підписки
- Заміна системного сценарію Double Opt-In
- Створення pop-up-форм за допомогою Google Tag Manager або WordPress
- Надсилання подій з віджетів eSputnik до Google Analytics
- A/B-тестування віджетів
- Збір контактних даних за допомогою форм запитів
Автоматизація
- Налаштування та редагування сценаріїв
- Налаштування умов запуску та зупинки сценарію
- Блок “Старт”
- Група блоків “Популярні”
- Група блоків “Повідомлення”
- Використання блока повідомлень “Одне з багатьох”
- Група блоків “Контакт”
- Група блоків "Умови"
- Група блоків “Інше”
- Група блоків “Повідомлення на групу”
- Група блоків “Час”
- Розширені параметри блоків сценаріїв
- Дозволений час відправлення
- Вебхуки в сценаріях
- Відстеження історії запусків сценарію
- Якщо сценарій не працює
- Подвійне підтвердження підписки
- Вітальна серія
- Вітальна серія із сегментацією за категоріями
- Запуск сценарію після імпорту контактів
- Регулярний сценарій для групи
- Вітання з днем народження
- Привʼязка сценарію до кнопки
- Використання змінних із замовлення у сценарії
- Збір відгуків про замовлення
- Реактивація клієнтів та підписників
- Відправка розсилки непрочитавшим
- Налаштування додаткових розсилок
- Відправлення нагадувань в заданий користувачем час
- А/B-тестування в сценаріях
Персоналізація
- Підстановка промокоду з файлу
- Підстановка промокоду з використанням API
- Принципи генерації промокодів за допомогою PHP/JAVA
- Підстановка промокоду за допомогою персоналізації
- Завантаження промокодів для використання в сценарії
- Генерація промокодів у сценарії
- Відправлення промокоду за допомогою передпроцесора
- HTTP-запит для передачі промокоду з повідомлення до картки контакту
Аналітика
- Звіт щодо email-розсилки
- Звіт щодо SMS-розсилки
- Звіт щодо розсилки Web Push
- Звіт щодо Viber-розсилки
- Звіт щодо розсилки Mob Push
- Звіт щодо розсилки App Inbox
- Звіт щодо Telegram-розсилки
- Звіт зі взаємодії з In-App
- Звіт зі взаємодії з віджетами
- Звіт щодо тригерної розсилки
- Звіт щодо AMP-розсилки
- Звіт щодо мультимовної розсилки
- Налаштування передачі UTM-міток
- Візуалізація доходу
- Відстеження ефективності кампаній у Google Analytics 4
- Статистика повідомлень
Мультимовність
Відстеження подій та поведінки
- Події для запуску тригерних розсилок
- Найменування користувацьких подій
- Валідація параметрів подій
- Відстеження активності на сайті за допомогою Generate event
- Підстановка даних з подій в повідомлення
- Розгалуження сценарію в залежності від параметрів події
- Відстеження активності клієнтів у мобільних застосунках
- Вебхуки для відстеження активності
- Аналітика подій
Товарні рекомендації
API
- Поширені питання: Інтеграція з API
- API-ключі
- Ресурси API для додавання контактів
- Використання API-ресурсу Generate event
- Передача замовлень API-ресурсом Generate event
- Отримання рекомендацій щодо API ресурсом Contact recommendations based on web tracking
- Використання API-ресурсу Send prepared message
Зміна системи
Документи
Інтеграція
Передавання замовлень API-ресурсом Add orders
Для передавання замовлень необхідно налаштувати виклик спеціального API-ресурсу Add orders. У запиті можна передати до 1000 замовлень.
Кожного разу, коли ви передаєте замовлення API-ресурсом, у системі створюється подія, яка може запускати сценарій. Для кожного статусу замовлення створюється відповідний тип події, що дозволяє вам налаштувати окремі тригери.
Назви подій
Назви подій складаються з двох частин: зі слова order і статусу замовлення, наприклад: orderINITIALIZED, orderIN_PROGRESS, odrerDELIVERED, orderCANCELLED, orderABANDONED_SHOPPING_CART.
Щоб переглянути створені події, перейдіть до розділу “Тригери” → “Історія подій”:
Параметри подій
Кожна подія містить обов'язкові параметри та може містити додаткові параметри:
-
${eventKey} — ключ унікальності замовлення. Передається в поле externalOrderId. Використовується як ідентифікатор замовлення;
-
${orderId} — ID замовлення в системі; параметр потрібний для роботи сценарію.
Як ідентифікатор контакту повинен використовуватися один із таких параметрів:
-
${externalCustomerId} — зовнішній ID контакту;
-
${email} — email-адреса контакту;
-
${phone} — номер телефону контакту.
Важливо
Якщо в замовленні не переданий зовнішній ID, email або номер телефону, то система не пов'яже контакти із замовленням і не відправить повідомлення цим контактам. У таких випадках ID контакту можна побачити на вкладці “Тригери” → “Замовлення” → стовпець “Контактні дані”.
Щоб замінити значення параметрів повідомлення, передавайте поля з параметрами події у вигляді масиву.
-
Обов'язкові поля у масиві ordes: externalOrderId, totalCost, status, date, currency.
-
Обов'язкові поля у масиві items: externalItemId, quantity.
Зверніть увагу
Ціна переданих у замовленні товарів повинна співпадати з значенням totalCost (загальна сума замовлення). Якщо клієнт купляє товар зі знижкою, вона повинна враховуватись у полі items.cost для кожного товару.
Масив з товарами items можна не передавати, якщо в листах дані щодо товарів вам не потрібні або ви передаєте замовлення тільки для RFM-аналізу.
Див. повний перелік полів замовлення з описами>
Приклад тіла запиту:
{
"orders": [{
"externalOrderId": "100500",
"externalCustomerId": "12345",
"totalCost": 1000,
"status": "INITIALIZED",
"date": "2017-03-08T09:30:00+02:00",
"email": "mail@example.com",
"phone": "380942583691",
"firstName": "John",
"lastName": "Smith",
"currency": "USD",
"shipping": 10,
"discount": 0,
"deliveryMethod": "express",
"paymentMethod": "cash",
"deliveryAddress": "First str. 1",
"items": [{
"externalItemId": "200600",
"name": "Super Device",
"category": "devices",
"quantity": 1,
"cost": 990,
"url": "http://example.com/item/200600",
"imageUrl": "http://example.com/item/200600/image.png",
"description": "High quality"
}]
}]
}
Вдала відповідь на запит міститиме статус 200. У тілі відповіді також передається перелік замовлень, які неможливо додати або оновити.
Можливі причини:
- Одне або кілька обов'язкових полів порожні або невірний формат значень.
- Усі наступні необов'язкові поля порожні: externalCustomerId, email, phone.Для створення замовлення необхідна наявність хоча б одного з них.
Важливо
Для формування RFM-таблиці та візуалізації доходу від розсилок на вкладці "Звіти" використовуються тільки замовлення зі статусом DELIVERED.
Виключення становлять замовлення, отримані з мобільного SDK, — в такому випадку за замовчуванням у візуалізації доходу враховуються статуси INITIALIZED та DELIVERED. За необхідністю врахування статусів INITIALIZED можна відключити — для цього зверніться у нашу службу підтримки support@esputnik.com
За замовленнями зі статусом DELIVERED можна налаштувати сегментацію з такими умовами: середній чек, кількість продажів та дата останнього продажу.
ABANDONED_SHOPPING_CART — статус для покинутих кошиків. Використовуйте цей статус, якщо ви самі займаєтесь визначенням покинутих кошиків. При використанні веб-трекінгу налаштовувати API для покинутих кошиків не потрібно.
Для оновлення статусу або інших даних замовлення передавайте оновлене замовлення з тим самим externalOrderId. За цим параметром у системі визначається унікальність замовлень.
Перевірка параметрів подій
Щоб перевірити правильність передачі замовлення, перейдіть до розділу: “Тригери” — “Замовлення” вашого облікового запису eSputnik. Натисніть ID замовлення, і перегляньте всі поля у форматі JSON.
Щоб переглянути інформацію про контакт, натисніть значок "Попередній перегляд контакту".
Важливо
- Для кожного унікального контакту передавайте унікальний externalCustomerId в замовленні, з номером телефону і поштою, які будуть збігатися в замовленні та картці контакту.
- Якщо раніше вже було замовлення з таким externalCustomerId, то система відразу записує нове замовлення тому ж контакту. Якщо такого externalCustomerId не було раніше, то відбудеться перевірка за номером телефону та поштою.
Створення сценаріїв для тригерних розсилок
1. Перейдіть до розділу "Тригери" → "Сценарії". Натисніть кнопку "Новий сценарій".
2. Вкажіть назву сценарію (“Замовлення доставлено”, “Замовлення в процесі” тощо).
3. Додайте до сценарію такі блоки:
- Блок “Задача” — “Отримати замовлення”. За допомогою цього блоку система витягне всі дані щодо замовлення й передасть у лист;
- Блок відправлення повідомлення. Виберіть повідомлення, яке ви заздалегідь створили для цього сценарію.
Замість одного повідомлення можна зробити серію. Наприклад, через 1-2 тижні після повідомлення про доставлене замовлення відправити прохання про відгук.