Междоменное отслеживание на стороне сервера с использованием тега Cookie reStore

Автор
Stape
Опубликовано
July 02, 2022
Также есть

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

Междоменное отслеживание на стороне сервера может быть еще более разочаровывающим. В этой статье я расскажу о том, как работает кросс-доменное отслеживание ss, а также о некоторых смежных темах, таких как серверное отслеживание Google Analytics, использование куки FPLC и тег Cookie ReStore от Stape, который может помочь повторно использовать куки в разных доменах.

Отслеживание кросс-доменов Google Analytics на стороне сервераСкопировать ссылку на этот раздел

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

Google Analytics отслеживает сеансы пользователей, генерируя уникальный идентификатор клиента (_ga) для каждого из них. Таким образом, он может определить, возвращается ли пользователь на сайт или является новым.

Когда Google Analytics связывает пользователей между разными доменами, он использует один и тот же идентификатор клиента для обоих сайтов. Идентификатор клиента хранится в файлах cookie браузера. Если включено отслеживание междоменных переходов, веб-аналитика GA добавляет параметр linker к URL-адресам, указывающим на целевой домен.

Этот параметр URL содержит идентификатор клиента, метку времени и метаданные браузера. На целевом домене GA проверяет наличие параметров в URL, и если находит линкерные параметры, то GA извлекает ID клиента из параметра и сохраняет его в cookies.

Когда вы переходите на серверную версию Google Analytics и управляемые сервером файлы cookie, создается новый файл cookie FPID. Он заменяет _ga и имеет флаг HttpOnly, что означает, что он недоступен для JavaScript. Вот тут-то и начинаются сложности.

Мы уже обсуждали, что междоменное отслеживание в web GA использует идентификатор клиента ( _ga cookie) и добавляет параметры компоновщика к домену назначения. Поскольку куки FPID является HttpOnly, прочитать и добавить его в URL невозможно, так как JavaScript не может получить доступ к куки HttpOnly.

Чтобы устранить эту проблему, Google создал новый файл cookie FPLC.

FPLC - это хэш куки FPID, и он не является HttpOnly, что означает, что JavaScript может получить доступ к FPLC и использовать его для междоменного отслеживания.

Есть несколько важных нюансов, о которых вы должны знать, прежде чем настраивать междоменное отслеживание для ss GA:

  • Время жизни куки FPLC составляет 20 часов. Это означает, что междоменное отслеживание будет работать только в том случае, если пользователь нажмет на целевой URL менее чем через 20 часов после перехода на сайт. Предположим, что будет почти 0 случаев, когда пользователь остается на странице дольше 20 часов и нажимает на целевой URL.
  • Оба сайта должны использовать отслеживание на стороне сервера. Поскольку FPID и FPLC доступны только для ss GA, оба сайта, для которых вы устанавливаете кросс-доменное отслеживание ss, должны использовать ss GA.
  • Оба сайта должны принадлежать одному и тому же аккаунту Google Tag Manager. Вы можете использовать разные контейнеры GTM, но должны использовать один аккаунт GTM.

Как и в случае с кросс-доменным отслеживанием в web GA, после настройки кросс-доменного отслеживания в ss GA, GA добавит параметр FPLC в URL-адреса целевого сайта. Серверный контейнер целевого сайта перехватит параметр FPLC из URL и установит FPID. 

Междоменное отслеживание Google Analytics на стороне сервера помогает только при отслеживании GA на разных доменах. Но что если вы хотите передать другие файлы cookie с доменаА.com на доменВ.com. Чтобы помочь решить эти проблемы, Stape создал тег Cookie reStore для серверного Google Tag Manager.

Тег cookie reStore предназначен для хранения идентификаторов пользователей и их файлов cookie в Firebase и восстановления их в нужный момент. Чтобы этот тег работал, вы должны передать любые идентификаторы пользователей на первом сайте и использовать тот же идентификатор пользователя на другом сайте для извлечения файлов cookie.

Нет никаких ограничений на тип идентификатора пользователя и его номер. Это может быть либо адрес электронной почты, либо какой-то другой вид уникального идентификатора, например, идентификатор пользователя в CRM, cookie и т.д.

