Приветствую! Меня зовут Андрей Степанов, я CTO во fuse8. Мне интересно знакомиться с опытом коллег по цеху и делиться своим. В сфере я уже больше 20 лет. В этой статье – введение в возможности отслеживания пользовательского опыта с помощью Kentico. Поговорим о том, как настраивать сбор данных на сайте на базе Kentico, разберем, как это сделать на примере реального проекта, и почему работа с данными важна для бизнеса.

В мире Digital Experience платформ (DXP) понимание процессов работы с данными – ключ к достижению успеха. В этом материале – реальный сценарий внедрения продвинутого трекинга и аналитики с использованием Kentico Xperience 13 DXP. Не важно, работаете вы с Xperience by Kentico или с Kentico Xperience 13, принципы мониторинга активности остаются неизменными. Поэтому статья актуальна для обоих случаев.

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

Фишка 0: сначала трекинг, а потом остальные маркетинговые мероприятия

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

Фишка 1: выход за рамки стандартного отслеживания

Kentico Xperience 13, как и другие DXP, предлагает отслеживание действий на сайте по умолчанию, его недостаточно для полного понимания бизнес-контекста сайта. Чтобы получить более ценные знания о взаимодействии посетителей с ресурсом, нужно отследить и контекст.

Отслеживание активности по умолчанию в Kentico Xperience предлагает мониторить следующие данные:

Посещения страниц. В журнале активности вы увидите URL-адрес посещенной страницы и URL-адрес реферера (страницы, которую пользователь посетил непосредственно перед переходом на ваш сайт, и определенной согласно защитной политике реферера). Однако информация о контексте содержимого посещенной страницы не отслеживается.
Отправка форм. Здесь немного больше информации, включая ссылку на данные для отправки формы и тип формы. Но если заполнялась общая форма, используемая на многих страницах, то контекст страницы здесь не указывается.
E-commerce артефакты. Добавление товаров в корзину, покупки, закрытие корзины. Это, пожалуй, самая продвинутая область стандартного отслеживания, включающая в себя множество данных о товарах. Но не контекст страницы на сайте.

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

Чтобы было понятнее, давайте рассмотрим реальный сценарий, который мы недавно реализовали с помощью Kentico Xperience 13:

Сайт агентства недвижимости, работающего по модели франчайзинга.
Более 100 офисов размещают объявления о продаже и аренде недвижимости.
Различные типы недвижимости – дома, квартиры, коммерческая и т.д.
Функция геолокационного поиска для нахождения недвижимости в выбранном городе, почтовом индексе и т.д.

Фишка 2: раскрытие интересов пользователей на основе посещений страниц

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

В нашем примере при переходе на страницу с подробной информацией о недвижимости выясняется:

Продается или сдается объект
Местонахождение объекта
Цена
Тип недвижимости (дом, квартира, коммерческая недвижимость и т.д.)
Статус (доступен сейчас или в будущем, уже продан/арендован и т.д.)

На странице результатов поиска мы можем получить очень похожие данные:

Фильтр «купить» или «арендовать»
Фильтр по региону, в котором находится объект недвижимости
Ценовой диапазон
Тип недвижимости
Статус

В идеале вся эта ценная информация должна отслеживаться в дополнение к активности посещения страницы.

Фишка 3: Создание аналитических данных, пригодных для практического применения

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

Ниже приведены примеры отчетов, которые могут быть полезны бизнесу в нашем примере. Эти отчеты могут быть получены в любой из систем – Kentico Xperience или Google Analytics:

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

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

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

Фишка 4: сначала учитываем пользовательские роли

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

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

В нашем примере с сайтом агентства недвижимости мы выделили основные пользовательские роли и их поведение на сайте.

Алина, покупатель. Стремится приобрести новую недвижимость. Как правило, она:
- Посещает целевую страницу «покупка».
- Выполняет несколько поисковых запросов по объектам недвижимости, выставленным на продажу, указывая регион, ценовой диапазон, тип и размер недвижимости.
- Посещает несколько страниц с информацией о недвижимости, выставленной на продажу.
- Отправляет форму заявки для просмотра наиболее интересных объектов.
- Добавляет их в избранное.

