Управление сайтами, мультисайтовость и структура проектов в Matomo

Именно от раздела Websites зависит, как будут строиться отчеты, будут ли теряться пользователи между доменами, получится ли нормально масштабировать аналитику и не превратится ли через год ваша установка Matomo в хаотичный набор из сотен идентификаторов сайтов. Эта проблема касается не только крупных проектов: даже обычный интернет-магазин со временем начинает обрастать блогом, help-разделом, checkout-доменом, мобильным приложением, лендингами, CRM или личным кабинетом. И в какой-то момент команда неизбежно задает вопрос: «Это один Website в Matomo или несколько?» Неправильный ответ здесь быстро приводит к сломанной атрибуции, потере сессий, дублям трафика и конфликтам между аналитиками и разработчиками.

Зачем Matomo нужен раздел Websites

В Google Analytics многие привыкли к логике: аккаунт → ресурс → поток данных. В Matomo архитектура устроена иначе: здесь основной сущностью аналитики является Website, который внутри системы называется measurable. Каждый measurable получает собственные:

• Site ID;
• набор доменов;
• настройки tracking;
• контейнеры Tag Manager;
• цели и ecommerce;
• права доступа;
• архивы отчетов.

Именно поэтому архитектура measurable напрямую влияет на качество аналитики. Ошибка в структуре сайтов потом начинает «фонить» буквально во всех отчетах: от attribution до ecommerce.

Причем measurable — это не обязательно именно сайт. В качестве отдельного measurable Matomo может хранить:

• веб-проект;
• мобильное приложение;
• SPA;
• поддомен;
• API;
• агрегированный Roll-Up.

Чем различаются Website, Mobile App и Roll-Up

Классический Website используется для обычных сайтов: интернет-магазинов, блогов, лендингов и корпоративных проектов. Именно такой measurable Matomo предлагает создать сразу после установки системы.

Mobile App — отдельный тип аналитики для мобильных приложений, здесь уже другая логика экранов, сессий и событий. Очень важно не смешивать мобильную и веб-аналитику в одном measurable, иначе позже появляются проблемы с retention, attribution и user flow.

Отдельного внимания заслуживает Roll-Up — одна из самых мощных enterprise-функций Matomo. Она позволяет объединять данные сразу из нескольких measurable в единый отчет. Например, если у компании есть сеть региональных сайтов, десятки лендингов, группа брендов или франшиза. При этом исходные сайты продолжают существовать отдельно, со своими правами и настройками, а руководство получает единый дашборд всей сети.

Почему архитектура сайтов влияет на аналитику

Большинство проблем Matomo начинаются не с кода отслеживания, а именно с неправильной структуры measurable: например, checkout вынесли в отдельный Site ID, блог оставили в основном сайте, а help-систему подключили через другой контейнер Tag Manager. Внешне всё работает, но через несколько месяцев появляются потерянные сессии между доменами, дублирование пользователей, сломанные атрибуции, некорректный прямой трафик. Причем чем крупнее проект, тем дороже потом исправлять архитектуру, потому что Matomo очень глубоко завязан:

• на Site ID;
• cookies;
• cross-domain tracking;
• roll-up aggregation;
• структуру архивов.

Фактически Website в Matomo — это фундамент всей аналитической архитектуры.

Типовые сценарии использования

Самый простой сценарий — один сайт и один measurable. Такой вариант подходит для небольших корпоративных сайтов или лендингов. Но как только появляются поддомены, ситуация усложняется. Иногда их логично хранить как один Website, если нужна единая аналитика пользователей между всеми разделами. В других случаях проекты лучше разделять, особенно если разные команды, разные KPI, отдельные аналитики, независимые ecommerce-отчеты.

Отдельный enterprise-сценарий — Roll-Up аналитика: например, когда компания объединяет десятки региональных сайтов в единый дашборд, но при этом сохраняет отдельную аналитику каждого проекта.

Очень часто встречается и связка Website + Mobile App. Причем сайт, Android и iOS почти всегда лучше хранить как отдельные measurable, потому что мобильная аналитика и веб-аналитика — это две разные вселенные.

