Перші кроки
Дані користувача
- Огляд адаптивного 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
Зміна системи
Документи
Інтеграція
Найменування користувацьких подій
Стандартизуйте іменування ваших користувацьких подій та їх параметрів від початку роботи в eSputnik. Це полегшить інтерпретацію коду, і будь-який учасник вашої команди зможе легко зрозуміти, що означає кожна подія.
Що таке стандартизація найменування
Стандартизація найменування — це дотримання певних правил при назві подій та їх параметрів, які ви передаєте на інші платформи. Стандартизовані назви спростять аналітику та налаштування трекінгу.
Переваги стандартизації найменування
Завдяки стандартизованому найменуванню ваші дані будуть однакові, зручні для використання та розуміння:
- Уніфікація. Коли всі події та їх параметри мають однакові назви на всіх платформах, це спрощує їхнє використання.
- Зручність використання. У міру зростання вашого бізнесу вам потрібно буде відстежувати дедалі більше нових подій. Стандартизоване найменування спростить реалізацію їх передачі і заощадить час ваших розробників.
- Прозорість. З тими самими даними працюють різні команди: розробники, маркетологи, аналітики тощо. Стандартизовані назви дозволяють кожному легко зрозуміти подію та її параметри для подальшого аналізу, експериментів та інших дій.
Схема ObjectAction
Без чітких і стандартних правил найменування подій ваша аналітика ставатиме все більш заплутаною та неясною. Наприклад, коли користувач входить на ваш сайт, ви можете надіслати цю подію як Log in, Login або User logged in.
Щоб уникнути подібних проблем та ефективно використовувати всі дані, створіть стандартну схему найменування та дотримуйтесь її під час створення всіх подій та їх параметрів.
Ми рекомендуємо створювати назви подій із двох частин: об'єкта та пов'язаної з ним дії. Наприклад, CartAbandoned або ProductViewed.
Використовуйте дієслова в минулому часі, щоб наголосити на тому, що події створилися після того, як відбулися дії.
Схема найменування подій ObjectAction допоможе вам
- Побудувати вирву для аналізу взаємодії з певними функціями вашого сайту: ви побачите дії, пов'язані з об'єктами, в алфавітному порядку.
- Легко знаходити події в історії подій.
- Розуміти, які події фіксуються в аналітиці: очевидно, що подія з назвою ProductAddedToWishlist означає додавання товару до списку бажань.
Параметри подій
Чим більше параметрів ви передасте в події, тим ширшу картину взаємодії з брендом ви отримаєте. Наприклад, у події ProductPurchased можна передати загальну вартість та вартість кожного товару, величину знижки, опис товару, спосіб доставки тощо.
Створіть список стандартних параметрів для всіх подій. Наприклад, у подіях CartAbandoned та ProductViewed потрібно передавати ProductId, ProductName, ProductDescription, ProductCost тощо.
Стандартизовані параметри подій дозволять вам створювати умовні групи на основі поведінки контактів на вашому сайті та у додатку для маркетингової аналітики та цільових кампаній.
CamelCase формат
Використовуйте 2 різновиди формату CamelCase:
- Кожне слово у назві події пишеться з великої літери без пробілів, підкреслень та інших спеціальних символів: ProductPurchased.
- Перше слово в назві параметра пишеться з малої літери, а кожне наступне слово — з великої, без пробілів, підкреслень та інших спеціальних символів: imageUrl.
Список стандартних подій та параметрів
Назва події | Параметри |
CartAbandoned | productName, productPrice, productUrl, imageUrl, brand, tagsWeight, tagsOldPrice |
ContactCreated | externalCustomerId, email, phone, token |
Примітка
Всі події повинні включати стандартну інформацію про пристрої та контакти.