Идентификатор клиента Google Analytics в AMP-страницах

Итак, в статье я расскажу о AMP страницах (Accelerated Mobile Pages), а так же рассмотрим возможность идентификации пользователей веб-сайта привычным для всех способом.

AMP не только имеет свой собственный уникальный синтаксис для идентификатора клиентов Client ID. Он также сохраняет его в разных местах. К примеру, в AMP Cache (таким образом, в поисковике Google) он хранится в localStorage. Если кто-то напрямую заходит на ваш сайт и подключается к AMP-страницам, то Client ID сохраняется в куки AMP_ECID_GOOGLE. А если кто-то посещает обычную страницу на вашем сайте, то Client ID можно найти в куки _ga.

Примеры показаны на NodeJS и PHP (WordPress). Тем не менее, метод универсален и достаточно прост для применения с программным обеспечением любого веб-сервера.

Обзор

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

GA1.2.1234567891.1711325712

Значение GA1 показывает, что это версия 1 куки _ga. Цифра 2 указывает на количество разделенных точками компонентов в URL, в котором хранятся куки. К примеру, если бы GA хранил куки в shop.analytictracking.in, вместо 2 в строке стояла бы цифра 3.

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

Тем не менее, есть способ использовать только _ga куки для всех источников, обслуживающих ваш веб-контент. Для этого нам необходимо настроить компонент amp-analytics.

Изменение конфигураций AMP

Компонент amp-analytics используется AMP для отслеживания взаимодействий пользователей. Если хотите узнать больше о всех его свойствах, просмотрите в блоге руководство по AMP для GTM (Google Tag Manager). Там есть вся необходимая информация.

Для наших целей давайте сконцентрируемся на атрибуте config. Это необязательный атрибут. При помощи его вы можете как бы «сказать» AMP: «Эй, у нас есть несколько дополнительных конфигураций, которые нужно извлечь отсюда». Этот атрибут должен быть установлен в тот URL, откуда будут извлекаться дополнительные конфигурации. Другими словами, нужно указать конечную точку запроса HTTP, которая возвращает совместимый с AMP валидный конфигурационный файл в формате JSON.

Как только браузер загрузит AMP-страницу, и она отобразится в окне браузера, AMP получит внешний конфигурационный файл. Он использует его, чтобы дополнить те конфигурации, которые уже установлены на странице. В отличии от других ресурсов в вашем контенте, конфигурация amp-analytics всегда будет направляться на ваш сервер и результат не станет автоматически кэшироваться. Когда запрос придет на сервер, он будет содержать все куки, установленные в браузере пользователя на вашем домене.

Обратите внимание! Если ваш контент обслуживается посредством Google AMP Cache, любая внешняя конфигурация должна загружаться с HTTPS ресурса. Таким образом, если ваш сервер на HTTP, вам нужно будет или пускать в ход пользовательские конфигурации тогда, когда посетители находятся на вашем домене, или же просто использовать конфигурации по умолчанию. Или, знаете ли, переключиться на HTTPS как можно скорее.

Присваивание куки _ga

Когда ваш веб-сервер получает запрос пользовательского AMP, вы можете проверить куки в запросе HTTP. Так можно будет увидеть, установлен ли уже _ga куки для пользователя на домене сайта. Это в том случае, если посетитель посещал вас ранее и не чистил куки. Если куки найден, то вы можете использовать специальный HTTP заголовок (смотрите ниже) в ответе, чтобы передать куки домену, с которого был направлен запрос, например, с кэша Google’s AMP.

Если куки не найден, то можно создать новый _ga куки, следуя той же схеме, которая используется analytics.js. Это может быть случайное 32-разрядное число в сочетании с меткой времени, округленной до ближайшей четной цифры, как в примере:

1789536866.1471440764

После вы можете использовать заголовок Set-Cookie в HTTP ответе, и настроить браузер на сохранение нового Client ID в куки _ga. При этом убедитесь, что домен, путь и срок годности соответствует домену, с которого идет запрос (например, cdn.ampproject.org), как делает analytics.js. Также нужно будет добавить тот же GA1.X. префикс, используемый Google Analytics. Кстати, вам нужно будет это делать с каждым отдельным запросом, чтобы срок службы куки _ga продлевался с каждой загрузкой страницы. А Set-Cookie в конечном итоге должен выглядеть примерно так:

Set-Cookie: _ga=GA1.1.18347199128.1478727498; Domain=example.com; Path=/; Expires=Sat, 10 Nov 2018 21:06:48 GMT;

В конечном итоге, вы можете вернуть Client ID в ответ JSON в качестве пользовательского AMP для использования с вашими AMP запросами.

Чек-лист для настройки обработчика запросов

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

В HTML сайта:

  • Добавьте тэг скрипта amp-analytics и компонент amp-analytics в ваши шаблоны AMP.
  • Настройте компонент JSON на желаемые триггеры и запросы, используя ${clientId} для параметра &cid. В качестве альтернативы вы можете использовать преднастроенный шаблон от Google Analytics, добавив в компонент type=»googleanalytics».
  • Укажите атрибут config конечной точке или API на вашем собственном сервере.
  • Установите data-credentials=»include».

