Тестування розділених URL-адрес

Тестування з розділеними URL-адресами – це метод експерименту, в якому кожен варіант знаходиться за власною окремою URL-адресою, і відвідувачі перенаправляються на одну з них випадковим чином. Це відрізняється від стандартного A/B-тестування, де варіанти відображаються за однією адресою шляхом зміни сторінки після її завантаження або шляхом надсилання різної розмітки із сервера. Тестування з розділеними URL-адресами є доцільним вибором, коли варіанти відрізняються надто суттєво, щоб їх можна було створити шляхом модифікації на стороні клієнта: повністю перероблена цільова сторінка, інший процес оформлення замовлення, новий шаблон, що працює на окремій інфраструктурі, або сторінка, створена іншою командою на іншому стеку.

Головна перевага — свобода. Оскільки варіант — це реальна сторінка, а не набір маніпуляцій DOM, застосованих до існуючої, немає практичного обмеження щодо того, наскільки вона може відрізнятися, і немає ризику, що варіант зламається, коли базова сторінка зміниться. Команди розробників можуть створювати конкуруючий варіант у своєму звичайному середовищі, зі своїми звичайними інструментами та контролем якості, а не виражати редизайн як скрипт, який переписує оригінал. Для суттєвих редизайнів це часто єдиний робочий підхід.

Витрати однаково реальні. Перенаправлення додає затримку, зазвичай кілька сотень мілісекунд, яка застосовується до однієї групи, а не до іншої, і тому вносить систематичну різницю, не пов'язану з тестованим дизайном. Повільніші варіанти конвертуються гірше, тому штраф за перенаправлення зміщує результати на шкоду конкуренту. Перенаправлення також призводять до втрати відвідувачів під час переходу, що є поширеною причиною невідповідності співвідношення вибірки. Конфігурація аналітики складніша, оскільки сеанси тепер охоплюють дві URL-адреси, і інформація про реферер може бути втрачена. Пошуковим системам необхідно запобігти індексації варіанта, що вимагає канонічних тегів, що вказують на оригінал.

Ретельне впровадження зменшує більшість цих наслідків. Переадресації на стороні сервера швидші та надійніші, ніж на стороні клієнта. Попереднє завантаження або попереднє підключення до домену варіанта зменшує сприйняту затримку. Послідовне сегментування, завдяки якому відвідувач, що повертається, завжди потрапляє на той самий варіант, запобігає вкрай неоднорідному досвіду перегляду різних версій протягом сеансів. Запуск A/A-тесту URL-адрес перед реальним експериментом, де обидві URL-адреси обслуговують однакові сторінки, показує, яка частина виміряної різниці є артефактом переадресації, а не ефектом дизайну, і цю цифру слід знати, перш ніж робити висновки.

Тестування розділених URL-адрес також є природним механізмом тестування, що перетинає технологічні межі. Коли організація переносить розділ свого сайту на нову платформу, запуск старої та нової версій як розділених URL-адрес дозволяє виміряти вплив міграції на бізнес до повного запровадження, а не виявляти його пізніше. Те саме стосується тестування нової комерційної платформи, переробленої системи бронювання або переплатформованої системи контенту, де альтернативою є жорстке перенесення без будь-яких вимірювань.

Обробка пошуковими системами вимагає навмисного налаштування, і неправильне виконання може пережити експеримент. Варіант URL-адреси повинен містити канонічний тег, що вказує на оригінал, щоб сигнали ранжування консолідувалися на одній адресі, а перенаправлення має бути тимчасовим, а не постійним, оскільки постійний код стану вказує пошуковим системам замінити оригінал у своєму індексі. Виключення варіантів URL-адрес з карти сайту та моніторинг їх появи в результатах пошуку є розумними запобіжними заходами на великих сайтах. Після завершення тестування варіант, що програє, слід видалити або перенаправити, а не залишати доступним, оскільки покинуті тестові URL-адреси накопичуються протягом років, індексуються, приваблюють посилання та зрештою з'являються в результатах пошуку як дублікати сторінок, які компанія з того часу кілька разів змінювала.

У випадках, коли обговорюється питання редизайну, саме цей метод перетворює суб'єктивну суперечку щодо нового дизайну на питання, на яке можна відповісти. дизайн продукту команда може правильно побудувати змагання, і Послуга CRO Команда може порівняти це з існуючим оператором за реального трафіку, з кількісною оцінкою та врахуванням штрафу за перенаправлення. Зокрема, для рішень щодо переплатформування це різниця між міграцією, виправданою бізнес-кейсом, та міграцією, виправданою надією, і це стандартна частина того, наскільки великі підприємство програми зменшують ризик змін, які в іншому випадку були б незворотними.