Варианты использования тега cookie reStore:

  • Междоменное отслеживание
  • Кросс-браузерное отслеживание
  • Установка правильных UTM-тегов
  • В принципе, любые ситуации, когда вам нужно хранить и извлекать куки одного и того же пользователя.

Тег cookie reStore использует Firestore для сохранения cookie на одном сайте и их извлечения на другом. Поскольку вы будете использовать одну коллекцию Firestore для обоих сайтов, убедитесь, что оба сайта имеют доступ к одной базе данных Firestore.

Firebase Path - путь к коллекции Firebase, которая должна использоваться для записи/чтения данных. Тег будет создавать новый документ Firestore в указанной коллекции при каждом срабатывании тега cookie reStore.

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

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

Список cookies, которые необходимо восстановить - список cookies и их время жизни в секундах, которые необходимо сохранить и восстановить.

cookie restore tag

В этом примере я сохраню файлы cookie fbc, fbp и channel_flow на сайте https://wp-demo.stape.io/ и восстановлю их на https://stape.dev/. 

Чтобы установить этот тег, мне нужно:

  • Оба сайта, использующие отслеживание на стороне сервера через sGTM.
  • Настроенный междоменный Google Analytics, поскольку я буду использовать _ga в качестве уникального идентификатора пользователя.
  • Аккаунт Google Service создан и подключен к обоим контейнерам в stape.io power-ups. Для учетной записи сервиса настроено разрешение Firestore.

Давайте приступим к настройке тега cookie reStore.

1. Скачайте тег Cookie reStore с GitHub -> Откройте разделы шаблонов тегов в серверном контейнере Google Tag Manager -> Нажмите New -> Импортируйте шаблон тега reStore, который вы недавно скачали -> Нажмите Save.

Скачайте и импортируйте тег Cookie reStore для всех сайтов, для которых вам нужно настроить кросс-доменное отслеживание. В моем случае я добавил шаблон тега Cookie reStore в sGTM контейнеры https://wp-demo.stape.io/ и https://stape.dev/.

cookie restore tag

2. Создайте тег cookie reStore. Добавьте путь к Firebase и идентификатор проекта Firebase. Убедитесь, что вы подключили аккаунт Google Service к контейнерам stape.io.

Добавьте куки, которые должны храниться в Firebase. Я буду использовать куки _ga первой стороны в качестве уникального идентификатора пользователя. Чтобы иметь тот же идентификатор пользователя на домене назначения, я настроил междоменное отслеживание UA.

cookie restore tag

3. Когда пользователь заходит на wp-demo.stape.io, он может нажать кнопку и попасть на другой домен, stape.dev. Каждый раз, когда пользователь нажимает на исходящую ссылку, параметр _ga linker будет добавляться к URL-адресу назначения. 

cookie restore tag
cookie restore tag

Для извлечения параметра _ga из URL на сайте назначения я использую переменную split string, доступную в галерее шаблонов sGTM. 

split string

4. В контейнере sGTM целевого сайта (stape.dev) я настроил тег cookie reStore, который извлекает и устанавливает cookie fbc, fbp и channel flow из Firestore на основе параметра client_id, который использует параметр _ga, извлеченный из URL. 

cookie restore tag

5. Закончив настройку, откройте sGTM previews, Firebase и консоль, чтобы провести тест. В моем случае я проверил, что cookies wp-demo.stape.io соответствуют cookies stape.dev, и соответствующие записи были созданы в Firestore. 

cookie restore tag
cookie restore tag
cookie restore tag

6. Не забудьте опубликовать обновления для обоих контейнеров после завершения настройки.

Заключение:Скопировать ссылку на этот раздел

Надеюсь, эта статья пролила больше света на междоменное отслеживание на стороне сервера. Мы обсудили, что Google Analytics имеет собственное решение для междоменного отслеживания, которое использует новый файл cookie FPLC, доступ к которому можно получить с помощью JavaScript и передавать эти файлы cookie между различными доменами.

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

Надеюсь, это руководство поможет вам настроить междоменное отслеживание на стороне сервера. Если вам нужна помощь в настройке отслеживания ss, обращайтесь.

Хостите свой сервер GTM на Stape

Регистрируясь, вы соглашаетесь с Условиями использования и Политикой конфиденциальности Stape