Быстрый или бедный

Level 2: Интеграция по User ID

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

В большинстве случаев транзакции фиксируются параллельно в двух местах: в CRM и системах онлайн-аналитики. Да, пользователь может быть залогинен (зарегистрирован) на сайте. Да, он уже не впервые заходит сюда и каждый раз вводит свои данные. Но как только он меняет устройство или браузер, наступает путаница. В CRM он остается тем же самым человеком (с его логином и паролем), а в системах статистики Google Analytics и Яндекс.Метрика фиксируется как другой пользователь. Новый браузер на новом устройстве присваивает ему новый идентификатор Client ID. Информация о продажах, сделанных по звонку, тоже не попадает в системы онлайн-аналитики. Туда подтягиваются лишь данные с сайта – по тому самому последнему Client ID.

Возникает разрыв коммуникации между маркетологом-аналитиком и бизнесом. Классическая ситуация: приходит клиент, мы смотрим отчет по транзакциям в Яндекс.Метрике («Электронная коммерция», те самые данные с сайта) и говорим: «Дружище, ты зарабатываешь 20 миллионов». А в ответ слышим: «Но я зарабатываю 15!» или «Я зарабатываю 25!» (информация из CRM). При таких разночтениях говорить о повышении эффективности рекламы по меньшей мере некорректно.

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

Рассмотрим эту схему на примере любого сервисного продукта, например системы управления интернет-рекламой Rookee. Человек увидел объявление на телефоне, перешел на сайт, зарегистрировался. Но пользоваться сервисом удобнее и привычнее с десктопа. Человек пришел домой и зашел на сайт. Данная схема аналитики свяжет это событие с переходом на сайт с телефона. После этого мы не потеряем данные об эффективности рекламы. Без такой настройки человек на десктопе и человек в мобильном телефоне были бы для системы аналитики двумя разными людьми.

Плюсы

Как видите, в основе лежит базовая модель сквозной аналитики, только вместо лидов – транзакции. Эта схема больше подходит интернет-магазинам и сервисам с периодической абонентской платой. Принципиальное различие в том, что пользователь определяется здесь уже не по cookie-файлам и привязанному к ним Client ID, а по аккаунту пользователя (логин, пароль) с уникальным идентификатором User ID. Именно по нему данные о транзакциях из CRM передаются в системы аналитики.

Если зарегистрированный на сайте (залогиненный) пользователь сменил устройство, зашел с чужого компьютера или почистил cookie, мы его не теряем. Кроме того, в CRM появляется такой этап, как «Приход» или «Возврат». Он важен в тех случаях, когда клиент сначала бронирует товар на сайте, а после выкупает его в магазине. При завершении покупки мы можем передать в Google Analytics событие, которое подтвердит этот факт.

Минусы

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

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

Кому подходит

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

Стоимость

От 250 000 рублей.

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

Level 3. Интеграция через Power BI

Первый и второй уровни сквозной аналитики все-таки могут терять клиентов. Например, если кто-то посмотрел каталог на сайте, но за покупкой пошел непосредственно в офлайн-магазин. При этом пользователь мог никак не обозначить своих намерений на сайте: не позвонил, не забронировал товар. Продажа фиксируется в CRM, но не сопоставляется с данными Google Analytics и Яндекс.Метрики. Вопрос: как связать факт покупки в магазине с тем, какие рекламные сообщения, предложения на сайте этот человек видел в онлайне?

Для решения этой задачи используется схема с интеграцией через Power BI. На сайте пользователю предлагается уникальный код, по которому клиент в магазине (дилерском центре, ресторане и др.) получит скидку. Это может быть дисконтная карта, купон, персональное предложение. Идентификаторы могут добавляться в артикул товара, если покупатели называют его при покупке. Так часто бывает при выборе оборудования, где модификации отличаются именно артикулом. Разумеется, максимальную эффективность дает комбинация этих вариантов.

Вместе с кодом, который связан с User ID, мы передаем данные о клиенте в офлайн. Пользователь приходит в магазин, называет код или артикул менеджеру, который продает по нему товар. Когда данные об этом попадут в CRM, они автоматически свяжутся с историей этого пользователя на сайте. В большинстве случаев человек воспользуется нежданной скидкой или предложением системы лояльности, особенно если покупает что-то дорогое и значимое.

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

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

А что если при посещении сайта каждый пользователь получает уникальный промокод? В офисе администратор оформляет по нему карту, действия клиента в онлайне и офлайне сопоставляются. Вуаля!

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

Плюсы

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

Еще одно важное преимущество схемы – объединение всей разнородной статистики компании в единых понятных бизнесу отчетах, как, например, это происходит при использовании уже упомянутой нами платформы для бизнес-аналитики Microsoft Power BI.

Минусы

Схема интеграции через Power BI сложна в настройке и поддержке. Часто для ее корректной работы приходится пересматривать бизнес-процессы компании. Плюс остается погрешность в виде тех, кто отказался от скидки, промокода, купона.

Кому подходит

Крупным компаниям, оказывающим услуги, а также сетевым офлайн-магазинам и заведениям (например, ресторанам, автодилерам), которые ведут первичную коммуникацию через интернет.

Стоимость

Индивидуально.

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