Новые возможности и вызовы омниканального маркетинга

Тезисы вебинара:

1. Какие изменения произошли в мире omnichannel-маркетинга.
2. Как можно быстро внедрять нововведения, используя eSputnik, и достигать больших результатов.
3. Прогнозы на этот год и ближайшие обновления нашего сервиса, которые точно упростят работу пользователям.

Customer Data Platform

В базе того, что сейчас движет всем direct-маркетингом, лежит понятие CDP. Раньше мы использовали CRM. Разница между ними небольшая. CRM – это система, которая чаще всего помогает продажникам: там видно, кто и как покупал, когда и с кем созванивался (если есть конкретный контакт). То есть основные задачи CRM – это аналитика и продажи. Все то же самое, только с точки зрения маркетинга, лежит в области CDP. И тут сбор данных более важен, потому что сами данные (в том числе и те, которые получаем, судя по поведению на сайте о пользователе, о котором мы ничего не знаем) должны потом быть сегментированы.

Есть 4 крупные задачи, которые нужно решить CDP:

1. сбор данных;
2. определение, к кому эти данные относятся (нужно понять, что человек, который сейчас на сайте, смотрел уже товар и что это тот самый, который есть в базе email, поэтому я могу ему отправить “брошенные корзины”, “брошенные просмотры” );
3. сегментирование (группирование людей);
4. активирование (есть сегмент, у которого сегодня день рождения, и его нужно как-то активизировать: связаться с ним, отправить сообщение).

Email Marketing Infrastructure

Когда мы говорим в общем про инфраструктуру email-маркетинга, то она строится немного сложнее. Я расписал так, чтобы было понятно, где скрывается правильное сообщение, время, контакт и канал.

У нас есть база, куда собираются данные отовсюду и привязываются к человеку. Из этого создается сегмент. Чем больше микросегментов, тем больше мы можем отправлять автоматических микротриггеров, но чем больше таких триггеров, тем больше для них нужно сформировать сообщений. Вот тут и работает механизм персонализации, когда мы используем тот же набор данных, но можем подобрать определенный контент для каждого человека. А когда мы знаем, какой контент хочет получить человек, остается лишь выбрать правильный канал и поддержать как можно больше каналов. Выбираем самый активный контакт и доставляем сообщение.

В рамке этого базиса мы и двигаемся. Чтоб реализовать связь персонализации с автоматизацией, нужно очень много изменить в структуре создания сообщений. Чтобы поменять принцип автоматизации рисования сценариев так, чтоб можно было запустить самые гибкие сценарии, нужно поменять принципы автоматизации (как у нас это было раньше реализовано). Чтобы реализовывать на основании сегмента какие-то сложные вещи и использовать их во всех каналах, мы снова должны изменить принципы работы сегментации для работы с большими данными. Нужно собирать иначе информацию, что мы и делаем.

Data Gathering

Есть три этапа сбора данных:

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

Как собирать данные и что нового мы добавили по обработке этих данных? Первое и прогнозируемое: раньше мы пользовались помощью сервисов, теперь мы можем собирать и хранить данные о поведении пользователя прямо на сайте, используя все те же механизмы, только они теперь интегрированы внутрь самой системы eSputnik. То есть скрипт ставим на сайт, он собирает поведение пользователя, мы авторизуем сессию при первой возможности, и теперь эти данные можно использовать в сегментации.

А раньше нельзя было создавать сегменты. Раньше у нас реализовывалось все так: кто-то собирал данные (в данном случае Softube), потом мы настраивали его таким образом, чтоб он вкидывал нам информацию о брошенных корзинах, просмотрах и т. д. Нынче все данные собираются, мы имеем к ним доступ, и теперь можно создать сегмент на основании этих данных (все те, кто смотрел товары такой-то категории в такой-то промежуток времени).

И что делать дальше, если у человека нет email? Вы собираете подписки на web-push и можете каждому из этих людей, задав соответствующий сегмент, отправить сообщение. Как отправить сообщение? Для этого нужны персонализация, сегментация, а также все собрать. Кроме того, мы сделали для пушей поддержку Safari и еще много чего. Это просто, ведь это только сбор веб-активности, зато не каждый может собирать geodata.

