Сшивать пользователей между сессиями со Stape стало еще проще

Если вы уже давно занимаетесь серверным отслеживанием, вы наверняка настраивали какую-то версию сшивки пользователей самостоятельно (я делала это не раз!). Вы перехватывали email при отправке формы и сохраняли его, например, в Data Store. Затем вы извлекали эти пользовательские данные для каждого последующего события или использовали их для кросс-девайсного отслеживания. Это работает, хоть и отнимает массу времени, но многие из нас понимают: это необходимо, чтобы повысить эффективность рекламных платформ и передавать им ценные данные.

Я Manisha Mistry, технический руководитель в MeasureU. Я настраивала это уже не раз и знаю, сколько сил уходит на внедрение и поддержку. Схема всегда одна и та же: перехватить информацию, сохранить ее с помощью тега Stape Store Writer, извлечь обратно через переменную Stape Store Lookup, а затем повторить все это для каждого идентификатора и каждой целевой платформы.

В прошлом месяце Stape выпустил улучшение Enricher, и оно полностью изменило мой взгляд на весь этот процесс. Enricher делает все то, чем мы раньше занимались вручную: берет на себя всю сшивку данных и делает этот процесс невероятно простым.

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

Проще всего понять работу улучшения Enricher, сравнив его с тем, как большинство из нас настраивает сшивку сейчас.

Автономная настройка Data Store для сшивки пользователей:

• Вы записываете пользовательские данные в Store с помощью тега Store Writer.
• Вы считываете пользовательские данные из Store с помощью переменной Store Lookup.
• Это работает, но требует времени на настройку и управление.

Data Store через улучшение Enricher:

• Stape извлекает идентификаторы из входящих запросов, сохраняет их и повторно прикрепляет к будущим запросам до того, как сработают клиенты и теги в sGTM.
• Обогащение происходит на уровне инфраструктуры, и ваши теги сразу видят полностью обогащенное событие, поступающее на сервер.

Как по мне... это чистая МАГИЯ (но это лишь мое мнение). А теперь давайте подробно разберем, как это устроено и как происходит сопоставление.

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

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

Особое внимание хочу обратить на колонку «День 9», где посетитель возвращается на сайт с совершенно нового устройства и повторно вводит тот же email. Поскольку Data Store умеет сопоставлять данные по email, он подтягивает полный профиль пользователя, дополняет входящее событие недостающими данными и обновляет сохраненный профиль новой информацией. 

Именно эта особенность улучшения Enricher меня по-настоящему впечатлила. Обычно при настройке сшивки пользователей сопоставление идет по email, ID или по обоим параметрам. Enricher выходит на новый уровень, предлагая возможность сопоставлять входящие события по любому из этих шести идентификаторов:

• email — основной идентификатор
• _sbp — cookie приложения Stape
• FPID — идентификатор собственных cookie
• _ga — client ID в GA4
• _dcid — Stape Data Client ID
• X-Stape-User-Id — идентификатор улучшения Stape User ID

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

Как только Enricher находит совпадение по любому из шести идентификаторов, он сохраняет в профиль пользователя все данные, которые вы передаете через теги данных или событий. Сюда могут входить: имя, фамилия, номер телефона, город, страна, регион/штат, почтовый индекс, улица, дата рождения, пол, а также специфические для платформ идентификаторы кликов для Meta (_fbp, _fbc), Google Ads (gclaw, fpgclaw), TikTok (ttp, ttclid), LinkedIn (liFatId), Pinterest (epik) и Snap (scclid, scid).

Затем, когда поступает новое событие и совпадает по любому из шести идентификаторов, Enricher проверяет, чего не хватает в событии, и подставляет недостающие пользовательские данные из сохраненного профиля до срабатывания тегов в sGTM. Благодаря этому ваш тег Meta CAPI, тег конверсий Google Ads и тег TikTok Events API гарантированно получают идентификаторы кликов и хешированные данные пользователей даже для тех событий, которые поступили на сервер практически без пользовательских данных. 

Перед написанием этой статьи мне хотелось понять, как сопоставление по этим шести идентификаторам работает под капотом. Поэтому я созвонилась с Dan Murovtsev, продакт-менеджером Stape. По его словам, для сопоставления Enricher использует детерминированный подход.

Это означает, что улучшение Enricher не строит догадок и не ищет совпадение по подстроке («содержит»): оно выполняет точное сопоставление в строгом иерархическом порядке, чтобы связать пользователя на сайте с имеющимися данными. 

Порядок проверки следующий:

1. 1.
   email
2. 2.
   _sbp (cookie приложения Stape)
3. 3.
   FPID
4. 4.
   _ga (client ID в GA4)
5. 5.
   _dcid (Stape Data Client ID)
6. 6.
   X-Stape-User-Id

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

Кроме того, улучшение Enricher разработано так, чтобы поддерживать актуальность данных. Это означает, что при появлении нового значения любых пользовательских данных — например, нового _ga, FPID или email — Enricher считает его единственным источником правды и обновляет сохраненный профиль. Иными словами, самое свежее значение заменяет предыдущее. Я проверила это лично: удалила cookie _ga у пользователя, для которого Enricher уже создал профиль, и в тот момент, когда поступило новое значение _ga, сохраненный профиль сразу обновился.

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

