Сквозная аналитика в Google Analitycs

Сегодня мы будем говорить о сквозной аналитике и способе реализации этого инструмента внутри Google Analytics.

О чем будем говорить:

• Зачем нужна сквозная аналитика?

• Как реализовать ее на практике?

• Какие ошибки могут быть и как их решить?

Что такое сквозная аналитика?

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

Проще говоря, вкладываем мы какие-то деньги, например 1000 у.е., в наш маркетинг. Эти 1000 долларов расходятся по каким-то долям в разные каналы коммуникации:

• 200 долларов на контекстную рекламу,

• 300 долларов на поисковую оптимизацию,

• 100 долларов на прайс-площадки.

Т.е мы можем равномерно или неравномерно распределять эти суммы. И нам нужно понимать, насколько наши вложения эффективны, и какие « отрабатывают» лучше. Например, куда лучше вложить - в SEO, Яндекс Директ или в Google Adwords. Или все закрыть и работать только с прайс-площадками или какими-то агрегаторами. Только после анализа мы поймем, когда будет больше отдача от этих денег, которые мы вкладываем.

Как считать отдачу и эффективность этих вложений в разные рекламные каналы?

На данный момент большинство бизнеса или маркетологов, кто работает с Google Analytics считают эффективность затрат исключительно по каким-то коммуникативным действиям пользователя. Т.е. пользователь может позвонить или оставить заявку или даже, если это случай e-commerce, полностью пройти процедуру заказа и на последнем шаге нажать “Оформить заказ”. Очень здорово, если у нас есть возможность принять платеж от пользователя на этом шаге или на одном из последних шагов. Когда у пользователя есть возможность ввести данные своей кредитной карты или оплатить через PayPal. В таком случае мы четко понимаем, что это те люди, которые оформили заказ, это как раз те люди, которые у нас купили.

Это в идеале. А в реальности? Количество транзакций в интернете с использованием карт или других платежных инструментов относительно небольшое. У меня статистика за прошлый год или позапрошлый, что-то в районе 3-5%,это даже не доминирующий процент, т.е. это не 50%. Мы понимаем, что большое количество аудитории платит как угодно.

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

Например, 100 пользователей прошли полностью процедуру, воронку оформления заказа и только 50 из них, действительно, заплатило.

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

Что у нас отображается в Google Analytics?

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

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

Может быть у нас, допустим другого источника Google Adwords меньшее количество оформленных заявок на покупку, но при этом конверсия в реальную оплату там достаточно высокая (100 человек проходят полностью в корзину оформления покупки с Google Adwords 95 из них платят). И мы понимаем, что в таком случае этот канал будет для нас явно более эффективным, нежели чем бесплатный поиск в Google, если мы работаем с инструментом

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

Но если пользователь позвонил нам, отправил письмо на наш обычный ящик, если пришел в магазин, если он воспользовался онлайн-чатом, то по умолчанию вся эта информация не собирается. И для очень большого количества бизнесов у нас может быть такая ситуация, что количество этих коммуникаций через звонок, письмо, оффлайн и онлайн-чат будет больше чем 50-60-70%, и количество людей, которые оформляют форму может быть не очень большим, но фактически только их мы и фиксируем, только тех людей, кто у нас оформил форму.

Сформулируем три большие проблемы:

1. мы не видим реальных оплат с тех привязанных к рекламным или не рекламным каналам, которые мы используем.

2. не учитываем по умолчанию все коммуникации. Т.е. таким образом мы не можем сопоставить те данные, которые у нас есть в CRM - что именно этот заказ пришел, именно с этого источника трафика и пользователь при этом воспользовался, скажем, звонком, письмом или чем-нибудь другим. А раз так, внутри Google Analytics принимать решение о эффективности рекламных каналов достаточно сложно. И как тогда принимать решения об эффективности того или иного канала, рекламной кампании внутри Яндекс Директ. и вообще любых сущностей, которые у нас передаются в Google Analytics ( регионы, соцдем, любая другая информация) — сложно. Мы фактически ничего этого не знаем. Фактически тем данным, которые у нас есть внутри Google Analytics, напрямую верить нельзя.

3. не учитываем возвраты

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

Резюме:  

1. пользователь не понял как с нами связался, точнее мы понимаем, но не можем связать это с рекламным каналом

2. мы не видим точной оплаты

3. мы не учитываем возвраты

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