Михаил, арендодатель. Хочет сдать свою недвижимость в аренду:
- Отправляет форму запроса оценки (для сдачи в аренду).
- Ищет уже сданные в аренду объекты недвижимости в прошлом, чтобы проверить, насколько эффективно работают агенты по недвижимости в выбранном районе.
- Посещает целевую страницу сдачи недвижимости в аренду
Александра, арендатор. Хочет арендовать недвижимость:
- Выполняет несколько поисковых запросов по объектам для аренды, указав их район, ценовой диапазон, тип и размер недвижимости.
- Посещает несколько страниц с объектами недвижимости, предлагаемыми в аренду.
- Отправляет форму для просмотра наиболее интересных объектов.
- Посещает целевую страницу аренды.
Андрей, продавец. Хочет продать недвижимость, а затем купить или арендовать другую:
- Отправляет форму запроса оценки (для продажи).
- Ищет уже проданные в прошлом объекты недвижимости, чтобы проверить, насколько эффективно работают агенты по недвижимости в выбранном районе.
- Посещает целевые страницы, посвященные продаже.
- Загружает документы с условиями и тарифами.
Елизавета, перспективный франчайзи. Рассчитывает вложить средства в открытие нового филиала:

Посещает блог о франчайзинге.
Подписывается на рассылку новостей франчайзинга.
Заполняет контактную форму франчайзинга.

Фишка 5: создание идеальной структуры данных

Приведенный выше список – отправная точка для пользовательских активностей, которые мы хотим отслеживать, и вот что может быть настроено при создании нового типа пользовательской активности в Kentico Xperience 13 (или Xperience by Kentico):

ActivityType – это основной уникальный идентификатор типа пользовательской деятельности.

ActivityItemID – целочисленный идентификатор любого «первичного» объекта из базы данных DXP, который вы хотели бы связать с этим видом деятельности: местоположение или офис, например.

ActivityItemDetailID – еще один целочисленный идентификатор для связи с чем-то «вторичным», например, с самим объектом недвижимости.

ActivityValue – свободное текстовое поле, в которое можно поместить любую дополнительную информацию.

ActivityComment – то же самое, что и предыдущее, еще одно свободное текстовое поле.

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

Существует две противоположности в моделировании данных для пользовательских типов деятельности:

Крайняя специфичность: Создание нового типа для каждого конкретного вида деятельности, который вы отслеживаете. С��едуя этому принципу, будут существовать «поиск недвижимости на продажу, по цене от А до Б, в Москве», «посещение страницы с деталями недвижимости, для аренды, в Краснодаре» и так далее.

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

Чрезвычайная универсальность: Создание одного общего пользовательского типа, например, «пользовательская деятельность агента недвижимости», и хранение максимально возможного количества дополнительной информации в 4 доступных полях.

Например, в ActivityItemID храним идентификатор офиса, если это необходимо; в ActivityItemDetailID храним идентификатор объекта недвижимости; в полях ActivityValue и ActivityComment храним всю дополнительную информацию, сериализованную в виде XML или JSON. Это может быть «продажа» или «сдача в аренду», ценовой диапазон, идентификатор области поиска, подтип выполненного действия – поиск, посещение страницы, загрузка и т.д.

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

Фишка 6: поддержание управляемости количества типов активности

Главное правило: следить за количеством типов пользовательских активностей – от 10 до 25. Обычно в этот диапазон можно уложиться, если создать тип активности для каждой комбинации настроек, внутри которой пользовательские роли и список действий, которые необходимо отслеживать.

В нашем примере с агентством недвижимости:

Основная настройка – имущественный интерес:
1. Продажа
2. Сдача в аренду
Тип выполняемого действия:
1. Отправлена форма запроса на оценку
2. Отправлена форма запроса на просмотр недвижимости
3. Посещение страницы объекта недвижимости
4. Поиск недвижимости
5. Недвижимость сохранена в избранное
6. Поиск недвижимости сохранен в избранное

В результате будет создано 12 уникальных типов активности, среди которых: посещение страницы продажи недвижимости, посещение страницы сдачи недвижимости в аренду, поиск продаваемой недвижимости, поиск сдаваемой недвижимости и далее по списку с учетом «прикладывания» каждого действия к одной из настроек.

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

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

Выбрать тип активности «посещение страницы продаваемой недвижимости».
Либо выбрать «посетил страницу недвижимости» и настроить дополнительное условие »где страница недвижимости является продающей».

Второй вариант менее привлекателен, поскольку:

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

Фишка 7: Добавление дополнительного контекста

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

Хранение данных во вложенном объекте. Здесь мы можем создать структурированный объект типа пользовательского класса модуля, записать в него всю необходимую контекстную информацию, а затем при регистрации объекта активности просто хранить целочисленный идентификатор, ссылающийся на этот пользовательский класс.
Хранение данных в структурированном текстовом формате. Альтернатива – подготовка сериализованной контекстной информации в формате XML (или JSON) и сохранение ее в одном из двух текстовых полей, доступных в объекте активности.

Заключение

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

Огромная благодарность за подготовку материала Дмитрию Бастрону!

Осваиваем продвинутый трекинг данных с Kentico Xperience