Приветствую! Меня зовут Андрей Степанов, я 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. Обычно в этот диапазон можно уложиться, если создать тип активности для каждой комбинации настроек, внутри которой пользовательские роли и список действий, которые необходимо отслеживать.
В нашем примере с агентством недвижимости:
-
Основная настройка – имущественный интерес:
Продажа
Сдача в аренду
-
Тип выполняемого действия:
Отправлена форма запроса на оценку
Отправлена форма запроса на просмотр недвижимости
Посещение страницы объекта недвижимости
Поиск недвижимости
Недвижимость сохранена в избранное
Поиск недвижимости сохранен в избранное
В результате будет создано 12 уникальных типов активности, среди которых: посещение страницы продажи недвижимости, посещение страницы сдачи недвижимости в аренду, поиск продаваемой недвижимости, поиск сдаваемой недвижимости и далее по списку с учетом «прикладывания» каждого действия к одной из настроек.
Здесь стоит отметить одну небольшую, но важную деталь: в нашем примере можно было бы избежать создания дубликатов данных для продажи и сдачи в аренду и хранить значение продажи или сдачи в деталях активности. Однако это усложнило бы использование этих данных в других маркетинговых функциях, например, при создании правил скоринга пользовательских ролей или автоматизации маркетинга. Было бы не так наглядно.
Например, при настройке правил скоринга пользовательских ролей для покупателя мы можем:
Выбрать тип активности «посещение страницы продаваемой недвижимости».
Либо выбрать «посетил страницу недвижимости» и настроить дополнительное условие »где страница недвижимости является продающей».
Второй вариант менее привлекателен, поскольку:
Дополнительные условные проверки могут повлиять на производительность на сайтах с высокой посещаемостью.
Он менее нагляден в админке DXP. В списке правил скоринга персон, журнале активности и других местах эти дополнительные условия не отображаются, поэтому, чтобы заметить разницу, необходимо развернуть конкретное правило.
Фишка 7: Добавление дополнительного контекста
При настройке пользовательской активности для отслеживания доступны только 4 поля для заполнения, но существуют способы добавления более ценной контекстной информации.
Хранение данных во вложенном объекте. Здесь мы можем создать структурированный объект типа пользовательского класса модуля, записать в него всю необходимую контекстную информацию, а затем при регистрации объекта активности просто хранить целочисленный идентификатор, ссылающийся на этот пользовательский класс.
Хранение данных в структурированном текстовом формате. Альтернатива – подготовка сериализованной контекстной информации в формате XML (или JSON) и сохранение ее в одном из двух текстовых полей, доступных в объекте активности.
Заключение
Освоение и внедрение продвинутых методов отслеживания и аналитики неизбежно приводит к получению ценной информации о поведении пользователей и оптимизации маркетинговых мероприятий. Выходя за рамки стандартного трекинга активностей, понимая интересы пользователей при посещении страниц, делая аналитику действенной, планируя пользовательские пути, создавая идеальную структуру данных и добавляя необходимый контекст, можно создать комплексную и эффективную стратегию трекинга для сайта на Kentico.
Огромная благодарность за подготовку материала Дмитрию Бастрону!