Но фактически, для того, чтобы корректно собирать данные и корректно учитывать эффективность источников трафика нам нужна другая схема. У нас есть трафик, который генерируют посетители. Эти посетители у нас могут использовать разнообразные инструменты для коммуникации с бизнесом, и каждый из этих инструментов мы должны учитывать внутри CRM. Но вместе с ним мы должны и понимать внутри CRM, что этот пользователь, который воспользовался онлайн-чатом, пришел именно с конкретной рекламной кампании, например, Google Adwords по какому-то ключевому запросу. И вот как только вот здесь, в CRM будет принято решение, т.е. по сути менеджер, который ведет этот заказ поставит статус, что этот клиент проплатил, мы сразу же передаем информацию об этой успешной оплате в систему аналитики. Мы также можем передавать всякие коммуникативные штуки для того, чтобы строить воронки и видеть эффективность не только рекламных инструментов, но и других способов коммуникации.

Как новая система аналитики выглядит на практике?

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

Таким образом до внедрения callbackhunter у нас было 100 звонков в месяц и после внедрения callbackhunter те же самые 100 звонков в месяц. Т.е. он никакой дополнительной ценности для бизнеса не принес

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

И после того, как мы возьмем и реализуем такую схему

Если мы будем учитывать каждый канал коммуникации, если мы будем учитывать возвраты, если мы будем только с момента реальной оплаты пользователем (только в этот момент передавать данные из CRM в Google Analytics) - только тогда мы можем строить вот такие красивые воронки. И тогда у нас будет видна полностью ситуация по эффективности нашего маркетинга. У нас могут быть разные рекламные каналы, которые переходят в заявки, т.е. пользователи совершают какую-то коммуникацию, тогда мы видим на этом этапе ситуацию по эффективности рекламных каналов с точки зрения заявок. Мы видим сколько нам стоит одна заявка с Яндекс Директа или одна заявка с ВКонтакте или одна заявка еще откуда-нибудь. Мы видим количество заявок, мы видим коэффициент конверсии (т.е. отношение тех людей, кто оставил заявку, к тому трафику, который пришел вообще на сайт).

Собственно, мы можем видеть и глубже, мы можем видеть сделку. Это не просто заявка, а скажем уже сделка, где прошла уже какая-то коммуникация менеджера с пользователем, они оформляют какие-то детали, т.е. не просто заявка, а сделка, и , соответственно, мы также можем эту информацию передавать Google Analytics.

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

Например, мы можем четко понимать, что тут Яндекс Директ привел нам 100 лидов, но было 2 продажи, и ROI, у нас скажем там, 103%. А вот Гугл Эдвордс принес нам 50 лидов, меньше чем Яндекс Директ, но при этом у нас было не 2 продажи, а 48 продаж. Конверсия из заявок в продажи предположим у Гугл Эдворсд гораздо выше и тогда ROI у нас 500%. Вывод: несмотря на то, что Яндекс Директ приносит нам больше заявок для нас. но с точки зрения бизнеса, денег, прибыли, эффективен Гугл Эдвордс.

Но без такой воронки мы этого никогда не скажем, если мы не настроим в аналитике все нюансы, тогда мы будем слепы.

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

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

Решаем задачи сквозной аналитики

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

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

Мы можем в такие таблицы вводить коммуникативные цели, и, фактически, мы можем внутри Google Analytics мерять каждый из этапов метриками, которые лучше всего показывают нам эффективность того или иного шага. У нас может быть несколько отчетов, каждый из отчетов у нас будет показывать разные метрики. Тогда мы будем видеть картину в целом, фактически видеть всю нашу воронку.

Как правильно настроить Google Analytics?

Во-первых, нужно использовать функционал расширенной электронной торговли.

Плюс расширенной электронной торговли в том, что мы можем брать не все, что там реализовано, а только какую-то часть, а именно часть о конкретной оплате и фактически не брать весь остальной функционал. То есть реализовывать ее частями. Но в таком случае у нас поменяется схема реализации. И на последнем шаге, на странице thank you page у нас будет не тот код, который передает Google Analytics, информацию о транзакции, а будет предпоследний шаг воронки. Грубо говоря на последнем шаге (транзакции) у нас на сайте мы будем просто передавать информацию о том, что пользователь прошел этот шаг, что он как-то с нами прокоммуницировал.

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

Для того, чтобы реализовать всю эту систему нам необходимо три шага:

1) запомнить id пользователя с любого канала коммуникации. Т.е. неважно как пользователь с нами связался - он может позвонить, он может написать нам на почту, он может пойти в оффлайн или сделать что-угодно. Нам нужно с каждого канала записывать его уникальный идентификатор. Скажу чуть больше - это уникальный идентификатор, который Google Analytics дает каждому пользователю.

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

3) Третий шаг - мы передаем успешные оплаты из CRM в Гугл Аналитикс только по факту реальной оплаты. Причем мы передаем как оплаты (факт оплат), так и возвраты (в случае, если они у нас есть).

