8 неудобных вопросов «Яндекс Метрике»

Обсудим особенности «Яндекс Метрики», которые имеют значение для пользователей с серьезными бюджетами на продукт и маркетинг, где цена ошибки становится критической.

8 неудобных вопросов «Яндекс Метрике»

Содержание

Подумать только, Яндекс Метрика была создана аж в 2007 году. Вскоре после того как Google купил Youtube, анонсировал публичный доступ к Google Analytics (ранее Urchin) и незадолго до запуска самой первой беты Google Chrome. В общем, было это очень давно. Изначально Метрика была составной частью Яндекс Директ, но с 2009 образовала самостоятельную вертикаль.

Теперь рунет без Метрики помнят только седовласые ветераны онлайн-маркетинга. Они могут рассказать, как когда-то пользователи жаловались на проблемы с загрузкой сайта из-за предыдущей библиотеки Яндекс Метрики и первой версии вебвизора, нашествия ботов и многое другое. Теперь Метрика оперирует более легким кодом счетчика, но это не единственные изменения.

Метрика значительно обновила и "очеловечила" интерфейс, интегрировала сервис проведения экспериментов Вариокуб и анонсировала Метрику Про – версию для бизнеса, заинтересованного в точных данных с более высоким уровнем детализации. У Яндекс Метрики крайне простой процесс установки, куча интеграций и низкий порог входа. Благодаря всему этому это один из самых популярных счетчиков веб-аналитики (присутствует на 4% сайтов по оценке w3techs.com).

Однако, не все так гладко.

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

Первый вопрос – почему так долго не было событий?

Яндекс Метрика – как и многие (на самом деле все) счетчики веб-аналитики – выросла из парадигмы "пользователь-сеанс". В Метрике сеанс получил название "визит", но сущность осталось такой же. Визит – это несколько взаимодействий с вашим ресурсом в рамках короткого периода времени, как правило, 30 минут. На заре индустрии это было самое то, но очень быстро зона роста сместилась в более глубокий анализ того, что происходит внутри этого самого "визита" – воронки, цепочки событий, поведенческие и так далее.

Уже в конце "десятых" событийная модель стала стандартом для маркетинг - и продуктовой аналитики. Четвертая версия Google Analytics закрыла путь к отступлению – все стали переходить на события. Но в Яндекс Метрике события были добавлены только в середине 2024 года.

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

Второй вопрос – что с междоменным отслеживанием?

Если ваш продукт представлен несколькими веб-сайтами на разных доменах первого уровня (например xyz.ru и abc.ru), то отслеживать их в рамках одного счетчика Яндекс Метрики несложно – необходимо просто прописать эти домены в настройках счетчика. Проблемы начинаются, когда пользователь переходит с одного домена на другой.

В этом случае Метрика будет создавать двух разных пользователей, хотя фактически он один. Связано это с тем, что в качестве идентификаторов пользователей используются cookie-файлы, которые хранятся в привязке к конкретному домену. В большинстве счетчиков веб-аналитики это решается с помощью проброса клиентского идентификатора через фрагмент URL в момент клика. Но в Метрике этого, к сожалению, до сих пор нет.

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

Поэтому если вы работаете с 2-3 сайтами (и путь юзера подразумевает переходы между площадками) – будьте готовы к определенному шуму в пользовательских метриках.

Третий вопрос – что с определением визита?

Визит – это активность пользователя на сайте, которая длится определенный временной промежуток. Визит считается завершенным, если пользователь не проявляет активности в течение некоторого времени — по умолчанию, это 30 минут.

Визит очень тесно связан с атрибуцией трафика. Для понимания распределения трафика по источникам каждый из визитов получает определенный параметр – так называемый, источник трафика.

Если пользователь в рамках одного визита переходит на сайт с нового источника (скажем, e-mail-рассылки или органического поиска), Метрика не будет создавать новый визит. Это исключение не касается рекламного трафика, который всегда будет генерить новое посещение. Но в общем, этот трафик "внутри визита" останется нераспознанным. Это добавит сложностей для трекинга дожимающих рассылок, которые пользователи могут получать в течение или сразу же после визита.

Кроме того, Метрика не позволяет вручную фильтровать рефералов. Это означает, что вы не сможете исключить из источников нежелательные площадки – скажем, биллинг-провайдеров.

Четвертый вопрос – что вообще такое "цели"?

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

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

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

