SEO-эксперименты — один из самых мощных способов принятия решений на основе данных, а не ощущений. Но в отличие от продуктовых А/Б‑тестов, где можно контролировать почти все, в SEO нужно действовать осторожно: влияние внешних факторов, задержка в отклике поисковых систем, асимметричность страниц и многое другое.

В этой статье мы разберем вопросы:

1. В чем отличие SEO эксперимента от Продуктового A/Б тестирования?

2. Как уберечь SEO от Продуктового А/Б тестирования?

3. Как правильно провести SEO эксперимент?

4. Можно ли объединить Продуктовый и SEO А/Б тест?

5. Как генерировать гипотезы и где искать точки роста?

Прежде, чем начнем, давайте обозначим зачем нужны эксперименты в SEO:

• Отделяют догадки от фактов — показывают, что действительно работает

• Помогают принимать решения на данных, а не на интуиции

• Снижают риски — можно проверить идею на части сайта перед масштабированием

• Повышают доверие к SEO — есть доказанный эффект

• Учеба на ошибках без ущерба — если гипотеза не сработала, это тоже результат

Вопрос 1 - В чем отличие SEO эксперимента от продуктового A/Б тестирования?

Продуктовое А/Б‑тестирование и SEO‑эксперименты отличаются прежде всего средой, в которой они проводятся и методом сбора данных.

1. В продукте тестируются изменения в интерфейсе, которые осуществляются на одной странице и делим аудиторию пользователей на группы

2. Мы полностью контролируем, кому что показать, и уже через несколько дней можем получить результат по числу кликов, конверсий или удержания пользователя.

3. Главное отличие в том, что в продукте мы контролируем все — среду, трафик, пользователей.

В SEO все иначе. Мы не можем на одной странице внедрять два разных изменения одновременно. Изменения делим не по аудиториям, а по документам. Мы не можем контролировать трафик — он зависит от спроса, реакции поисковых систем, конкуренции и алгоритмических изменений.

Краткий список аспектов отличия:

Итого:

— Продуктовый А/Б тест — это эксперимент с делением групп по аудиториям, где одна группа видит вариант А, другая — вариант B.
— SEO А/Б тест — это эксперимент проводимый на разных группах страниц для всех пользователей

Вопрос 2 - Как уберечь SEO от продуктового А/Б тестирования

Продуктовые А/Б‑тесты часто затрагивают интерфейс, тексты, навигацию, контент, скорость загрузки.
К примеру, это может повлиять на:

• Индексацию страниц

• Качество сниппетов

• Внутреннюю перелинковку

• Релевантность контента

• Скорость загрузки и Core Web Vitals

Если SEO‑специалист не в курсе продуктовых тестов, то он может узнать о внедренных изменениях уже по факту падения трафика, которые исправить зачастую бывает сложно, долго и дорого.

Шаг 1 — Внедрить SEO чек‑лис (регламент) для продуктовых команд

Добавьте статью в продуктовый портал, к примеру в Confluence, блок «Проверка на влияние SEO» и перечислите все зоны на сайте, которые могут повлиять на результаты ранжирования в поисковых системах.

В нем необходимо обозначить важный вопрос, который продуктовые менеджеры должны задавать себе или бизнес аналитикам: «Меняются ли [обозначенный пункт из регламента]?»:

«Меняется ли скорость загрузки страниц?» «Меняется ли структура SSR?» и т. д.

Если ответ «да» — им необходимо подключить команду SEO и обсудить зоны риска.

Шаг 2 — Договориться о кросс‑функциональном ревью

Перед запуском А/Б‑теста должна пройти техническая встреча с участием SEO, где обсуждают план, цели, методы тестирования и влияние на SEO.

Особенно если:

• затрагиваются шаблоны карточек, категорий, фильтров

• изменяется набор блоков, содержимое текстовых блоков

• скрываются или добавляются ссылки

• затрагиваются тексты h1/h2, title, descriptions и т. д.

Шаг 3 — Закрываем доступ к поисковым ботам

Продуктовые команды часто используют JS для тестирования гипотез в А/Б тестах, где в варианте «А» тестируемый блок доступен в SSR, а в варианте «Б» сделан в JS и бот его не увидит (при условии запрета чтения JS).

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

