AMP-страницы отслеживаются Google Analytics с ошибками


Оглавление (нажмите, чтобы открыть):

Страницы AMP не отслеживаются в Google Analytics

Мы преобразовали наши два модуля в AMP, и все шло хорошо, все страницы отслеживались в Analytics, но неожиданно со вчерашнего дня (23 января 2020 г.), около 9:30 утра EST страницы AMP не отслеживались в Analytics.

Мы используем скрипт GTM для отслеживания наших страниц, и он размещен правильно.

Показ рекламы был увеличен вчера, но общее количество просмотров страниц меньше.

Даже я проверил инструмент веб-мастера, и у нас нет никаких проблем

Пожалуйста, дайте мне знать, что можно сделать, чтобы вернуть его

Ошибка пришла от амп-аналитики. Этот пиар откатился и скоро все будет хорошо. Но не сейчас, ошибка все еще здесь.

Обновить

Уже все хорошо. Эта ошибка не только влияет на аналитику. но также весь ваш код в GTM для AMP перестал работать на 23 часа. Это длинный длинный день.

Google Analytics некорректно отслеживает AMP-страницы

Сервис Google Analytics некорректно отслеживает AMP-страницы. К такому выводу пришёл SEO-специалист из Испании Кристиан Оливейра (Christian Oliveira).

В своём блоге он опубликовал подробное объяснение причин отклонений. Технический лид проекта Google AMP Малте Убл (Malte Ubl), подтвердил наличие проблем.

