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

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

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

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

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

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

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

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

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

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

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

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

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

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

Google Analytics

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

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

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

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

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

//www.your-site.com/log?event=pageview&page={{Page Path}}&ga={{Page Client ID}}&referrer={{Document Referrer}}

В фигурных скобках указаны ссылки на 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 ^[5].

Реализация этого решения достаточно простая: нужно добавить 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. На верхнем уровне файл выглядит примерно так:

{
   "requests":{...},
   "triggers":{...},
   "vars":{...},
   "transport":{...},
   "linkers":{...},
}

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

   "vars":{
      "clientId":"CLIENT_ID(AMP_ECID_GOOGLE,,_ga)",
   }

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

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

   "vars":{
      "clientId":"111111111.111111111", // значение задаем динамически из куки
   }

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

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

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

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

Автор: Dmitry

Источник ^[7]