Как устроена структура сайтов в Matomo

После первой установки Matomo многим кажется, что раздел Websites — это просто список сайтов с установленными кодами отслеживания. Но внутри система устроена гораздо глубже. 

Site ID — фундамент всей аналитики

Каждый Website в Matomo получает уникальный идентификатор — site_id. Именно этот параметр используется:

• в tracking code;
• API;
• Tag Manager;
• отчетах;
• архивации данных;
• cross-domain tracking.

Фактически Site ID — это главный идентификатор проекта внутри Matomo. Типичный tracking code выглядит как _paq.push(['setSiteId', '3']); где 3 — это и есть Site ID.

Alias URLs и зачем они нужны

По сути, это список дополнительных доменов и поддоменов вроде blog.site.com, shop.site.com, help.site.com, которые Matomo считает частью одного measurable. Если эти домены принадлежат одному проекту и пользователь должен перемещаться между ними без потери сессии, их нужно добавлять в Alias URLs.

Без этого Matomo начинает:

• воспринимать переходы между доменами как referrer;
• дробить сессии;
• создавать ложный direct traffic;
• ломать атрибуции.

Ограничения Matomo Cloud и возможности On-Premise

Здесь начинается одно из главных различий между Cloud- и On-Premise версиями Matomo. В Matomo Cloud часть серверных настроек недоступна:

• нельзя глубоко менять конфигурацию;
• ограничен доступ к инфраструктуре;
• нет полного контроля над cron;
• сложнее управлять очередями и архивами;
• часть enterprise-функций зависит от тарифа.

Для небольших проектов это обычно некритично, но при росте инфраструктуры начинаются ограничения:

• сотни measurable;
• roll-up аналитика;
• сложные multi-domain схемы;
• большие объемы ecommerce;
• кастомные attribution-модели.

Именно поэтому крупные проекты почти всегда переходят на On-Premise, потому что self-hosted Matomo позволяет полностью контролировать архитектуру measurable, управлять производительностью, тонко настраивать archiving, строить собственную аналитическую инфраструктуру. Фактически On-Premise Matomo — это уже полноценная платформа аналитики.

Добавление нового сайта в Matomo

После установки Matomo первый Website обычно создается автоматически. Все measurable управляются через меню Administration → Websites → Manage.

Именно здесь создаются новые сайты, редактируются домены, настраиваются Alias URLs, включается ecommerce, управляются timezone и валюта.

Настройка имени сайта

На крупных инсталляциях Matomo название measurable появляется:

• в roll-up отчетах;
• email-репортах;
• дашбордах;
• API;
• автоматизации.

Именно поэтому лучше сразу использовать понятную структуру именования, например по шаблону RU | Ecommerce, EU | Blog, иначе через пару лет в системе появляются New site, Test 2 и Landing old.

Часовой пояс

Timezone влияет буквально на всю аналитику:

• сессии;
• daily reports;
• атрибуции;
• ecommerce;
• cron archiving.

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

Валюта

Настройка валюты особенно важна для ecommerce-проектов. Она влияет на revenue, ecommerce-отчеты, мультиканальную аналитику и дашборды. Если проект работает в нескольких странах, лучше заранее продумать, будет ли единый measurable или отдельные ecommerce measurable под каждую валюту, потому что смешивать USD, EUR и RUB в одном revenue-report — удовольствие сомнительное.

Ecommerce

Matomo позволяет включать ecommerce прямо на уровне Website. После активации появляются отчеты по продуктам и электронной коммерции, аналитика корзин, брошенные корзины и так далее.

Alias URLs

При создании measurable почти всегда стоит сразу настроить Alias URLs, особенно если используются:

• www / non-www;
• поддомены;
• checkout-домены;
• мультиязычные версии.

Это одна из тех настроек, за которой необходимо тщательно следить и документировать. 

Исключение IP-адресов и параметров URL

Matomo позволяет сразу исключать:

• внутренний трафик;
• IP сотрудников;
• технические параметры URL;
• service query-параметры.

