Шукати тих, хто виріс нещодавно
У новій ніші я раніше починав із сайтів, які роками займали перші місця. Зараз частіше шукаю тих, хто помітно виріс нещодавно. Так я звужую пошук до змін, які ще можна простежити.
На консультації магазину техніки я отримав більше ідей, коли перейшов від великих лідерів до сайтів, які почали зростати. У них було простіше простежити зміни й сформулювати питання для власного тесту.
Відокремити спостереження від пояснення
У лідера ніші одночасно працюють бренд, історія домену, офлайн-бізнес, продукт і зовнішні посилання. Побачити певний елемент на сторінці недостатньо, щоб приписати йому позицію. Навіть збіг дати зміни та зростання ще не доводить причинності.
Я розглядаю конкретну групу сторінок за порівнюваний період: що змінилося, звідки це відомо й наскільки точна дата. Якщо бачу лише поточну версію, не можу впевнено описати попередню. Розрахункову видимість стороннього сервісу також відділяю від фактичного трафіку конкурента.
Перетворити знахідку на перевірювану гіпотезу
З аналізу я хочу винести кілька гіпотез для нашого продукту. У BUKI ми спостерігали й за конкурентами з менш сильним брендом, які експериментували зі структурою та іншими SEO-рішеннями.
У гіпотезі я пояснюю, яку перешкоду прибере зміна, для кого та чому це може позначитися на результаті. Далі обираю сегмент для власної перевірки. Наявності елемента у сайту з ТОП-3 мені недостатньо для масштабного запуску.
Узгодити метрику й умову зупинки до запуску
Для такого тесту я б зафіксував групу сторінок, дату, очікувану поведінку та спосіб порівняння. Контрольну групу перевірив би на порівнюваність ще до зміни. Без контролю залишив би висновок обережнішим: звичайне «до/після» слабше ізолює вплив дії.
Основна метрика має відповідати задачі. Для сторінки вибору це може бути частка переходів до релевантних пропозицій або заявок; для зміни пошукового покриття — відповідний сегмент пошукових переходів. Поруч варто мати показники можливого погіршення: помилки, зручність вибору, якість заявок. Горизонт тесту залежить від обсягу даних і механізму зміни, універсального строку тут немає.
Зберегти негативний результат
Частина гіпотез не підтвердиться. Корисно розділяти «отримали дані проти гіпотези», «даних поки недостатньо» та «перевірку зіпсувала інша зміна». Це різні результати, і вони ведуть до різних наступних дій.
У журналі залишається історія рішення: що побачили, що припустили, що змінили й що виміряли. Нижче показую структуру на вигаданому прикладі; це не кейс BUKI.
Від спостереження до рішення
Навчальний приклад на умовному каталозі. Так я пропоную записувати гіпотезу перед тестом.
| Крок | Що записати |
|---|---|
| Спостереження | У конкурента з’явився блок фільтрів за спеціалізацією; дата запуску невідома. |
| Дані, яких бракує | Попередня версія, точна дата, зміни в інших частинах сайту й попиті. |
| Гіпотеза | Якщо відвідувач швидше знайде потрібну спеціалізацію, зросте частка переходів до релевантних пропозицій. |
| Перевірка | Власна порівнювана група каталогів; журнал релізів; визначений до запуску спосіб порівняння. |
| Можливе рішення | Розширити, зупинити або продовжити збір даних. У цьому прикладі фактичного результату немає. |
Олександр Захода
Head of SEO в BUKI. Product SEO, дані й експерименти.