User-ID в GA4 помогает связать действия авторизованного покупателя, если магазин передаёт собственный устойчивый идентификатор. Ошибка при выходе способна приписать следующие действия прежнему аккаунту. Поэтому проверять нужно весь цикл входа, выхода и смены клиента. Официальная справка проверена 27 октября 2026 года; это инструкция для собственных ресурсов продавца.

Выберите идентификатор, который действительно различает клиентов

Используйте уникальный постоянный ключ пользователя из системы магазина. Не подставляйте одно демонстрационное значение всем вошедшим посетителям и не передавайте информацию, позволяющую третьей стороне установить личность человека. Поле User-ID не предназначено для прямой отправки почты или телефона. Согласуйте технический источник ключа и правила использования данных до подключения к рабочему потоку.

В учебной проверке нужны два разных аккаунта с разными ключами. Сохраните только обезличенные тестовые обозначения и ожидаемое поведение. Если оба клиента получают один ID, дальнейший красивый отчёт о повторных визитах не имеет надёжного смысла. Начинать следует с качества идентификатора, а не с настройки сегментов на уже смешанной статистике магазина.

Проверьте состояние после выхода

После выхода Google требует очистить ранее установленный User-ID значением null. Строка «null» — другое значение: она интерпретируется как самостоятельный идентификатор. То же относится к строковым заглушкам. Передайте разработчику это различие явно и проверьте фактический тип, вместо общего требования «пусть поле становится пустым» без описания поведения интеграции.

Пройдите последовательность: анонимный просмотр, вход аккаунта A, действие, выход, новое действие, вход аккаунта B. Сверьте значения на каждом шаге через проверку событий DebugView. Особенно важен промежуток после выхода: страница может выглядеть неавторизованной, а тег продолжать отправлять старое состояние, сохранённое в приложении или шаблоне.

Учитывайте способ представления пользователей в отчёте

Для использования User-ID в отчётной идентичности подходят варианты Blended и Observed. Это настройка представления измеренных пользователей, а не механизм создания аккаунтов магазина. Ранее собранная до внедрения история не перерабатывается в полном объёме и не связывается задним числом. Внутри сеанса возможна связь действий до входа, но она не означает восстановление всей прошлой активности.

Не смешивайте User-ID с признаком нового покупателя. Один идентификатор помогает различать людей, а статус первой покупки требует проверенной истории заказов. Проблема неизвестного гостевого клиента разобрана в материале о new_customer и customer_type. Наличие нового технического ID не является доказательством, что человек впервые приобрёл товар у продавца.

Принимайте связку по сценариям, а не по уменьшению числа пользователей

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

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