И это крайне желательно делать на старте проекта, потому что иначе тестировщики начинают портить конверсию, разработчики ломают карты кликов, UTM-разметка раздувает количество URL в отчетах. Особенно важно правильно настраивать исключения:

• по fbclid;
• gclid;
• yclid;
• session-параметры;
• service tokens.

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

Как уже сказано выше, когда проект растет, аналитика усложняется. Именно на этом этапе большинство проектов впервые сталкиваются с проблемой отслеживания. Проблема в том, что браузер и Matomo не понимают «бизнес-логику проекта». Для системы site.com, shop.site.com, checkout.site.com — это потенциально три разных сайта, поэтому мультидоменную архитектуру нужно проектировать отдельно.

Cross-domain tracking

Cross-domain tracking нужен, когда пользователь перемещается между несколькими доменами, а вы хотите сохранить единую сессию и одного пользователя. Типичный пример:

site.com → checkout.com

Без cross-domain tracking Matomo воспринимает переход как новый источник трафика. В результате создается новая сессия, пользователь дублируется, оформление заказа начинает считаться как прямой трафик. Особенно больно это бьет по ecommerce.

Например:

1. Реклама привела пользователя.
2. Пользователь перешел на checkout.
3. Заказ оформился.
4. Но revenue ушел в прямой вместо рекламного канала.

Для включения кросс-доменного отслеживания достаточно добавить в трекинг-код следующее:

_paq.push(["setDomains", ["*.domain1.com", "*.domain2.com"]]);

_paq.push(["enableCrossDomainLinking"]);

Tracking across subdomains

С поддоменами ситуация чуть проще, но проблемы возникают те же: например, при переходе blog.site.com → help.site.com Matomo должен понимать, что это один пользователь. Для этого обычно используются Alias URLs, общая cookie domain и единый Site ID.

Cookie domains

Один из самых критичных параметров multi-domain аналитики — cookie domain. Именно cookies позволяют Matomo «узнавать» пользователя между страницами и доменами. Например:

*.site.com

позволяет использовать одну cookie на все поддомены.

Если cookies настроены неправильно, пользователь теряет сессию, появляются новые visit ID, растет прямой трафик, ломаются отчеты. Причем проблема может проявляться не сразу, иногда это обнаруживают только через месяцы после запуска проекта, поэтому не пренебрегайте этим полем. Лучше сразу настроить общую cookie для всех доменов.

Roll-Up measurable

Эта настройка нужна для ответа на вопрос «Как смотреть аналитику сразу по всей экосистеме?». Например, у вас 40 региональных сайтов, сеть франшиз, группа брендов и мультирегиональный ecommerce. Создавать один гигантский Website обычно плохая идея. Именно для этого в Matomo существует Roll-Up measurable: Roll-Up объединяет несколько Website в единый агрегированный measurable, сохраняя при этом отдельную аналитику каждого проекта. По сути, это «виртуальный сайт» поверх остальных measurable.

Roll-Up создается как отдельный measurable в разделе Administration → Websites → Roll-Ups.

Дальше в него добавляются нужные Website. После этого Matomo агрегирует данные, строит общий дашборд, сохраняет отдельные дашборды для каждого сайта и объединяет отчеты. 

Важно: Roll-Up не копирует данные физически. Он работает поверх существующих measurable, поэтому почти всегда легче и безопаснее, чем попытка объединить все сайты в один.

Проблемы дублей и рефереров

Практически все multi-domain ошибки в Matomo сводятся к двум симптомам: дубли пользователей и ложные рефереры. Обычно это выглядит как рост прямого трафика. Почти всегда причина — одна из трех:

• неправильный Site ID;
• не настроены Alias URLs;
• сломанное кросс-доменное отслеживание.

Причем в больших инфраструктурах такие ошибки могут жить годами и незаметно портить всю аналитику.

Дашборд All Websites — центральная панель аналитики

All Websites dashboard — это центр мониторинга всей экосистемы Matomo. Он отображает трафик по всем measurable, динамику пользователей, состояние проектов и многое другое, причем всё в одном интерфейсе. Для крупных инсталляций это буквально «карта состояния бизнеса».

