Особенности Google Analytics, которые сэкономят вам деньги

Из вебинара вы узнаете:

1. Как правильно читать и интерпретировать данные в GA
2. Что нужно знать об атрибуции в Google Analytics
3. Ошибки в ecommerce, которые съедают ваш бюджет

Как правильно читать и интерпретировать данные в GA

Первое, что нужно понимать: в основе работы Google Analytics лежит сеанс. Сеанс – это последовательность взаимодействий пользователя с веб-сайтом за определенный промежуток времени. Другими словами, это один визит пользователя, где каждый визит – новый сеанс.

Новый сеанс формируется в  00:00. Если вы зашли в 23:59, то в 00:00 начинается новый сеанс: один сеанс, когда вы только зашли, и ещё один сеанс образуется в помощь. Это техническая особенность Analytics, с которой просто нужно смириться.

То что новый сеанс формируется спустя 30 минут по умолчанию, ни для кого уже не секрет. Эта настройка также задаётся в Analytics. Эту длительность сеанса по умолчанию можно регулировать, но изначально она составляет 30 минут. Если в течение этого времени пользователь не совершал каких-либо действий, не отправлял в GA никаких событий о своём визите, то сеанс прерывается, а через 31 минуту, когда человек вернулся или перешел на другую страницу сайта, начинается новый сеанс.

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

Почему это важно знать и помнить?

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

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

Визуализация последовательности

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

На самом деле про этот отчет тоже нужно знать несколько секретов. Это не столько секреты, сколько информация, которая есть в справке, но до которой мало кто докапывается. 

Первое, что нужно знать: этот отчет тоже основан на сеансах. Те цифры, которые в нём видны, это не пользователи, не уникальные посетители, а сеансы.

Следующий момент: в этой воронке пропущенные шаги восполняются. Она нам не показывает полную картину о том, как действительно двигается пользователь. Например, есть три шага и финальная четвертая конверсия. Если человек, не добавляя товар в корзину, перешел сразу к оформлению заказа (прямо с карточки товара перешел к оформлению) и совершил конверсию, то предыдущих два дополнительных шага по умолчанию заполняются. По сути, речи о том, чтобы здесь мы увидели реальную картину, реальную последовательность, быть не может.

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

Еще один важный момент: на этот отчёт нельзя накладывать сегменты. Мы видим общую картину вообще всего трафика. Сегментировать по бесплатным, платным или другим критериям невозможно. 

Как и по умолчанию в аналитике, здесь фиксируется одна цель на сеанс. Если человек в рамках своего визита на сайт сделал три конверсии – это скорее будет работать для транзакций. Человек сделал три покупки, но мы увидим только одну, поскольку так считает аналитика по умолчанию: одна уникальная конверсия за сеанс. 

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

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

Многие годы многие маркетологи с этим работают и на основе этих данных и отчётов строят стратегии. Аналитика занижает коэффициент конверсии, но что с этим делать?

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

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

Что нужно знать об атрибуции в Google Analytics

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

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

Модели атрибуции

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

В Google Analytics по умолчанию используется модель атрибуции по последнему непрямому клику. То есть вся ценность конверсии присваивается последнему источнику, исключая прямой. 

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

Ценность всей конверсии присвоена одному источнику, а мы в данном случае никак не оцениваем вклад каждого канала. Насколько ценным был бесплатный поиск или email – мы оценить не сможем, поскольку видим всю ценность лишь в последнем канале. 

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

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

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

Решением может быть одна из моделей Data Driven, основаная на каких-либо данных. 

Атрибуция на основе воронки

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

Рассмотрим воронку интернет-магазинов: человек зашел на сайт, совершил полезное действие (ряд условий по длительности, количеству просмотренных страниц, более-менее вовлеченный визит), просмотрел карточку товара, добавил товар в корзину, оформил заказ и совершил конверсию. К каждому следующему шагу доходит всё меньше пользователей. На основе этого рассчитывается сложность каждого шага: чем больше пользователей потерялось на переходе к нему, тем больше этот шаг важный и сложный и тем более ценны пользователи, которые этот шаг совершили. Таким образом, общую ценность конверсий мы можем распределить между шагами в зависимости от того, сколько на каждом шаге теряется пользователей. 

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

Рассмотрим пример, когда пользователь из канала display (например, медийной рекламы) зашел на сайт и перешел на карточку товара, после попал на рассылку, перешел по email и оттуда уже добавил товар в корзину. Далее перешел к оформлению заказа, а третьим сеансом вернулся по брендовому источнику из органики, просмотрел еще раз карточку и совершил транзакцию. 