Следует отметить, что сбор данных, например, на основе IP-адреса, очень неточный, но что-то можно догадываться, особенно если есть VPN. С другой стороны, при подписке на сайте можем попросить человека оставить геолокацию, тогда мы точно будем знать его местонахождение и сможем реализовать механизмы геофенсинга, когда вы можете на карте выделить регион и сказать, что человек вот здесь находится. Это применимо, например, для транспортных компаний, которые продают билеты человеку. Мы знаем, где он находится, и можем отправлять ему предложения, потому что знаем, что он сейчас не в родном городе.

Если использовать мобильное приложение, то оно всегда очень четко передает местоположение. Все это сохраняется, и мы можем использовать его в дальнейшем. Мобильное приложение мы можем усовершенствовать расширениями с помощью инструкции, которую даем разработчику. Это небольшая доработка, обычно она занимает у разработчика 1-2 дня максимум. Он добавляет трекинг, возможность работать с мобильными пушами, и мы можем отправить такие пуши клиенту. Это направление очень активно развивается, и количество отправляемых сообщений растет. Самое важное: вы можете делать такую же сегментацию, как и для других каналов.

Следом хочется отметить такие источники данных, как BigQuery и Postgre. Вы собираете данные о поведении пользователей и стримите их в BigQuery с помощью, например, OWOX. У вас какие-то данные интегрируются. Вот те данные, которые у вас есть в BigQuery, теперь можно использовать для сегментации в eSputnik.

То есть вы создаете себе представление в BigQuery и на основании этих данных разрешаете eSputnik делать сегмент. Вы строите сегмент – соответствующие этому сегменту контакты появляются в eSputnik. Если поиграться в обратную сторону: все, что происходит в eSputnik, передается в BigQuery или в Postgre, и вы имеете всю статистику. Там вы можете использовать эти данные или обогащать любыми, какие у вас есть. Например, детский магазин, а точнее магазин, продающий взрослым товары для детей. Нужно не просто сохранить, сколько у них детей, а еще решить, куда этих детей забивать в системе.

Чаще всего используются механизмы дополнительных полей (возраст, пол, имя, имя в родительном падеже). Обычно магазины рассматривают до 8 детей по количеству, соответственно создают 8 дополнительных полей. Теперь вам нужно создать сегмент для всех, у кого есть ребенок в возрасте 4-8 лет, это девочка, и вы хотите сделать им какое-то предложение. Для этого нужно перебрать все дополнительные поля (как обратиться по имени к девочке, например). Это становится крайне тяжело, но вместе с интеграцией в BigQuery и Postgre можно загружать инфу про детей в реляционные таблицы, где можно строить самые разные связи, а на основании этого делать запрос и создавать представления. Даже если два ребенка попали в одно и то же состояние, каждому контакту будет создано два таких представления, и эти данные можно уже использовать в письме.

Другой пример использования внешних таблиц – это автостраховка. Вот есть у человека паркинг, где несколько автомобилей. У каждого из владельцев авто есть свое ТО, страховка, заканчивается кредит, и каждого нужно оповестить. Как в таком случае поступить? Чаще всего приводят собственных разработчиков, чтобы они каждый раз реализовывали механику и отправляли события. Теперь этого делать не надо. Вы можете просто создать структуру базы, настроить события и двигаться дальше. Особенно хорошо это для SaaS или для компаний, которые не напрямую попадают в структуру заказов, которую мы поддерживаем, или в структуру обычных дополнительных полей, когда к каждому человеку есть набор действий с особенностями, категоризацией и т. д. Данные можно импортировать с разных источников (CRM, CRS и др.), об этом нужно говорить отдельно.

Advanced segmentation

Вот пример обычной сегментации. Мы переделали полностью механизм, UI, возможности и методику построения групп. Можно создавать самые разные условия, пересечения, отрицания, объединения, включая туда модель устройства, с которого человек заходил, смотрел, подписывался на web-push или читал письма, регион, таймзону и т. д.