По умолчанию дашборд показывает основные метрики:

• визиты;
• уникальных посетителей;
• события;
• отказы;
• выручку;
• конверсии.

Но главное преимущество — не сами метрики, а возможность быстро находить аномалии, например внезапное падение трафика или просадку конверсии. Благодаря этому на больших проектах All Websites часто используется как дашборд мониторинга здоровья аналитики.

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

Отдельные дашборды под разные сайты

Когда measurable в Matomo становится много, очень быстро выясняется, что одного дашборда на всех уже недостаточно. Маркетологам нужны трафик, кампании и воронки, выручка по каналам, а руководству — вообще один All Websites дашборд по всей группе сайтов. Именно поэтому дашборды в Matomo легко конфигурируются и их можно создавать сколько угодно.

Создание дашбордов под конкретный Website

В Matomo дашборды можно создавать отдельно под каждый measurable. 

Дашборды создаются через Dashboard → Create new dashboard. После этого можно:

1. Выбрать Website.
2. Добавить нужные widgets.
3. Настроить layout.
4. Сохранить как default dashboard.

Виджеты (Widgets)

Вся логика дашбордов в Matomo строится вокруг виджетов. Причем widgets здесь намного ближе к BI-подходу, чем к классической веб-аналитике. На дашборд можно выводить:

• трафик;
• ecommerce;
• воронки;
• карты кликов;
• цели;
• пути пользователей;
• источники;
• аналитику по кампаниям;
• кастомные отчеты.

Именно благодаря widgets Matomo хорошо масштабируется. Важный момент в том, что виджеты привязаны к measurable, поэтому при неправильной архитектуре дашборд может быстро превратиться в хаос.

Отслеживание разделов сайта как разных сайтов

Одна из самых сильных возможностей Matomo — отслеживание отдельных разделов одного домена как независимых measurable. Именно здесь Matomo сильно отличается от «классических счетчиков».

Tracking subfolders

В Matomo отдельным сайтом можно сделать не только домен, но и отдельную директорию: например, site.com/finance/ и site.com/law/. С технической точки зрения это один домен, один сервер, одна инфраструктура, но для аналитики — уже три независимых measurable. 

Разделение бизнес-юнитов

На крупных проектах отслеживание подпапок часто используется для разделения бизнес-юнитов: например, внутри одной платформы могут жить бухгалтерия, CRM, HR, маркетинг и обучение. Формально это один продукт, но аналитически это уже разные проекты. И здесь Matomo позволяет разделять права, строить отдельные дашборды и использовать отдельные воронки. Очень часто именно так строится аналитика SaaS-платформ, маркетплейсов, enterprise-порталов и суперприложений.

Заключение

Чем дольше работаешь с Matomo, тем сильнее понимаешь, что это уже давно не просто альтернатива Google Analytics. Matomo постепенно превращается в полноценную self-hosted платформу аналитики, где сайты — это отдельная аналитическая сущность: дашборды работают как mini-BI, Roll-Up позволяет строить аналитическую платформу enterprise-уровня. И именно поэтому архитектура measurable здесь настолько важна.

Чем Matomo отличается от GA4

Главное отличие Matomo от GA4 — контроль над архитектурой: в GA4 многое скрыто, в Matomo вся аналитическая система находится под контролем владельца. А On-Premise версия Matomo дает вообще полный контроль над аналитической инфраструктурой — это означает собственный сервер, собственную базу данных, собственные очереди, полный доступ к config.ini.php, управление производительностью, возможность строить кастомную архитектуру measurable. Фактически Matomo On-Premise — это уже отдельный analytics backend внутри компании.

Рекомендации по архитектуре

Если обобщать опыт production-инсталляций Matomo, то почти всегда хорошо работают несколько правил: 

1. Архитектурные measurable нужно проектировать заранее.
2. Мобильные приложения, ecommerce и крупные бизнес-юниты лучше разделять на отдельные measurable.
3. Roll-Up почти всегда лучше, чем попытка запихнуть всю экосистему в один сайт.