Перевод статьи с портала Moz.
В первой половине этой статьи я кратко изложу наиболее вероятные причины, по которым результаты ваших конверсий в стандартных отчетах Google Analytics могут быть далеки от желаемых.
Из второй половины статьи (начиная с раздела «Как фильтровать конверсии с помощью Менеджера тегов») вы узнаете о продвинутом способе интеллектуальной фильтрации конверсий с помощью Менеджера тегов и файлов cookie.
Если вы уже знакомы с проблемой, можете сразу перейти ко второму разделу. Однако я считаю важным сначала рассмотреть основные моменты, а уже потом углубляться в более сложные решения.
Как избежать ложных конверсий
Помимо отсутствия регистрации важных данных, один из самых действенных способов испортить вашу аналитику — это регистрировать неправильные данные и объединять их с правильными.
Неправильный подсчет конверсий может затруднить автоматическое назначение ставок, а также оценку работы отдельных каналов или даже всего бизнеса. В этой статье мы будем использовать термин «ложные конверсии».
Есть огромное количество способов отслеживать конверсии в Google Analytics, а также огромное количество способов делать это неправильно. В этой статье мы сосредоточимся именно на последних способах, когда при подсчете конверсий опираются только на то, что пользователь заполнил форму и перешел на страницу благодарности.
Итак, мы рассмотрим:
- Некоторые полезные способы.
- Когда происходит случайная конверсия пользователей.
- Как защитить цели на основе просмотра страницы от ложных конверсий.
- Оптимальный подход к цели на основе события.
- Как защитить цели на основе события от ложных конверсий.
Полезные инструменты
Эти инструменты помогут вам провести ряд важных проверок.
Chrome DevTools
Chrome DevTools открывается с помощью клавиши F12 (в зависимости от клавиатуры может быть клавиша Fn). Вы можете протестировать JavaScript в разделе Console («Консоль») и просмотреть активные файлы cookie в разделе Application («Приложение»).
Предварительный просмотр Менеджера тегов Google
Менеджер тегов Google содержит новую функцию предварительного просмотра, благодаря которой вы можете увидеть, что происходит на ряде страниц с течением времени.
Adswerve dataLayer Inspector
Этот плагин суммирует информацию о слое данных в Chrome Console.
Плагин Instant Tracking Monitor
Действительно полезный плагин, который проверяет, какая информация отправляется в Google Analytics. У него есть одна замечательная функция, а именно возможность блокировать отправку обращений в Google Analytics во время регистрации данных.
Tag Assistant
Плагин Chrome Tag Assistant показывает, какие теги Менеджера тегов присутствуют на странице. Если вы используете функцию регистрации сеанса, вам также будет предоставлена разбивка всех событий на каждой странице. Тем не менее я не склонен так сильно полагаться на регистрацию данных, если у меня есть доступ к Менеджеру тегов, поскольку много полезной информации можно узнать между новым предварительным просмотром GTM и плагином Tracking Monitor.
Tag Mapper
Я создал бесплатный инструмент Tag Mapper, который позволяет легко отслеживать изменения в Менеджере тегов. Если вы планируете что-то изменить в своей учетной записи GTM, вы также сможете увидеть, на что еще эти изменения окажут влияние. Точно так же, если вы заметили какие-либо отклонения, этот инструмент поможет найти основную причину.
Что следует проверить
Часто может возникнуть соблазн сразу перейти к комплексному решению. Но если конверсии, которые вы регистрируются в отчете, оказываются «ложными»,то, скорее всего, посетители сайта также делают что-то неправильно.
Давайте начнем с краткого обзора необходимых проверок, которые помогут убедиться, что вы не просто подгоняете цифры, игнорируя проблемы веб-сайта.
1. Вы регистрируете конверсии только на страницах благодарности?
Чтобы проверить, не регистрируете ли вы конверсии на посторонних страницах (например, на каждой странице вашего сайта), просмотрите отчет Reverse Goal Path («Обратный путь к цели») в Google Analytics:
Conversions > Goals > Reverse Goal Path («Конверсии > Цели > Обратный путь к цели»).
Первый столбец слева в отчете показывает, где происходят ваши целевые конверсии, если только вы не используете какие-либо нестандартные способы. Если в этом столбце появляется несколько страниц, вам нужно изменить критерии конверсии.
Рисунок 1. Обратный путь к цели
При этом следует помнить одну вещь: если вы регистрируете конверсии на основе событий, а не просмотров целевой страницы, но при этом в столбце в отчете отображается другая страница, убедитесь, что конверсия учитывается только после просмотра страницы.
2. Вы ссылаетесь на страницы конверсии другими способами, помимо заполнения форм?
Если вы используете цели на основе загрузки определенной страницы (например, страницы благодарности), и вы знаете, что конверсии регистрируются только на страницах благодарности, то ошибка может заключаться в случайных ссылках на эти страницы. То есть пользователь может оказаться на странице конверсии, просто нажав не на ту ссылку. И это необходимо исправить.
Для проверки используйте инструмент Screaming Frog, который позволяет сканировать сайт и находить страницы конверсии. Если вам удалось их найти, то проблема очевидна. Чтобы решить эту проблему, выберите интересующие страницы и проверьте панель Inlinks («Входящие ссылки»), которая предоставит вам список всех ссылок на эти страницы.
Рисунок 2. Screaming Frog
3. Попадают ли пользователи сразу на страницы благодарности?
Использование сегментов — это быстрый способ проверить, достигают ли пользователи страниц благодарности. Если вы создадите сегмент, в котором целевой страницей является страница благодарности, вы можете получить представление о том, как часто, по мнению Google Analytics, пользователи переходят на страницу конверсии.
Ниже вы можете увидеть скриншот интерфейса сегмента. Я включил в него все сеансы, где первым взаимодействием был переход пользователя на целевую страницу благодарности. Как видите, на этом сайте было 339 сеансов:
Рисунок 3. Интерфейс сегмента
Зная, как часто пользователи попадают на страницы благодарности, вы можете точно определить источники, которые приводят пользователей на сайт.
Ниже я применил сегмент lands on thank-you page («попадает на страницу благодарности») к отчету Source/Medium («Источник / канал»). Теперь мы видим множество прямых сеансов, несколько сеансов с оплатой за клик и прочие органические сеансы:
Рисунок 4. Сегмент lands on thank-you page
Здесь важно иметь в виду, что отчет создан на основе мнения Google Analytics. Это не обязательно означает, что пользователи попадают на страницы непосредственно благодаря рекламе. Иногда такие результаты указывают на некорректную работу кода отслеживания. Тем не менее это дает нам материал для исследования.
Например:
- Есть ли у нас реклама или другая деятельность, указывающая прямо на страницы конверсии?
- Индексируются ли наши страницы конверсии в Google?
- Есть ли в середине нашего потока конверсии страница, которая не отслеживается?
- Исправен ли наш код отслеживания и не совершают ли пользователи действия, которые могут запутать Google Analytics?
3.1 Есть ли у нас реклама или другая деятельность, указывающая прямо на страницы конверсии?
Полный разбор этого вопроса занял бы много времени, но суть в том, что все рекламные платформы позволяют вам проверять активные целевые страницы. Также важно убедиться, что у вас нет аффилиатов, случайно или злонамеренно ссылающихся на страницы конверсии. В этом случае вы можете платить им намного больше, чем они того заслуживают.
Сложнее будет проверить неоплачиваемые ссылки, например, активность в социальных сетях. Однако в любом случае стоит потратить время на проверку. Если вы обнаружите случайные ссылки на эти страницы конверсии, необходимо разработать определенные правила, чтобы избежать подобного в будущем.
3.2 Индексируются ли наши страницы конверсии в Google?
Google может быть частой причиной проблем со страницей конверсии. Все дело в ненасытности поисковых роботов. Они будут переходить по внутренним и внешним ссылкам вашего сайта, и, если на страницу благодарности ведет сканируемая ссылка, она, вероятно, будет обнаружена.
Быстрый способ проверить, проиндексировал ли Google ваши страницы благодарности (и может ли направлять пользователей непосредственно на них), — это выполнить поиск страниц в Google.
Оператор “site:” фильтрует результаты Google только по страницам вашего сайта. Оператор “inurl:” фильтрует результаты только по страницам, содержащим определенную строку.
Ниже приведен пример проверки для одного из наших клиентов. Мы обнаружили в индексе много страниц благодарности (более 600). В некоторых случаях все было в порядке, однако ряд страниц конверсии требовали немедленного вмешательства:
Рисунок 5. Проверка
3.3 Исправен ли наш код отслеживания и не совершают ли пользователи действия, которые могут запутать Google Analytics?
Здесь тоже может быть великое множество причин. Но мы рассмотрим самые основные:
- Отсутствует ли код отслеживания на некоторых страницах? Возможно, вам не удается зафиксировать пользователя до того, как он попадет на страницу благодарности.
- У вас разные версии Google Analytics на разных страницах? Это также может привести к путанице или разделению сеансов.
- Включаете ли вы параметры UTM во внутренние ссылки? Обнаружить это поможет любой поисковой робот.
- Правильно ли указан часовой пояс в Google Analytics? Сеансы не могут пересекать время 0:00, в этом случае GA разделит их на два отдельных сеанса.
- Содержит ли страница благодарности важную информацию, ради которой пользователь сохранит ее в закладках, чтобы потом посетить повторно? Одно из возможных решений — не включать на страницу благодарности каких-либо сведений, касающихся пользователя. Вместо этого заверьте его, что всю подробную информацию он получит по электронной почте. В противном случае вы можете потерять доверие посетителя.
- Есть ли у вас формы, на заполнение которых уходит больше получаса, в течение которого вы не регистрируете взаимодействия? Вы можете избежать этого, разбив форму на несколько страниц и отслеживая, когда посетители заполняют поле формы или обнаруживают ошибки. Это напрямую не касается темы статьи, однако должно помочь сделать ваши формы более удобными для пользователей.
Проверив все эти пункты, вы можете приступить к улучшению фильтрации данных о конверсиях.
Как защитить цели на основе просмотра страницы от ложных конверсий
Если в Google Analytics у вас установлен тип цели Destination («Целевая страница»), то GA регистрирует каждый просмотр определенной страницы как конверсию.
Вы также можете настроить так, чтобы на пути к цели пользователи сначала посещали другие страницы, используя воронку. Функция Funnel («Воронка») в настройках позволяет указать шаги, ведущие к цели. В этом случае не будут регистрироваться конверсии, когда пользователи напрямую попадают на страницы благодарности.
Вы также можете использовать воронку для разделения различных типов конверсий. Например, если вы используете одну и ту же страницу благодарности для нескольких форм, у вас могут быть разные цели, требующие перехода через определенную последовательность страниц.
Рисунок 6. Типы конверсий
Это сработает, если:
- У вас небольшое (и довольно статичное) количество различных целей.
- У вас небольшое (и довольно статичное) количество способов, с помощью которых пользователи могут «законно» достичь каждой цели.
Однако шаги воронки не допускают использования регулярных выражений, поэтому этот способ недостаточно гибкий. Кроме того, вы можете использовать воронки только с целями на основе просмотра страницы. Итак, воронки не помогут, если:
- Ваши цели основаны на событиях.
- У вас есть много способов достижения цели.
- Сайтом управляют несколько команд, поэтому нет смысла отслеживать все способы достижения цели пользователем.
Вы должны понимать, что при наличии таких проблем, как внутренние UTM или тайм-аут сеанса, воронки могут привести к потере потенциальных конверсий. Поэтому настоятельно рекомендуем убедиться, что все сопутствующие проблемы решены.
Оптимальный подход: цели на основе события
Оптимальный подход предполагает регистрацию конверсий на основе событий, а не просмотра целевых страниц. В этом случае GA получает информацию о событии после заполнения формы пользователями, а не дожидается появления страницы благодарности. Затем GA фиксирует каждый случай этого события как целевую конверсию.
Ниже приведены критерии целевой конверсии на основе события. Это может помочь, если вы не видели их раньше и не знаете, как их настраивать. Целевая конверсия регистрируется каждый раз, когда GA получает событие категории thank_you_page:
Рисунок 7. Критерии целевой конверсии
Этот вариант настройки является оптимальным, поскольку вы регистрируете конверсию только тогда, когда пользователь действительно совершает ожидаемое действие. Большинство же целей конверсии на основе просмотра страницы — попытка угадать, что сделал пользователь. Это относится к тем ситуациям, когда пользователи попадают прямо на страницу благодарности, минуя заполнение формы.
Может показаться немного странным, что я упомянул столь оптимальное решение только сейчас, однако дело в том, что реализация данного способа не так проста. Это может потребовать больших усилий со стороны разработчиков, например, если им придется редактировать вашу CMS или, что еще хуже, взламывать путь к внешнему решению для вашей формы.
Я предлагаю это решение только сейчас, потому что для его реализации вам придется убеждать свою команду. Ведь их первым вопросом, скорее всего, будет: «Рассматривал ли ты другие варианты?» Во время обсуждения вы можете привести следующие доводы:
- Мы позаботились о том, чтобы фиксировать конверсии только на нужных страницах.
- Мы позаботились о том, чтобы пользователи не попадали на эти страницы обходными путями.
- Мы убедились, что нет никаких других проблем с отслеживанием сайта.
- Наши данные о конверсиях сильно искажаются, поскольку приходится полагаться только на просмотры страниц благодарности.
- Мы не можем отфильтровать конверсии с помощью Google Analytics.
- Лучший способ убедиться, что мы получаем точные данные, — это использовать события. А наиболее точные события — это когда пользователь выполняет на сайте нужное нам действие.
- Если вы поможете мне сделать это, я буду безмерно благодарен.
Альтернатива воронкам Google Analytics
Иногда описанное выше решение на основе событий невозможно применить. Жизнь полна разочарований, но главное — не падать духом.
Альтернативный вариант — в любом случае переключиться на конверсии на основе событий и использовать Менеджер тегов. С помощью Менеджера тегов и файлов cookie вы можете создать более гибкую версию воронки GA. В этом случае события конверсии будут регистрироваться, только если пользователи попадают на страницу благодарности, посетив до этого страницу квалификации. Как это работает? Расскажем вкратце:
1. Когда пользователь заходит на одну из страниц квалификации, вы помещаете файл cookie в его браузер.
2. Когда пользователь загружает страницу благодарности, вы проверяете файл cookie и, если он присутствует, отправляете событие конверсии в Google Analytics. И, соответственно, не отправляете, если файла cookie у пользователя нет.
3. Затем вы очищаете cookie.
Это означает, что вы не будете регистрировать следующие ложные конверсии:
- Пользователи сразу попадают на страницы благодарности.
- Пользователи случайно нажимают на страницу с благодарностью, при этом не посетив страницу с соответствующей формой.
- Пользователи оставляют вкладку с благодарностью открытой или добавляют в закладки и возвращаются к ней позже, уже после истечения сеанса GA.
В следующем разделе мы рассмотрим основную терминологию Менеджера тегов. Самое запутанное: Custom Event («Пользовательское событие») и Google Analytics Event («Событие Google Analytics») — это совершенно разные вещи.
Основная терминология
Я выделил синим цветом терминологию Менеджера тегов, а терминологию Google Analytics — оранжевым. Однако если вы все-таки запутаетесь, то ознакомьтесь с дополнительной информацией в интернете или поговорите со знающим коллегой или консультантом.
Событие (Event) — то, что мы отправляем в Google Analytics для регистрации определенного действия.
Пользовательское событие (Custom event) — то, что происходит на веб-странице и что мы можем использовать как критерии для триггера Менеджера тегов.
Триггер (Trigger) — набор условий, который мы размещаем в Менеджере тегов. Когда все эти условия выполняются одновременно, триггер срабатывает и активирует тег.
Тег (Tag) — компонент Менеджера тегов, который выполняет определенные действия. Звучит несколько расплывчато, поскольку это может быть что угодно — от отправки события в Google Analytics до полного переписывания страницы.
Переменная (Variable) — информация в Менеджере тегов, на которую мы можем легко ссылаться в триггерах, тегах или других переменных.
Слой данных (Data layer) — структурированная информация на странице, которая упрощает передачу данных в Менеджер тегов.
Как фильтровать конверсии с помощью Менеджера тегов
1. Убедитесь, что на вашем сайте установлен Менеджер тегов Google.
Он должен быть на каждой странице. Если вам нужны дополнительные инструкции, то Google предоставляет краткое руководство по началу работы с Менеджером тегов.
Если вы переходите со стандартного кода Google Analytics на Менеджер тегов, убедитесь, что вы не используете GA и Менеджер тегов одновременно, иначе вы проведете двойной учет.
2. Сообщайте Менеджеру тегов о каждой загрузке страницы благодарности
Мы предполагаем, что все ваши страницы благодарности относятся к одному типу, поэтому просьба к разработчикам внести изменения во все страницы благодарности будет вполне разумной и выполнимой. Попросите их добавить что-то вроде следующего сценария.
Пример сценария
<script>
window.dataLayer.push({
«event»: «conversion»
});
</script>
Если вы хотите протестировать этот процесс, прежде чем привлекать разработчиков, попробуйте добавить код самостоятельно, вставив его в консоль с помощью Chrome DevTools.
При загрузке страницы этот сценарий добавит информацию в слой данных. Менеджер тегов обнаружит изменение, которое можно будет использовать в качестве условия для триггера. В этом случае Менеджер тегов зафиксирует пользовательское событие, как конверсию, поскольку добавлены соответствующие данные. Мы еще вернемся к этому позже.
3. Сообщайте Менеджеру тегов о каждой загрузке страницы квалификации
Мы также предполагаем, что между вашими страницами квалификации есть некоторое сходство. Во-первых, все они, вероятно, содержат ту или иную форму. Вы можете согласовать со своей командой разработчиков автоматическое добавление/активацию сценария при использовании одной из этих форм.
Пример сценария
<script>
window.dataLayer.push({
«event»: «qualifying»
});
</script>
В этом случае вы увидите пользовательское событие, зафиксированное как посещение страницы квалификации (qualifying). Вы также можете проверить этот сценарий, вставив его в консоль.
4. Каждый раз, когда пользователь попадает на страницу квалификации, устанавливайте файл cookie
Используйте посещение страницы квалификации как пользовательское событие в качестве критерия для триггера. Ниже приведен снимок экрана с настройкой триггера:
Рисунок 8. Настройки триггера
Затем создайте тег, который будет активироваться этим триггером. Тег добавит некоторый контент на страницу, в данном случае — JavaScript (даже если тип тега указан как HTML). JavaScript будет запущен сразу после добавления и установит файл cookie для пользователя. Таким образом, вы сможете передавать информацию с одной страницы на другую.
Рисунок 9. JavaScript
Пример сценария
<script>
// Установить время 30 минут с данного момента (поскольку по умолчанию тайм-аут сеанса GA
// составляет полчаса, и нужно, чтобы он совпадал с тайм-аутом файла cookie)
var dt = new Date();
dt.setHours( dt.getHours() + 0.5 );
// Настройте файл cookie «qualified» со значением «true», срок действия которого истекает через 30 минут.
document.cookie = «qualified=true; path=/; expires=»+dt;
</script>
5. Получите значение cookie
Используйте переменную Менеджера тегов, чтобы убедиться в том, что вы определяете значение файла cookie и сможете получать текущее значение файла qualified при каждой проверке.
Рисунок 10. Переменная
6. Определите, следует ли фильтровать конверсию
На втором шаге вы создали событие dataLayer, которое будет происходить на всех последних страницах конверсии.
Теперь нужно создать триггер, который срабатывает при событии conversion.
Рисунок 11. Создание триггера
Далее создайте тег, который активируется этим триггером, а также еще одно пользовательское событие.
Рисунок 12. Создание тега
Ниже приведен пользовательский HTML-код, который вы также можете добавить. Он проверяет наличие у файла qualifying значения true. Это говорит о том, что пользователь в этом сеансе посетил страницу квалификации. Если значение true, создайте еще одно пользовательское событие под названием create_filtered_conversion. Если значение false, ничего делать не нужно. В любом случае необходимо удалить файл cookie, установив в качестве срока истечения дату из достаточно далекого прошлого.
Пример сценария
<script>
// Когда мы пытаемся запустить конверсию, проверьте, есть ли на то основания.
// Если да, создайте событие, которое запускает конверсию,
// если нет — создавать ничего не нужно. При любом исходе — удалите cookie.
// Получите переменные
var isQualified = {{Variable — qualified cookie}}
// Проверьте, подтверждена ли конверсия
if (isQualified === «true»){
// Если у пользователя есть cookie со страницы квалификации
window.dataLayer.push({
«event»: «conversion_confirmed»,
});
} else {
// Не делайте ничего, если решили не запускать конверсию
«»
}
// Установите срок действия cookie на дату из достаточно далекого прошлого, чтобы удалить файл
document.cookie = «qualified=false; path=/; expires=Thu, 01 Jan 1970 00:00:00»;
</script>
7. Отправьте событие в GA
Сначала создайте триггер, который ожидает событие conversion_confirmed.
Рисунок 13. Триггер для conversion_confirmed
Затем создайте тег, который активируется указанным выше триггером, после чего происходит отправка соответствующего события в GA. Специфика событий, отправляемых в GA, может быть любой, нужно просто убедиться, что они соответствуют критериям вашей цели в GA.
Рисунок 14. Создание тега
8. Не отключайте старые конверсии сразу
Есть одно преимущество: вы можете запустить алгоритм вместе с существующим отслеживанием конверсий, чтобы узнать, как часто происходит фильтрация. Некоторое время оставьте в рабочем состоянии старую настройку конверсии (это время зависит от частоты вашей конверсии).
Следите за двумя показателями и проверьте, не отфильтровываете ли вы слишком много конверсий. Это поможет вам обнаружить ошибки либо в старой, либо в новой настройке.
Google Analytics никогда не будет точно регистрировать все, что происходит на вашем веб-сайте. Но эти проверки и процессы должны помочь вам отсеять способы, которые вводят вас в заблуждение.
Автор: Робин Лорд
P.s. Подписывайтесь на наш телеграм-канал t.me/seoantteam, чтобы первыми узнавать о выходе новых материалов. Мы публикуем только полезный контент на тему SEO, например, о том, как ускорить индексацию сайта в Google, о причинах падения трафика или о том, когда и почему стоит использовать инструмент Google Disavow Tool.