Поэтому, решаем внутри что для нас важнее:
— Или показывать всем ботам только контрольную версию
— Или открыть индексацию с canonical для тестовых вариантов

Во избежания дублей, т.к. каноникал — это всего лишь рекомендация, советуем выбрать первый вариант. Это делается через включение поисковых ботов в список «исключений».

Список поисковых ботов можно найти тут: Яндекс и Google.

Шаг 4 — Мониторить релизы

Договорится с продуктом о том, что они подключают команду SEO к мониторингу продуктовых релизов.

Будьте готовы, что получите сотни писем про разные задачи, которые готовы к релизу, прошли или были отменены в процессе релиза, баги и т. д. — еженедельно.

Определите какие зоны ответственности вы будете контролировать, перечислите теги, к примеру «SSR», «Веб» или «SEO», и выделите из своей команды ответственного за эту задачу мониторинга.

Пример из практики:

Кейс:

Продуктовая команда хотела изменить порядок блоков на странице категории, инфу из которых команда SEO использовали для вывода УТП в сниппет. Но так как он не отключался, а меняли только его позицию на странице, то решили, что риск минимален.

Результат:

А/Б тест реализовали через JS, результат показал рост конверсии на 3%. Однако спустя какое‑то время команда SEO заметили падение CTR в выдаче ПС, причиной которого стала пропажа информации с УТП. В итоге, несмотря на рост конверсии, общее количество органического трафика снизилось.

Вывод:

Продукт принес локальную пользу, но повредил каналу, который генерирует трафик.

Рекомендуем проверять и мониторить реализацию на проде — «сделали как договорились или как захотели?»

Вопрос 3 - Как правильно провести SEO эксперимент?

Выделим 4 основные этапы проведения экспериментов:

• Оценка гипотезы

• Сегментирование

• Запуск и мониторинг

• Подведение итогов

В эти 4 этапа 1й и 2й входят в единую группу «Подготовка к запуску».

Этап 1. Оценка гипотезы

Этап оценки гипотезы состоит из 5 основных шагов:

• Определение ценности эксперимента

• Определение цели и метода его достижения

• Определение метрик для измерения результата

• Определение инструментов для мониторинга и оценки результатов

• Определение рисков и ограничений в период проведения теста

А/Б эксперименты — мощный инструмент, но при неправильной подготовке они легко превращаются в размытые гипотезы, на которые невозможно сделать вывод.

Шаг 1 — Ценность эксперимента

Прежде чем перейдем к подготовке запуска эксперимента, нам необходимо понять:

1. Сколько стоит проведение эксперимента для бизнеса и SEO команды?

2. Какой профит мы получим после масштабирования удачного эксперимента?

3. Оправданы ли расходы и выделяемые ресурсы для проведения эксперимента?

т. е. мы должны понимать, стоит ли вообще заниматься этим экспериментом или ее профит настолько незначителен, что мы больше тратим, чем зарабатываем.

Чтобы оценить стоимость SEO‑эксперимента включаем в расход прямые ресурсы команд:

• Время SEO‑специалиста на анализ и подготовку гипотезы

• Время разработчиков на внедрение (backend/frontend)

• Аналитика: настройка сбора метрик, отчетов, визуализации в Дашбордах

• Ресурсы продукта, UX, контента, при необходимости

А также включаем в расход дополнительные ресурсы:

• Стоимость привлечения внешнего аутсорса

• Стоимость покупки или подписки платных инструментов привлеченных для проведения эксперимента

Далее считаем профит от инициативы:

• Объем потенциального Ptraf умножаем на среднюю конверсию и средний чек — получаем объем дохода (GMV) — оценка для бизнеса.

Пример подсчета расходов:

Общее время команд = ~60–80 часов Средняя стоимость: 400–600 тыс. руб. в месяц. Команда будет работать: — 2 месяца полной загрузки команд (подготовка и запуск) = до 1,2 млн руб. — 3 месяца частичной загрузки (поддержка) = 400 тыс. руб. Итого расход — 1,6 млн за 5 месяцев работы.

Считаем профит на примере улучшения CTR в выдаче ПС:

