Сегментация аудитории в Телеграм

Сегодня мы разберем:

• Организацию работы: инфраструктура, типология данных, подписки;
• Тактические сегменты: атрибуты, поведение, составы заказов;
• Аналитические сегменты: эффективность, динамика покупок, RFM, LTV.

Организация работы с данными. Чтобы работать с сегментами нам надо уметь накапливать данные и переводить к конкретному клиентскому профилю, чтобы дальше вести с ними работу. Данные сегменты важно различать, потому что методология работы с ними будет отличаться.

Мы узнаем на каких данных строятся тактические сегменты, что они должны в себя включать и как их настраивать. В аналитических сегментах мы узнаем на основе каких данных мы можем строить аналитику. А также узнавать какую пользу мы сможем получать от реализованных тактических задач.

Организация работы с данными

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

В чем их концепция и как они внедряются в инфраструктуру проекта? Мы начнем это рассматривать с простых схем.

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

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

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

Источники обогащения данными

Для мобильного приложения – это Firebase. Это платформа, на которой создается приложение и где содержится информация о поведении клиента.

Это внешние или внутренние источники данных.

Это может быть SQL, Query, которые можно привязывать к CDP (Customer Data Platform). Может возникнуть вопрос, если есть своя база данных, то зачем делать привязку? Это делается, чтобы выстраивать все эти данные вокруг клиентского профиля. Потому что в базах компании она хранится в отдельных местах и списках. Компании не могут их связать вместе в одном профиле клиента и добавлять туда свежие данные.

Компании предпочитают работать с данными в рамках своей базы. Но тут многое зависит от наличия у компании CRM, которая способна эти данные закручивать. А вот CRM есть не у каждой компании. Некоторые заменяют CRM CDP. Поэтому тут надо смотреть на все данные и организацию технической структуры.

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

Данные с сайта. Чем эти данные отличаются от данных из базы? До тех пор, пока с сайта не ушел запрос в нашу базу данных на сервер, все, что делает клиент помечается скриптами, установленными на сайте.

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

Это все нужно, чтобы мы могли зафиксировать покупку клиента. Именно эти данные мы можем передавать с касс в клиентский ID. Если на кассе все устроено так, что клиент сначала авторизуется в программе лояльности и только потом взаимодействует с кассиром, то CDP может сразу обрабатывать информацию и делать специальное предложения, которые кассир может сразу озвучить клиенту.

При этом алгоритм будет видеть:

• Пользовался ли клиент до этого продуктом магазина;
• Смотрел ли что-то на сайте.

Он будет знать всю историю поведения клиента на сайте, в каком бы канале она ни была.

Дополнительные данные, которыми можно обогащать сведения о клиенте – это информация о рекламе:

• Баннеры, с которыми взаимодействовал клиент;
• Ретаргетинг. Был ли отклик на какие-то рекламные каналы;
• Данные по географии. Где конкретно находится клиент. Если есть мобильное приложение, то мы можем осуществлять трекинг и определять его настоящее местоположение. Или это могут быть данные, которые он вводит в своей анкете.

Это данные, которые могут пригодиться для некоторых проектов. К примеру, вы занимаетесь продвижением ресторанов или занимаетесь доставкой, то вы бы могли определить его местоположение и пригласить в свой ресторан поблизости.

А здесь показаны данные, которые можно получить с веб-сайта:

Данные регистрационные, когда клиент заполняет анкету информацией о себе. Поведенческие данные: просмотры, переходы по страницам и так далее. Добавление в корзину. Ввел или не ввел он информацию на сайте. Данные об устройстве клиента, о его браузере и другая техническая информация.

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

События на Back-End. Их мы объединили с данными по сайту. Здесь CRM хорошо ориентирован на тэгирование клиентов. Если какое-то событие произошло на back-end в рамках CRM, то можно передать отдельную категорию событий в CDP, чтобы не дублировать хранение информации.

Данные, которые можно получить с оффлайн касс

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

Данные из мобильного приложения и Firebase

Прежде всего это данные об установке и удалении приложений. Отключение уведомлений и отписки. Регистрационные клиентские данные – это данные, которые могут отличаться от тех данных, которые клиент может вписать на сайте или в оффлайне.

