Сквозная аналитика
Традиционно под сквозной аналитикой подразумевают решение, которое позволяет объединить три типа данных: расходы на рекламу, поведение пользователей на сайте, показатели из CRM о реализации товаров и услуг. В целом это определение – правильное, однако я предлагаю рассматривать сквозную аналитику как нечто большее.
Пусть это будет хранилище, некая база данных, куда можно не только складировать различные данные, но и объединять их по ключевым словам, а также наглядно изучать всю отчетность. Речь не просто о соединении данных о расходах на интернет-рекламу и результатах реализации, а об использовании любых структурированных данных внутри бизнеса. Например, можно оценить эффективность продаж определенного сотрудника в торговом зале, узнать результаты работы конкретного оператора в кол-центре и т. д.
Поэтому, прежде чем говорить о сквозной аналитике, стоит хотя бы поверхностно разобраться с теорией баз данных. Если упростить определение, любая база данных – это набор таблиц, в каждой из которых соблюдается строгий порядок столбцов. В ячейки столбцов можно вносить данные определенного типа, такие как:
• текст;
• целое число;
• число с запятой;
• правда или ложь и т. д.
В каждой таблице есть уникальный первичный ключ (primary key), который нужен для однозначной идентификации каждой записи в таблице. Это значит, что в одной таблице не может быть двух разных строк, у которых этот параметр совпадает.
Также в базе данных есть внешний ключ (foreign key), который нужен для связывания двух и более таблиц.
Логично, что все данные в любом бизнесе могут быть оцифрованы и приведены в табличный вид, где работает строгое правило: значения в ячейке должны соответствовать типам данных в столбце. Это значит, что нельзя в столбец «Фамилия» записать числа. Теперь вы понимаете, что для формирования баз данных, которые необходимы для сквозной аналитики, требуется сначала собрать массив информации. И в этом помогут:
• рекламные кабинеты;
• web-аналитические системы с детальной разметкой;
• системы коллтрекинга и email-трекинга;
• CRM;
• данные мобильных приложений;
• любые другие данные, которые вы хотите подгрузить, например по офлайн-продажам.
Все рекламные системы делятся на два типа: с доступом в личный кабинет и без него. Некоторые специалисты могут не предоставлять доступ в рекламные кабинеты, потому что «вшивают» наценку на свою работу в стоимость закупки. Например, у вас подписан договор, в рамках которого вы покупаете клики по фиксированной цене, как апельсины на рынке. В таком случае исполнитель может купить клики по цене ниже реализации и заработать на разнице.
На мой взгляд, все же важно иметь доступ в основные рекламные кабинеты:
• «Яндекс. Директ»;
• Google Ads;
• MyTarget;
• «ВКонтакте»;
• DV360.
Если подрядчик сообщает, что не может предоставить вам доступ к рекламным кабинетам в этих системах, это означает только одно – он не хочет этого делать. И тогда нужно задаться вопросом, зачем вам такой подрядчик.
Из рекламного кабинета вам нужна в первую очередь информация по срезам:
• дата;
• идентификатор аккаунта;
• идентификатор кампании;
• идентификатор группы объявлений;
• идентификатор объявления.
Также по каждому из этих параметров нужно выгрузить ряд метрик, таких как:
• расход;
• количество показов;
• количество кликов.
Это минимальный набор, который потребуется для аналитики результативности рекламы. У вас получится таблица из нескольких идентификаторов и метрик, привязанных к ним. Напомню, что идентификаторы – основной ключ для сопоставления данных с информацией из web-аналитики о поведении пользователя на сайте.
Из «Яндекс. Метрики» и Google Analytics нужно выгружать данные, которые соединены с данными из рекламных кабинетов. Я упоминал, как связать данные по рекламе и web-аналитику в подглаве «Как определяется источник перехода на сайт?»: для этого потребуется использовать UTM-метки.
Из web-аналитических систем необходимо выгружать следующие данные:
• источник;
• канал;
• кампания;
• содержание объявления;
• ключевое слово.
Каждый из этих параметров отмечается UTM-меткой, за исключением первых двух. Если у каналов нет UTM-меток, данные прописываются на основании реферера.
В дополнение к этим параметрам потребуются и показатели метрики, например:
• сеансы/визиты;
• глубина просмотра;
• время на сайте;
• показатель отказов;
• достижение цели (3);
• идентификатор конверсии;
• идентификатор достижения цели.
Таким образом создается связь между расходами на рекламу из разных рекламных кабинетов или из Google-таблицы, в которой можно фиксировать расходы по каналам, у которых нет рекламных кабинетов, скажем по SEO-продвижению.
Эти системы необходимы сайтам, у которых значимая доля заказов приходится на телефонные звонки или обращения через email.
Упрощенно схему работы этих систем можно представить так: за сайтом закрепляется определенный пул телефонных номеров и email-адресов. Когда пользователь переходит на сайт, коллтрекинг сохраняет данные о времени начала визита, реферере и UTM-метках, с которыми пользователь пришел, привязывая эти данные к конкретному телефонному номеру или email.
Итак, в системе коллтрекинга или email-трекинга хранится следующая информация:
• дата;
• HT TP-referer;
• UTM-метки;
• факт звонка или письма.
Выгрузив эти данные, можно соединить их с данными из web-аналитики.
Сразу отмечу, что системы email-трекинга усложняют восприятие почтового адреса. Например, система автоматически присваивает уникальный идентификатор, в результате email получает такой вид: comeon+502741@medianation.ru. Согласитесь, подобные ящики выглядят непонятно и некрасиво, поэтому лучше установить на сайте формы для отправки сообщений.
В этой системе хранится информация о действиях и статусе клиентов, состоянии их заявок. Чтобы связать эти данные с массивом, который мы обсудили ранее, потребуются следующие ключи:
• идентификатор транзакции (целевого действия);
• номер заявки;
• входящий номер звонившего.
Идентификатор транзакции и номер заявки – это внутренний уникальный признак, который в CRM обозначает целевое действие. С ним может возникнуть ряд проблем:
• путаница в именах. Это происходит, когда идентификатор транзакции в CRM отличается от идентификатора на сайте, который присваивает CMS и передает в модули Google Analytics и «Яндекс. Метрики». В этом случае необходимо создать промежуточный словарь для сопоставления идентификаторов транзакций из обеих систем;
• отсутствие идентификатора. Например, уникальный номер заявки есть в CRM, но его нет в системах web-аналитики. Подобная ситуация часто возникает, когда владельцы сайтов забывают отправить идентификатор заявки из CMS в web-аналитические системы. Хотя его можно отправлять не только в модуль электронной коммерции, но и в Google Analytics и «Яндекс. Метрику» в качестве атрибута события или индивидуальной переменной на уровне сессии;
• сложные взаимосвязи. Иногда в компании, помимо CRM, в которой собираются данные о клиентах, работает также 1С, где хранится информация о конечном статусе реализации. В этом случае процесс объединения данных усложняется, поскольку добавляется еще одна система, которую потребуется связать с остальными.
Входящий номер звонившего – второй важный признак, который необходимо сохранять в CRM и связывать с целевым действием. Это позволит связать данные из системы коллтрекинга, а именно – данные по дате звонка, UTM-меткам и HT TP-referer, с последующей историей заявки.
Основная проблема при этом: часто операторы, которые принимают звонки, не делают никаких отметок в системе коллтрекинга. В результате ей не хватает данных о том, был ли звонок целевым или нет, что происходило после звонка, была ли получена выручка с этой заявки. Поэтому гораздо проще сопоставить данные из системы коллтрекинга по API с данными из CRM-системы, используя в качестве ключа номер звонившего и дополнительно дату, чтобы можно было сопоставить эти данные.
Куда выгружать данные для сквозной аналитики?
Когда собрана вся необходимая информация для сквозной аналитики, наступает следующий этап – выгрузка данных в систему управления базами данных (СУБД). Проверенные и наиболее простые в обслуживании облачные технологии:
• Google BigQuery (GBQ);
• Yandex Managed Service for ClickHouse (YCH).
Основное их различие – в Google нет необходимости формировать базу данных. Вы просто создаете нужную таблицу, загружаете данные в GBQ и выполняете необходимые запросы или планируете расписание, когда они будут производиться.
Однако в GBQ есть особенности по оплате, которая взимается:
• за единицу хранимых данных;
• за единицу обработанных во время запроса данных.
Кажется, что обслуживание этой СУБД дорогое, но это иллюзия. Цена за единицу настолько мала, что порой грамотно выстроенная система в GBQ может обходиться даже дешевле, чем коробочное решение[33].
Для развертывания YCH потребуются некоторые навыки администрирования, поскольку сначала создается кластер ClickHouse, который будет обслуживать «Яндекс». К этому кластеру производится подключение и только потом в него загружаются данные. Нужно отметить, что в YCH не такой дружественный интерфейс, как в GBQ, и запросы лучше выполнять во внешней программе. Скорее всего, работать непосредственно в web-интерфейсе не получится. Впрочем, это неудобство компенсируется оплатой – она взимается ежемесячно и зависит от производительности кластера.
К сожалению, в GBQ и YCH нет встроенных инструментов для визуализации данных. Если это необходимо, можно использовать внешние системы, которые будут подключаться к имеющимся СУБД. В качестве базовых рекомендую остановиться на:
Google Data Studio, https://datastudio.google.com/u/0/;
Yandex DataLense, https://cloud.yandex.ru/services/datalens.
Google Data Studio часто получает обновления и новый функционал от Google. Из него можно напрямую отправлять запросы в GBQ, что делает связку СУБД и визуализатора удобной, особенно если вы работаете не на рынке РФ. Также у него интуитивно понятный интерфейс, который позволит быстро создавать нужные визуализации. В качестве примера на рис. 36, 37 можно рассмотреть части простого отчета, который формирует система.
Рис. 36. Пример отчета по общей статистике Google Data Studio.
Рис. 37. Пример отчета эффективности рекламы по типам кампаний Google Data Studio.
Как видите, в Google Data Studio есть масса возможностей по визуализации данных и созданию элементов для взаимодействия с ними. Причем на рисунках показана лишь малая часть отчетов. Самое главное – собрать максимум данных.
Yandex DataLense – новичок на рынке визуализации данных. Функционал в нем более скромный, чем в Google, но есть и свои плюсы. Так, если связать визуализатор с YCH, меньше времени займет настройка информационных панелей (дашбордов). Кроме того, все данные, включая визуализацию, будут храниться в «Яндекс. Облаке», которое можно оплачивать со счета юридического лица, зарегистрированного в РФ, и получать полный пакет необходимых закрывающих документов. Что немаловажно: он соответствует ФЗ-152, а значит, его могут использовать компании с государственным участием.
На рис. 38, 39 показаны примеры визуализации отчетов из этой системы.
Рис. 38. Пример отчета Yandex DataLense.
Рис. 39. Пример отчета Yandex DataLense.
Наверняка вы обратили внимание, что с точки зрения набора визуализаций DataLense пока уступает Data Studio. Однако система активно развивается. А за счет простой интеграции с кластером ClickHouse на «Яндекс. Облако» становится незаменимым инструментом, когда все данные размещаются в облаке.