Как получить и установить tracking code Matomo
После того как сервер Matomo развернут, measurable созданы, а архитектура сайтов продумана, начинается следующий этап — подключение кода отслеживания к проекту. Весь код отслеживания Matomo генерируется внутри интерфейса системы. Для этого необходимо перейти:
Administration → Websites → Tracking Code
После этого Matomo автоматически покажет готовый JavaScript-код для выбранного Website.
Очень важно: код отслеживания всегда привязан к конкретному Site ID. Именно поэтому при переключении measurable код будет меняться. Внутри tracking code уже автоматически подставляются:
- адрес Matomo-сервера,
- matomo.js,
- эндпоинт трекера,
- Site ID.
На скрине выше представлен типичный код отслеживания. В отличие от многих «классических счетчиков», Matomo использует полноценный JavaScript tracking client. По сути, этот код состоит из двух частей:
- очереди
_paq, - и внешнего JS-tracker matomo.js.
Очередь _paq собирает команды еще до загрузки основного tracker.
Например:
_paq.push(['trackPageView']);
означает:
«После загрузки tracker отправь pageview».
А:
_paq.push(['enableLinkTracking']);
включает автоматическое отслеживание:
- внешних ссылок,
- загрузок файлов,
- outlink-clicks.
Где размещать tracking code
Matomo рекомендует размещать код как можно ближе к началу страницы. Чаще всего tracker вставляют внутри <head> либо сразу после открытия <body>. Но здесь есть нюансы.
Размещение внутри <head>
Это наиболее распространенный и рекомендуемый вариант.
Плюсы:
- tracker загружается раньше,
- pageview фиксируется стабильнее,
- меньше риск потерять события.
Особенно это важно:
- для SPA,
- ecommerce,
- динамических фронтенд-фреймворков,
- проектов с ленивой загрузкой.
Размещение внутри <body>
Иногда tracking code вставляют после открытия <body>. Обычно это делают через CMS или через шаблоны. Такой вариант тоже рабочий, но есть риски:
- код отслеживания может загрузиться позже;
- часть быстрых событий потеряется;
- некоторые метрики страниц и события могут быть неточными.
Для простых сайтов это обычно не критично, но на сложных фронтенд-проектах лучше использовать <head>.
Проверка установки tracker
После подключения tracking code обязательно нужно проверить, загружается ли container.js, корректный ли Site ID, нет ли JS-ошибок, не блокирует ли код сам браузер. Самый простой способ — открыть DevTools → Network и посмотреть наличие контейнера.
Как работает _paq.push() внутри Matomo
На первый взгляд JavaScript- код отслеживания Matomo выглядит довольно просто:
var _paq = window._paq = window._paq || [];
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
Большинство разработчиков воспринимают это как обычный вызов функций аналитики. Но фактически _paq — это центральная очередь команд всей клиентской аналитики Matomo. Через нее проходят просмотры страниц, события и практически вся логика сбора данных. Именно поэтому понимание работы _paq.push() особенно важно на SPA-проектах, ecommerce-сайтах и сложных фронтенд-приложениях.
Асинхронная очередь команд
Главная идея _paq — работа через асинхронную очередь команд. До загрузки файла контейнера браузер еще не знает, как именно работает код отслеживания. Именно поэтому Matomo сначала создает обычный JavaScript-массив:
var _paq = window._paq = window._paq || [];
После этого в него начинают складываться команды:
_paq.push(['trackPageView']);
или:
_paq.push(['enableLinkTracking']);
На этом этапе _paq — это просто очередь инструкций, ожидающих загрузки основного кода отслеживания.
После загрузки контейнера Matomo:
- Находит очередь _
paq. - Читает накопленные команды.
- Выполняет их по порядку.
- И затем начинает работать уже в режиме реального времени.
По сути, _paq становится внутренним механизмом передачи команд между страницей и системой аналитики.
Выполнение методов внутри _paq.push()
Каждая команда внутри _paq.push() представляет собой массив. Например:
_paq.push(['trackPageView']);
означает: «Вызови метод trackPageView».
А команда:
_paq.push(['setSiteId', '3']);
передает уже не только название метода, но и параметры для него. Фактически структура выглядит так:
_paq.push([
'methodName',
parameter1,
parameter2
]);
После загрузки matomo.js код отслеживания начинает последовательно выполнять все накопленные команды.
Почему важен порядок вызова функций
В Matomo порядок вызова команд имеет огромное значение.
Например:
_paq.push(['setSiteId', '3']);
_paq.push(['trackPageView']);
работает корректно.
А вот такой порядок уже потенциально опасен:
_paq.push(['trackPageView']); _paq.push(['setSiteId', '3']);
Проблема в том, что просмотр страницы может отправиться раньше, чем код отслеживания узнает Site ID. В результате данные могут потеряться или попасть в другой measurable. Именно поэтому в Matomo обычно сначала выполняют настройку кода отслеживания:
- задают адрес tracker,
- указывают Site ID,
- настраивают cookies и domains,
- подключают user tracking,
и только потом начинают отправлять pageview и события.
Выполнение JavaScript-функций внутри _paq
Еще одна мощная возможность Matomo — выполнение собственных JavaScript-функций через _paq.push().
Например:
_paq.push([function() {
console.log(this.getVisitorId());
}]);
В этом случае в очередь передается уже не команда, а обычная JavaScript-функция. После выполнения Matomo запускает функцию, передает внутрь контекст кода отслеживания, позволяет обращаться к внутреннему API tracker. А значит, через this можно получить:
- Visitor ID,
- информацию о cookies,
- текущий URL,
- параметры аналитики,
- состояние tracker.
Tracking PageView и кастомизация страниц
После того как код отслеживания Matomo установлен и _paq.push() начал работать, система автоматически начинает фиксировать просмотры страниц через команду:
_paq.push(['trackPageView']);
Она отправляет в Matomo информацию:
- о текущем URL,
- title страницы,
- referrer,
- браузере,
- устройстве,
- cookies,
- источнике трафика.
После этого Matomo создает visit, pageview, связывает данные с пользователем и обновляет атрибуцию к источнику.
Именно trackPageView является базой всей аналитики Matomo. Через него строятся:
- посещения,
- источники трафика,
- пользовательские пути,
- time on page,
- bounce rate,
- большая часть стандартных отчетов.
Но на современных проектах простого отслеживания URL уже давно недостаточно. Сегодня фронтенд стал намного сложнее. Часто бывает, что SPA не перезагружают страницы, URL могут меняться динамически, title обновляется через JavaScript, часть контента загружается асинхронно, а один экран приложения иногда вообще не имеет отдельного URL. Именно поэтому Matomo позволяет гибко управлять тем, какую страницу увидит аналитика, какой URL будет записан, какой title попадет в отчеты и когда именно отправлять pageview.
setDocumentTitle — изменение title страницы
По умолчанию Matomo берет title страницы из document.title.
Но во многих фронтенд-приложениях title меняется динамически: например, в React или Vue. Если ничего не делать, в аналитике можно получить Home, Home, Home вместо реальных названий экранов. Именно поэтому перед trackPageView можно вручную задать title:
_paq.push([
'setDocumentTitle',
'Каталог товаров'
]);
_paq.push(['trackPageView']);
После этого Matomo запишет уже новый title. Очень важно: setDocumentTitle всегда вызывается ДО trackPageView. Иначе pageview уйдет со старым названием страницы.
setCustomUrl — подмена URL страницы
Еще одна очень важная команда:
_paq.push([
'setCustomUrl',
'/pricing'
]);
Она позволяет вручную указать URL, который попадет в аналитику. Это особенно важно:
- для SPA,
- AJAX-navigation,
- модальных окон,
- виртуальных экранов,
- фильтров,
- фронтенд-routing.
Например, пользователь может находиться:
на https://site.com/app
но внутри SPA фактически открыть:
/dashboard/reports
Без setCustomUrl Matomo продолжит считать, что пользователь сидит на /app. В результате ломаются отчеты, исчезают страницы, некорректно строится user flow и рушится SEO-аналитика. Именно поэтому современные фронтенд-приложения почти всегда используют ручную подмену URL.
Типичная структура выглядит так:
_paq.push([
'setCustomUrl',
'/dashboard/reports'
]);
_paq.push([
'setDocumentTitle',
'Отчеты'
]);
_paq.push(['trackPageView']);
SPA tracking — отслеживание SPA-приложений
Single Page Application — одна из самых сложных тем для любой системы аналитики. Проблема SPA в том, что страница визуально меняется, но браузер ее не перезагружает. Для Matomo это выглядит так, будто пользователь вообще никуда не переходил. В результате pageview не отправляются, user flow ломается, страницы исчезают из отчетов. Именно поэтому SPA-отслеживание почти всегда требует ручной отправки pageview. Обычно это делается через router фронтенд-приложения. Например:
- React Router.
- Vue Router.
- Angular Router.
После изменения маршрута фронтенд вручную вызывает:
_paq.push([
'setCustomUrl',
newUrl
]);
_paq.push([
'setDocumentTitle',
newTitle
]);
_paq.push(['trackPageView']);
Фактически SPA начинает самостоятельно сообщать Matomo: «Пользователь открыл новый экран». Именно поэтому Matomo хорошо подходит для современных фронтенд-фреймворков: код отслеживания здесь можно встроить практически в любую архитектуру приложения.
Virtual pageviews — виртуальные просмотры страниц
Иногда pageview нужно отправлять даже без изменения URL. Например:
- открытие popup,
- шаг checkout,
- wizard-интерфейс,
- вкладки,
- SPA-модалки,
- onboarding screens.
Физически пользователь остается на одной странице, но логически переходит между разными экранами. В таких случаях используют virtual pageviews. Например:
_paq.push([
'setCustomUrl',
'/checkout/step-2'
]);
_paq.push([
'setDocumentTitle',
'Checkout Step 2'
]);
_paq.push(['trackPageView']);
Хотя реальный URL не изменился, Matomo создаст отдельный pageview.
Типичные ошибки при tracking pageview
Практически все продакшен-проблемы начинаются с неправильной отправки pageview. Самые частые ошибки:
trackPageViewвызывается раньше настройки URL;- title обновляется после pageview;
- SPA-router не отправляет pageview;
- дубли pageview;
- виртуальные страницы используют одинаковые URL;
- фронтенд отправляет pageview несколько раз подряд.
Особенно часто это встречается на React- и Vue-проектах, где аналитика внедряется «поверх» готового фронтенда. В результате растет уровень отказов, ломается атрибуция по источникам, появляются дубли, user flow теряет смысл. Именно поэтому отслеживание pageview в современных проектах — это уже не «вставить счетчик», а полноценная фронтенд-интеграция аналитики.
Event Tracking — отслеживание действий пользователей
Event Tracking в Matomo — это полноценная система отслеживания поведения пользователей внутри интерфейса. Через события обычно собирают: клики, взаимодействия с интерфейсом, использование функций, видео, CTA-элементы, JavaScript-взаимодействия, действия внутри SPA и вообще всю продуктовую аналитику.
В общем виде отслеживание действий пользователей в Matomo можно представить в виде следующей схемы:
trackEvent — базовая команда событий
Основная команда Event Tracking выглядит так:
_paq.push([
'trackEvent',
'Category',
'Action',
'Name',
'Value'
]);
Здесь:
Category— категория события.Action— действие.Name— дополнительное имя объекта.Value— числовое значение.
Минимально достаточно первых трех параметров:
_paq.push([
'trackEvent',
'Button',
'Click',
'Buy'
]);
После этого событие попадет в Behavior → Events в интерфейсе Matomo.
Как правильно строить структуру событий
Самая большая ошибка при внедрении Event Tracking — хаотичная структура событий: например, Button Click, button_click, btn, CLICK_BUTTON.
Всё это быстро превращает аналитику в мусор. Именно поэтому продакшен-проекты должны использовать строгую иерархию:
Category → Action → Name
Например:
_paq.push([
'trackEvent',
'Pricing',
'Click CTA',
'Start Trial'
]);
Так аналитика остается читаемой даже спустя годы развития проекта.
Отслеживание кликов
Самый популярный сценарий Event Tracking — клики по интерфейсу. Например:
button.addEventListener('click', function () {
_paq.push([
'trackEvent',
'Button',
'Click',
'Buy Now'
]);
});
Через это обычно отслеживают CTA-кнопки, меню, фильтры, сортировки — да практически всё.
Tabs и интерфейсные переключатели
На современных фронтенд-проектах пользователи часто взаимодействуют с интерфейсом без смены страницы. Например:
- tabs,
- accordions,
- dropdown,
- wizard-интерфейсы,
- SPA-navigation.
Pageview здесь уже бесполезен, потому что URL не меняется. Именно поэтому обычно отправляют события:
_paq.push([
'trackEvent',
'Tabs',
'Open',
'Pricing'
]);
Это позволяет понять, какие вкладки реально открывают, какой контент используют, какие элементы интерфейса игнорируются.
JS interactions — JavaScript-взаимодействия
Event Tracking отлично подходит для отслеживания любых фронтенд-действий, которые создаются на JS и CSS. Например:
- scroll depth,
- hover,
- drag-and-drop,
- AJAX interactions,
- SPA-actions,
- copy buttons,
- custom widgets.
Например:
_paq.push([
'trackEvent',
'Widget',
'Open',
'Chat'
]);
Video Tracking — отслеживание видео
Видео — один из самых недооцененных источников аналитики. Через события обычно отслеживают:
- play,
- pause,
- complete,
- progress,
- replay.
Например:
_paq.push([
'trackEvent',
'Video',
'Play',
'Product Demo'
]);
Это особенно полезно для онлайн-курсов, медиа и вообще везде, где используется видеоконтент. На основе таких событий потом строят engagement-анализ, контентные воронки, scoring и т. д.
CTA Tracking — отслеживание CTA
Практически любой маркетинг сегодня завязан на CTA: «Купить», «Оставить заявку» и т. д. Именно поэтому CTA-отслеживание обычно является обязательной частью аналитики.
Например:
_paq.push([
'trackEvent',
'CTA',
'Click',
'Start Trial'
]);
Позже такие события связывают с воронками, конверсиями, рекламой, источниками трафика, A/B-тестами и выручкой для получения полноценной сквозной аналитики. Именно через это строится перформанс-маркетинг-аналитика.
Goal Tracking и конверсии
Если отслеживание Event отвечает за действия пользователей, то Goal Tracking в Matomo отвечает уже за бизнес-результат этих действий. Именно goals (цели) позволяют понять, какие действия приводят к заявкам, какие источники дают продажи, какие страницы реально конвертируют, сколько денег приносит трафик и как пользователь превращается в клиента. По сути, именно отслеживание целей превращает аналитику посещений в перформанс-аналитику.
Что такое Goal в Matomo
Goal в Matomo — это зафиксированная конверсия. Это может быть отправка формы, регистрация, покупка, заявка, подписка, звонок, оформление заказа и т. д. Цель можно либо создать через интерфейс Matomo, либо отправлять вручную через JavaScript. Обычно используют оба подхода одновременно.
trackGoal — ручная отправка конверсии
Базовая команда Goal Tracking выглядит так:
_paq.push([
'trackGoal',
1
]);
Где 1 — это ID цели в Matomo.
После выполнения Matomo:
- Фиксирует конверсию.
- Связывает ее с визитом.
- Сохраняет источник трафика.
- Обновляет атрибуцию к источнику.
- Пересчитывает отчеты.
Но чаще всего trackGoal используют вместе с выручкой.
Revenue — передача выручки
Matomo позволяет передавать стоимость конверсии прямо в Goal Tracking. Например:
_paq.push([
'trackGoal',
1,
9900
]);
Здесь:
- 1 — ID цели.
- 9900 — выручка.
После этого Matomo начинает строить полноценную перформанс-аналитику, и можно считать выручку:
- по источникам,
- страницам,
- рекламным кампаниям,
- сегментам,
- устройствам.
Именно через это обычно считают ROI, ROMI, CPL, CAC, окупаемость трафика.
Lead Generation — отслеживание лидов
Один из самых популярных сценариев Goal Tracking — лидогенерация. После успешной отправки формы фронтенд обычно вызывает:
_paq.push([
'trackEvent',
'Lead',
'Submit',
'Main Form'
]);
_paq.push([
'trackGoal',
2
]);
Именно такая связка чаще всего используется в продакшене: событие показывает действие, goal фиксирует конверсию. Это позволяет потом анализировать конверсию, стоимость лида, источники лидов, поведение пользователей до заявки.
Form Submits — отслеживание отправки форм
Формы — основа большинства веб-конверсий. На практике Goal Tracking почти всегда строится вокруг отправки формы, успешной отправки (внимание: это разное), thank-you page, AJAX success response. Например:
form.addEventListener('submit', function () {
_paq.push([
'trackGoal',
3
]);
});
Важно! Никогда не отправляйте goal по click на кнопку до успешного ответа сервера или до подтверждения отправки формы. Иначе аналитика начнет завышать конверсии.
Правильнее отправлять trackGoal после success response, после AJAX 200 OK, после успешного сохранения лида либо на thank-you page.
CRM Events — конверсии из CRM
На больших проектах простых фронтенд-конверсий обычно недостаточно, потому что лид может стать продажей через неделю, сделка закрывается в CRM, выручка появляется позже, а часть конверсий вообще происходит офлайн. Именно поэтому Matomo часто интегрируют с CRM: например, с Bitrix24, amoCRM и даже Saby CRM. Сценарий обычно выглядит так:
- Пользователь оставляет заявку.
- Matomo фиксирует lead.
- CRM получает сделку.
- После продажи CRM отправляет conversion event обратно в Matomo.
В результате появляется полноценная сквозная аналитика — от клика до выручки и финальной продажи.
Offline Conversions — офлайн-конверсии
Еще один очень важный сценарий — офлайн-конверсии. Особенно это актуально:
- для B2B,
- медицины,
- недвижимости,
- автодилеров,
- образования,
- ретейла,
- кол-центров.
Потому что пользователь может оставить заявку онлайн, а купить офлайн. Matomo позволяет связывать такие конверсии через Visitor ID, User ID, CRM ID и client identifier. После этого можно догружать офлайн-продажи, связывать их с рекламой, считать реальный ROI и строить полноценную сквозную аналитику.
Почему Goal Tracking намного важнее pageview
На маленьких сайтах можно смотреть посещаемость, pageview, отказы, но для бизнеса этого почти всегда недостаточно, потому что pageview не отвечает на главный вопрос: «Какой трафик приносит деньги?». А вот goals связывают аналитику с выручкой, превращают события в бизнес-метрики, позволяют считать окупаемость, дают нормальную атрибуцию по источникам. По этой причине на крупных проектах именно Goal Tracking обычно становится главным слоем всей аналитики.
На этом этапе мы уже разобрали фундамент JavaScript-аналитики в Matomo: установку кода отслеживания, устройство _paq.push(), отслеживание pageview и событий и работу целей с конверсиями. И на самом деле даже этого уже достаточно, чтобы построить полноценную систему веб-аналитики для большинства сайтов.
Matomo — слишком большая система, чтобы уместить все возможности JavaScript-отслеживания в одну статью, без превращения материала в многотомный фронтенд-справочник. А если попытаться впихнуть сюда еще ecommerce, кросс-доменное отслеживание, SPA-отслеживание, User ID, Custom Dimensions и перформанс-оптимизацию, статья будет огромной. Именно поэтому дальше будем двигаться отдельными частями. В следующих статьях я подробно разберу оставшиеся вопросы.