На вашем веб-сервере:

  • В обработчике запросов вашего веб-сервера извлеките Client ID из куки _ga или создайте новый.
  • Добавьте параметр clientId в объект vars в конфигурации JSON. Установите его в Client ID из _ga куки.
  • Добавьте заголовок Set-Cookie с _ga куки, с двухгодичным сроком годности.
  • Установите заголовок Access-Control-Allow-Origin в https://cdn.ampproject.org. Заметка: символы подстановки (*) в этом контексте являются недействительными.
  • Установите заголовок Access-Control-Expose-Headers в AMP-Access-Control-Allow-Source-Origin.
  • Установите заголовок Access-Control-Allow-Credentials в true.
  • Установите заголовок  AMP-Access-Control-Allow-Source-Origin в исходный домен документа (например, в https://mysite.com)
  • Верните конфигурацию JSON в тело ответа.

Чтобы увидеть пример подробнее, заходите в репозиторий на GitHub. Если вы используйте конфигурации от Google Analytics по умолчанию, то это все, что вам нужно. Если же вы хотите совместить этот концепт с Google Tag Manager, читайте дальше!

Прокси Google Tag Manager с использованием NodeJS

Как я упоминал ранее в другом руководстве, Google Tag Manager (GTM) дает возможность создавать метки и триггеры в веб-интерфейсе, а затем компилировать их в конфигурацию JSON в ожидаемом для AMP формате. Однако, если мы используем стандартную GTM реализацию, то запрос отправляется непосредственно на GTM сервер. Это означает, что наш измененный API не сможет обслуживать правильный Client ID. Тем не менее, мы все еще можем комбинировать. Только нужно немного больше старания.

Вот краткий пример с использованием Node и Express. Полный код можно посмотреть в репозитории GitHUB.

 

В этом списке действий соединены пользовательский Client ID с AMP контейнером Google Tag Manager. Новые шаги отмечены жирным.

В HTML страницы:

  • Добавьте тэг скрипта amp-analytics и компонент amp-analytics в ваши шаблоны AMP.
  • Укажите атрибут config конечной точке или API на вашем собственном сервере.
  • Установите data-credentials=»include».

На вашем веб-сервере:

    • В обработчике запросов вашего веб-сервера извлеките Client ID из куки _ga или создайте новый.

 

  • Запросите контейнер JSON из GTM, пройдясь по всем параметрам исходного amp-analytics запроса.
  • Замените все ‘CLIENT_ID(AMP_ECID_GOOGLE)’ в запросе на ‘${clientId}’.

 

  • Добавьте параметр clientId в объект vars в конфигурации JSON. Установите его в Client ID из _ga куки.
  • Добавьте заголовок Set-Cookie с _ga куки, с двухгодичным сроком годности.
  • Установите заголовок Access-Control-Allow-Origin в https://cdn.ampproject.org. Заметка: символы подстановки (*) в этом контексте являются недействительными.
  • Установите заголовок Access-Control-Expose-Headers в AMP-Access-Control-Allow-Source-Origin.
  • Установите заголовок Access-Control-Allow-Credentials в true.
  • Установите заголовок  AMP-Access-Control-Allow-Source-Origin в исходный домен документа (например, в https://mysite.com)
  • Верните конфигурацию JSON в тело ответа.

В коде вашего сайта вам потребуется следующее:

Поздравляем, вы создали новый веб-прокси, который извлекает контейнер Google Tag Manager с серверов Google и модифицирует JSON для использования значений, хранящихся в куки _ga.

Прокси Google Tag Manager и WordPress

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

WordPress предоставляет хук rest_api_init, который дает вам создавать конечную точку HTTP запроса на вашем веб-сервере.

Эта часть кода в вашем functions.php создает конечную точку GET-запроса в пути вашего веб-домена /wp-json/amp-gtm/amp.json. Если GET-запрос записан в этой конечной точке, активируется функция обратного вызова  retrieve_gtm_json.

Это скрипт API, который обрабатывает запросы для контейнера Google Tag Manager. Прокси извлекает контейнер GTM и заменяет обычный Client ID на вариабельную для AMP ${clientId}. В свою очередь, это добавляется к конфигурации JSON вместе со значением, извлекаемым из куки _ga. Если этого куки не существует, создается новый.

В коде вашего сайта вам потребуется следующее:

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

И вместо игога

Это все-таки слишком техническая статья, но я считаю, что необходимо обязательно показать потенциальные недостатки аналитики в AMP и их негативное влияние на общий план отслеживания.

Немного странно, что AMP не использует автоматически куки _ga, когда запрос сделан в Google Analytics. Помимо того, непонятно, почему Google Tag Manager работает по умолчанию с AMP_ECID_GOOGLE. Все было бы намного проще, если мы могли бы указать название куки или переменного AMP для Client ID в запросе.

Поскольку кэш Google’s AMP находится на другом домене, то нет способа изменить Client ID, не вовлекая сторонние куки, как было показано в примере. Запрос должен иметь возможность обрабатывать куки, написанные на вашем домене. Только таким образом то же значение _ga куки может быть использовано на страницах во внешнем домене.

К счастью, техническое решение этой дилеммы не слишком сложно. Прокси, созданный вами на веб-сервере, довольно прост, и вы, скорее всего, сможете легко настроить его с любым программным обеспечением. Возможно, вы пожелаете добавить несколько собственных улучшений, например, локальное кэширование контейнера Google Tag Manager. Я хотел бы прочесть ваши советы и узнать о вашем опыте. Оставляйте комментарии!

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *