Performance23 октября 2026 г.4 мин

Посетитель видит оба варианта лендинга: как проверить закрепление

Проверка закрепления варианта A/B-теста: повторные визиты, вход в аккаунт, cookie, серверный рендер и журнал смены варианта.

Обложка статьи: Посетитель видит оба варианта лендинга: как проверить закрепление

Для проверки закрепления нужны один тестовый пользователь, журнал событий и ожидаемое поведение до начала прогона. Если после обновления человек получает другой заголовок, красивое распределение групп не восстанавливает чистоту эксперимента.

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

Пройдите один маршрут и запишите семь результатов

Назначьте тестовой единице вариант Б поддержанным способом вашей системы. Запишите ID эксперимента, его версию, ключ распределения и значение варианта. Тестовый оверрайд может обходить часть обычного распределения, поэтому после проверки интерфейса потребуется прогон реального механизма назначения.

  1. Откройте страницу впервые. Ожидается одно назначение Б, видимое содержание Б и связанное событие показа. Сохраните отдельно назначенное значение и то, что действительно увидели. Если сервер отдаёт А, а клиент меняет его на Б, это уже отдельный дефект первого отображения.
  2. Обновите страницу при прежнем состоянии хранения. Ожидается тот же Б для той же единицы и версии. Сравните ключ распределения до и после. Новое событие просмотра допустимо, новый пользователь из-за обновления — повод проверить идентичность.
  3. Откройте вторую вкладку. Ожидается прежний вариант. При расхождении проверьте, не произошли ли два назначения до сохранения первого и не использует ли вкладка отдельное локальное состояние.
  4. Войдите в аккаунт. Для выбранного контракта Б сохраняется. Запишите анонимный и авторизованный ID и способ их связи. Если ваш продукт назначает вариант аккаунта, ожидаемый переход должен быть описан заранее; переименовать неожиданную смену в норму после прогона нельзя.
  5. Закройте браузер и вернитесь следующим днём в пределах срока хранения. Ожидается Б. Если срок истёк или изменилась версия эксперимента, сначала уточните, какое правило продолжения предусмотрено, затем оценивайте результат.
  6. Удалите тестовые cookie и повторите вход без аккаунта. Здесь узнавание прежнего человека уже не гарантировано. Допустимая новая единица должна быть отражена в ограничениях, а не скрыта обещанием вечного закрепления.
  7. Повторите путь на другом устройстве. При неподтверждённой связи идентичности новое назначение возможно. Сохраните этот предел вывода. Затем отдельно проверьте поддержанный переход между устройствами после авторизации.

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

Найдите момент смены в журнале

Условный пример записи, которую удобно передать разработчику:

12:00:00 — anonymous-17, experiment-v3, assignment Б 12:00:01 — anonymous-17, exposure Б, страница Б 12:01:10 — выполнен вход, account-42 12:01:11 — account-42, assignment А 12:01:12 — account-42, exposure А, страница А Ожидание: после входа сохранить Б. Факт: ключ идентичности сменился, правило связи не исполнено.

Такую хронологию рекомендует исследовать и диагностика variant jumping у Amplitude: важны assignment, exposure, ключ и история таргетинга. Общий кеш, резервный вариант и клиентская гидратация добавляют свои возможные причины; их подтверждают воспроизведением.

Sticky bucketing Amplitude не гарантирует отсутствие переходов при разных анонимных и авторизованных ID. Функция относится к Feature experiments и flags, а не Web experiments. Само включение настройки не заменяет выполненный маршрут.

Что сделать с найденным нарушением

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

После исправления повторите именно провалившийся шаг, затем весь маршрут для А и Б. Подготовка гипотезы лендинга имеет смысл после этой приёмки: журнал должен подтверждать, что группа описывает реальный показ.

Ещё по теме