В e-commerce почти каждое решение влияет на прибыль. Но без системного подхода к аналитике продуктовая команда не видит, что действительно работает, а что тянет метрики вниз. Чтобы продукт не превратился в «чёрный ящик», а продуктовые решения не принимались интуитивно, важно выстроить регулярный контроль ключевых показателей и встроить аналитику в ежедневные процессы.
Аналитик студии комплексной разработки цифровых решений CleverPumpkin Алёна Сорокина и эксперты брендов со зрелым data-driven подходом «М.Видео» и Unirest.tech (бренд Rostic's) разбирают, как использовать данные, чтобы управлять конверсией, минимизировать риски при релизах и масштабировать работающие решения для роста e-commerce продуктов.
Продуктовая аналитика
Продуктовые метрики отражают реальное поведение пользователей и показывают, обеспечивает ли продукт ценность, насколько востребованы ключевые функции, где возникают барьеры на пути к покупке. Эти данные помогают находить продуктовые инсайты и должны лежать в основе решений о доработках интерфейса, логики, функциональности и персонализации.
Среди базовых показателей – активность DAU, WAU, MAU, выручка, средний чек, retention и воронки сценариев. Ключевой эффект не в количестве метрик, которые вы собираете, а в том как они применяются для улучшения продукта.
«В доработке поиска по каталогу мы постоянно анализируем поисковые запросы, клики, глубину просмотра, поведение после выдачи и адаптируем алгоритмы под реальные паттерны клиентов. По сути, данные становятся не отчётностью, а источником продуктовых инсайтов, которые напрямую меняют UX и коммерческий результат».
Андрей Скачёк
Директор по маркетингу, М.Видео
В e-commerce, где каждое ценовое предложение влияет на прибыль, важно знать, кому, когда и зачем его предлагать. Данные позволяют уйти от массовых акций к точечным офферам и экономить на маркетинге.
«Один из самых показательных кейсов — запуск ML-модели, работающей со склонностью к покупке. На основе данных о поведении на сайте и в приложении, истории покупок, реакции на промо, а также офлайн-покупок мы встроились в клиентский путь точечно. В результате модель выдает предложение только там, где оно реально нужно, и только тем клиентам, у кого есть высокая вероятность инкрементальной покупки. Эффект был очень заметный, ROI вырос почти в 3 раза, с ~80% до ~250%, и мы продолжаем улучшать этот показатель».
Андрей Скачёк
Директор по маркетингу, М.Видео
Важно отслеживать метрики как для развития, так и для поддержки стабильной работы продукта, быстро реагировать на баги, ошибки в интеграциях или неудачные UX-решения после релизов.
«Анализируя конверсию на последнем шаге воронки, мы видели довольно большое число отказов пользователя на платёжной форме банка (доступа к аналитике платёжной формы у нас не было). Возникла идея, что это проблема конкретного банка связанная с антифродом – так и оказалось. По результатам A/B-теста нам удалось снизить долю ошибок на 27% с другим банком».
Алексей Ефремов
Head of Product, Unirest.tech (бренд Rostic's)
Как решают эту задачу на практике
Сейчас есть много сервисов, которые можно использовать: Firebase, AppMetrica, AppsFlyer, Amplitude.
AppMetrica – одна из тех систем аналитики, которой пользуется CleverPumpkin для проектов. В ней все функции бесплатны до достижения определенного количества событий.
A/B-тестирование и эксперименты
Проведение тестов и экспериментов делает подход к процессу развития цифрового продукта более системным. Как и продуктовая аналитика, эксперименты помогают лучше понимать пользователей, снижают риски при внесении изменений или добавлении функций, поскольку позволяют сначала проверить гипотезу на небольшой группе пользователей.
«A/B-тесты мы используем гибко. Для чувствительных и автоматизированных каналов часто используем тест 50/50-распределение, чтобы быстро увидеть негативный эффект и вовремя остановиться. По итогам MVP мы либо масштабируем решение, либо закрываем гипотезу — без эмоциональной привязки».
Андрей Скачёк
Директор по маркетингу, М.Видео
«Чаще всего наши продуктовые инкременты связаны с крупными изменениями в бизнес-логике с очевидным позитивным эффектом на GMV или CV. И A/B-тесты мы используем, когда видим риски негативного влияния на какие-то другие метрики. Недавний пример: внедряем ML-модель для точного расчёта времени приготовления заказа и с помощью A/B хотим убедиться, что доля отмен значимо не растёт из-за того, что пользователь видит слишком долгое время ожидания».
Алексей Ефремов
Head of Product, Unirest.tech (бренд Rostic's)
Общие рекомендации проведения А/B-тестов
Настройте процесс отбора гипотез.
«Поиск точек роста и формирование гипотез — это не разовая активность и не привязка к спринтам, а постоянный процесс. Идеи могут быть из нескольких источников: голос клиента и обратная связь, анализ воронки и поведения, идеи команд, данные и аномалии в метриках.
Дальше эти идеи проходят воронку: часть отсекается сразу, часть — на этапе аналитической проверки, часть доходит до MVP. После этого гипотеза запускается в небольшом масштабе, часто в ручном режиме, с чётко определёнными метриками успеха».
Андрей Скачёк
Директор по маркетингу, М.Видео
2. Обязательно сохраняйте контрольную группу и осознанно выбирайте распределение трафика.
В A/B-тесте всегда должна быть контрольная группа – текущая версия продукта, с которой сравнивается новое решение. Без неё невозможно корректно оценить влияние изменений и отделить эффект гипотезы от сезонности или внешних факторов.
Часто используется распределение 50/50: оно позволяет быстрее набрать выборку и обеспечивает максимальную статистическую мощность при равных условиях.
Однако долю трафика можно варьировать в зависимости от рисков и масштаба гипотезы. Если изменение потенциально влияет на ключевые метрики или несёт бизнес-риски, тест можно запускать на меньшей части аудитории и постепенно увеличивать охват при отсутствии негативного эффекта.
Главное – заранее определить целевые метрики и минимально значимый эффект, чтобы результат теста был интерпретируемым и применимым.
3. Сравнивайте небольшие изменения. Так можно лучше понять, что конкретно повлияло на ту или иную метрику.
В нашем примере кардинально разные дизайны для сравнения, которые не все гипотезы позволят проверить, но например покажут частоту переходов в конкретные разделы.
4. Делайте выборку от 1000 пользователей. Если тестируемую функцию или экран использует слишком мало человек, в тесте не наберётся достаточное количество пользователей, и не удастся однозначно засчитать выигрышный вариант.
Например, в приложении есть сторис с анонсами и скидками. Однако пользователи не очень активно ими пользуются. Если проводить для них A/B-тест, то разница между двумя вариантами либо будет не очень заметна, либо понадобится очень много времени, чтобы набрать достаточное количество людей. В этом случае рекомендуем повышать видимость и проверять используемость функции, так как время затраченное на улучшение может быть нецелесообразным.
5. Тестируйте наличие функциональности осознанно и с чёткой целью.
A/B-тесты на наличие/отсутствие фичи могут быть полезны, если цель – проверить её реальную продуктовую ценность и влияние на ключевые бизнес-метрики: конверсию, удержание, средний чек или глубину сценария. Такие тесты помогают понять, создаёт ли функциональность дополнительную ценность или усложняет интерфейс.
Например, если на экране есть кнопка подбора товара по заданным критериям, то тест на её удаление может показать, влияет ли она на переходы к покупке или на общую воронку, а не только на количество кликов по самой кнопке.
Однако важно учитывать риски: полное отключение фичи может повлиять на пользовательский опыт, вызвать негативную реакцию или затронуть узкую, но ценную аудиторию. В таких случаях стоит либо ограничивать тест сегментом пользователей, либо глубже анализировать поведение, например, изменение сценария покупки или перераспределение действий между экранами.
Если задача – оптимизировать уже работающий элемент, эффективнее тестировать его расположение, визуальное оформление или формулировку. Это позволяет уточнить влияние конкретного изменения, не затрагивая саму ценность функциональности.
6. Тестируйте одну конкретную однозначную гипотезу. Так по результатам вы сможете сказать, подтвердилась ли она. Если гипотез несколько, засчитать результат теста не получится.
7. Измеряйте тест метриками: количеством покупок, добавлений в корзину, открытий экрана товара и т.д. Самые показательные метрики должны относиться к основной воронке в приложении, совместно с влиянием на LTV/CAC/Retention и метриками unit-экономики. Для e-com-приложения она выглядит так: открытие каталога – открытие экрана товара – добавление товара в корзину – успешная покупка. Если будет перебор метрик, то по итогам теста понять однозначный результат не получится.
Например, мы тестируем функцию, которая должна увеличить количество проигрываний видео в карточке товара. В гипотезе влияние на конверсию в выкуп (увеличиваем число целевых покупок и уменьшаем число возвратов). Если редизайн фильтров плохо повлиял на конверсию в покупку или доход, то может показаться, что уже не так важно, как он повлиял на применение фильтра, но всегда стоит учитывать систему целиком. Возможно, что новые фильтры применяются лучше, а проблема в нерелевантности выдачи. При исправлении ошибки последующего шага мы получим лучший итоговый результат, хотя первоначально метрики могли показать ухудшение конверсии.
Как решают эту задачу на практике
Один из инструментов для A/B-тестов у нас на проектах — платформа Kameleoon, которая позволяет проверять гипотезы, анализировать поведение пользователей и настраивать взаимодействие с ними.
A/B-тесты в этом сервисе для мобильных платформ проводятся через систему фича-флагов (переключателей, с помощью которых включаются/отключаются функции без изменения кода), но важно учитывать, что это за дополнительную оплату.
Однако не для всех гипотез подходит проверка A/B-тестами. Иногда опросы гораздо эффективнее, например по результатам оформления заказа или по выбору варианта дизайна. Для таких целей можно использовать сервис «Яндекс Взгляд», которая помогает собирать отзывы, тестировать интерфейсы и проверять гипотезы на большом пуле реальных пользователей, что повышает точность внедряемых улучшений.
Аналитика на стыке данных и исследований
Даже при выстроенной аналитике цифры в отрыве от пользовательского фидбэка могут не всегда отражать реальную картину. Чтобы учитывать поведение, мотивацию и бизнес-ограничения одновременно, команды комбинируют количественные с качественными данными. Принимая во внимание все переменные, легче сформировать контекст и определить причины отклонений.
«При сочетании количественных данных с обратной связью мы используем принцип: доверяй, но проверяй. Например, в гибридной сегментации первый слой строится на прямой обратной связи клиентов — опросах, интервью, исследованиях. Второй слой — это проекция этих ответов на данные: чеки, поведение, частоту покупок, реакцию на коммуникации. У нас есть Customer 360 с ~300 атрибутами на клиента, и мы всегда проверяем, насколько голос клиента совпадает с тем, что он реально делает.
Это важно, потому что люди часто интерпретируют свои действия постфактум или забывают детали. Если совпадений между метриками и негативными комментариями нет — ищем косвенные признаки, формируем гипотезы, проверяем и только потом масштабируем».
Андрей Скачёк
Директор по маркетингу, М.Видео
В Rostic’s, где цикл сделки короткий, основой решений остаются количественные метрики. Обратная связь подключается точечно и для внутренних инструментов, где важно мнение конкретной группы пользователей.
«Так как у нас высоко транзакционный бизнес, мы в первую очередь ориентируемся на количественные данные. Обратная связь от пользователей для нас важна во внутренних продуктах, которыми пользуются сотрудники, например OMS (orders management system)».
Алексей Ефремов
Head of Product, Unirest.tech (бренд Rostic's)
Проседание метрик после релиза не всегда означает, что новое решение неудачное или гипотеза не подтвердилась. На поведение пользователей и метрики могут влиять сезонность, перегретый трафик, конкурирующие кампании и другое. Без анализа всех причин выводы могут быть ошибочны и команда может отказаться от полезных решений.
«Негативная динамика после релиза — нормальная часть работы. Мы не смотрим только на цифру, а разбираем причины. Иногда мы полностью откатываем изменения, иногда дорабатываем гипотезу. Был случай, когда сезонная промоактивность «размыла» эффект пилота. В другом — тестировали номиналы бонусов: маленькие не сработали и были отключены, большие — дали прирост, но вызвали вопросы по экономике, и мы приостановили масштабирование».
Андрей Скачёк
Директор по маркетингу, М.Видео
Автоматизация сбора и анализа данных
Чем больше каналов и точек контакта, тем сложнее e-commerce-продукт и больше данных он генерирует. Data-driven подход требует не просто сбора метрик, а их максимально быстрой интерпретации. Чтобы не тратить время на выгрузки и сводные таблицы, бизнес всё чаще внедряет автоматизированные сервисы, которые выявляют узкие места, сигналят о сбоях и ускоряют принятие решений.
Крупные компании развивают собственные AI/ML-системы для персонализации и анализа воронок. Но такие системы требуют отдельных ресурсов на создание, дообучение и поддержку.
Как решают эту задачу на практике
Платформа UX Rocket автоматически строит воронки, выявляет падения конверсий и предлагает конкретные продуктовые гипотезы, основанные на поведенческих паттернах.
Мониторинг технических метрик
Без корректной работы приложения даже лучшая продуктовая аналитика не имеет смысла. Сбои и скорость работы существенно влияют на возврат пользователей в приложение, конверсию в покупку и лояльность. Поэтому нужно регулярно отслеживать технические метрики и мгновенно реагировать на отклонения до того, как это заметит пользователь.
«За мониторинг у нас отвечает выделенная команда, так как установлен высокий SLA по uptime перед бизнесом (допустимое время простоя). Поэтому, если релиз «неудачный», мы почти мгновенно это видим и откатываем изменения. И только потом уже проводим RCA (анализ первопричин), а также используем каждый такой кейс как возможность для обучения и роста зрелости вовлеченных команд».
Алексей Ефремов
Head of Product, Unirest.tech (бренд Rostic's)
Наибольшее внимание стоит уделять первым часам и дням после обновления — проверять работоспособность через 4 часа, 24 часа, 3 дня после релиза. В большинстве систем мониторинга можно включить уведомления на почту о крупных сбоях, чтобы в случае ошибки можно было быстро среагировать.
При возникновении ошибок важно определять, единичная ли возникла ошибка или массовая. Иногда слабое устройство без интернета у одного конкретного пользователя может набрать большое количество ошибок и испортить общую статистику. Особенно, когда не все пользователи ещё обновились и их общее количество маленькое.
Основные технические метрики:
Crash rate (количество сбоев) — какой процент сессий пользователей завершился аварийным закрытием приложения. Это самая важная метрика, по которой можно увидеть сбои, которые напрямую влияют на стабильность приложения. Сессий без аварийного закрытия должно быть более 99,9%.
App start time (время/скорость загрузки) — сколько времени прошло с момента, как пользователь нажал на иконку приложения у себя на девайсе до того, как приложение полностью готово к работе (откроется первый экран). Идеальным временем считается < 2 секунд. Если > 4-5 секунд, то есть риск, что пользователь подумает, что приложение не работает, и уйдет.
Средняя скорость работы с сетью — скорость отправки и загрузки данных от приложения к серверу/интернету и обратно (загрузка изображений, получение ответов на запрос к серверу, отправка формы обратной связи). Показывает, насколько стабильна сетевая инфраструктура, как быстро всё грузится у пользователя в приложении.
Ошибки сети (Network Errors) — какие ошибки и как часто происходят при взаимодействии приложения с сервером. Сессий без ошибок должно быть больше 95%.
Заключение
Стабильность и предсказуемость — только базовый уровень e-commerce-продукта. Уже на этапе MVP важно отслеживать ключевые метрики, чтобы выявлять ошибки, инсайты и не тратить ресурсы на неэффективные сценарии.
«Для ecom критически важно следить за conversion funnel (воронкой конверсий), GMV (совокупной стоимостью всех товаров), доступностью приложения и backend. Я бы начал с правильной настройки AppMetriсa, минимального набора бизнес-отчётности и системы оперативной реакции на прод-инциденты».
Алексей Ефремов
Head of Product, Unirest.tech (бренд Rostic's)
«В первую очередь я бы настроил real-time-метрики и полную прозрачность происходящего в продукте: воронку, конверсии, поведение пользователей, источники трафика, возвраты, частоту покупок, скорость принятия решений. Ключевые KPI — продажи, рост, эффективность каналов, удержание — должны быть видны в режиме реального времени. Без этого e-commerce быстро превращается в «чёрный ящик», где решения принимаются интуитивно, а не на основе данных».
Андрей Скачёк
Директор по маркетингу, М.Видео
По мере роста продукта метрик будет становиться всё больше, а интерпретация сложнее. Чтобы сохранить управляемость, масштабируйте инструменты поэтапно, автоматизируйте сбор и анализ данных, включая решения на базе AI.
MVP:
Аналитика из магазинов приложений — смотреть загрузки и удаления;
Мониторинг сбоев через App Store Connect/Google Play Console. Там будет минимальная аналитика по количеству сбоев;
Firebase — как инструмент для трекинга событий и мониторинга крешей. Есть автоматический сбор ключевых событий, однако на этапе MVP стоит добавить событий 15, чтобы отслеживать основные действия, связанные с воронкой покупки. Также в нём можно мониторить технические метрики и проводить A/B-тесты.
AppMetrica, Яндекс.Метрика для веба.
Рост и масштабирование продукта:
Ecom-аналитика и кастомные события, покрывающие большинство действий пользователя. Поможет анализировать покупки, а покрытие событиями максимального количества действий поможет максимально понимать пользователей и последовательность их действий;
Инструмент для A/B-тестов, например Kameleoon. Его можно использовать при уже стабильном росте приложения, когда есть возможность выделить бюджет на проведение тестов;
Внедрение ML-моделей и AI-инструментов.
Развитие цифрового продукта на данных — это полноценный двигатель роста. Неважно, на каком этапе ваша аналитика, системный подход к данным становится конкурентным преимуществом.
Это блог CleverPumpkin. Создаём цифровые решения полного цикла — веб-сервисы, сайты, мобильные приложения и интеграции. На Хабре делимся опытом, рассказываем о проектах, технических сложностях и решениях, которые помогают бизнесу достигать целей. Если вы настраиваете аналитику с нуля или хотите усилить текущую — напишите CleverPumpkin в Telegram. Поможем настроить события, выбрать подходящие инструменты и встроить аналитику в продуктовый цикл вашего проекта.