CTR вырос на 0.5 п.п. — это +5000 кликов в месяц GMV = 5000  CR (2%) AOV (6500) = 650 тыс. руб. в месяц где CR — это средняя конверсия в заказ, а AOV — это средний чек Если предположим, что спрос стабилен, то можем ожидать за следующие месяцы равнозначный профит, с учетом постепенного достижения максимального показателя. Почему постепенного, потому что требуется время для индексации всех изменений и получения роста показателей по всем документам: — 1-й месяц — 10% от максимального профита = 65 тыс. руб. — 2-й месяц — 20% = 130 тыс. руб. — 3-й месяц — 40% = 260 тыс. руб. — 4-й месяц — 50% = 325 тыс. руб. — 5-й месяц — 70% = 455 тыс. руб. — 6-й месяц — 90% = 585 тыс. руб. Итого за 6 месяцев получаем 1,8 млн. руб. Разница от расхода в +200 тыс. руб. Учитывая, что последующие месяцы продолжаем получать по 80–90% от профита, то ценность инициативы для всех ясна.

Это пример. У каждого могут быть свои вводные данные по расходам, стоимости рабочих часов команд и ожидаемому профиту. Главное учесть, что эксперимент должен быть оправдан.

Если ожидаемый профит по итогу масштабирования эксперимента оправдывает расходы разработки и другие ресурсы, то переходим к следующему шагу.

Шаг 2 — Определение цели и метода его достижения

Эксперимент начинается не с кода и не с разметки, а с четкого ответа на вопрос: что именно мы хотим проверить и зачем?

• Необходимо сформулировать гипотезу в формате: «Если мы сделаем ЧТО‑ТО, то это приведёт к К ЧЕМУ‑ТО за счет ТОГО‑ТО»

• Обязательно надо связать гипотезу с бизнес‑целью

Примеры целей:

— Увеличить CTR за счет изменения title, description или микроразметок — Сократить время индексации за счет изменения структуры сайта — Увеличить видимость в ПС за счет улучшения релевантности документа

Для примера разберем эксперимент, который проводили для оценки влияния объема кода вертикальное меню на скорость загрузки сайта и видимость в ПС:

Потребность:

В рамках инициативы по ускорению скорости загрузки страниц сайта, продуктовая команда зашла с запросом по удалению из кода категории 4-го уровня вложенности. т. е. не рендерить ее в SSR. В SPA сохраняем как есть для пользователей.

Мы приступаем к оценка гипотезы. В данном кейсе гипотезой являлась то, что улучшается скорость загрузки страниц сайта.

Чтобы оценить теорию и определить как правильнее провести эксперимент необходимо задать себе несколько вопросов:

• Какую проблему мы стремимся решить?

• Оправдано ли наше внимание?

• Какие подходы возможны для её решения?

• Какие аспекты затрагивает эта проблема?

• Какие объекты будем анализировать?

• Что с чем будем сравнивать?

Задав себе вопросы и проанализировав мы поняли, что да, действительно есть проблема со скоростью загрузки сайта из‑за большого объема кода меню, который занимает больше половины кода. А ее отсутствие почти вдвое улучшает скорость загрузки.
Но удаление 4-го уровня вложенности влияет на внутреннюю перелинковку и мы можем потерять видимость в поиске по этим категориям.

Поэтому начали анализировать и выявили, что если мы удалим не 4-й уровень, а все другие ветки категорий иной тематики, то можем также улучшить текстовую релевантность. К примеру для детства не будет товаров 18+, а для электроники одежды и обувь.

Таким образом мы нашли дополнительные методы решения задачи и предусмотрели, что может повлиять отрицательно, а что положительно:

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

Получилось у нас две цели:

— Ускорить скорость загрузки страницы
— Улучшить текстовую релевантность документа

А также два метода их достижения

— Удаление кода категорий 4го уровня вложенности
— Удаление кода категорий иной ветки из меню

НО.. всегда надо задавать вопрос «а что, если..?»:

Что если и 4й и иная ветка покажет хорошие результаты?
— Тогда внедрим оба?

Что, если внедрение двух методов скажется отрицательно?
— Будем проводить второй тест?

И тут, чтобы не задаваться в итоге этими вопросами и не тратить время на еще один эксперимент, мы добавляем третий метод «All»

«All» — включает в себе первый и второй метод одновременно.

т. е. у нас выходит не A/Б тест, а A/Б/В тестирование.

Итоговый список методов достижения цели получается 3:

1. «4-й уровень» — Удаление части кода меню по коллекциям 4-го уровня вложенности