Сумма ценностей каждого шага закладывается во вклад каждого из каналов. Чем больше полезных действий совершил пользователь из этого канала, тем более тот канал будет ценным. К примеру, ценность была совершена в конверсии на тысячу гривен. Вся тысяча гривен будет распределена между каналами следующим образом: медийная реклама принесет, к примеру, 180 гривен; email будет присвоено 490 гривен, поскольку там был визит, просмотр, добавление товара в корзину и начало оформления заказа; органике будет присвоено 330 гривен, так как там был тоже визит, просмотр карточки товара и финальная транзакция.

Если бы мы считали здесь атрибуцию по последнему непрямому клику, то у органики были бы все 100% ценности, а display и email не получили бы ценности вообще. Соответственно, выводы, которые мы бы делали на основе этих данных, были бы не совсем верными и корректными. 

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

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

Ошибки ecommerce в Google Analytics, которые съедают бюджет

Дублирование транзакций

Первая и довольно распространенная ошибка – это дублирование транзакций (когда одна и та же транзакция может отправляться несколько раз). При большом объёме данных это даже не сразу заметно. Какие могут быть причины?

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

Как всё-таки обнаружить эту ошибку?

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

Например, в общем отчёте 493 транзакции, а уникальных строк – 476. Сразу понятно, что есть какие-то транзакции, которые удваиваются, и можно понять, что стоит нацеливаться именно на это направление, искать ошибки.

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

Ошибки при работе с мультивалютными сайтами

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

Например, на сайте есть три валюты, а составляющий техническое задание не указал в Google Analytics, что нужно создать отдельное поле «Валюта». Если его не указать, то аналитика по умолчанию любую сумму будет отображать в той валюте, которая задана в Google Analytics.

Рассмотрим в качестве примера краску для волос, которая стоит 787 рублей, а аналитика в иенах, как и подача дохода. Фиксится это тоже довольно просто: дать задание разработчику, который это реализовывал, что в коде обязательно нужно добавить строку валюты, а также передавать туда актуальную валюту, в которой будет сделан заказ. Тогда Google Analytics конвертирует валюту, в которой будет совершен заказ, в валюту, которая задана в аналитике по умолчанию. Тогда и будет более объективная картина в Analytics.

Ошибки с платежными системами

Благодаря развитию различных платежных шлюзов, онлайн-оплат часто возникают случаи, когда платежные системы падают нам в рефералы. Например, в PayPal 9 пользователей и 5 транзакций, а коэффициент конверсии становит 21%. Что на самом деле здесь происходит?

Есть вариант оплаты через PayPal: человек заходит, выбирает этот способ, его редиректит на PayPal, где он совершает транзакцию, оттуда обратно переходит на сайт и попадает на Thank-You-Page. Срабатывает код ecommerce с отправкой транзакций, и мы видим, как он присваивает ему реферал PayPal. 

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

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

Также распространенная ситуация, когда человек заказывает через LiqPay или PayPal, а мы вообще транзакций не видим. То есть нас никуда не редиректит, заходим в аналитику, а там пустота. С чем это связано?

Это связано с тем, что код аналитики стоит на сайте Thank-You-Page, но никакой транзакции он не отправляет, потому что нет редиректа из платежной системы на Thank-You-Page. 

С современными платежными системами есть сложности с редиректом. В таких случаях это всё настраивается через Measurement Protocol: когда в платежной системе совершили транзакцию, а данные о ней отправляются напрямую на сервера Lanetis. 

У Analytics по Measurement Protocol есть отдельная справка. Measurement Protocol являет собой протокол передачи данных, которые использовались бы аналитиком. Другими словами, это способ передачи данных в аналитику напрямую. 

Когда мы передаем данные для того, чтобы аналитика смогла связать визит пользователя с ними, мы должны передать какой-то связывающий идентификатор. Зачастую это CID, который берется из значений и с cookie Google Analytics. 

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

С чем связана эта ошибка?

Когда мы передаем транзакцию через Measurement Protocol, зачастую в ТЗ разработчику так и пишут: CID нужно брать из cookie Google Analytics. Когда cookie просто нет у пользователя, то поле CID остается пустым. Если CID не задан, то никакой информации в аналитику вообще не поступит. Эти данные будут теряться. 

Почему может быть пустой CID?

Здесь множество вариантов. Это могут быть блоки, которые блочат все эти cookie; пользователь зашел на сайт, нажал Ctrl + F5 и очистил все cookie, а потом совершил транзакции. 

Около 5-7% транзакций приходят с пустыми CID по тем или иным техническим причинам. 

Как это фиксить? 

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

Special Request Inline