Расширенная сегментация позволяет вам обогатить имеющиеся у вас данные о ваших подписчиках данными в режиме реального времени об их покупках, поведении на веб-сайте и в приложении, а также другими данными, полезными для вашего бизнеса. Вы сможете использовать все подключенные данные, чтобы точно нацелить свою аудиторию и персонализировать свои сообщения для достижения лучших результатов. Сюда относятся: геотаргетинг, версия браузера и язык, адрес страницы подписки, IP во время подписки, операционная система, устройство, модель устройства, регион, часовой пояс.

Как поддержать многоязычность в письмах, если вы отправляете на русском и на украинском? А еще есть глобальные продукты, где клиенты отправляют нам по 20 языков. Создание одной такой рассылки (точнее 20 рассылок) значит, что кто-то должен ее перевести, запустить. А если это в триггере? А как поддерживать сразу все 20 языков? Можно ли сначала только английский, а потом расширить остальные? Все в этом направлении растет, что-то можно уже сегодня делать, а что-то можно будет сделать позже.

Данные из внешних источников в условных группах

Пример на основании Postgre (подключенные коннекторы и их источники доступны для создания условий). В условиях вы выбираете этот источник данных, выбираете, какое представление вы используете, например, “Car_purchase_date”, строите на основе этого запрос. Потом результаты этого запроса могут использоваться в письмах.

Если заходили с мобилки через Android, к примеру, то мы будем предлагать скачать приложение, в котором можно что-то сделать.

Все эти данные могут выгружаться в BigQuery, и можно строить кастомные отчеты с самыми необычными представлениями, ERFM, когортами и т. д. С обогащениями данных с внешних источников очень разная статистика. Можно выгружать данные в Postgre и в BigQuery, а потом подключать к Tableau, Power BI, Data Studio и др.

Person-based Content

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

Самое важное – это отправлять сообщения, чтобы у каждого они были уникальные. Раньше для того, чтоб отправить все сообщения каждому человеку, нужно было формировать персонализированные алгоритмы. Теперь все намного проще, ведь используются коннекторы. Для получения внешних данных нужно настроить коннектор любого типа: рекомендации, таблицу BigQuery, таблицу PostgreSQL, RSS-канал или файл препроцессора в формате json.

Работает это приблизительно так: вы подключаете источник, на основании которого будут формироваться рекомендации, строите рекомендации, на основании которых можно формировать сообщения (это может быть наш движок рекомендаций, основанный на наработках Softube, либо BigQuery, Postgre или файл json). Например, у вас есть предложение – акция, одна для мужчин, одна для женщин и одна, если не знаем пол. Вы хотите, чтоб в письме они были показаны. Что нужно сделать? Можно создать три блока и написать: если мужчинам, то что-то одно, если женщинам – другое. А можно загрузить файлик с ключом, допустим “gender” (мужской/женский/неизвестный), и загрузить туда набор акций, а в конкретном письме потом указать, что брать вот из этого набора данных.

Как это выглядит: в редакторе eSputnik появляется блок динамического контента, в котором мы выбираем источник данных, который до этого был зарегистрирован (например, рекомендация по методу брошенной корзины), и мы хотим вставить его в письмо. В блоке мы можем указать “не создавать письмо, если данных нет” или “не отправлять” его, или “отправлять без этого блока”. Брошенная корзина, если такие данные не могут быть получены, вряд ли сможет быть создана. В связи с этим добавилось много возможностей – теперь все рекомендации можно использовать не только в триггерах, но и в проморассылках. Некоторые уже успешно это делают. Как настроить? Когда вы прокликиваете эту область в брошенной корзине, вы указываете, каким образом данные, которые получены из источника, должны быть отображены в UI. Мы задаем, какие блоки идут вначале, какие блоки заканчивают. До этого создаем набор блоков и используем их для генерации.

Допустим, человек просматривал три карточки. И до тех пор, пока у нас будут данные о карточках, он будет генерировать. Теперь не нужно писать код, вы видите конкретно, как это будет выглядеть, когда будет идти отправка. Вы можете взять и поменять блок, который умеет оперировать этими данными. Это можно использовать и в проморассылках, и в SMS, и в web-push, и в мобильных пушах.