2. «Дерево коллекций» — Удаление части кода меню по коллекциям другой структурной иерархии

3. «All» — Удаление части кода меню по коллекциям 4-го уровня + коллекций другой структурной ветки

Пояснение:

В рамках «Дерево коллекций» удаляем из кода меню, со страниц выбранных коллекций, все ссылки коллекций «Другой ветки» сохраняя только ссылки на коллекции «Основной ветки»: — Основная ветка — все категории вложенные в ту же категорию 1-го уровня — Другая ветка — все категории вложенные в иную категорию 1-го уровня К примеру для категории «Смартфоны» основной веткой считается все категории вложенные в «Электронику», а другой веткой считается категории вложенные в «Детские товары» или «Красота и уход».

Промежуточный итог первого шага в этапе оценки:

В описанном примере с удалением кода меню мы не только проанализировали влияние на скорость загрузки, но и обнаружили потенциальные последствия для SEO: потерю перелинковки и тематику. Это дало нам возможность проработать несколько гипотез, заранее учесть негативные сценарии и усилить позитивный эффект.

Такой подход — не просто про эксперимент ради эксперимента. Это системная работа, где цели, методы и последствия продуманы заранее, а результат можно смело можем использовать для принятия решений.

Шаг 3 — Определить метрики для измерения результата

Хорошая гипотеза — это половина успеха. Вторая половина — правильный выбор метрик.

Следующий шаг это определение метрик по которым будем оценивать результат и подводить итоги. У каждого эксперимента свой набор метрик.

Перед запуском эксперимента необходимо задать себе или команде вопрос: «Достаточно ли этих данных для принятия решения?»

Важно:

— Не путайте технические метрики с бизнес‑метриками
— Согласуйте ключевые показатели с продуктом и разработкой

Пример:

Гипотеза: изменение шаблона title повысит CTR Метрики: CTR,%Ptraf, сред. позиция,%ТОП с 1 по 10 и визиты Нельзя ограничиваться только CTR — важно видеть, на каких позициях этот CTR достигается и есть ли результат в виде реальных переходов — иначе в чем смысл? ?

Из нашего примера с оптимизацией кода Меню были определены следующие метрики:

Вот пример, где наглядно показано, что недостаточно брать только видимость ТОП10 или только%Ptraf, т.к. могут быть кейсы, где они дополняют друг друга:

Частота сбора данных:

Оптимально — собирать данные ежедневно. Минимум — 2 раза в неделю.

Шаг 4 — Определить инструменты для мониторинга и оценки результатов

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

• реализации сервисов и инструментов внутренней командой

• привлечением внешних разработчиков для реализации инструментов

• привлечением подрядчиков для временного решения вопроса

Цель данного шага — Обеспечить техническую возможность проведения теста и сбора необходимых данных

Я предпочитаю внутренние системы визуализации и анализа данных, но если у вас их нет, то, к примеру SEOWORK решает большую часть потребности, где можно разделить документы на сегменты и сравнивать как динамику между ними, так и между конкурентами:

Шаг 5 — Определить риски и ограничения в период проведения теста

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

При выборе периода необходимо:

1. Исключить период сезонного роста спроса

2. Исключить период пересечения с другими тестами

3. Переждать обновления ПС (если они были объявлены)

4. Переждать шторм выдачи ПС

5. Определить ресурсы продуктовых и IT команд

Заложить 2–3 месяца на период теста и 1–2 месяца на пост‑анализ отката

Для нашего примера были определены следующие зоны:

Этап 2 - Сегментирование

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

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

Шаг 1 — Построение модели трафика

Соберите исторические данные о трафике и видимости в ПС (рекомендуется за 100 дней), чтобы построить модель ожидаемого поведения трафика без изменений, что позволит точно оценить влияние эксперимента.

Такая процедура избавит нас от рисков включения документов с трендом снижения трафика или видимости.

Шаг 2 — Выбор подходящего типа тестирования и определение групп

Определите, какой тип тестирования подходит для вашего случая: А/Б или А/Б/n, где n — это вариативности внесенных изменений, чтобы обеспечить точность результатов и избежать смешения эффектов при тестировании нескольких изменений одновременно.