Настройка. Шаг первый

Если вы у себя допустим в браузере Хром зайдете на какой-нибудь сайт, где стоит Google Analytics (в общем-то, это почти любой сайт), не считая может каких-то социальных сетей, кликните правой кнопкой, нажмете “посмотреть код”, то у вас появится дополнительный блок, который может быть справа или снизу.

Сейчас это называется application, раньше resources, где у нас есть такая вкладочка и подпункт Куки, если мы туда зайдем, то увидим куку, которая называется GA и этот уникальный номер и есть clientID.

Т.е. это и есть уникальный идентификатор, который пользователю (каждому браузеру) выдается от Google Analytics. Если пользователь зайдет, например, второй раз на тот же самый сайт, то его уникальный идентификатор будет точно таким же. Но если впервые придет на сайт, то этот идентификатор будет другим.

Наша задача:

— взять этот clientID. С помощью JavaScript, PHP или любых технологий мы можем этот clientID получить.

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

Если пользователь нам позвонил, мы также можем взять и получить этот идентификатор.clientID - это уникальный идентификатор, к которому у нас привязывается вся информация внутри Google Analytics о посещениях этого пользователя. Например, начальный источник трафика, через который он пришел и т.д.

Если мы этот clientID видим у себя в CRM, то можем его потом передать, расширить знания Google Analytics о том, что именно этот пользователь купил. Соответственно, у нас есть разные каналы коммуникации - звонок, письмо, онлайн-форма, онлайн-чат. Каждый из этих каналов коммуникации можно учитывать.

Звонок - здесь нам необходим динамический call tracking, с помощью которого мы можем подменять номер телефона для каждого клиента, пользователя, который зафиксирован в Гугл Аналитикс. Соответственно, по звонку пользователя мы сможем получить у колтрэкинговой системы уникальный идентификатор clientID.

Письмо мы можем отправить на адрес info+..@domen.com. Письмо попадет на info@domen.com, но при этом у нас будет сохранен наш идентификатор. Т.е. мы для каждого пользователя будем показывать свой уникальный почтовый адрес, но при этом вся почта будет приходить на наш основной почтовый адрес info@domen.com.

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

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

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

Настройка. Шаг второй

Есть много сервисов, которые позволяют это сделать. Большинство из них платные. К примеру, OWOX BI - у них есть возможность импортировать данные о рекламных расходах.

Настройка. Шаг третий

Третий шаг (самый важный) - передача данных из CRM в Google Analytics. Этот шаг реализуется с помощью технологии Measure Protocol. Это один из API, который есть внутри у Google Analytics. С помощью этого API мы можем расширять данные, которые у нас есть. Т.е. данные, с одной стороны, у нас собираются с помощью обычного кода, который мы размещаем на сайте. И еще один способ - передать данные из любого места, где у нас есть интернет. Это может быть CRM, любой сайт или устройство, подключенное к интернету. Оттуда мы можем с помощью Measure Protocol в Google Analytics передать какую-то информацию. В частности, решая нашу задачу, мы можем передать информацию об успешной транзакции, которую сделал пользователь.

Шаг последний. Анализируем готовые данные

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

Визуализация анализа

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

Проблемы сквозной аналитики

При передаче данных по measure protocol создается новая сессия внутри Google Analytics у этого пользователя и эта сессия с direct/none.

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

Что же мы можем сделать?

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

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

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

Measure protocol может не всегда корректно отрабатывать и это надо контролировать. Периодически возникают проблемы с передачей данных по этому протоколу, если мы используем POST запросы, чаще меньше проблем, если мы используем GET запросы. Опыт подсказывает, что желательно при реализации этой схемы иметь лог-файл, в который каждый запрос записывать, который был отправлен Google Analytics, потому что Google Analytics может просто ответить, что все хорошо, а по-настоящему может быть не все хорошо. Если у нас есть лог-файл мы можем быстро найти какие-то ошибки.

Например, если у нас валюты внутри CRM записываются по-разному - где-то у нас рубли, где-то доллары, где-то гривны, где-то евро. И, если мы не приводим эти данные к одному виду или вообще не учитываем при реализации всей схемы, то данные Google Analytics у нас будут неточные.

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

Андрей Осипов, основатель Школы веб-аналитики Андрея Осипова

От редакции: Это расшифровка вебинара Андрея Осипова. Андрей - автор прекрасных статей: "Как стать крутым веб-аналитиком", "Аналитика посадочных страниц: взаимодействие с контентом"

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

ЗАПИСАТЬСЯ