Снижение отказов интернет-магазина: дерево диагностики и план работ

Снижение отказов интернет-магазина начинается не с редизайна, а с разделения причин: технический сбой, несоответствие ожиданию посетителя и нецелевой вход — это три разные ветки, и лечатся они по-разному. Ниже — дерево диагностики, таблица принятия решения, чек-лист приёмки и учебный пример с условными данными.

Что считать отказом и где границы задачи

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

Второй шаг — очертить границы. Задача снижения отказов интернет-магазина обычно охватывает страницы каталога, карточки товара, корзину и шаги оформления. За её пределами остаются смежные сюжеты: как устроен поиск по товарам, как оформляются возвраты, как работает предзаказ. Их лучше вести отдельными задачами, иначе правки расползаются, а результат невозможно приписать конкретному изменению.

Третий шаг — назначить ответственных. За метрику и её трактовку отвечает аналитик или маркетолог, за техническую часть — разработчик, за приоритеты и приёмку — руководитель проекта. Если ответственный один на всё, диагностика быстро превращается в набор догадок, которые нечем проверить.

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

Дерево диагностики: от симптома к причине

Дерево диагностики — рабочий артефакт этой задачи. Оно строится сверху вниз: сначала симптом, который видно в отчёте, затем ветка причин, затем конкретная проверка, которая подтверждает или снимает гипотезу.

Верхний уровень — три ветки.

Ветка «техника». Посетитель не увидел страницу или увидел её слишком поздно. Признаки: длительная загрузка, ошибки сервера, пустые блоки, сломанная вёрстка на части устройств.

Ветка «соответствие». Страница открылась, но содержание не совпало с ожиданием: не тот товар, не та цена, не тот город, нет нужной характеристики.

Ветка «трафик». Посетитель пришёл из источника, который в принципе не подразумевал покупку: информационный запрос, случайный переход, объявление с нерелевантным обещанием.

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

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

Как пользоваться деревом на практике

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

Сбой интерфейса или нецелевой вход: как различить

Различить эти причины можно по наблюдаемым признакам, и они почти не пересекаются.

Признаки технического сбоя

Отказы сосредоточены на конкретных страницах или типах страниц, а не размазаны по сайту. Метрика резко меняется после даты, которую можно сопоставить с обновлением, сменой настроек или ростом объёма данных. Проблема воспроизводится при повторном открытии страницы, в том числе из другого браузера. В отчётах по устройствам виден перекос: например, на мобильных отказы заметно выше, чем на десктопе.

Признаки несоответствия ожиданию

Отказы выше на страницах, куда ведёт реклама или ссылка с конкретным обещанием. Посетитель уходит, но перед этим успевает просмотреть страницу — в системах аналитики это видно по времени и по прокрутке. Часто рядом есть страница-конкурент по смыслу: например, посетитель искал модель с определённой характеристикой, а попал в общую категорию.

Признаки нецелевого входа

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

Практический вывод прост: пока не разделены эти три группы, любые правки интерфейса — лотерея.

Проверка конкретных страниц и источников

Дальше диагностика становится скучной и точной: нужны срезы.

Срез по страницам

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

Срез по источникам и устройствам

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

Что фиксировать в отчёте

В отчёте по диагностике стоит фиксировать: определение метрики, период, сегментацию, список проверенных страниц, список проверенных источников, найденные аномалии и гипотезы с указанием, какая проверка их подтвердила или сняла. Такой отчёт — основание для плана работ, и он же потом используется при приёмке. Если нужен внешний взгляд на такую проверку, его даёт аудит интернет-магазина, где результат оформляется отдельным документом.

Скорость и стабильность: техническая ветка

Техническая ветка чаще всего связана со скоростью генерации страниц и со стабильностью данных.

В материалах сообщества разработчиков 1С-Битрикс описан случай, когда нагрузка на базу данных выросла после того, как увеличился объём обмена данными с учётной системой. Причиной оказались запросы, выполняемые в цикле, и выборка по неточному совпадению вместо точного. После правок и добавления проверки на изменение данных нагрузка снизилась. Там же отмечено, что часть выигрыша дала замена некэшируемых выборок в шаблоне на кэшируемый компонент и кэширование части динамической информации, запрашиваемой на каждой странице.

Для задачи снижения отказов из этого следуют практические выводы. Первый: рост объёма данных сам по себе может ухудшить скорость, даже если код не менялся. Второй: обмен с учётной системой — частая причина незаметного роста нагрузки, и его объём стоит уточнять заранее. Третий: кэширование повторяющихся блоков влияет на время генерации страницы, а значит, и на то, успеет ли посетитель увидеть содержимое.

Важная оговорка: любые изменения, затрагивающие работающий магазин, делают на копии, с резервированием и планом возврата. Проверять гипотезы на боевом сайте без копии нельзя — это риск потерять заказы.

