{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Как исправить учет трафика в Google Analytics через Google Tag Manager на одностраничных сайтах (SPA)

Данная статья – перевод поста https://www.simoahava.com/gtm-tips/fix-rogue-referral-problem-single-page-sites/ из блога Симо Ахава (Simo Ahava), спасибо автору за него.

Из статьи вы узнаете, как исправить проблему, когда платный трафик попадает в органический и реферальный каналы GA, если у вас SPA. Мы столкнулись с этой проблемой на нашем SPA на React'e (https://vseapteki.ru/), когда переходили с обычного внедрения GA на GTM.

Одностраничные сайты (или одностраничные приложения), Single-Page Applications, обычно загружают страницу в браузере только 1 раз. При навигации по сайту новое содержимое либо извлекается непосредственно из DOM (объектной модели документа), где оно находилось в скрытом состоянии, либо загружается с сервера путем HTTP-запросов, которые не вызывают обновление страницы. Такое поведение, однако, имеет некоторые последствия для отслеживания трафика в Google Analytics, особенно при его настройке через Google Tag Manager (Диспетчер тегов).

В архитектуре SPA страница обновляется без полной загрузки новой страницы. e-nor.com

Суть проблемы заключается в следующем: когда вы создаете счетчик Google Analytics, URL страницы (без возможного #хеша) с момента создания трекера определяется как значение поля «URL местоположения документа» (Document Location) при каждом обращении (хите), которое использует этот трекер. Это используется в разных вещах, наиболее значимо – для атрибуции, т.е. чтобы связать сессию с кампанией, которая определяется параметрами в URL’е, такими как gclid (AdWords) или utm_source, utm_medium.

На одностраничных сайтах вы отправляете «виртуальные» просмотры страниц, когда с сервера загружается новый контент. Причина, по которой это работает хорошо с кодом GA, который установлен непосредственно в коде страницы, в том, что там всегда используется одно и тоже имя трекера для отправки хитов. Google даже рекомендует это в в своем руководстве для разработчиков. Таким образом, местоположение документа остается прежним и кампании атрибутируются корректно.

При использовании Google Tag Manager, каждый тег с Universal Analytics, который запускается на сайте, создает новый уникальный объект трекера. Это означает, что местоположение документа (поле Document Location) обновляется каждый раз, когда запускается тег. Это приводит к проблеме, если URL в браузере меняется из-за манипуляции историей браузера. Таким образом вы можете столкнуться с ситуацией, когда первый тег Universal Analytics содержит gclid в URL’е, что позволяет связать эту сессию с AdWords, но следующий просмотр пользователя больше не имеет данного параметра в URL, поскольку вы бы не включили его в путь виртуальной страницы. Вместо этого, поскольку gclid больше нет в URL, GA смотрит на HTTP referrer страницы, чтобы увидеть, что было указано на предыдущей страницы сессии для атрибуции. Он находит google.com, поскольку вы пришли из поисковой системы (HTTP referrer не обновляется при манипуляции с URL в API HTML5 истории браузера). Стартует новая сессия и она атрибутируется органическому поиску Google! Я назвал это проблемой Мошеннических Рефералов.

Учет трафика при различных внедрениях GA (во втором случае триггерами являются «All Pages» и «History Change».

Есть несколько способов бороться с этим. Давид Вальехо написал прекрасную статью про назначение имени трекера в GTM тегах. Это будет эффективно работать как код GA, установленный непосредственно на странице, сохраняя исходное значения URL местоположения документа на протяжении всей загрузки страницы. Однако с настройкой имени трекера есть некоторые риски, поэтому я хочу предложить альтернативный способ.

Устанавливайте вручную Document Location для предотвращения Мошенических Рефералов

Сохраняя вручную оригинальный URL страницы (без хеша) и отправляя его в поле Location во все GTM-теги, вы гарантируете, что одностраничное приложение не вернется к Referer'у, отправляя «виртуальные» просмотры.

Принцип работы этого способа – вы сохраняете оригинальный URL в глобальной переменной, такой как dataLayer и затем вручную задаете поле Document Location во всех ваших тегах, используя эту переменную.

Самый надежный способ сделать это – разместить следующий код перед кодом контейнера GTM:

window.dataLayer = window.dataLayer || []; window.dataLayer.push({ originalLocation: document.location.protocol + '//' + document.location.hostname + document.location.pathname + document.location.search });

Это позволит сохранить оригинальный URL страницы (без #хеша) в переменной dataLayer с именем originalLocation. Теперь вы должны добавить ее во все ваших теги Universal Analytics с помощью добавления поля в разделе Fields to Set. Для этого нужно зайти в настройки пользовательской переменной, где хранятся настройки Universal Analytics:

Название поля: location

Значение: {{Data Layer Variable - originalLocation}}

Здесь {{Data Layer Variable - originalLocation}} будет созданной вами пользовательской переменной типа Data layer Variable, указывающей на originalLocation, который вы сохранили при первой загрузке страницы.

(Обратите внимание, что если вы добавляете поле location, вы также должны задать page, в противном случае все страницы будут использовать то, что хранится в location в качестве пути, отправляемого в GA! Если у вас одностраничный сайт, возможно, вы уже имеете в поле page адрес виртуальной страницы, но если нет, вы всегда можете использовать что-то типа:

Название поля: page

Значение: {{JS - Get Page URL}}

Где переменная {{JS - Get Page URL}} – это переменная типа Custom JavaScript, содержащая следующий код:

function() { return document.location.pathname + document.location.search; }

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

Если вы не можете или не хотите редактировать HTML-код страницы, вы можете использовать порядок активации тегов. Во-первых, вам нужно создать тег типа Custom HTML, содержащий код из первого блока (заключенный в теги <script> и </script>). Затем вам нужно определить первый тег Universal Analytics, который запускается на сайте. Обычно это будет тег с триггером «All Pages» или каким-либо другим триггером просмотра страницы. Далее вам нужно добавить Custom HTML тег в последовательность этого тега просмотра страницы, чтобы он запускался до него.

(Почитайте следующий раздел Предостережение, если вы выбрали способ сделать все на стороне GTM, а не в шаблоне страницы!).

Таким образом, исходный URL сохраняется в dataLayer перед тем, как запустится тег Universal Analytics, и он будет доступен всем тегам, запускаемым на данной странице.

Предостережение

Если вы отправляете originalLocation через GTM, а не код шаблона страницы, может возникнуть проблема с очередностью исполнения - когда originalLocation сохраняется в dataLayer и когда теги пытаются получить доступ к нему. В этих случаях analytics.js не использует текущий URL по умолчанию, что приводит к отсутствующему полю Document Location. Чтобы исправить это, вместо добавления переменной {{Data Layer Variable - originalLocation}} непосредственно в поле местоположения в тегах GA, вы можете добавить пользовательскую переменную типа Custom JavaScript со следующим кодом:

function() { return {{Data Layer Variable - originalLocation}} || window.location.protocol + '//' + window.location.hostname + window.location.pathname + window.location.search; }

Он вернет либо {{Data Layer Variable - originalLocation}}, либо, если это еще не было задано, текущий URL без хеша.

Подведем итоги

Если у вас есть одностраничный сайт и вы отправляете «виртуальные» просмотры страниц в GA, вы можете проверить, есть ли у вас проблема мошеннических рефералов. Простой способ обнаружить ее – посмотреть в отчет «Статистика по пользователям» («User Explorer»), просматривая сессии, которые начинаются с хита AdWords, но быстро переходят в сессию с источником «органический поиск Google» в качестве кампании.

На самом деле, если вы используете Google Tag Manager и отправляете виртуальные просмотры страниц, вы наверняка будете страдать из-за проблемы мошеннических рефералов до тех пор, пока вы не зададите имя трекера или URL местоположения документа, как указано в данном руководстве.

P.S. Прим. переводчика. Все вышеописанное относится к SPA с реализацией, при которой в адресной строке меняется URL при переходе между страницами (с помощью HTML5 History API). Если же этого не происходит, сначала нужно настроить передачу фрагмента URL в GA, см. How To Track Single Page Web App with Google Tag Manager.

0
3 комментария
Михаил Кобзарёв

Спасибо, вы спасли мне 100500 нервных клеток )

Ответить
Развернуть ветку
Евгения Березникова

Спасибо за статью. У меня такой проблемы не было на SPA сайтах. Все работало через GTM. Может не корректно был установлен код (я про установку двух частей кода https://www.owox.ru/blog/use-cases/how-to-install-google-tag-manager/#second-item )

Ответить
Развернуть ветку
Vladimir Kharev
Автор

Евгения, есть разные реализации SPA.
Что касается установки кода - вторая часть для юзеров без JS.

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда