Процесс кросс-доменного отслеживания сложен, даже для браузерного отслеживания. Для того чтобы кросс-доменное отслеживание работало правильно и точно, необходимо соответствовать целому списку требований - кроме того, существуют различные технологии, используемые при настройке собственной системы.
Междоменное отслеживание на стороне сервера может быть еще более разочаровывающим. В этой статье я расскажу о том, как работает кросс-доменное отслеживание ss, а также о некоторых смежных темах, таких как серверное отслеживание Google Analytics, использование куки FPLC и тег Cookie ReStore от Stape, который может помочь повторно использовать куки в разных доменах.
Междоменное отслеживание позволяет рассматривать пользователей, посетивших два разных домена, как один сеанс, а не как два отдельных сеанса. Это помогает более точно измерить путь пользователя.
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:
Как и в случае с кросс-доменным отслеживанием в 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:
Тег cookie reStore использует Firestore для сохранения cookie на одном сайте и их извлечения на другом. Поскольку вы будете использовать одну коллекцию Firestore для обоих сайтов, убедитесь, что оба сайта имеют доступ к одной базе данных Firestore.
Firebase Path - путь к коллекции Firebase, которая должна использоваться для записи/чтения данных. Тег будет создавать новый документ Firestore в указанной коллекции при каждом срабатывании тега cookie reStore.
Firebase Project ID - добавьте идентификатор проекта Firebase. Тег использует идентификатор проекта по умолчанию, связанный с вашей учетной записью сервиса, если он пуст.
Список идентификаторов - добавьте идентификаторы пользователей, которые должны использоваться для идентификации одного и того же пользователя.
Список cookies, которые необходимо восстановить - список cookies и их время жизни в секундах, которые необходимо сохранить и восстановить.
В этом примере я сохраню файлы cookie fbc, fbp и channel_flow на сайте https://wp-demo.stape.io/ и восстановлю их на https://stape.dev/.
Чтобы установить этот тег, мне нужно:
Давайте приступим к настройке тега 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/.
2. Создайте тег cookie reStore. Добавьте путь к Firebase и идентификатор проекта Firebase. Убедитесь, что вы подключили аккаунт Google Service к контейнерам stape.io.
Добавьте куки, которые должны храниться в Firebase. Я буду использовать куки _ga первой стороны в качестве уникального идентификатора пользователя. Чтобы иметь тот же идентификатор пользователя на домене назначения, я настроил междоменное отслеживание UA.
3. Когда пользователь заходит на wp-demo.stape.io, он может нажать кнопку и попасть на другой домен, stape.dev. Каждый раз, когда пользователь нажимает на исходящую ссылку, параметр _ga linker будет добавляться к URL-адресу назначения.
Для извлечения параметра _ga из URL на сайте назначения я использую переменную split string, доступную в галерее шаблонов sGTM.
4. В контейнере sGTM целевого сайта (stape.dev) я настроил тег cookie reStore, который извлекает и устанавливает cookie fbc, fbp и channel flow из Firestore на основе параметра client_id, который использует параметр _ga, извлеченный из URL.
5. Закончив настройку, откройте sGTM previews, Firebase и консоль, чтобы провести тест. В моем случае я проверил, что cookies wp-demo.stape.io соответствуют cookies stape.dev, и соответствующие записи были созданы в Firestore.
6. Не забудьте опубликовать обновления для обоих контейнеров после завершения настройки.
Надеюсь, эта статья пролила больше света на междоменное отслеживание на стороне сервера. Мы обсудили, что Google Analytics имеет собственное решение для междоменного отслеживания, которое использует новый файл cookie FPLC, доступ к которому можно получить с помощью JavaScript и передавать эти файлы cookie между различными доменами.
Если вам нужно хранить и восстанавливать куки-файлы между доменами, лучшим решением может стать тег cookie reStore. Он сохраняет уникальные идентификаторы пользователей и куки в Firestore, а затем использует тот же уникальный идентификатор для восстановления куки на целевом сайте.
Надеюсь, это руководство поможет вам настроить междоменное отслеживание на стороне сервера. Если вам нужна помощь в настройке отслеживания ss, обращайтесь.
Все, что для этого нужно, - ответить на несколько простых вопросов. Нажмите Получить помощь, заполните форму, и мы вышлем вам предложение.