Данные о товаре и остатках: почему обещание расходится с реальностью

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

В материалах сообщества разработчиков 1С-Битрикс описан механизм количественного учёта и резервирования: у товара есть доступное и зарезервированное количество, а момент резервирования настраивается — например, при оформлении заказа или при оплате. Списание зарезервированного количества происходит при отгрузке, а при отмене оплаты резерв снимается. Там же упоминается, что при нескольких складах система оперирует общим количеством и общим резервом, без привязки к конкретному складу, и что часть заказов может помечаться как проблемные, если отгрузить не удаётся.

Что из этого важно для отказов. Если настройки резервирования не согласованы с реальным процессом обработки заказов, покупатель может видеть товар доступным там, где фактически его уже нет. Если обмен с учётной системой передаёт остатки без учёта резервов, возможны двойные резервы и занижение доступного количества. И то и другое ведёт к уходу на этапе оформления.

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

Таблица принятия решения

Учебный пример на тестовых данных

Учебный пример. Данные условные и не описывают ни один реальный проект.

Входные условия. Условный интернет-магазин бытовой техники. Метрика отказов считается системой аналитики как доля сессий с единственным просмотром. Период наблюдения — один месяц. Трафик идёт из трёх источников: поиск, реклама, прямые заходы. В каталоге около 40 страниц категорий и несколько сотен карточек. Есть обмен данными с учётной системой, который выполняется по расписанию.

Шаг первый. Аналитик делает срез по типам страниц. Оказывается, что отказы выше среднего сосредоточены на нескольких страницах категорий и на части карточек. Информационные страницы и страница контактов показывают высокий отказ, но их исключают из задачи: для этих типов такое поведение ожидаемо.

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

Шаг третий. По карточкам проверяют ветку соответствия. Часть уходов приходится на карточки, где товар показан доступным, но при добавлении в корзину оформление не проходит. Проверка на копии показывает, что доступное количество в карточке и фактическое состояние заказа расходятся из-за настроек резервирования и порядка обмена с учётной системой.

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

Что делают. По технической ветке — правку кэширования выносят на копию, проверяют, затем выкладывают с планом возврата. По ветке соответствия — согласуют настройки резервирования и порядок обмена, проверяют тестовым заказом на копии. По ветке трафика — меняют посадочную страницу объявления или корректируют текст, чтобы обещание совпадало со страницей.

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

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

Как проверить результат и принять работу

Приёмка опирается на заранее зафиксированные условия, а не на впечатление.

• Определение метрики зафиксировано письменно до начала работ.
• Период сравнения и сегментация выбраны заранее и совпадают с диагностикой.
• Сравниваются те же группы страниц и источников, а не среднее по сайту.
• Учтены внешние факторы: рекламные кампании, сезонность, изменения ассортимента.
• Технические правки проверены на копии до выкладки.
• Для каждой выкладки есть план возврата.
• Тестовый заказ на копии подтверждает, что данные о наличии и резерве согласованы.
• В отчёте указано, какие гипотезы подтвердились, а какие сняты.
• Отдельно перечислены ограничения: что не проверялось и почему.
• Результат по каждой ветке дерева диагностики описан отдельно.

Типичные ошибки и ограничения

Первая ошибка — менять всё сразу. Если одновременно переделать вёрстку, кэширование и рекламу, приписать результат конкретному изменению не получится.

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

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

Четвёртая — правки на работающем магазине без копии. Это прямой риск для заказов.

Пятая — игнорирование обмена данными. Рост объёма обмена может ухудшить скорость и точность данных без единой правки в коде.

Ограничения задачи тоже стоит назвать честно. Метрика отказов не показывает причину напрямую, она лишь указывает, где смотреть. Часть причин лежит вне сайта: ассортимент, цены, условия доставки, работа службы поддержки. Их нельзя устранить правками интерфейса, и в отчёте это стоит отметить отдельно.

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужен минимальный набор.

Доступ к системе аналитики и к настройкам, по которым считается метрика. Список типов страниц и их назначение. Перечень источников трафика и посадочных страниц. Данные о том, как устроен обмен с учётной системой и как часто он выполняется. Сведения о настройках количественного учёта и резервирования. Журнал изменений сайта за последние месяцы. Список ответственных по направлениям.

Отдельно стоит подготовить сведения о том, какие правки уже планировались: это помогает не смешивать задачи. Если планируется серьёзная переработка, полезно заранее понимать, из чего складывается Сколько стоит разработка интернет-магазина: из чего складывается цена, чтобы соотнести объём работ с бюджетом. Когда речь идёт о технических правках, их обычно ведёт разработка интернет-магазина — там же фиксируется порядок выкладки и возврата.