К примеру у вас есть идеи улучшения сниппета в выдаче ПС внедрением УТП нескольких типов для улучшения CTR, и вы хотите проверить все варианты разом, чтобы не запускать тест поочередно и сэкономить время. Для этого для каждого варианта подбираете отдельные группы документов и мы получаем:

• А — документы без изменений

• Б — документы с изменений варианта 1

• В — документы с изменений варианта 2

• и т. д.

На нашем примере с «Меню» мы в процессе такого анализа получаем следующие группы:

В нашем примере мы делим их на тип «text» и «link», что направлены на изучение влияния отсутствия ссылок и улучшение текстовой релевантности страницы. Таким образом получается 5 основных сегментов, которых далее делим на подгруппы по факторам влияния на ранжирование — это следующий шаг.

Шаг 3 — Подгруппы по факторам влияния на чистоту эксперимента

На этом шаге нам необходимо задать себе вопрос:

«Какие факторы могут повлиять на чистоту эксперимента?»

Это может быть:

• Типы страницы

• Тематика / Направления по категориям

• Ассортимент и доля товаров в наличии

• SEO оптимизация

• Наличие seo‑текста

• Шаблонизация или уникальные title

• Наличие в блоках перелинковок (дополнительных)

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

Пример:

Предположим, что вы хотите провести тест улучшения сниппета для повышения CTR, где необходимо учесть: — Группы по позициям запросов или среднюю позицию документов, чтобы изменения могли сравнивать равнозначно, т.к. есть прямая связь позиции и CTR — Наличие колдунщиков в выдаче ПС — Позицию колдунщиков в выдаче ПС — Наличие расширенного сниппета — Признак наличия сильных конкурентов (выше или ниже нас) и другие элементы, которые могут повлиять на CTR в выдаче ПС

Шаг 4 — Исключаем документы попадающие в зону риска

На данном шаге мы приступаем к чистке документов, которые попадают под риск потери трафика и бизнес показателей:

• Сезонные категории (исключаем ближайшие на 4 месяца)

• Ключевые направления для бизнеса (к примеру исключаем по GMV)

• Участвующие в других экспериментах

• Малый ассортимент (меньше 15 товаров)

• Малая доля товаров в наличии (более 10%)

• В зависимости от задачи сегмента фильтруем по видимости в ТОПы (в некоторых экспериментах создаем отдельные группы по доле видимости)

Пример из другого кейса, где мы в зависимости от внедряемых изменений применяем фильтр по «Критериям отбора», объему WS или видимости в ПС:

Другой кейс, когда у нас несколько действий (вносимых изменений) с определенными зонами влияния, имеют свой набор критериев отбора документов под каждый сегмент:

Следующий пример, почему важно исключать листинги с малым числом товаров или с малым объемом товаров в наличии. Чем ниже доля товаров в наличии на первой странице листинга, тем ниже видимость и для чистоты эксперимента необходимо:

• либо исключить эти документы

• либо внедрить подгруппы или фильтры в дашбордах, чтобы можно было анализировать показатели в разбивке этих подгрупп

Шаг 5 — Сбор стартовых показателей и разделение на ТГ и КГ

Для всех отобранных документов, по предыдущим шагам, снимаем стартовые показатели по всем метрикам, которых ранее определили и согласовали с бизнесом (продуктовыми командами, аналитиками).

Думаю и так понятно для чего надо собирать стартовые данные перед запуском по всем метрикам, а не только того, что хотим улучшить, но давайте зафиксируем на всякий случай:

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

• Если мы не зафиксируем стартовые данные всех отобранных метрик, то рискуем сравнивать А/Б‑группы, которые уже были неравны изначально.

• Прогнозирование тренда. Мы ранее это затронули в предыдущих шагах, повторим, что можем определить тренд снижения или роста, что поможет сделать правильные выводы по итогу теста.

• Идентификация скрытых факторов. Собрав данные за пару недель до запуска мы также определяем есть ли влияние внешних факторов (резкий рост спроса, инфоповод, колебания в аналитике или в выдаче ПС)

После отбора документов и сбора стартовых показателей, мы приступаем к делению на равнозначные ТГ (Тестовая Группа) и КГ (Контрольная Группа) группы.

Важно:

— разделение на тестовую и контрольную группы должна быть осуществлена по схожим параметрам документов
— равное деление не только по значениям метрик в день старта эксперимента, но и в динамике за последние пару недель
— мы смотрим на равное деление не только по сегментам, но и по группам.