Что меняется: перехватывая идентификаторы, улучшение Enricher записывает cookie _sbpee на устройство посетителя и считывает этот cookie при каждом событии.

Что остается неизменным: расходы на сервер не меняются, поскольку cookie хранится на устройстве посетителя, а не на инфраструктуре Stape.

Компромисс: как и любой другой, cookie, созданный улучшением Enricher, привязан к конкретному устройству. Поэтому телефон и ноутбук одного и того же посетителя получат два разных cookie _sbpee. Кроме того, cookie могут быть удалены, и вы не получаете преимуществ кросс-девайсного или офлайн-отслеживания.

Что меняется: улучшение Enricher записывает перехваченные идентификаторы в Data Store на инфраструктуре Stape и сопоставляет входящие события со всей базой Store при каждом запросе.

Что остается неизменным: текущие настройки Store остаются нетронутыми. Улучшение Enricher просто считывает и записывает данные в то же хранилище Store, к которому у вас всегда был доступ.

Компромисс: как и всегда, использование Data Store расходует лимиты вашей подписки, поэтому влечет дополнительные затраты. Однако за эту стоимость вы получаете сопоставление между устройствами, сессиями и офлайн-данными, которое не зависит от сохранности cookie на устройстве пользователя, а также возможность загружать офлайн-данные через импорт Profiles CSV.

Обсудив этот вопрос с Dan, мы со Stape даем однозначную рекомендацию: используйте оба варианта, если позволяют ваш тариф и бюджет. Cookie обеспечивает базовый функционал, а Store служит надежной подстраховкой и открывает возможности сопоставления между устройствами и офлайн-данными.

Теперь, когда мы понимаем, как Enricher устроен под капотом, давайте перейдем к сценариям использования, в которых power-up Enricher принесет максимальную пользу. Важно отметить, что сами идеи не новы: многие из нас уже решали эти задачи с помощью Data Store.

Многие из нас сталкивались на созвонах с клиентами с обсуждением предупреждений в Meta или Google Ads о низком показателе EMQ. Приятного в таких разговорах мало, а происходят они обычно тогда, когда в контейнер sGTM поступает событие без идентификаторов вроде email или номера телефона.

Именно здесь на помощь приходит Enricher: при получении события power-up Enricher проверяет, сохранены ли пользовательские данные по одному из шести идентификаторов. Если данные есть, он заполняет недостающую информацию (например, хешированные имя, фамилию и телефон) в событии до того, как оно будет передано в Meta CAPI, Google Ads и на другие платформы. Это, в свою очередь, улучшает данные, отправляемые на рекламные платформы, и помогает повысить качество сопоставления.

Этот сценарий наверняка воодушевит многих, особенно тех, у кого клиенты используют вебхуки событий или загрузку офлайн-конверсий. Без power-up Enricher, когда вебхук из CRM, файл с офлайн-конверсиями или любое другое событие поступает на сервер не из браузера, у нас обычно есть только пользовательские данные (email, номер телефона и, возможно, имя), но нет никаких cookie-идентификаторов, связывающих пользователя с его поведением на сайте.

При включенном power-up Enricher в момент поступления офлайн-события на сервер система пробует сопоставить пользователя по email. Если совпадение найдено, она подставляет недостающие пользовательские данные из сохраненного профиля: _ga, FPID, _sbp, кликовые идентификаторы платформ и многое другое. Это означает, что теперь ваш тег Meta CAPI для офлайн-события может содержать те же идентификаторы, что и онлайн-события Meta, а это повысит показатель EMQ. 

Это работает и в обратном направлении через вкладку Profiles в power-up Enricher, где Stape позволяет загружать экспорт пользовательских данных. После загрузки Enricher может сопоставлять отправленные онлайн данные пользователей с загруженными профилями, используя email в качестве критерия сопоставления.  

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

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

Именно здесь Enricher раскрывает весь свой потенциал. 

Пока на всех устройствах и в сессиях используется один и тот же идентификатор (например, email), система может найти совпадение в Data Store, и каждое последующее событие будет содержать обогащенные пользовательские данные. Это касается и событий, передаваемых в Meta и Google Ads, что помогает повысить наш EMQ.

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

После тестирования power-up Enricher на собственной конфигурации и обсуждения с коллегами по веб-аналитике мы пришли к единому выводу: все в полном восторге. Stape создал очередную отличную функцию, которая сэкономит массу времени и поможет улучшить сигналы и данные, отправляемые на рекламные платформы.

Если вы уже используете Data Store и связываете пользователей между сессиями и устройствами старым способом, рекомендуем подключить power-up Enricher уже сегодня. Протестируйте его и посмотрите, как он покажет себя в вашей конфигурации, даже если для начала вы выберете только вариант с cookie. Со временем, оценив преимущества вместе с клиентом, подключайте Data Store и переходите к полноценному связыванию пользователей на разных устройствах.

Чего же вы ждете? Подключайте power-up и прокачайте свое отслеживание.