Настройка динамического блока: для блока с динамическим контентом нужно выбрать источник данных.

Есть запрос, в котором есть блок лучших предложений или новинок, и из источника данных, которые зарегистрированы, подставляется в тот дизайн, который для этого был создан. Поэтому каждому человеку будет уходить разное письмо, в зависимости от того, где он находится, какие предпочтения у него и т. д. У ребят из “Покупона” огромное количество акций, новинок, а нужно подобрать каждому свое. Алгоритмы подбора конфигурируются и обсуждаются отдельно, но эта часть уже не зависит от дизайна и автоматизации.

Данные, дизайн и логика отправки – когда мы смогли разделить эти три вещи, то масштаб внедрения и применения очень сильно изменился. То же самое касается и брошенных корзин: просто формируете, когда, что, кому нужно показать. Вся логика, оговоренная ранее, может быть применена и на web-push, и для мобильных пушей в самом разном отображении. Пуши доступны для браузеров Mozilla, Chrome для всех ОС, а также для Safari iOS.

Cart & Browse Abandonment with Personal Recommendations

eSputnik (а именно его AI) предсказывает, какие продукты с наибольшей вероятностью будут покупать, используя ряд сложных алгоритмов рекомендаций, в том числе:

• “Best Buy” рекомендации;
• по сопутствующим товарам;
• на основе отзывов клиентов с предыдущих покупок;
• “другим пользователям также нравится”;
• “следующее лучшее предложение”.

Marketing Automation

Автоматизация тоже изменилась, как и ее возможности применения. Наш удобный и простой в использовании редактор рабочего процесса drag’n’drop позволит вам визуально управлять автоматическими коммуникациями. Вы можете создавать рабочие процессы любой сложности и масштаба, просто перетаскивая элементы в рабочую область. Раньше, когда создавались триггеры брошенных корзин, нужно было сначала стартовать, потом приходило событие, подождать три часа, потом посмотреть, есть рекомендация или нет, вставить ее в письмо, опять подождать, каждый раз подтверждая. Сейчас просто стартуешь и отправляешь письмо.

Если есть данные, то они подтянутся, если нет – письмо не отправится (линейные цепочки). Сложные цепочки – это не достоинство, а недостаток. У нас сейчас активно развивается направление упрощения сложных цепочек, и один из ключевых этапов – это модульность в письмах, которую можно использовать в комбинации с полученными данными. И эти данные используются для сегментации и автоматизации. Теперь можно строить микросегменты и запускать триггеры на них. Создал сегмент (смотрел товар, но не положил в корзину или не купил за какой-то период), запустил триггер. Такой сегмент перестраивается регулярно, и отправляется событие.

Сейчас мы этот же подход внедряем еще в “Изменилась цена на сайте на товар, который ты смотрел”. Триггер можно настроить в нашем интерфейсе, никуда не выходя. Главное, чтоб сегментация позволяла делать такие штуки, а она уже крайне много позволяет, лишь бы данные подключались, собирались и могли использоваться.

AMP

Еще одно крупное изменение в создании сообщений – это AMP. Что такое AMP? В прошлом месяце произошло революционное объединение Google, Mail.ru, Yahoo Mail и Microsoft Outlook, которые сказали, что поддерживают этот стандарт. AMP (Accelerated Mobile Pages) – это технология, которая использовалась для того, чтобы в мобилках HTML можно было верстать намного проще, лучше, чтоб свапы работали, чтоб все работало быстрее.

Теперь это внедрили в письмо, а это значит, что в письме можно чатиться, делать покупку, настраивать события, делать опросы, получать фидбэк, отправлять формы. Обогащается сам интерфейс работы в письме, что означает, что email не умирает, а преобразовывается, делает так, чтобы промописьма были в промописьмах, но при этом хорошие предложения – сверху, чтобы их можно было быстро сортировать и просматривать, не делая потом 5000 кликов на сайте.

Special Request Inline