В середине 2024 года Метрика представила отчет "Параметры целей" – в нем можно связывать параметры событий (а не только визитов) с целями. Но это слабо компенсировало странную двойственность. События и цели – это как будто одно и то же, но между ними есть тонкая разница.Цели – это, вроде как, очень важные события, а события – этакие "недоцели" 🙂.

Во-вторых, чаще чем достижения цели, в отчетах используются такие метрики как количество целевых посетителей и целевых визитов. А последняя, в частности, используется для расчета метрики конверсии. И это крайне спорное решение.

Пятый вопрос – что с метрикой конверсии?

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

Несмотря на то, что есть и такой показатель как конверсия посетителей, в отчетах (скажем, в отчете "Конверсия") дефолтно используется как раз доля визитов с достижением цели. И тут интерфейс Метрики неявно подталкивает пользователя к неверным решениям.

Шестой вопрос – почему такая скудная электронная коммерция?

Электронная коммерция – система репортов, событий и параметров для анализа покупок в интернет-магазине. В Яндекс Метрике ее возможности выглядят немного ограниченными. Например, в Метрике вы можете оперировать следующим набором: 8 дефолтных событий электронной торговли и 11 параметров товара. В GA4 (которая тоже в этом смысле не является идеальным примером для подражания) 14 рекомендованных события для учета онлайн-покупок, 23 параметра скоупа "товар" и возможность добавлять кастомные параметры для данных о продуктах.

Из коробки вы не сможете отслеживать в Метрике возвраты, просмотры корзины, стоимость доставки и (самое главное) воронку чекаута. Практически для любого онлайн-стора оптимизация последних шагов воронки является мощной зоной роста. И трекинг этого этапа жизненно важен. Пользователям остается лишь робкая надежда, что в одном из ближайших обновлений появится что-то похожее на "begin_checkout" (возможно, даже с шагами).

Седьмой вопрос – почему оффлайн-конверсии без событий электронной торговли?

Оффлайн-конверсии – это действия, происходящие вне контура вашего веб-сайта. Допустим, покупки в оффлайн-магазине, изменения статусов сделки в CRM и так далее. В общем, важная очень штука. И в Яндекс Метрике у этого функционала масса ограничений.

Во-первых, под каждую загрузку вам нужен CSV-файл. Это касается кейса, если у вас нет рабочей интеграции скажем с АМО или Bitrix.

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

В-третьих, если разница между последним визитом пользователя и оффлайн-конверсией более 21 дня, то событие не передается. Это делает невероятно сложной работу с длинным циклом сделки. При этом стандартное окно атрибуции в Яндекс Метрике – 90 дней.И наконец, вы не можете отправить оффлайн-покупки в виде событий электронной торговли. Оффлайн-конверсией может быть только цель.

Восьмой вопрос – а как же сырые данные?

Яндекс Метрика в своем интерфейсе дает доступ к отчетам, построенным на данных, предварительно подвергшихся предобработке и агрегации. То есть, в отчетах вы получаете доступ к агрегированным данным. У этого есть своя тонкость - для расчета метрик практически всегда используется, так называемое, сэмплирование. По сути это метод предназначенный для уменьшения количества данных, обрабатываемых при формировании отчетов. Он позволяет ускорить работу сервиса при больших объемах исходных данных. При этом демонстрация данных является своеобразной моделью, сделанной на определенной выборке, то есть только части полных данных. Для понимания размера этой выборки в отчетах есть переключатель "Выборка".

Если вы обладаете сильной SQL-экспертизой и не готовы мириться с ограничениями сэмплирования, то всегда есть возможность работы с, так называемыми, сырыми данными. Они представляют собой таблицы хитов и сессий, выгружаемые с помощью Logs API.

Но!

Во-первых, это требует вовлечения сильного дата-инженера. Поставка данных предусматривает создание, настройку, использование кликхаус-кластера в Яндекс Облаке и подготовку регулярной загрузки. Просто включить стриминг в облачную БД не получится, и это делает порог входа достаточно высоким.

Во-вторых, структура таблиц атипична. Если вы не сталкивались с ней ранее, то придется попотеть над парсингом, скажем, параметров визита или событий из соответствующих массивов. И самое главное – само сообщество пока что не спешит делиться SQL-шаблонами для типовых решений на сырых данных в Метрике.

В-третьих, Logs API предусматривает свои ограничения. Одно из них – это 10гб на загрузку. Для проектов с большим трафиком это может стать бутылочным горлышком. Возможное решение – Метрика ПРО – будет стоить вам от 300тыс. руб. в месяц без учета стоимости кластера.

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

