Первые шаги
Отслеживание событий и поведения
Пользовательские данные
- Обзор адаптивного email-редактора
- Создание оформления для письма
- Создание сквозных модулей
- Настройка адаптивности
- Настройка Smart-элементов
- Оформление промовкладки для Gmail
- Добавление Rolloverʼа
- Добавление фона в письмо
- Добавление анкорных ссылок
- Библиотека блоков (Модули)
- Добавление блока "Видео"
- Добавление таблицы в письмо
- Работа с блоком "Баннер"
- Добавление пользовательских шрифтов
- Добавление кастомных иконок соцсетей
- Работа с блоком "Соцсети"
- Создание кнопки CTA
- Редактирование HTML и CSS
- Робота с блоком "Изображения"
- Работа с блоком “Таймер"
- Настройка блока "Меню"
- Создание футера
Омниканальность
- SDK для мобильных приложений
- Управление ключами доступа к мобильному SDK
- Подключение мобильного приложения
- Создание Google проекта для Mob Push
- Создание мобильных push-сообщений
- Настройка аналитики доставляемости и кликов
- Планирование мобильных push-уведомлений
- Настройка универсальных ссылок (deeplinks & Universal links)
- Отчеты по мобильным push-рассылкам
Автоматизация
- Настройка дополнительных рассылок
- Двойное подтверждение подписки
- Приветственная серия
- Приветственная серия с сегментацией по категориям
- Запуск сценария после импорта контактов
- Регулярный сценарий для группы
- Поздравление с днем рождения
- Привязка сценария к кнопке
- Согласование переменных события со сценарием на примере сценария "Заказ доставлен"
- Сбор отзывов о заказе
- Реактивация клиентов и подписчиков
- Отправка рассылки непрочитавшим
Персонализация
- Подстановка промокода из файла
- Подстановка промокода с использованием API
- Принципы генерации промокодов с помощью PHP/JAVA
- Подстановка промокода с помощью персонализации
- Загрузка промокодов для использования в сценарии
- Генерация промокодов в сценарии
- Отправка промокода с помощью препроцессора
- HTTP-запрос для передачи промокода из сообщения в карточку контакта
Аналитика
- Отчёт по email-рассылке
- Отчет по AMP-рассылке
- Отчеты по мобильным push-рассылкам
- Отчет по SMS-рассылке
- Отчет по Web-push рассылке
- Отчет по Viber-рассылке
- Настройка передачи UTM-меток
- Визуализация дохода от рассылок
- Отслеживание эффективности рассылок в Google Analytics
- Как открыть CSV-файл после экспорта
Мультиязычность
Товарные рекомендации
API
Смена системы
Документы
Интеграция
Согласование переменных события со сценарием на примере сценария "Заказ доставлен"
В этой статье мы рассмотрим один из самых популярных вопросов к нашей технической поддержке – как согласовываются переменные события со сценарием – на примере одного из самых популярных транзакционных сценариев “Заказ доставлен”. Корректное написание переменных нужно для того, чтобы сценарий работал без сбоев и все необходимые параметры подставлялись в контент письма. Поэтому, если вы создали сценарий, но он почему-то не работает – проверьте корректность настроек следовательно этой инструкции.
Базовые шаги
В подготовке любого сценария, который отправляет письма с информацией о данных пользователя, адресе доставки, номере заказа и пр., должны учитываться следующие этапы:
-
передача данных о заказе по API;
-
подготовка письма с динамическим контентом;
-
настройка сценария для отправки триггерного письма.
Подробную информацию о настройке всех этих этапов мы описали в этой инструкции.
Передача данных о заказе
Для передачи данных о заказах в системе используется API-ресурс Add orders. В запросе передается один или несколько заказов, каждый из которых содержит обязательные и дополнительные поля.
Формат запроса и описание всех полей доступны здесь.
Обязательные поля для массива orders
- ExternalOrderId,
- ExternalCustomerId,
- TotalCost,
- Status,
- Date,
- Email или Phone
Обязательные поля для массива items
- ExternalItemId,
- Name,
- Quantity,
- Cost,
- Url,
- ImageUrl
Также для заказов используются несколько важных статусов, которые отображают шаги воронки продаж:
-
Только созданный заказ обычно имеет статус INITIALIZED.
-
Заказ, который находится в процессе доставки, отображается со статусом IN_PROGRESS.
-
Для оплаченного и доставленного используется статус DELIVERED.
-
А для отмененного, соответственно, – CANCELLED.
Такое распределение нам нужно прежде всего для того, чтобы точно понимать, на каком этапе находятся пользователь и не слать сообщения о доставке тем, кто отменил заказ или только его создал.
Создание событий
Каждый раз, когда вы передаете данные о заказах по API, в системе создаются соответствующие события, которые в дальнейшем могут использоваться как условие, запускающее триггерный сценарий.
Для каждого статуса заказа создается релевантное событие, названия которых состоят из слова order и дописанного к нему статуса. Например, INITIALIZED = orderINITIALIZED, IN_PROGRESS = orderIN_PROGRESS, DELIVERED = orderDELIVERED, CANCELLED = orderCANCELLED.
Их мы можем видеть в разделе "Триггеры" → “История событий” в системе eSputnik. Перед вами откроется список последних событий, которые были переданы в систему.
В каждом из них есть свой ключ. В случае с событиями о заказах ими будут идентификаторы заказов (те, что передаются в параметре externalOrderId).
Обратите внимание!
Матчинг параметров “extrenalCustomerId” и “ContactId” происходит при первой передаче заказа. Соответственно, в последующих заказах, даже если в теле заказа указать “email” нового контакта, но “extrenalCustomerId”, от контакта, который уже есть в системе, то “Id” будет передаваться в параметрах события тому контакту, с которым был первоначальный матчинг.
Например, события по заказам включают следующие стандартные переменные:
-
${eventKey} – ключ уникальности заказа, содержит значение поля externalOrderId;
-
${orderId} – id заказа в базе eSputnik. Параметр нужен для работы сценария;
-
${contactId} – id контакта в eSputnik;
-
${EmailAddress} – email-адрес покупателя (если передан в заказе);
-
${SMS} – номер телефона покупателя (если передан в заказе).
Правила написания параметров событий в сценариях
Соблюдайте написание параметров
Параметры из событий необходимо прописывать в сценариях именно в том виде, в котором они были созданы. Это значит, что если в событии о заказах передается стандартный параметр “EmailAddress”, то переменная в поле для ввода email в сценарии также должна называться “EmailAddress”. Другие варианты написания типа “email” или “EmaiL” работать в сценарии не будут.
Для удобства пользователей системные события (сгенерированные запросом “subscribe” либо регулярным сценарием) имеют ряд стандартных параметров, поэтому такие блоки сценариев обычно работают по умолчанию, даже без прописанных вручную переменных. Однако если вы изменили событие для запуска сценария на отличное от стандартного, то отрабатывать по умолчанию сценарий не будет. Во избежание путаницы команда eSputnik рекомендует вручную прописывать переменные в сценарии. В таком случае сценарии всегда будут работать исправно.
Проверка на вхождение в группу
Если в запросе “subscribe” указан список групп, в которые должен добавиться контакт при подписке, а после в сценарии предусмотрена проверка на вхождение в одну из этих групп, используйте между этими действиями таймер минимум на 4 мин. Это обеспечит корректную работу сценария и последовательное исполнение всех запросов в системе.