Маркетолог потерял историю аналитики при смене сервиса: своя Matomo

MAATRIX

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

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

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

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

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

Чем это оборачивается на практике для маркетолога

Потеря истории — это не абстрактная неприятность, а вполне конкретные последствия в работе.

Не с чем сравнивать «до и после». Ключевая метрика вашей работы — показать, что изменилось после запуска кампании, редизайна сайта или смены позиционирования. Без непрерывной истории за прошлые периоды такое сравнение превращается в «поверьте на слово» — у вас просто нет данных, к которым можно апеллировать.

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

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

Миграция между инструментами становится рискованной сама по себе. Даже плановый переход с одного облачного сервиса на другой — это окно, в которое старые данные легко потерять или получить в урезанном виде. Каждая такая миграция — риск, который вы несёте не потому что решили сменить инструмент, а потому что инструмент вам это навязал.

В чём разница со своим сервером

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

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

Практический путь — self-hosted аналитика: система сбора и обработки данных о посетителях сайта, которую вы разворачиваете на собственном сервере вместо того, чтобы подключать сторонний облачный скрипт. Одна из самых известных таких систем с открытым исходным кодом — Matomo (бывший Piwik). Она устанавливается на обычный VPS, собирает данные по тому же принципу, что и облачные аналитические сервисы — счётчик на страницах сайта, — но хранит всю историю в базе данных, которая физически находится у вас.

Что даёт своя Matomo, а что нет

Важно сразу быть честным насчёт границ этого решения — иначе ожидания разойдутся с реальностью.

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

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

Как ставить и настраивать Matomo на сервере, подробно разобрано в гайде по установке Matomo на VPS — там пошагово: PHP, база данных, веб-сервер, первичная настройка счётчика. Если после установки что-то работает не так, как ожидалось, отдельная статья разбирает типичные проблемы Matomo и их решения — от белого экрана при установке до того, почему дашборд не обновляется без настроенной архивации по cron.

Сервер под свою аналитику: чего он требует со временем

Здесь стоит понимать динамику, а не только точку старта. В первый месяц Matomo с небольшим трафиком спокойно работает на скромном VPS. Дальше происходит то, ради чего вы вообще это затеяли, — база с историей растёт, и требования к серверу растут вместе с ней.

Практический ориентир по ресурсам:

Точный расчёт памяти под конкретный объём трафика — вопрос индивидуальный и зависит от посещаемости сайтов, которые вы подключаете к счётчику. Логика простая: сервер, который брался «под тест», не всегда тянет тот же инструмент через год, когда он стал основным источником исторической аналитики компании. Разумная стратегия — не экономить на старте на паре гигабайт RAM ради небольшой разницы в цене тарифа: миграция базы с накопленной историей на более мощный сервер — решаемая, но лишняя задача, которой проще избежать заранее.

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

Перенос истории и то, что реальнее восстановить, а что нет

Если вы уже стоите перед фактом — старый сервис аналитики режет доступ к истории, — важно понимать реалистичные границы миграции.

Что переносится без проблем. Если у вас уже есть self-hosted Matomo и вы просто переезжаете на новый сервер — переносится дамп базы данных целиком, вместе со всей накопленной историей визитов и настройками. Это стандартная операция бэкапа и восстановления, а не миграция данных между разными системами, и она не теряет ни одной записи при аккуратном выполнении.

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

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

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

Бэкап — единственная страховка от повторения истории

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

Минимальная разумная схема — регулярный дамп базы данных плюс отдельное хранение конфигурации Matomo:

# дамп базы Matomo с сжатием, ежедневно по cron
mysqldump -u matomo_user -p matomo_db | gzip > /backup/matomo_$(date +%F).sql.gz

# храним конфиг отдельно — токены API, настройки трекера
tar czf /backup/matomo_config_$(date +%F).tar.gz /var/www/matomo/config/

Дампы стоит хранить не только на том же сервере, где крутится сама Matomo, — если диск сервера откажет целиком, локальная копия бэкапа не поможет. Практика инструментов вроде BorgBackup, которые умеют шифровать и дедуплицировать копии при отправке на удалённое хранилище, разобрана в гайде по установке BorgBackup на VPS — подход применим и к базе Matomo, и к остальным данным на сервере.

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

Частые вопросы