Выводы

Бизнес ожидает от сервиса аналитики, как минимум, трех вещей – эффективности, точности и актуальности. И, очевидно, Яндекс Метрике по всем направлениям есть куда расти.

  • Допустим, использование событийной модели. Де-факто, это отраслевой стандарт. В интерфейсе Метрики события вроде как есть, но ни создать когорты, ни поработать с воронками на базе событий не получится (по крайней мере, пока).

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

  • Или когорты. Чтобы построить их в интерфейсе Метрики, вам придется использовать сегменты по дате первого сеанса или отчеты по периодичности.

И так очень во многих аспектах.

Пока зарубежные аналитические платформы друг за другом уходят из России по очевидным причинам, выбор российского решения становится практически безальтернативным. Он был бы ЯМ-безальтернативным, но благодаря, в частности, UX Rocket - выбор среди российских сервисов все-таки есть. 🙂 Мы интегрировали все лучшее, к чему вы привыкли, используя наиболее сильные западные продукты, и сделали это еще удобнее для пользователя.

В UX Rocket вся аналитика строится исключительно на сырых данных и событийной модели. И для того, чтобы посмотреть на таблицы своими глазами, не нужно магических пасов – можно просто перейти в соответствующий раздел.

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

В UX Rocket вы можете быстро и комфортно формировать последовательности событий, оперировать кастомными ивентами, фокусироваться на сегментах и даже формировать когорты на основе событий. Работать с событиями без необходимости лезть в сырые данные – это удобно 🙂.Более того, используя функционал "конверсионные события" (когда ML анализирует все события между шагами воронки и рассчитывает корреляцию с конверсией или оттоком) вы можете осознанно изменять путь клиента, устраняя и добавляя шаги. Ничего подобного на сэмплированных данных сделать не получится!

У UX Rocket есть возможность врезаться в сущность когорт сразу в нескольких местах – на этапе формирования отчета, кастомных событий или собственно самих когорт. Когортный анализ позволяет найти конверсионное поведение, т.е. последовательность шагов, которые делают активные покупатели. Этот опыт можно транслировать на всех своих покупателей, повышая конверсию.

Все эти и многие другие особенности и делают наш инструмент крайне гибким, удобным и эффективным для аналитика.

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

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

Чтобы быть в курсе актуальных трендов в продуктовой и маркетинговой аналитике, А/В - тестировании, а также узнать больше о новых возможностях платформы UX Rocket, подписывайтесь на наш Telegram - канал и группу "ВКонтакте".

77
4 комментария

С парой моментов сталкивалась, про остальные не задумывалась

2

Обращался в службу поддержки так, как Яндекс метрика не фиксирует переходы с других рекламных каналов (майтаргет/вк/tg), Ютм прописаны, но 60-70% трафика не фиксируется, цели в отчетах источники и сводка тоже не фиксируются, то есть система не дает отслеживать конверсию того или иного канала и стоимость Лида с источника, а если сравнивать стоимость перехода с альтернативных рекламных источников то она ниже чем у Яндекса в 3 раза, напрашивается вопрос почему Яндекс делает так!?)

1

Антон, спасибо за комментарий! Очень хороший вопрос :)

Хорошая статья.
Я лично не понимаю стратегию развития метрики.
Да, события это что все хотели и ждали. Но это не решило основную проблему - Как объеденить события с визитом и источником визита.
Очевидный ответ (в том числе ожидаемый от поддержки) - есть ведь параметры визитов. Это не плохое решение, но даже если опустим высокий порог входа, это не снимает ограничения в 500 событий в рамках визита. И основная проблема на больших проектах - когда ты пытаешься объеденить таблицу визитов с таблице просмотров (где и лежал все полные данные по событиям) - у тебя нет единого ключа. Только по поведенческим метрикам. И даже тут сталкнешься с тем что часть id пользователя могут отсутсвовать.
Единственное чего не хватает (даже для отчасти бесплатного инструмента) - нет объедения таблиц единым ключом. Это я еще опустил проблемы с самими визитами и определением источников.
Когда ты доходишь до этих проблем по уровню бекраунда - проще интегрировать самописку какую нибудь из open source решений и написать собственную атрибуцию.
И однозначно использовать монополистическое ценообразование в 300к на один счетчик - бред полный и попахивает психушкой. А если у бизнеса 4 счетчика ? Больше 1 млн платить метрике с учетом текущих проблем? За что блядь?