Этапы проведения SEO-экспериментов с примерами: от гипотезы до вывода (+чек-лист)
SEO-эксперименты — один из самых мощных способов принятия решений на основе данных, а не ощущений. Но в отличие от продуктовых А/Б-тестов, где можно контролировать почти все, в SEO нужно действовать осторожно: влияние внешних факторов, задержка в отклике поисковых систем, асимметричность страниц и многое другое.
В этой статье мы разберем вопросы:
В конце статьи найдете ссылку на чек-лист :)
Прежде, чем начнем, давайте обозначим зачем нужны эксперименты в SEO:
- Отделяют догадки от фактов - показывают, что действительно работает
- Помогают принимать решения на данных, а не на интуиции
- Снижают риски - можно проверить идею на части сайта перед масштабированием
- Повышают доверие к SEO - есть доказанный эффект
- Учеба на ошибках без ущерба - если гипотеза не сработала, это тоже результат
Вопрос 1 - В чем отличие SEO эксперимента от продуктового A/Б тестирования?
Продуктовое А/Б-тестирование и SEO-эксперименты отличаются прежде всего средой, в которой они проводятся и методом сбора данных.
- В продукте тестируются изменения в интерфейсе, которые осуществляются на одной странице и делим аудиторию пользователей на группы
- Мы полностью контролируем, кому что показать, и уже через несколько дней можем получить результат по числу кликов, конверсий или удержания пользователя.
- Главное отличие в том, что в продукте мы контролируем все - среду, трафик, пользователей.
В SEO все иначе. Мы не можем на одной странице внедрять два разных изменения одновременно. Изменения делим не по аудиториям, а по документам. Мы не можем контролировать трафик - он зависит от спроса, реакции поисковых систем, конкуренции и алгоритмических изменений.
Краткий список аспектов отличия:
Итого:
- Продуктовый А/Б тест - это эксперимент с делением групп по аудиториям, где одна группа видит вариант А, другая - вариант B.
- SEO А/Б тест - это эксперимент проводимый на разных группах страниц для всех пользователей
Вопрос 2 - Как уберечь SEO от продуктового А/Б тестирования
Продуктовые А/Б-тесты часто затрагивают интерфейс, тексты, навигацию, контент, скорость загрузки.
К примеру, это может повлиять на:
- Индексацию страниц
- Качество сниппетов
- Внутреннюю перелинковку
- Релевантность контента
- Скорость загрузки и Core Web Vitals
Если SEO-специалист не в курсе продуктовых тестов, то он может узнать о внедренных изменениях уже по факту падения трафика, которые исправить зачастую бывает сложно, долго и дорого.
Шаг 1 - Внедрить SEO чек-лис (регламент) для продуктовых команд
Добавьте статью в продуктовый портал, к примеру в Confluence, блок "Проверка на влияние SEO" и перечислите все зоны на сайте, которые могут повлиять на результаты ранжирования в поисковых системах.
В нем необходимо обозначить важный вопрос, который продуктовые менеджеры должны задавать себе или бизнес аналитикам: “Меняются ли [обозначенный пункт из регламента]?”:
Если ответ «да» - им необходимо подключить команду SEO и обсудить зоны риска.
Шаг 2 - Договориться о кросс-функциональном ревью
Перед запуском А/Б-теста должна пройти техническая встреча с участием SEO, где обсуждают план, цели, методы тестирования и влияние на SEO.
Особенно если:
- затрагиваются шаблоны карточек, категорий, фильтров
- изменяется набор блоков, содержимое текстовых блоков
- скрываются или добавляются ссылки
- затрагиваются тексты h1/h2, title, descriptions и т.д.
Шаг 3 - Закрываем доступ к поисковым ботам
Продуктовые команды часто используют JS для тестирования гипотез в А/Б тестах, где в варианте “А” тестируемый блок доступен в SSR, а в варианте ”Б” сделан в JS и бот его не увидит (при условии запрета чтения JS).
Сегодня боты попали на старую версию, все ок. Завтра увидели тестовую без важного блока или увидели другой контент и видимость начинает падать.
Поэтому, решаем внутри что для нас важнее:
- Или показывать всем ботам только контрольную версию
- Или открыть индексацию с canonical для тестовых вариантов
Во избежания дублей, т.к. каноникал - это всего лишь рекомендация, советуем выбрать первый вариант. Это делается через включение поисковых ботов в список “исключений”.
Шаг 4 - Мониторить релизы
Договорится с продуктом о том, что они подключают команду SEO к мониторингу продуктовых релизов.
Будьте готовы, что получите сотни писем про разные задачи, которые готовы к релизу, прошли или были отменены в процессе релиза, баги и т.д. - еженедельно.
Определите какие зоны ответственности вы будете контролировать, перечислите теги, к примеру “SSR”, “Веб” или “SEO”, и выделите из своей команды ответственного за эту задачу мониторинга.
Пример из практики:
Кейс:
Продуктовая команда хотела изменить порядок блоков на странице категории, инфу из которых команда SEO использовали для вывода УТП в сниппет. Но так как он не отключался, а меняли только его позицию на странице, то решили, что риск минимален.
Результат:
А/Б тест реализовали через JS, результат показал рост конверсии на 3%. Однако спустя какое-то время команда SEO заметили падение CTR в выдаче ПС, причиной которого стала пропажа информации с УТП. В итоге, несмотря на рост конверсии, общее количество органического трафика снизилось.
Вывод:
Продукт принес локальную пользу, но повредил каналу, который генерирует трафик.
Рекомендуем проверять и мониторить реализацию на проде - "сделали как договорились или как захотели?"
Вопрос 3 - Как правильно провести SEO эксперимент?
Выделим 4 основные этапы проведения экспериментов:
- Оценка гипотезы
- Сегментирование
- Запуск и мониторинг
- Подведение итогов
В эти 4 этапа 1й и 2й входят в единую группу «Подготовка к запуску».
Этап 1. Оценка гипотезы
Этап оценки гипотезы состоит из 5 основных шагов:
- Определение ценности эксперимента
- Определение цели и метода его достижения
- Определение метрик для измерения результата
- Определение инструментов для мониторинга и оценки результатов
- Определение рисков и ограничений в период проведения теста
А/Б эксперименты - мощный инструмент, но при неправильной подготовке они легко превращаются в размытые гипотезы, на которые невозможно сделать вывод.
Шаг 1 - Ценность эксперимента
Прежде чем перейдем к подготовке запуска эксперимента, нам необходимо понять:
- Сколько стоит проведение эксперимента для бизнеса и SEO команды?
- Какой профит мы получим после масштабирования удачного эксперимента?
- Оправданы ли расходы и выделяемые ресурсы для проведения эксперимента?
Т.е. мы должны понимать, стоит ли вообще заниматься этим экспериментом или ее профит настолько незначителен, что мы больше тратим, чем зарабатываем.
Чтобы оценить стоимость SEO-эксперимента включаем в расход прямые ресурсы команд:
- Время SEO-специалиста на анализ и подготовку гипотезы
- Время разработчиков на внедрение (backend/frontend)
- Аналитика: настройка сбора метрик, отчетов, визуализации в Дашбордах
- Ресурсы продукта, UX, контента, при необходимости
А также включаем в расход дополнительные ресурсы:
- Стоимость привлечения внешнего аутсорса
- Стоимость покупки или подписки платных инструментов привлеченных для проведения эксперимента
Далее считаем профит от инициативы:
- Объем потенциального Ptraf умножаем на среднюю конверсию и средний чек - получаем объем дохода (GMV) - оценка для бизнеса.
Пример подсчета расходов:
Считаем профит на примере улучшения CTR в выдаче ПС:
Это пример. У каждого могут быть свои вводные данные по расходам, стоимости рабочих часов команд и ожидаемому профиту. Главное учесть, что эксперимент должен быть оправдан.
Если ожидаемый профит по итогу масштабирования эксперимента оправдывает расходы разработки и другие ресурсы, то переходим к следующему шагу.
Шаг 2 - Определение цели и метода его достижения
Эксперимент начинается не с кода и не с разметки, а с четкого ответа на вопрос: что именно мы хотим проверить и зачем?
- Необходимо сформулировать гипотезу в формате: «Если мы сделаем ЧТО-ТО, то это приведёт к К ЧЕМУ-ТО за счет ТОГО-ТО»
- Обязательно надо связать гипотезу с бизнес-целью
Примеры целей:
Для примера разберем эксперимент, который проводили для оценки влияния объема кода вертикальное меню на скорость загрузки сайта и видимость в ПС:
Потребность:
В рамках инициативы по ускорению скорости загрузки страниц сайта, продуктовая команда зашла с запросом по удалению из кода категории 4-го уровня вложенности. Т.е. не рендерить ее в SSR. В SPA сохраняем как есть для пользователей.
Мы приступаем к оценка гипотезы. В данном кейсе гипотезой являлась то, что улучшается скорость загрузки страниц сайта.
Чтобы оценить теорию и определить как правильнее провести эксперимент необходимо задать себе несколько вопросов:
- Какую проблему мы стремимся решить?
- Оправдано ли наше внимание?
- Какие подходы возможны для её решения?
- Какие аспекты затрагивает эта проблема?
- Какие объекты будем анализировать?
- Что с чем будем сравнивать?
Задав себе вопросы и проанализировав мы поняли, что да, действительно есть проблема со скоростью загрузки сайта из-за большого объема кода меню, который занимает больше половины кода. А ее отсутствие почти вдвое улучшает скорость загрузки.
Но удаление 4-го уровня вложенности влияет на внутреннюю перелинковку и мы можем потерять видимость в поиске по этим категориям.
Поэтому начали анализировать и выявили, что если мы удалим не 4-й уровень, а все другие ветки категорий иной тематики, то можем также улучшить текстовую релевантность. К примеру для детства не будет товаров 18+, а для электроники одежды и обувь.
Таким образом мы нашли дополнительные методы решения задачи и предусмотрели, что может повлиять отрицательно, а что положительно:
После того как провели мозговой штурм и определили все возможные варианты исхода, пришло время определить итоговую цель и методы ее достижения.
Получилось у нас две цели:
- Ускорить скорость загрузки страницы
- Улучшить текстовую релевантность документа
А также два метода их достижения
- Удаление кода категорий 4го уровня вложенности
- Удаление кода категорий иной ветки из меню
НО.. всегда надо задавать вопрос «а что, если..?»:
Что если и 4й и иная ветка покажет хорошие результаты?
- Тогда внедрим оба?
Что, если внедрение двух методов скажется отрицательно?
- Будем проводить второй тест?
И тут, чтобы не задаваться в итоге этими вопросами и не тратить время на еще один эксперимент, мы добавляем третий метод "All"
«All» - включает в себе первый и второй метод одновременно.
Т.е. у нас выходит не A/Б тест, а A/Б/В тестирование.
Итоговый список методов достижения цели получается 3:
- «4-й уровень» - Удаление части кода меню по коллекциям 4-го уровня вложенности
- «Дерево коллекций» - Удаление части кода меню по коллекциям другой структурной иерархии
- «All» - Удаление части кода меню по коллекциям 4-го уровня + коллекций другой структурной ветки
Пояснение:
Промежуточный итог первого шага в этапе оценки:
В описанном примере с удалением кода меню мы не только проанализировали влияние на скорость загрузки, но и обнаружили потенциальные последствия для SEO: потерю перелинковки и тематику. Это дало нам возможность проработать несколько гипотез, заранее учесть негативные сценарии и усилить позитивный эффект.
Такой подход - не просто про эксперимент ради эксперимента. Это системная работа, где цели, методы и последствия продуманы заранее, а результат можно смело можем использовать для принятия решений.
Шаг 3 - Определить метрики для измерения результата
Хорошая гипотеза - это половина успеха. Вторая половина - правильный выбор метрик.
Следующий шаг это определение метрик по которым будем оценивать результат и подводить итоги. У каждого эксперимента свой набор метрик.
Перед запуском эксперимента необходимо задать себе или команде вопрос: “Достаточно ли этих данных для принятия решения?”
Важно:
- Не путайте технические метрики с бизнес-метриками
- Согласуйте ключевые показатели с продуктом и разработкой
Пример:
Из нашего примера с оптимизацией кода Меню были определены следующие метрики:
Вот пример, где наглядно показано, что недостаточно брать только видимость ТОП10 или только %Ptraf, т.к. могут быть кейсы, где они дополняют друг друга:
Частота сбора данных:
Оптимально - собирать данные ежедневно. Минимум - 2 раза в неделю.
Шаг 4 - Определить инструменты для мониторинга и оценки результатов
Для каждой выбранной метрики необходимо определить источник данных или инструмент для его сбора. Если источник или инструмент отсутствует, то следует обеспечить его путем:
- реализации сервисов и инструментов внутренней командой
- привлечением внешних разработчиков для реализации инструментов
- привлечением подрядчиков для временного решения вопроса
Цель данного шага - Обеспечить техническую возможность проведения теста и сбора необходимых данных
Я предпочитаю внутренние системы визуализации и анализа данных, но если у вас их нет, то, к примеру SEOWORK решает большую часть потребности, где можно разделить документы на сегменты и сравнивать как динамику между ними, так и между конкурентами:
Шаг 5 - Определить риски и ограничения в период проведения теста
Далее необходимо с продуктовой командой договорится о зонах действий, типах страниц, устройств и выбрать период для проведения эксперимента.
При выборе периода необходимо:
- Исключить период сезонного роста спроса
- Исключить период пересечения с другими тестами
- Переждать обновления ПС (если они были объявлены)
- Переждать шторм выдачи ПС
- Определить ресурсы продуктовых и IT команд
Заложить 2-3 месяца на период теста и 1-2 месяца на пост-анализ отката
Для нашего примера были определены следующие зоны:
Этап 2 - Сегментирование
Данный этап включает в себя процесс отбора документов и дальнейшую сегментацию, разделение на группы с целью сделать эксперимент более прозрачным минимизировать шум.
Прежде чем приступать к отбору документов для тестирования гипотезы по отобранным метрикам в предыдущем этапе, необходимо выполнить подготовительные шаги.
Шаг 1 - Построение модели трафика
Соберите исторические данные о трафике и видимости в ПС (рекомендуется за 100 дней), чтобы построить модель ожидаемого поведения трафика без изменений, что позволит точно оценить влияние эксперимента.
Такая процедура избавит нас от рисков включения документов с трендом снижения трафика или видимости.
Шаг 2 - Выбор подходящего типа тестирования и определение групп
Определите, какой тип тестирования подходит для вашего случая: А/Б или А/Б/n, где n - это вариативности внесенных изменений, чтобы обеспечить точность результатов и избежать смешения эффектов при тестировании нескольких изменений одновременно.
К примеру у вас есть идеи улучшения сниппета в выдаче ПС внедрением УТП нескольких типов для улучшения CTR, и вы хотите проверить все варианты разом, чтобы не запускать тест поочередно и сэкономить время. Для этого для каждого варианта подбираете отдельные группы документов и мы получаем:
- А - документы без изменений
- Б - документы с изменений варианта 1
- В - документы с изменений варианта 2
- и т.д.
На нашем примере с “Меню” мы в процессе такого анализа получаем следующие группы:
В нашем примере мы делим их на тип «text» и «link», что направлены на изучение влияния отсутствия ссылок и улучшение текстовой релевантности страницы. Таким образом получается 5 основных сегментов, которых далее делим на подгруппы по факторам влияния на ранжирование - это следующий шаг.
Шаг 3 - Подгруппы по факторам влияния на чистоту эксперимента
На этом шаге нам необходимо задать себе вопрос:
“Какие факторы могут повлиять на чистоту эксперимента?”
Это может быть:
- Типы страницы
- Тематика / Направления по категориям
- Ассортимент и доля товаров в наличии
- SEO оптимизация
- Наличие seo-текста
- Шаблонизация или уникальные title
- Наличие в блоках перелинковок (дополнительных)
или другие элементы на странице сайта, которые отличаются от страницы к странице и могут оказать влияние на ранжирование в ПС. Каждый из этих факторов мы выделяем в отдельные подгруппы для мониторинга метрик.
Пример:
Шаг 4 - Исключаем документы попадающие в зону риска
На данном шаге мы приступаем к чистке документов, которые попадают под риск потери трафика и бизнес показателей:
- Сезонные категории (исключаем ближайшие на 4 месяца)
- Ключевые направления для бизнеса (к примеру исключаем по GMV)
- Участвующие в других экспериментах
- Малый ассортимент (меньше 15 товаров)
- Малая доля товаров в наличии (более 10%)
- В зависимости от задачи сегмента фильтруем по видимости в ТОПы (в некоторых экспериментах создаем отдельные группы по доле видимости)
Пример из другого кейса, где мы в зависимости от внедряемых изменений применяем фильтр по “Критериям отбора”, объему WS или видимости в ПС:
Другой кейс, когда у нас несколько действий (вносимых изменений) с определенными зонами влияния, имеют свой набор критериев отбора документов под каждый сегмент:
Следующий пример, почему важно исключать листинги с малым числом товаров или с малым объемом товаров в наличии. Чем ниже доля товаров в наличии на первой странице листинга, тем ниже видимость и для чистоты эксперимента необходимо:
- либо исключить эти документы
- либо внедрить подгруппы или фильтры в дашбордах, чтобы можно было анализировать показатели в разбивке этих подгрупп
Шаг 5 - Сбор стартовых показателей и разделение на ТГ и КГ
Для всех отобранных документов, по предыдущим шагам, снимаем стартовые показатели по всем метрикам, которых ранее определили и согласовали с бизнесом (продуктовыми командами, аналитиками).
Думаю и так понятно для чего надо собирать стартовые данные перед запуском по всем метрикам, а не только того, что хотим улучшить, но давайте зафиксируем на всякий случай:
- Нужен ориентир от чего мы отталкиваемся. Без метрик до изменений мы не сможем понять, произошёл реальный рост или это падение.
- Если мы не зафиксируем стартовые данные всех отобранных метрик, то рискуем сравнивать А/Б-группы, которые уже были неравны изначально.
- Прогнозирование тренда. Мы ранее это затронули в предыдущих шагах, повторим, что можем определить тренд снижения или роста, что поможет сделать правильные выводы по итогу теста.
- Идентификация скрытых факторов. Собрав данные за пару недель до запуска мы также определяем есть ли влияние внешних факторов (резкий рост спроса, инфоповод, колебания в аналитике или в выдаче ПС)
После отбора документов и сбора стартовых показателей, мы приступаем к делению на равнозначные ТГ (Тестовая Группа) и КГ (Контрольная Группа) группы.
Важно:
- разделение на тестовую и контрольную группы должна быть осуществлена по схожим параметрам документов
- равное деление не только по значениям метрик в день старта эксперимента, но и в динамике за последние пару недель
- мы смотрим на равное деление не только по сегментам, но и по группам.
Для примера смотрим на один из сегментов, где все показатели плюс-минус равны и не превышают 30% разности (за исключением числа запросов в одной из групп, но т.к. объем спроса и видимость не сильно отличаются, то можем сделать исключение).
Сбор стартовых метрик - это основа, без которой SEO-эксперимент теряет смысл. Это наш контрольный снимок, без которого невозможно понять, что пошло не так - или наоборот, сработало идеально.
Этап 3 - Запуск и мониторинг
По завершению подготовки, наступает время запустить эксперимент и здесь важно на ежедневной основе мониторить показатели. Если такой возможности нет, то хотя бы пару раз в неделю.
Что важно учесть при запуске
- Фиксация даты и версии страниц
- Зафиксируйте точную дату и время запуска изменений.
Сделайте скриншоты: изменяемый блок, контент, сниппеты и т.д. - Задокументируйте, в чём конкретно заключаются изменения.
Я часто сохраняю с браузера веб версию к себе в архивную папку на случай возникновения потребности в сравнении, если вдруг появился какой-то новый элемент на странице - а тебе говорят, что он там был всегда (несколько раз такое бывало, берите на заметку). - Корректность внедрения
- Убедитесь, что только тестовая группа получила изменения.
Проверьте верстку, заголовки, внутренние ссылки и canonical и другие важные элементы влияющие на результат эксперимента по всем отобранным документам. - Индексация
- Проверьте, что поисковикам доступны документы и изменения (через парсеры). Если применяли JS-изменения, то удостоверьтесь, что они SSR-рендерятся и видимы ботам.
- Проверьте, что поисковики просканировали новую версию (через лог-файлы, GSC, Я. Вебмастер) и добавили в базу поиска. Зафиксируйте дату сканирования и обновления базы поиска.
Рекомендации по мониторингу:
- Частота съема - идеальный вариант ежедневно, в среднем 2 раза в неделю
- Визуализируйте данные (Looker Studio, Power BI или обычный Google Sheets для построения графиков). Так информация воспринимается лучше.
- Отслеживайте и фиксируйте тренды, аномалии и внешние события (обновления ПС, маркетинговые активности, проблемы с сайтом, усиления активностей у конкурентов и т.д.). Идеально, когда эти фиксации отражаются на графиках. Но в большинстве случаев достаточно в табличной форме, чтобы учесть при подведении итогов.
В нашем кейсе для измерения технических показателей, коллеги из 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 проектах - подписывайтесь, читайте и оставляйте комментарии. Мы учтем мнение каждого, чтобы следующие посты и статьи были полезны.
Всем спасибо! 🤗