Оливейра выяснил, что:

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

    SEO-специалист предложил своё решение для этих проблем, но оно подходит не всем и не является оптимальным, отмечает Searh Engine Land. В Google, со своей стороны, намерены усилить работу по поиску решения. Однако оно вряд ли будет найдено в ближайшее время.

    Влияние ошибок на страницах AMP Google на поисковый трафик

    Рассмотрим, как ошибки на AMP страницах влияют на органический трафик.

    Главная > Блог > Seo > Влияние ошибок на страницах AMP Google на поисковый трафик

    Влияние ошибок на страницах AMP Google на поисковый трафик

    Ошибки на страницах AMP Google приводят к снижению поискового трафика. Потому что страницы с ошибками не допускаются к работе и по ним нет показов в поиске.

    Страницы AMP положительно сказываются на трафике. Пример – наблюдаемый интернет-магазин книг на битриксе. В августе — сентябре были реализованы AMP страницы, а Google их проиндексировал и ввёл в работу.

    Органический трафик на AMP страницы.

    Трафик из поиска вырос до 750 переходов в день (в пике 1 500) из органики. При этом количество переходов из Google на десктопную версию практически не снизилось.

    Что произошло с появлением ошибок на страницах AMP?

    Трафик упал до нуля. Упал стремительно. Google заметил ошибки и начал удалять такие страницы из индекса.

    Ошибки на AMP страницах привели к снижению количества переходов из органики.

    Информация об ошибках представлена в консоле Вебмастера.

    В этой консоли мы видим все ошибки на AMP страницах

    В ней мы видим динамику, тип ошибки и количество страниц.

    Исправляем ошибки и отдаём Google на проверку. После исправления всё возвращается на круги своя.

    Исправили ошибки и в качестве благодарности вернули трафик на сайт

    С какого рода ошибками можно столкнуться?

    При работе с сайтом мы столкнулись со следующими ошибками.

    Ошибка: Необходимый тег «meta charset=utf-8» отсутствует или указан неверно

    Некорректный UTF убивает ваш трафик!

    Для исправления ошибки необходимо заменить на

    Ошибка: «Значительное несоответствие контента»

    Этот скрипт не соответствует требованиям AMP

    Ошибка возникает если контент AMP страницы отличается от контента основной страницы. Google требует, чтобы контент был схож. Допустимо небольшое отличие по тексту.

    В нашем случае скрипт не соответствовал требования AMP. Для исправления ошибки – его нужно удалить.

    Ещё причина ошибки — ресурсы одной из страниц заблокированы для доступа в robots.txt. Соответственно нужно убрать запрещающую директиву.

    Дополнительно нужно проверить, чтобы в AMP страницы была верно указана каноническая страница. Материалы на страницах должны быть одинаковые.

    Это самые крупные ошибки.

    Остальные — некорректное использование значений в тегах span и a.

    Для быстрого исправления в консоли есть валидатор.


    Рекомендую этот ресурс https://www.ampproject.org/ru/docs/reference/validation_errors — он позволит быстро найти и исправить ошибки на страницах AMP.

    Пользователям Chrome – пригодится расширение AMP Validator.

    Удобный валидатор AMP страниц

    Он поможет найти ошибку в документе. Затем даст ссылку на возможное решение проблемы.

    Что не так с Google Analytics: ошибки в настройках и особенности системы

    Чек-лист для проверки, список ошибок и особенностей ГА — что вы можете исправить, на что вы не можете повлиять

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

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

    20 ошибок в настройке Google Analytics

    Начнем с некорректных настроек, которые вы можете исправить. Пройдитесь по списку и сравните с вашими настройками на проектах. Исправления могут существенно улучшить вашу аналитику.

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

    1. Установка GA на тестовом сервере

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

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

    2. ID ресурса в настройках GA не соответствует ID в коде на сайте

    Такое случается, когда владелец сайта не следит за настройками аналитики (например, разработчик не переспросил, когда ставил код, сменился специалист, который занимался аналитикой, а новый специалист сделал все по-своему и т.д.).

    3. Неправильная комбинация кода отслеживания событий и кода GA

    Существует три типа скриптов GA: ga.js, analytics.js и gtag.js (самый свежий). Для корректного отслеживания событий (например, кликов) важно, чтобы код трекинга событий (event tracking code) соответствовал GA-коду. К примеру, если у вы установили актуальный скрипт ga.js, но оставляете старый трекинг-код для analytics.js, события не будут отображаться в дэшборде.

    4. Не настроен фильтр для внутреннего трафика

    С сайтом может работать множество сотрудников компании (маркетологи, разработчики, менеджеры по продажам и т.д.). Чтобы их посещения не влияли на данные в GA, необходимо настроить фильтр, исключающий внутренний трафик (по IP офиса/офисов и других мест, откуда могут работать сотрудники).

    Можно использовать два разных представления — с фильтрами и без них.

    5. Неправильный часовой пояс

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

    6. Неправильная валюта

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

    7. Не настроен или неправильно настроен тип соответствия для целей

    При настройке целей можно выбрать тип соответствия: «Equals to» («Равно»), «Begins with» («Начинается с») и «Regular expression» («Регулярное выражение»).

    • Если цель соответствует конкретному URL, следует выбрать «Равно».
    • Если при совершении отслеживаемого действия к URL добавляется ID cессии или транзакции, выбираем «Начинается с».
    • Если необходимо учесть несколько условий — настраиваем «Регулярное выражение».

    8. Собственный сайт не исключен из списка источников переходов

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

    9. Страницы платежей не внесены в список исключения источников переходов

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

    10. Google Search Console не связана с Google Analytics

    Если Google Search Console не связана с GA, вы не сможете узнать, какой поисковый запрос привел пользователя на ваш сайт, и на какой странице он оказался. Для отслеживания в разделе «Связь с другими продуктами» / «Все продукты» необходимо подключить Search Console.

    11. GA не связан с другими продуктами Google

    Для сбора более точной информации свяжите GA с Google Рекламой, Adsense, Ad Exchange и настройте импорт расходов. Это позволит проследить связь между действиями пользователей и вашей рекламной активностью.

    Профессиональные инструменты PromoPult: быстрее, чем руками, дешевле, чем у других, бесплатные опции. Оптимально для работы с контекстной рекламой.

    Съем позиций, кластеризация запросов, парсер Wordstat, сбор поисковых подсказок, сбор фраз ассоциаций, парсер мета-тегов и заголовков, анализ индексации страниц, чек-лист оптимизации видео, генератор из YML, парсер ИКС Яндекса (бесплатно).

    Мастер Йода рекомендует:  Аппетитный интерфейс 7 трюков, которые выделят приложение

    12. Не активирован анализ данных о пользователях

    Пользователи могут заходить на ваш сайт с разных устройств. Это искажает показатели в отчетах. Решение в GA есть: при отслеживании трафика система для каждого посетителя создает уникальный идентификатор. Это может быть файл cookie с названием _ga или функция User ID в сочетании с ID клиента. По умолчанию такое отслеживание отключено. Если у вас интернет-магазин или сайт услуг, его следует включить.

    13. Код GA проставлен не на всех страницах

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

    14. Код GA не проставлен на странице с 404 ошибкой

    Если на 404-й странице нет кода GA, данные о сеансе, включающем переход на 404-ю страницу, будут искажены. Будет происходить разрыв сеанса.

    15. Код GA не установлен на мобильной версии сайта

    Если ваш мобильный сайт имеет URL, отличный от десктопного, на нем должен стоять отдельный счетчик.

    16. Не настроены отдельные цели под мобильный сайт

    Опять же, для мобильного сайта все цели должны быть настроены отдельно.


    Полезно знать: в условиях Mobile First работа по продвижению мобильной версии становится приоритетной. И отчеты по продвижению десктопа и мобайл версии нужно готовить раздельно.

    17. Неправильное размещение кода GA

    Google рекомендует размещать код GA в хедере. Если он расположен после закрывающего тега , счетчик может работать некорректно.

    18. Несколько счетчиков GA на одной странице

    Если вы по ошибке разместили несколько кодов GA на одной странице, система не сможет правильно собрать аналитические данные.

    19. Неправильно настроены события «non Interaction» («без взаимодествия»)

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

    Для этого в объекте fieldsObject команды send присвойте полю nonInteraction значение true:

    Пример для видео:

    20. Реферальный спам

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

    6 искажений в статистике, на которые вы не можете повлиять

    Иногда статистика искажается по независящим от вас причинам. В этом случае можно лишь принять к сведению такую возможность.

    Измени то, что ты можешь изменить. Смирись с тем, что ты изменить не в состоянии. И научись отличать одно от другого.

    1. На некоторых браузерах заблокирован Java Script

    GA собирает информацию о сайте, используя Java Script. Если браузер его блокирует, скрипт не работает. К счастью, это редкий случай.

    2. Некоторые пользователи отключают куки

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

    3. Срок действия cookies истек

    Существует два типа cookies.

    • Постоянные — те, которые фиксируются при первом визите и остаются на устройстве до двух лет (или пока пользователь не обновит браузер или не почистит куки).
    • Сессионные — те, которые пользователь получает при каждом новом посещении.

    GA завершает сессию после 30 минут отсутствия взаимодействия со страницей. Т.е. если пользователь прервался на полчаса и затем вернулся к сайту, начинается новая сессия и он получает новую сессионную куку.

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

    4. Один посетитель использует несколько устройств

    Анализ поведения посетителей, использующих одновременно несколько устройств, — серьезная задача, с которой GA пока не справляется. Допустим, пользователь ищет товар со смартфона, изучает все характеристики, сравнивает разные варианты… а затем открывает ноутбук, заходит на сайт того же магазина и через 10 секунд оформляет заказ.

    В GA вы увидите посетителя мобильного сайта, который совершил много действий, но не дошел до конверсии, и посетителя десктопной версии, совершившего покупку за минуту. В итоге мы получаем искаженную картину поведения покупателей. Учитывая, что 67% посетителей используют для онлайн-шопинга несколько девайсов, проблема действительно серьезная.

    Это можно контролировать, если настроить анализ данных о пользователях (см. п.12 выше).

    5. GA не отображает данные в режиме реального времени

    GA обрабатывает данные в течение 24 часов. В режиме реального времени отображается крайне скудная информация:

    6. GA может анализировать выборочные показатели

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

    Чек-лист: что еще можно проверить

    Параметры и показатели

    Составлена и ведется актуальная таблица событий и целей

    Это таблица, в которой прописаны все события и цели, в каких частях страницы они проставлены, при каких условиях и на каких устройствах они срабатывают.

    Настроены вычисляемые показатели

    Вычисляемые показатели помогают рассчитать данные, которых нет по умолчанию. Например:

    • доход на пользователя = доход / пользователи;
    • сеансы на пользователя = сеансы / пользователи;
    • ценность лида = ценность цели / достигнутые переходы к цели;
    • расходы с учётом НДС или агентской комиссии = расход на рекламу * 1,20 (или на % комиссии).

    Созданы группы контента

    Группы контента полезны для сравнения популярности разных разделов сайта без фильтрации по URL. Например: основной сайт, интернет-магазин, блог, форум. Это особенно полезно, если сайт слабо структурирован.

    Добавлен фильтр поиска и замены

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

    Добавлен фильтр нижнего регистра

    Это важно, если в ссылках есть символы в разном регистре. Например, site.ru и Site.ru. Если фильтра нет, то в отчётах будет отдельная статистика по просмотрам site.ru и Site.ru.

    Исключены ненужные параметры запросов в URL

    Из отчётов лучше исключить любые параметры URL или уникальные идентификаторы сеансов, такие как sessionid, yclid, _openstat и пр. Так GA не будет воспринимать страницы с доп.параметрами как другие URL.

    Настроен поиск по сайту


    Вы узнаете, как часто пользователи пользуются поиском по сайту, что ищут и находят ли вообще.

    Настройки ресурса

    Доступ к GA есть только у тех, кто должен его иметь

    Контролируйте доступы и вовремя отключайте бывших сотрудников и подрядчиков.

    Настроен pageType

    Пользовательский параметр «тип страницы». Например, для интернет-магазина — main (главная), catalogue (каталог), product (карточки товара).

    Настроен clientID

    Пользовательский параметр Client ID — уникальный идентификатор клиента, который присваивается каждому устройству. По нему в отчетах учитываются уникальные пользователи. Он необходим для выгрузки данных о продажах через Measurement Protocol.

    Настроен userCity

    Если контент сайта меняется в зависимости от указанного города, стоит использовать пользовательский параметр userCity — так вы сможете делать отчет по городам.

    Настроен userID

    Пользовательский параметр userID — это ID пользователя из базы данных (CRM).

    Настроена интеграция с Youtube-каналом

    Если интеграция настроена, вы сможете анализировать трафик канала на Youtube.

    Настроены атрибуты динамического ремаркетинга

    Это нужно для создания рекламных кампаний динамического ремаркетинга.

    Включен сбор данных для ремаркетинга

    Аудитория ремаркетинга — группы пользователей, посетивших сайт. Информация о них копится в GA, если включить сбор данных для ремаркетинга.

    Нет личной информации о пользователях

    ФИО, номер телефона и кредитной карты, почту, уникальный ID мобильного телефона использовать нельзя (даже в хешированном виде). Допустим ID клиента в CRM. Если нарушить правило, Google может удалить аккаунт и все данные.

    Оповещения

    Можно настроить оповещения, которые позволят вам вовремя исправлять ошибки.

    • Рост JS ошибок на 50% ко дню на прошлой неделе.
    • Рост 404 ошибок на 100% ко дню на прошлой неделе.
    • 404 ошибка при переходе с UTM.
    • Падение главной сайтовой цели на 50%.
    • Перестал отрабатывать код GA.

    Удобство использования GA

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

    Например, вы работаете с каким-то ресурсом по CPA. Они хотят видеть заказы со своего источника. Достаточно дать им доступ на уровне представления только к конкретному источнику.

    Пользовательские отчеты, часто используемые отчеты

    Все необходимые отчеты созданы, а часто используемые добавлены в раздел «Сохраненные отчеты (Ярлыки)» для быстрого доступа.

    Пользовательские сводки

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

    Как настроить веб-аналитику на AMP страницах

    Привет, Хабр. Я data-аналитик отдела маркетинга Wrike: занимаюсь сбором и анализом всех рекламных данных, моделированием LTV и другими техническими задачами, помогающими команде делать самую эффективную рекламу во всех источниках. Недавно я столкнулся с проблемой настройки сбора данных на AMP-страницах и обнаружил совсем мало информации по теме, поэтому решил рассказать вам, как справиться с этой задачей.

    В Wrike мы построили систему веб-аналитики, обслуживающую большое количество различных стейкхолдеров: команды веб-сайта, лидогенерации, marketing ops, контент-менеджеров, маркетинговое руководство и C-level. Команде аналитиков очень важно поддерживать полноту, консистентность и своевременность собираемых на сайте данных, ведь на их основе строится большое количество отчетов и рассчитывается ожидаемая выручка для оценки эффективности рекламной кампании в реальном времени.

    На клиентской части наша аналитика работает на Google Tag Manager (GTM) — такое решение позволяет команде удобно добавлять и изменять аналитические скрипты без участия специалистов веб-сайта. Установленные скрипты можно разделить на три группы по конечной точке для данных:

    1. Google Analytics;
    2. Наши внутренние логи, из которых данные затем загружаются в PostgreSQL;
    3. Трекеры рекламных площадок и других систем аналитики (LinkedIn, Twitter и другие площадки считают просмотры страниц и конверсии, чтобы показывать отчеты о рекламе в своем интерфейсе).

    Внутренняя база данных обменивается данными с Google Analytics и сторонними площадками. При обмене мы обычно идентифицируем пользователя по присвоенному аналитикой client ID: он хранится и в нашей базе, и в Google Analytics в качестве пользовательского параметра. Для себя мы забираем значение из куки _ga .

    Недавно команда нашего веб-сайта адаптировала страницы корпоративного блога под стандарт AMP. Вкратце, AMP (Accelerated Mobile Pages) — это особый стандарт создания страниц для мобильных устройств, позволяющий значительно ускорить их работу. Если страница соответствует стандарту, то AMP Project кэширует страницу на своем CDN, и страница будет встроена в поиск Google на мобильных устройствах.

    Страница нашего блога в поисковой выдаче. Иконка AMP слева от ссылки означает, что страница откроется во фрейме (iframe) прямо на странице поиска.

    В частности, высокая скорость загрузки AMP-страниц достигается отсутствием исполняемого пользовательского JS в коде страницы (тег script запрещен, если не обладает типом application/ld+json или text/plain ), а сама страница выстраивается из ограниченного набора предоптимизированных тегов. Для веб-аналитики это стало испытанием, которое мы успешно преодолели.

    Мастер Йода рекомендует:  10 бесплатных сниппетов навигационных цепочек для веб-проектов

    При добавлении AMP-страниц в нашу экосистему возникают две проблемы:

    1. Обычные методы сбора данных, основанные на JS, перестают работать;
    2. В AMP вместо куки используется local storage, а client id генерируется по совершенно другой маске:

    Рассмотрим проблемы отдельно.

    Сбор информации

    В GTM можно завести отдельный контейнер, подходящий для AMP-страниц, но в последних сильно урезано разнообразие типов тегов, которые можно добавить. Самая большая проблема — это, конечно, отсутствие типа Custom HTML, через который мы обычно размещаем свои скрипты. Посмотрим, как решить эту и другие проблемы для каждой конечной точки данных.

    Google Analytics

    Это самая простая категория. В AMP-контейнерах предусмотрен тип тега Universal Analytics, через который можно установить Google Analytics. Вместе с отправкой просмотра страницы и события в аналитику попадают только пользовательские параметры и показатели. Группы контента, данные электронной торговли и другие поля, доступные в GTM для обычных страниц, настроить здесь не удастся.

    Если вместе с Google Analytics вы используете Яндекс.Метрику, ее также можно поставить, но через GTM уже не получится: придется подключать разработчиков. Здесь можно найти подробную инструкцию.


    Пример отправки просмотра страницы в Google Analytics через GTM для AMP

    Собственные логи

    Любые запросы можно отправить с помощью тега Custom Image. На бекенде важно обеспечить пиксель, который записывает данные из GET параметров запроса. Чтобы сконфигурировать отправку данных, добавьте необходимые переменные в адрес запрашиваемой страницы и не забудьте воспользоваться опцией Enable Cache Busting, чтобы пиксель не кэшировался.
    Например, отправить данные о просмотре страницы с client ID и реферером можно с помощью пикселя:

    //www.your-site.com/log?event=pageview&page=<>&ga= <
    В фигурных скобках указаны ссылки на GTM-переменные, их можно настроить в соответствующем разделе интерфейса GTM. Набор встроенных переменных, конечно, ограничен. Рассчитать собственные значения в связи с отсутствием JS тоже нельзя. Если необходимо, можно рассчитать нужные значения на клиентской части с помощью AMP-переменных — к ним можно обращаться из GTM.

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

    Прочие трекеры

    Адаптировать другие трекеры, которые не интегрированы с AMP, достаточно сложно. Чтобы понять, что можно адаптировать, а что нельзя, нужно посмотреть запросы, отправляемые этими трекерами. Если параметры, отправляемые трекером, доступны в GTM, то можно отправить нужные данные с помощью того же Custom Image. Если у счетчика есть noscript часть, ее, как правило, можно перенести в GTM.

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

    Унификация client ID

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

    1. Обычная версия (допустим, www.your-site.com/blog/article-name/ )
    2. Загрузка напрямую на сайте (здесь статья размещается для кэширования, например, www.your-site.com/blog/article-name/amp/ )
    3. Закэшированная версия в AMP CDN (адрес будет примерно таким: www-your-site-com.cdn.ampproject.org/v/s/www.your-site.com/blog/article-name/amp/ )
    4. Загрузка через iframe в поисковой выдаче: iframe будет смотреть на тот же адрес, что и в пункте 3, но формально пользователь просматривает www.google.com .

    Если команда аналитики не предпринимает никаких мер по интеграции AMP в свою систему аналитики, то client ID будет передаваться только между обычной и AMP-версиями, расположенными на вашем домене.

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

    Во всех остальных случаях client ID не передается. А значит, пользователь, прочитавший статью в поисковой выдаче и перешедший затем на сайт, с точки зрения автоматики — это два разных человека. В результате в аналитике вы увидите резкий рост «новых» пользователей, данные по источникам не будут отражать реальность, а во внутренней системе аналитики вы потеряете возможность составить правдивый путь пользователя от первого посещения и до конверсии.

    Решение 1. Client ID API

    Google предлагает воспользоваться Client ID API.

    Реализация этого решения достаточно простая: нужно добавить opt-in метатег на AMP-страницы и добавить конфигурацию в код Google Analytics на обычных страницах сайта. Однако у этого решения есть много минусов:

    1. Оно будет работать только в паре Google search – your site;
    2. Оно будет работать только в одну сторону: если пользователь впервые зашел на AMP, то на обычном сайте для него будет использоваться AMP-идентификатор. Если пользователь уже был на вашем сайте и зашел на AMP, то для него будет сгенерирован новый идентификатор;
    3. В нем используются AMP-идентификаторы. Если ваша внутренняя база построена на обычных client id, то это может привести к неожиданным проблемам.

    Client ID API позволяет передать данные пользователя из поисковой выдачи на ваш домен, но это работает только в одну сторону.

    Решение 2. Кастомизированная конфигурация amp-analytics

    В отличие от полноразмерной версии, в AMP GTM подключается не через JS, а через JSON-файл. Файл конфигурации содержит информацию о всех тегах, триггерах и другие настройки GTM. На верхнем уровне файл выглядит примерно так:

    Уровень vars содержит информацию о client ID:

    GTM будет использовать любой client ID, который передан в этом поле. Значит, мы можем скачать этот файл, разместить на своем основном домене и заменить client ID на тот, который хранится в куки (и доступен на основном домене). Для этого создаем на основном домене генератор JSON-файлов, который:

    1. Забирает JSON-конфигурацию из GTM по адресу https://www.googletagmanager.com/amp.json? > (замените GTM-XXXXXXX на идентификатор вашего контейнера и SOURCE_URL на адрес открытой пользователем страницы;
    2. Считывает куки _ga . Если ее нет, необходимо сформировать client ID в формате Google в виде: случайное девятизначное число, точка, временная метка (timestamp). Если значение пришлось создавать, запоминаем его в куки _ga . Возвращаем файл, полученный из GTM с подменой client ID:

    Заменяем установочный JSON GTM на свой с кастомизированным client ID и передаем один и тот же client ID для одного пользователя на все возможные клиенты AMP.

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

    С помощью подмены client ID все домены с AMP страницами используют одинаковые данные о посетителе и не создают лишних сессий.

    Спасибо, Симо Ахава, за идею с подменой client ID в JSON-конфигурации.

    AMP-страницы отслеживаются Google Analytics с ошибками

    Бывает, что ссылки с объявлений контекста ведут на несуществующие станицы сайта. В результате вы не только теряете деньги на оплату рекламы, но и понижается уровень магазина в глазах потенциального клиента. При переходе на несуществующую страницу сайта выдает 404 ошибку. Отслеживание 404 ошибки наиболее актуально будет для тех, у кого интернет магазин с большим ассортиментом товаров и реклама ведет на карточку с товаром. Так как при большом количестве изменений на сайте, так и в рекламных кампаниях с целью оптимизации ошибки практически неизбежны.

    Отслеживать 404 ошибки в google analytics довольно просто. Для этого вам необходимо знать название страницы с 404 ошибкой.

    Как узнать название страницы с 404 ошибкой
    1. Переходим на сайт и в адресной строке прописываем после название сайта 404errors
    2. Наводим на вкладку в браузере и смотрим название страницы.

    В примере мы видим , что название страницы «Ошибка 404 Страница не найдена»

    Переходим в google analytics

    Поведение/// Контент сайта /// Все страницы /// выбираем дополнительный параметр «название страницы»

    Выбираем фильтр: Изменить /// выбираем «название страницы» /// содержит «Ошибка 404 Страница не найдена» /// Применить

    В отчете видим, сколько раз посетители переходили на страницу с 404 ошибкой

    Если у Вас Google Adwords и Google analytics установлена связь можно настроить полезный пользовательский отчет

    Тип: простой

    Параметры: источник или канал, идентификатор объявлений AdWords, группа объявлений AdWords, Название страницы, Страница входа

    Показатели: Сеансы, Показатель отказов

    Фильтр:

    Название страницы /// точное соответствие /// Ошибка 404 Страница не найдена //(по примеру)


    Источник или канал /// точное соответствие/// google / cpc

    Из отчета видно, сколько переходов было на несуществующие страницы по google Adwords.

    Настройка отслеживания 404 ошибки через google tag manager

    Для этого нам также нужно знать название страницы, создать тег, триггер и переменные

    1.Создаем переменную название страницы «document.title»

    тип переменной: Переменная JavaScript

    имя глобальной переменной: document.title

    2.Находим названия страницы с 404 ошибкой

    Вводим в адресную строку название сайта и допишем 404errors

    Название страницы будет во вкладке адресной строки или можно посмотреть в отладчике gtm при прослушке кликов

    Теперь мы знаем, что переменная document.title на несуществующей странице принимает значение «The page you requested cannot be found!»

    3.Создаем триггер, что бы наш тег отправлялся только тогда, когда document.title принимает значение The page you requested cannot be found

    название: errors 404 page

    тип триггера: Просмотр страницы

    Триггер активируется на следующих страницах: некоторые просмотры страниц

    Условие: document.title содержит The page you requested cannot be found

    4. Для тега нам нужно активировать встроенные переменные, если они у Вас не активированные

    Переходим в раздел переменные /// настроить /// активируем переменные Page Path и Referrer

    5.Настроим тег

    Название: Errors 404 page

    Тип тега: Universal Analytics

    Тип отслеживания: событие

    Категория: Errors 404 page

    Действие: выбираем переменную «Page Path» — часть url ,без домена

    Ярлык: выбираем переменную Referrer – с какой страницы перешел пользователь

    Не взаимодействие: True

    Включаем переопределение настроек в этом теге

    Идентификатор отслеживания: cod ua – созданная переменная

    Триггер активации тега: выбираем Errors 404 page – который мы предварительно создали

    Отправляем настройки в gtm на публикацию

    Если вы не уверенные в корректности настроек проверяем через отладчик «Предварительный просмотр»

    Переходим на несуществующую страницу на вашем сайте и смотрим, какие теги сработали

    Мы видим, что наш тег «Errors 404 page» сработал

    Смотрим, какие данные будут передаваться в google analytics

    Теперь, когда мы настроили тег, который передает данные о 404 ошибке в google analytics настроим пользовательский отчет

    Тип: простая страница

    Параметры: категория событий, действие по событию, ярлык события

    Показатели: всего событий, уникальные события

    Фильтр: категория событий точное соответствие Errors 404 page

    Анализируйте, делайте выводы, принимайте решения и действуйте!

    Как предотвратить ошибки в сборе данных Google Analytics

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

    Однако за удобством в использовании Google Analytics порой могут скрываться незаметные, но болезненные изъяны в настройке, из-за которых данные по сайту будут передаваться в искаженном виде либо не передаваться вовсе.

    Ниже — пять примеров стратегически важных ошибок, которые наиболее часто встречаются в настройке Google Analytics, и пути к их устранению.

    1. Неполный или неверный код отслеживания

    Залог правильной работы Google Analytics — код отслеживания должен быть установлен на каждой странице сайта. Google рекомендует помещать код отслеживания сразу же после открывающего тега body, а в случае, если вы помещаете несколько контейнеров — использовать Google Tag Manager для удобного управления ими.

    Если ранее у вас не был настроен Google Analytics, настройте его сразу посредством GTM — в дальнейшем будет гораздо проще как вносить любые изменения в настройки контейнера, так и добавлять новые.

    Как устранить проблему:

    Чтобы быстро узнать, правильно ли установлен код отслеживания, воспользуйтесь расширением Tag Assistant для Chrome. С его помощью можно в один клик просмотреть, какие контейнеры отслеживания установлены на сайте. Также Tag Assistant показывает множество полезной для дебаггинга информации, например содержание объекта dataLayer для GTM, активированные события, а также способен дать ряд подсказок по оптимизации контейнеров.

    Мастер Йода рекомендует:  Как создать макет iPad


    При нажатии на кнопку «Record» можно отследить, как правильно срабатывают триггеры и срабатывают ли они вообще. Это особенно удобно для прицельного дебаггинга.

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

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

    Добраться до меню создания оповещений можно двумя способами: на вкладке «Отчеты» пункт в боковом меню «Оповещения», либо на вкладке «Администратор» — «Мои оповещения» в меню представления.

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

    2. Ненастроенные или неправильно настроенные цели

    Цели Google Analytics — основа любой стратегии веб-аналитики. Без целей трудно ориентироваться и сделать вывод о производительности сайта, его слабых звеньях и местах для улучшения.

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

    3. Отсутствие представления по умолчанию

    Две ситуации, равно чреватые для корректного анализа:

    • Единственное представление на весь аккаунт («Все данные по веб-сайту») без каких-либо фильтров, обеспечивающих качественный сбор статистики
    • Аккаунт со множеством неправильно определенных ресурсов и представлений, но без представления с чистыми данными.

    Как устранить проблему:

    Эксперты Google Academy советуют иметь как минимум три представления для каждого ресурса в вашем распоряжении:

    • Главное представление (Master view) — в котором настроены все «технические фильтры», устраняющие нерелевантную информацию по сайту.
    • Тестовое представление (Test view) — здесь вы экспериментируете с настройками с целью выбора оптимальной конфигурации, отражающей
    • Представление по умолчанию («Все данные по веб-сайту») — служит бэкапом на случай любых неприятностей с остальными представлениями.

    4 Отсутствие интеграции Google Analytics с другими сервисами

    Google Analytics поддерживает интеграцию со множеством других инструментов. Благодаря ним можно получать

    Привязка к AdWords

    Интеграция Google Analytics к аккаунту AdWords не составляет особого труда, а пользы приносит достаточно: после связки аккаунтов в Google Analytics откроется возможность просмотра разнообразной статистики по аккаунту AdWords, а также возможность импортировать цели из Google Analytics в AdWords и более эффективно работать со списками ремаркетинга.

    Привязка к Google Search Console

    При помощи интеграции Google Search Console вы получите доступ к данным по органическому поиску сайта прямиком в интерфейсе Google Analytics.

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

    5 Работа с сырыми данными

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

    Вот несколько советов по получению более надежных и достоверных данных.

    Используйте фильтры

    Для получения точных и не дублирующихся данных по сайту имеет смысл наложить следующие фильтры:

    • Исключение собственного IP-адреса, а также IP-адресов всех веб-мастеров, имеющих доступ к аккаунту.
    • Фильтры по нижнему регистру (lowercase filters) на параметрах кампании, URI запроса и имени хоста.
    • Фильтр по имени хоста.

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

    Используйте компоновщик URL

    По умолчанию Google Analytics отслеживает четыре источника трафика:

    • Прямой трафик (Direct traffic) — непосредственный переход через URL в адресной строке или закладке браузера;
    • Органический трафик (Organic traffic) — пользователи, пришедшие через поиск;
    • Реферальный трафик (Referrals) — пользователи, перешедшие с других сайтов;
    • Платный траффик (CPC — Cost per click) — при условии правильно интегрированного аккаунта AdWords.

    Однако если вы активно используете email-маркетинг либо запускаете партнерские программы, для корректного отслеживания этих кампаний следует воспользоваться компоновщиком URL.

    Исключите технические параметры запроса

    Параметры url-адресов, по которым переходят пользователи сайта, условно можно разделить на два типа:

    • Аналитические, релевантные для сбора данных Google Analytics, к примеру UTM-метки: utm_source, utm_medium, utm_campaign.
      Эти параметры исключать не следует, поскольку вместе с ними потеряются важные данные для Google Analytics
    • Технические, содержащие информацию прикладного характера, не релевантную в контексте веб-аналитики, например: example.com/?session >.
      Google Analytics будет распознавать страницы с подобными get-параметрами и без них как два разных адреса, и информация по одной странице может раздвоиться. В худшем случае одна страница с разными параметрами url разделит информацию на десятки групп.
      Воспользуйтесь этим окном, чтобы указать параметры, которые должны быть исключены:

    Заключение

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

    Если вы нашли ошибку, выделите участок текста и нажмите Ctrl + Enter или воспользуйтесь ссылкой , чтобы сообщить нам.

    Google Analytics предложил решение для лучшего отслеживания AMP-страниц

    С момента запуска AMP вебмастера неоднократно жаловались на то, что Google Analytics предоставляет некорректную статистику по этим страницам. Однако разработчики продолжают работать над этой проблемой. Вчера компания предложила новое решение AMP Client ID API, которое позволяет улучшить отслеживание сайтов с AMP-страницами.

    Новое решение требует «небольшого изменения кода» на AMP и обычных страницах.

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

    Что нужно изменить:

    AMP-страницы


    В раздел AMP-страницы необходимо добавить следующий код:

    Обычные страницы

    Диспетчер тегов

    В существующих опубликованных контейнерах тегов нужно сделать следующее:

    • Выберите «Конфигурация тега» > «Поля, которые необходимо задать»
    • Установите значение переменной useAmpClientId на «true».
    • Сохраните новую конфигурацию тега.
    • Опубликуйте контейнер.

    analytics.js

    Добавьте в код отслеживания Google Analytics следующий фрагмент:

    Напомним, что в мае Google объявил об обновлении отчётности, связанной с AMP. Теперь сервис унифицирует ID пользователя в том случае, если он посещал домен через AMP и обычные страницы. Ранее эти просмотры учитывались как отдельные сессии.

    Это решение действует на уровне домена сайта, а новое – во всех интерфейсах Google.

    AMP-страницы отслеживаются Google Analytics с ошибками

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

    Нажав кнопку «Принять и продолжить», вы соглашаетесь с Политики конфиденциальности

    Мы запустили рейтинг зарплат интернет-маркетологов! Прими участие в анонимном опросе.

    How-to – Читать 7 минут – 20 декабря 2020

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

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

    Основные причины, когда веб-страница выдает код ответа сервера «404 Not Found», заключаются в том, что:

    • страница удалена веб-мастером;
    • страница перемещена на новый адрес;
    • страница перемещена в другой раздел;
    • ссылка была битой;
    • неправильно настроен редирект;
    • некорректно сработал сервер;
    • допущена человеческая ошибка (опечатка в URL) и другое.

    Теперь отсортируем страницы так, что в итоге получим сводку, поиск который сосредоточен на название «Страница не найдена». В нашем случае применяется именно такое имя, потому оно используется на сайте-образце.

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

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

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

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

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

    Чтобы включить мониторинг возникновения 404 ошибки через Tag Manager, начните с создания переменной. Используйте произвольное название либо «Переменная заголовка страницы». Наша цель — сформировать переменную, проверяющую заголовок страницы (например, «Страница не найдена»).

    Выполните следующие шаги:

    Настроенная переменная сообщит имя веб-страницы, на которую зашел посетитель. Ввиду того, что нас интересует конкретный заголовок, например «Страница не найдена», мы уточним задачу. Создадим триггер, который реагирует именно на заголовок «Страница не найдена». Учтите, что наименования страниц варьируются: «404», «Ошибка», «Страница в обработке» и пр. Поэтому уточните тот, который зафиксирован у вас на веб-ресурсе.

    Переходим к созданию триггера. При добавлении нового триггера необходимо уточнить его настройки. Задайте отслеживание 404 ошибок под названием «404 Trigger Title» или другим понятным для вас именем.

    Выберите тип события Google Analytics «Просмотр страницы». Активацию настройте на некоторых страницах, которые должны отвечать 404 кодом:

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

    Создайте специальный тег под названием «404 — Событие Тег». Заполните предложенную ниже конфигурацию данному тегу.

    Параметры, которые вам нужно установить:

    • тип — выберите «Universal Analytics»;
    • тип трека — задайте «Событие»;
    • категория — укажите «Error 404»;
    • действие — сделайте «<>»;
    • напишите идентификатор отслеживания, который можно добавить в качестве постоянной переменной в инструмент Google Analytics, это в дальнейшем упростит работу в инструменте;
    • в завершении свяжите подготовленный триггер «Просмотра страниц» с типом аналитики из первого пункта.

    Сохранитесь и проверьте работу с помощью предварительного просмотра.

    Все переменные, триггер и тег работают непосредственно для отслеживания событий в Google Analytics.

    AMP-страницы отслеживаются Google Analytics с ошибками

    357 просмотра

    1 ответ

    16 Репутация автора

    Мы преобразовали наши два модуля в AMP, и все шло хорошо, все страницы отслеживались в Analytics, но неожиданно со вчерашнего дня (23 января 2020 г.), около 9:30 утра EST страницы AMP не отслеживались в Analytics.

    Мы используем скрипт GTM для отслеживания наших страниц, и он размещен правильно.

    Показ рекламы был увеличен вчера, но общее количество просмотров страниц меньше.

    Даже я проверил инструмент веб-мастера, и у нас нет никаких проблем

    Пожалуйста, дайте мне знать, что можно сделать, чтобы вернуть его

    Ответы (1)

    3 плюса

    962 Репутация автора

    Ошибка пришла от амп-аналитики. Этот пиар откатится и скоро все будет хорошо. Но не сейчас, ошибка все еще здесь.

    Обновить

    Уже все хорошо. Эта ошибка не только влияет на аналитику. но также весь ваш код в GTM для AMP перестал работать на 23 часа. Это длинный длинный день.

  • Добавить комментарий