Sticky-сплит: почему важен
Sticky-сплит: почему важен — вопрос, который встаёт сразу, как только сплит-тест начинает жить дольше одного визита: без закрепления варианта за конкретным визитором один и тот же человек может увидеть сначала вариант A, а через день — вариант B. Такой «прыгающий» показ незаметно ломает саму логику сравнения, потому что решение о конверсии перестаёт быть привязано к тому варианту, который на это решение реально повлиял. Разберём механику sticky-логики и почему без неё результаты теста нельзя считать надёжными.
Что значит sticky в сплит-тесте
Sticky означает, что вернувшийся визитор запоминается — по cookie, локальному хранилищу или идентификатору визитора — и при каждом следующем визите получает тот же вариант, что и при первом, а не новую случайную выдачу. Это касается не только прямого повторного захода на ссылку, но и любого возврата, включая клик по пуш-уведомлению спустя дни после первого визита.
Что ломается без sticky-логики
Без закрепления варианта один и тот же визитор может увидеть вариант A при первом клике и вариант B при повторном визите или клике по пуш-возврату. Если конверсия происходит на втором заходе, она засчитывается тому варианту, который просто оказался на экране в этот момент, а не тому, что реально сформировал решение пользователя, — сравнение вариантов перестаёт отражать их настоящую эффективность.
Как это искажает статистику теста
При не-sticky рандомизации один и тот же человек через несколько заходов может «размазать» и объём показов, и события конверсии между обоими вариантами неравномерно, из-за чего выборка выглядит больше, чем она есть по сути, а сигнал внутри неё, наоборот, слабее. В таких условиях тест способен показать «победителя», который на деле — просто статистический шум, а не реальная разница между вариантами.
Как sticky-логика реализуется в PWA-связке
Визитору присваивается вариант при первом заходе — метка обычно привязывается к тому же идентификатору, что используется для clickid или push-подписки, — и именно эта метка определяет, какой вариант отрисуется при каждом следующем обращении, включая переход из пуш-уведомления спустя дни после первого визита. Важно, что канал входа не должен переопределять уже закреплённый вариант — иначе логика теряет смысл ровно в самом частом сценарии возврата.
Как проверить, что sticky работает правильно
Проще всего вернуться на ту же ссылку с того же устройства несколько раз за время теста и убедиться, что каждый раз отрисовывается один и тот же вариант. Отдельно стоит проверить именно вход через клик по пуш-уведомлению — это самый частый повторный вход у активной базы, и он должен вести себя так же, как обычный повторный визит, а не как первый заход с новой случайной выдачей. В APEX сплит-тесты sticky по визитору по умолчанию, так что эту логику не нужно реализовывать отдельно поверх собственной инфраструктуры.
Частые вопросы
- Разве случайная выдача при каждом визите не более «честный» тест?
- Нет — для одного и того же человека это разрушает саму идею сравнения, потому что его решения размазываются между обоими вариантами вместо того, чтобы быть привязанными к одному из них.
- Работает ли sticky-логика для входа через пуш, а не только через первый клик по рекламе?
- Да, если реализована правильно: идентификатор визитора закрепляется один раз и работает на всех последующих входах, включая клики по пуш-уведомлениям спустя дни после первого визита.
- Нужно ли реализовывать sticky-логику самостоятельно при работе в APEX?
- Нет, сплит-тесты в APEX sticky по визитору из коробки — закрепление варианта не требует отдельной настройки или доработки.
- Что делать, если тест уже шёл без sticky-логики?
- Честнее перезапустить тест заново с sticky-закреплением, чем пытаться постфактум очистить или переинтерпретировать уже искажённые данные.
Клоака, антибот, пуши, сплит-тесты и свои домены — в одном сервисе.
Начать бесплатно