Для примера смотрим на один из сегментов, где все показатели плюс‑минус равны и не превышают 30% разности (за исключением числа запросов в одной из групп, но т.к. объем спроса и видимость не сильно отличаются, то можем сделать исключение).

Сбор стартовых метрик — это основа, без которой SEO‑эксперимент теряет смысл. Это наш контрольный снимок, без которого невозможно понять, что пошло не так — или наоборот, сработало идеально.

Этап 3 - Запуск и мониторинг

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

Что важно учесть при запуске

1. Фиксация даты и версии страниц

2. Зафиксируйте точную дату и время запуска изменений.Сделайте скриншоты: изменяемый блок, контент, сниппеты и т. д.

3. Задокументируйте, в чём конкретно заключаются изменения.Я часто сохраняю с браузера веб версию к себе в архивную папку на случай возникновения потребности в сравнении, если вдруг появился какой‑то новый элемент на странице — а тебе говорят, что он там был всегда (несколько раз такое бывало, берите на заметку).

4. Корректность внедрения

5. Убедитесь, что только тестовая группа получила изменения.Проверьте верстку, заголовки, внутренние ссылки и canonical и другие важные элементы влияющие на результат эксперимента по всем отобранным документам.

6. Индексация‑ Проверьте, что поисковикам доступны документы и изменения (через парсеры). Если применяли JS‑изменения, то удостоверьтесь, что они SSR‑рендерятся и видимы ботам.‑ Проверьте, что поисковики просканировали новую версию (через лог‑файлы, GSC, Я. Вебмастер) и добавили в базу поиска. Зафиксируйте дату сканирования и обновления базы поиска.

Рекомендации по мониторингу:

1. Частота съема — идеальный вариант ежедневно, в среднем 2 раза в неделю

2. Визуализируйте данные (Looker Studio, Power BI или обычный Google Sheets для построения графиков). Так информация воспринимается лучше.

3. Отслеживайте и фиксируйте тренды, аномалии и внешние события (обновления ПС, маркетинговые активности, проблемы с сайтом, усиления активностей у конкурентов и т. д.). Идеально, когда эти фиксации отражаются на графиках. Но в большинстве случаев достаточно в табличной форме, чтобы учесть при подведении итогов.

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

Пример из другого кейса, где мы на ежедневной основе мониторим изменения видимости в ПС в разрезе подгрупп:

Здесь мы видим динамику в срезе наличия мини текста или типа title (шаблонный или уникальный), что снимает все вопросы об их влиянии на результат эксперимента.

Важно:

Сравнение ТГ и КГ полезно не только для экспериментов связанных с изменениями на сайте, но и для определения эффективности внешнего продвижения.

Для примера приведу один из проектов, где для отслеживания эффективности был реализован Дашборд в Tableau c ежедневным мониторингом динамики:

• размещения и индексации ссылок

• видимости ТГ и КГ групп

• видимости подгрупп и более узких выборок

Где мы можем наблюдать динамику видимости в ПС в разрезе тестовой и контрольной группах и делать выводы на ее основе:

В данном примере мы видим, что ссылки хорошо работают для усиления видимости внутри ТОП10 и ТОП20.

Аналогичный пример мониторинга в разрезе типов страниц:

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

• набором метрик и инструментом сбора значений

• разделением документов на группы по факторам влияния

• исключением влияния внешних факторов

• сбором стартовых данных и мониторингов во время проведения теста

Имея все необходимые данные мы сможем корректно сравнить показатели «До», «Во время» и «После» и подвести итог о статусе гипотезы — рабочая или провальная.

Если повезло и итоговые показатели положительные, то приступаем к масштабированию. Как правильно масштабировать результаты напишем в следующей статье ?

Вопрос 4 - Можно ли объединить Продуктовый и SEO А/Б тест?

Да, объединить продуктовый и SEO А/Б тест возможно, но это требует особого подхода. Такие эксперименты называются гибридными и применимы в тех случаях, когда изменения влияют и на поисковую видимость, и на пользовательское поведение внутри сайта

Как это реализовать?

Запускаем два параллельных потока тестирования:

• SEO — разделение контрольной и тестовой группы страниц

• Продукт: разделяет пользователей внутри тестовой группы

