Первые шаги
Отслеживание событий и поведения
Пользовательские данные
- Создание сквозных модулей
- Оформление промовкладки для Gmail
- Настройка Smart-элементов
- Обзор адаптивного email-редактора
- Создание футера
- Настройка адаптивности
- Добавление Rolloverʼа
- Настройка блока "Меню"
- Добавление анкорных ссылок
- Робота с блоком "Изображения"
- Работа с блоком "Соцсети"
- Добавление таблицы в письмо
- Добавление фона в письмо
- Добавление пользовательских шрифтов
- Добавление кастомных иконок соцсетей
- Создание кнопки CTA
- Создание оформления для письма
- Редактирование HTML и CSS
- Работа с блоком "Баннер"
- Добавление блока "Видео"
- Библиотека блоков (Модули)
- Работа с блоком “Таймер"
Омниканальность
- Настройка универсальных ссылок (deeplinks & Universal links)
- Создание Google проекта для Mob Push
- Подключение мобильного приложения
- Планирование мобильных push-уведомлений
- Настройка аналитики доставляемости и кликов
- Управление ключами доступа к мобильному SDK
- Создание мобильных push-сообщений
- SDK для мобильных приложений
- Отчеты по мобильным push-рассылкам
Автоматизация
- Настройка формы подписки и двойного подтверждения
- Как настроить автоматическое поздравление с Днем рождения
- Согласование переменных события со сценарием на примере сценария "Заказ доставлен"
- Сегментация триггерных писем по дополнительным полям
- Запуск сценария после импорта контактов
- Контроль триггеров
- Как привязать сценарий к кнопке
- Устранение неполадок в работе сценариев
- Как настроить автоматическую реактивацию подписчиков и клиентов
- Настройка сценария для опросов и сбора отзывов
- Как отправить рассылку непрочитавшим
- Создание регулярного сценария для группы (видео)
- Создание welcome-цепочки для email-сообщений
Персонализация
- HTTP-запрос для передачи промокода из сообщения в карточку контакта
- Принципы генерации промокодов с помощью PHP/JAVA
- Подстановка промокода с использованием API
- Загрузка промокодов для использования в сценарии
- Подстановка промокода с помощью персонализации
- Подстановка промокода из файла
- Генерация промокодов в сценарии
- Отправка промокода с помощью препроцессора
Аналитика
- Настройка визуализации дохода от рассылок
- Отслеживание эффективности рассылок в Google Analytics
- Отчет по AMP-рассылке
- Отчет по Viber-рассылке
- Как корректно открыть CSV-файл после экспорта
- Отчёт по email-рассылке
- Настройка передачи UTM-меток
- Отчет по Web-push рассылке
- Отчет по SMS-рассылке
- Отчеты по мобильным push-рассылкам
Мультиязычность
API
- API-ключи
- Ресурсы API для добавления контактов
- Использование API-ресурса Send prepared message
- Получение рекомендаций по API ресурсом Contact recommendations based on web tracking
- Использование API-ресурса Generate event
- Интеграция с API – частые вопросы
- Передача заказов с помощью ресурса Generate event
Смена системы
Документы
Интеграция
Согласование переменных события со сценарием на примере сценария "Заказ доставлен"
В этой статье мы рассмотрим один из самых популярных вопросов к нашей технической поддержке – как согласовываются переменные события со сценарием – на примере одного из самых популярных транзакционных сценариев “Заказ доставлен”. Корректное написание переменных нужно для того, чтобы сценарий работал без сбоев и все необходимые параметры подставлялись в контент письма. Поэтому, если вы создали сценарий, но он почему-то не работает – проверьте корректность настроек следовательно этой инструкции.
Базовые шаги
В подготовке любого сценария, который отправляет письма с информацией о данных пользователя, адресе доставки, номере заказа и пр., должны учитываться следующие этапы:
-
передача данных о заказе по 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 мин. Это обеспечит корректную работу сценария и последовательное исполнение всех запросов в системе.