Расширенные данные по клиентскому профилю, которые вы хотите добавить в атрибуты.

Кстати, в Телеграм-марктениге есть понятие тэгов. То есть ответы клиента и есть тэги, которые ему присваиваются. Они тоже могут становиться данными расширенного клиентского профиля. Они не видны клиенту, но зато их видите вы. Эти данные можно передавать в Customer Data Platform (CDP). Все данные, которые мы проговариваем, будут доступны для сегментации, если вы поставите такое техническое задание на разработку.

Данные о коммуникациям

Всю информации о взаимодействии клиента или не взаимодействии можно получать и работать с ними.

Данные товарных каталогов

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

Еще раз обратимся к тому, как устроена CDP. Что происходит внутри нее.

У нас есть различная типология данных:

• Анкетные;
• Поведенческие;
• Транзакционные;
• Лояльность;
• Гео;
• Устройства.

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

Там эти данные привязываются к клиентскому профилю. Дополняются в реальном времени. Потом происходит автоматизация, персонализация и распределение по разным каналам. Далее распределяются по каналам:

• E-mail;
• SMS;
• Push / In App;
• Web;
• Ads;
• Messenger.

То есть то, что он чаще всего открывает, туда мы и стараемся чаще отправлять наши сообщения и предложения. Приоритетность каналов определяются еще по дороговизне их использования. Например, если СМС дороже всего, то туда мы будем отправлять сообщения в последнюю очередь.

Архитектура интеграций

Это про правильную последовательность подключений модулей для накопления данных и вывода их в нужное место. Как это может выглядеть?

То, что вы видите на рисунке – лишь один из вариантов. Все может быть как сложнее, так и проще. Может не быть и половины звеньев из схемы, потому что не у каждой компании есть мобильные приложения. Но если оно есть, оно должно связываться с CRM, или с кассами. Это нужно, чтобы системы понимали, что у нас свершилась транзакция.

Чаще всего они обмениваются данными друг с другом. Тем не менее данные не собираются комплексно в одном месте.

Допустим, что мы собрали данные в CDP из разных источников. Собрали данные о клиенте, обогатили их данными из продуктового модуля.

Теперь все это мы должны выводить в наши каналы, а потом в инструмент сквозной аналитики. У CDP есть бесшовная возможность вывода коммуникации в каналы.

Передача данных по API events

У нас есть форма сбора контактов на сайте, куда подписчик вводит свои данные. Когда он нажимает на кнопку, чтобы завершить регистрацию. Это нажатие инициирует событие, которое передается в формате json файла.

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

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

Что означает файл item.json, который есть на иллюстрации в левом нижнем углу? Благодаря ему мы можем получать сведения о товаре, который собирается купить клиент. То есть был список заказов, мы получили чек, в котором содержится:

• имя;
• цена;
• цвет товара.

Это можно использовать в Телеграм сообщении, чтобы сказать клиенту, что именно ему сейчас везет курьер.

Webhooks

Это тоже один из типов событий, но это событие системное. Его мы получаем из CDP, которое мы потом отправляем в другую платформу с набором информации.

Если вы соберетесь сделать интеграцию между CDP  и платформой Телеграм маркетинга, то там будет написано, что они смогут обмениваться с помощью webhook. Он привязывается к определенной ссылке, которая способна принимать эту информацию.

При настройке должен быть прописан URL, который должен будет расшифровывать информацию на сервере.

Пример бирфа на интеграцию

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

Еще один обмен данными, который нечасто используется, это интеграция с Internal data source: SQL, Query. Зато с его помощью удобно отдавать данные в другие сторонние системы.

Принцип работы в том, что в них выгружаются различные таблицы:

• о товарах;
• о клиентах;
• о чеках;
• об оффлайн точках;
• с поведением клиента;

Все эти данные имеют свои идентификаторы и выгружаются в этот внешний источник данных. Это позволяет делать множественную углубленную сегментацию за счет связки идентификаторов. Как это выглядит на практике?

Например, у нас есть клиент с идентификатором. Мы знаем его имя, его профессию, ресторан, в который он любит ходить и что он обычно там заказывает. Мы знаем тип блюд, которые он предпочитает заказывать. У ресторана так же есть свой идентификатор.

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