т. е. SEO‑тест идет по страницам, продуктовый только внутри тестовой группы.

В каких случаях это следует делать?

Объединить продуктовый и SEO А/Б тест можно и нужно, когда мы хотим:

• донести ценность улучшения сайта по запросам команды SEO, что мы не только трафик привлекаем, но и улучшаем пользовательский опыт

• отследить не ухудшит ли изменения продукта показатели SEO

К примеру, мы тестировали алгоритм ранжирования товаров в листинге и ее влияние на видимость в ПС. Одной из гипотез было доля товаров с отзывами в листинге:

Таким образом мы подтвердили, что товары с отзывами хорошо работают как для повышения конверсии внутри сайта, так и для улучшения видимости в ПС.

Вопрос 5 - Как генерировать гипотезы и где искать точки роста?

Что если, очень хочется найти новые точки роста, но гипотезы нет. Нет идей как привлечь новый трафик или улучшить качество текущего.

Гипотеза — это предположение о том, какое изменение на сайте приведет к улучшению конкретной метрики, и почему это произойдет.

Где искать? — конечно у себя на сайте и на сайте конкурентов, на выдаче поисковых систем, в аналитических отчетах и инструментах:

• Анализ СЯ — Не для точки роста дополнительного трафика созданием новых страниц. А для анализа поисковых запросов, чтобы понять боль и потребность пользователей. Часто они встречаются в НЧ запросах и запросах с длинными хвостами. Определив их мы можем составить список гипотез по добавлению доп ключей в Title или другие зоны документа.

• Анализ СЯ для сравнения текстовой релевантности — учет порядка слов или вхождения синонимов, к примеру у брендов (Samsung — Самсунг) и т. д.

• Страницы с низким CTR при хороших позициях — проверить title, description, сниппет.

• Определяем средний показатель CTR из Яндекс Вебмастера.‑ Отбираем документы с показателем ниже среднего для каждой позиции и изучаем — сравниваем с конкурентами для поиска новых вордингов или УТП, которые смогут привлечь внимания пользователей.

• Страницы на 11- 20 позициях‑ Разделить на типы страниц, элементы влияющие на ранжирование и сравнение между страницами, которые ранжируются выше — в чем их отличие?

• Плохая индексация — анализируем логи, структуру ссылок

• Длинные или тяжелые страницы — оптимизируем лишний код

• Сравнение с конкурентами — что есть у них, чего нет у нас

• Аномалии в метриках — провал по кликам, падение индексации, всплески — ищем причину и корреляцию с элементами на страницах (максимальная детализация)

• Лидеры против отстающих — отличия между топ‑страницами и неуспешными документами/сайтами

• Сигналы от пользователей и продукта — жалобы, пожелания, тесты UX

• Анализ поведения или пользовательский опрос. Часто хорошо работает исследования поведения пользователей внутренней или внешней командой.

• Анализ карточек товаров и влияние на бизнес показатели. Как правило, документы с высоким показателем закрытия пользовательской потребности, т. е. с высокими конверсионными способностями лучше ранжируются в ПС. А значит там, где есть проблемы с конверсией, может быть точкой роста и бизнес показателей, и SEO. К примеру число фотографий товаров, количество отзывов, наличие текста и т. д.

• Самый легкий способ — нанять аутсорс команду, которая будет искать и предлагать инициативы по точкам роста

Если пройтись по списку, то можно вкратце выделить основные зоны поиска точек роста:

• Исследование поискового спроса и выдачи

• Анализ и сравнение сайта с конкурентами

• Работа с бизнес показателями и потребностями пользователей

• Аналитика данных и поиск корреляции с факторами ранжирования

• Конференции, вебинары — заимствование у коллег с рынка.

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

Документирование

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

• Фиксация всех деталей помогает избежать ошибок или недопониманий в интерпретации данных.

• Помогает анализировать процесс и выявлять возможные улучшения или оптимизации.

• Предоставляет учебный материал для новых сотрудников

• Позволяет воспроизвести эксперимент и проверить результаты.

Переходите к нам в ТГ канал, где мы поделимся своим опытом работы в крупных e‑com проектах — подписывайтесь, читайте и оставляйте комментарии. Мы учтем мнение каждого, чтобы следующие посты и статьи были полезны.

Чек‑лист по статье

Всем спасибо! ?