Команди зазвичай починають цей перехід із 3 практичних причин: процес звітування здається простішим, змінилися вимоги до приватності або стара конфігурація перетворилася на набір власних правил, які пам’ятає лише одна людина. Якщо це вам знайомо, ви не самі. Обліковий запис Matomo з часом може стати дуже специфічним, і саме цю специфіку люди часто хочуть зберегти, прибравши все зайве.
Секрет у тому, щоб ставитися до цього як до проєкту з аналітики, а не просто як до заміни інструменту. Якщо ви плануєте усі сайти, за які відповідаєте, вести за однаковою логікою вимірювання, для міграції потрібні назви, цифри й письмова послідовність дій. Інакше перший тиждень після запуску ви проведете, з’ясовуючи, чому одна конверсія потрапила в Matomo, але так і не з’явилася в Astrina. Це поганий тиждень.
Тут важлива одна коротка думка: збережіть старі дані в безпеці. І ще одна: не здогадуйтеся. Міграція з Matomo на Astrina працює найкраще, коли ви точно знаєте, що відстежується зараз, що потрібно відтворити та які звіти мають безболісно перейти в нову систему в перший день. Саме тому налаштування аналітики Astrina після Matomo варто планувати як окремий, добре задокументований етап.
1. Чому варто перейти з Matomo на Astrina
Більшість команд переходять не тому, що їм не подобається аналітика. Вони переходять тому, що робочий процес навколо Matomo став важчим за питання, на які треба отримати відповіді. Маркетинг-менеджеру можуть бути потрібні 4 щоденні показники, а не 40 екранів. Розробнику — менше трекерів, які треба підтримувати. Фахівцю з комплаєнсу — інший підхід до згоди, доступу до даних або строків зберігання.
Є ще й аспект звітності. Деякі команди хочуть менше часу в глибоко вкладених меню і більше — в одному дашборді. Якщо це ваш випадок, Astrina може підійти краще, особливо якщо вам зручна конфігурація, у якій одна й та сама структура сайту, звіту та подій зрозуміла більше ніж одній людині. Для агенцій усі клієнтські сайти в одному дашборді можуть зекономити години, які інакше пішли б на перемикання між акаунтами.
Перехід між платформами — це не лише про функції. Це ще й про людей, яким доводиться ними користуватися. Якщо з 12 людей у команді Matomo добре розуміють лише 2, інструмент, ймовірно, робить більше, ніж потрібно команді. Така невідповідність швидко стає дорогою.
2. Перевірте поточну конфігурацію Matomo
Перш ніж щось змінювати, запишіть повний перелік налаштувань Matomo. Почніть із відстежуваних доменів: основний сайт, піддомени, staging і будь-які важливі cross-domain шляхи. Потім перелічіть теги, цілі, власні виміри, події, ролі користувачів та інтеграції. Так, усе. Забутий staging-домен може псувати живу звітність місяцями.
Далі перевірте назви подій. Якщо одна команда використовує “CTA Click”, а інша — “Button Click”, це вже два стандарти трекінгу. Збережіть точні рядки. Те саме стосується цілей, які залежать від URL, часу на сторінці або дій у подіях. Якщо ціль спрацьовує на третьому кроці оформлення замовлення, запишіть точний номер кроку.
Доступ теж має значення. Зафіксуйте, хто може редагувати теги, хто бачить сирі звіти, а хто отримує лише підсумки. Міграція може провалитися на рівні команди задовго до технічного збою. Якщо 1 аналітик і 4 маркетологи залежать від одного облікового запису Matomo, усі мають знати, що зміниться в день запуску.
Інтеграції легко пропустити. Перевірте, чи передає Matomo дані в CRM, рекламні платформи, інструменти згоди або внутрішні дашборди. Якщо звіт щопонеділка експортується в іншу систему, для цього передавання потрібна заміна. Немає передавання — немає довіри.
3. Зіставте звіти та події Matomo з Astrina
Ось тут багато міграцій стають поверхневими. Люди копіюють перегляди сторінок, а потім забувають про бізнес-логіку. Краще заздалегідь зіставити кожен звіт Matomo з тим звітом Astrina, який його замінить, рядок за рядком, ще до встановлення будь-якого скрипта. Якщо звіт Matomo показує трафік за цільовими сторінками входу, вирішіть, який саме показник перегляду сторінок в Astrina буде джерелом істини. Якщо подія Matomo фіксує “Download PDF”, залиште цей напис або інший настільки ж зрозумілий.
Те саме зробіть із конверсіями. Якщо Matomo рахує реєстрацію після сторінки подяки, а Astrina рахуватиме ту саму дію на події надсилання форми, обов’язково відзначте цю різницю в таблиці зіставлення. Саме ця деталь впливає на те, як ви порівнюватимете старі й нові цифри в перші 2 або 3 тижні. Вона також допомагає уникнути паніки, коли в перший день звіти не збігаються ідеально.
Зробіть таблицю простою, щоб її міг прочитати хтось інший. Добрий аркуш зазвичай має 4 колонки: елемент Matomo, значення, заміна в Astrina та примітки. Один рядок на показник. Один рядок на подію. Один рядок на ціль. Якщо згодом команді знову знадобиться, як перейти з Matomo на Astrina для другого сайту, цей аркуш стане шаблоном.
Якщо ви використовуєте Astrina для ширшої роботи із сайтом, корисно тримати поруч і пов’язані довідкові матеріали, наприклад astrina для рішень щодо SEO-орієнтованого трекінгу або структури звітності. Не кожній команді це потрібно в перший день, але дисципліна в назвах дуже добре переноситься далі.
4. Експортуйте потрібні дані та конфігурацію трекінгу
Експортуйте все, що можете, ще до перемикання. Історичні звіти важливі, бо вони показують базову лінію, з якою ви потім порівнюватимете результати. Збережіть останні 12 місяців, якщо можливо, або принаймні ті звітні періоди, які бізнес переглядає найчастіше. Продуктовій команді може знадобитися 90 днів. Контент-команді — 24 місяці. Кількість залежить від циклу перегляду, а не від інструменту.
Документуйте й налаштування. Це означає site ID у Matomo, визначення цілей, категорії подій, власні виміри, фільтри та будь-які сегменти, які використовуються у регулярній звітності. Якщо у вас є звіти за часом, збережіть часовий пояс. Якщо є виключення URL, зафіксуйте точні шаблони. Дрібниці після міграції стають великими речами.
Збережіть копії скриншотів звітів, важливих для керівництва. Діаграма з 6 місяцями трендів легше захищається, ніж усний опис того, що колись відбувалося. Якщо згодом хтось запитає, чому в березні просів трафік, вам потрібні старі докази під рукою.
Деякі команди експортують сирі дані для внутрішнього архіву. Інші документують лише ті звіти, які реально використовуються. Обидва варіанти можуть працювати. Не спрацює лише один підхід: залишити стару конфігурацію без документації й сподіватися, що пам’ять закриє прогалини через шість тижнів.
5. Налаштуйте Astrina та встановіть трекінг
Спочатку створіть обліковий запис Astrina, а потім додайте сайт. Якщо команда керує кількома доменами, використовуйте однакову схему назв для всіх властивостей. “Основний сайт”, “блог” і “чекаут” можуть здаватися очевидними, але очевидні назви допомагають уникати помилок, коли відкрито 8 вкладок і хтось пізно в п’ятницю копіює налаштування.
Установіть трекінг тим способом, який Astrina рекомендує для вашого сайту. Для одних команд це означає додати скрипт у header. Для інших — використати тег-менеджер або інший звичний шлях встановлення. Метод менш важливий, ніж послідовність: один сайт, один перевірений трекер, одне відоме місце для його підтримки. Якщо ви вже ведете документацію в центральному місці, додайте туди примітки щодо встановлення та зберігайте версію фрагмента коду.
Після встановлення перевірте базовий потік переглядів сторінок щонайменше на 3 сторінках: головній, контентній та сторінці конверсії. Така швидка вибірка допомагає виявити багато типових проблем налаштування — від відсутнього скрипта до подвійного завантаження. Якщо якась сторінка виключена в Matomo, перевірте, чи не потрібне таке саме виключення в Astrina до запуску.
Для команд, які порівнюють плани під час налаштування акаунта, astrina допоможе краще обговорити ліміти та зростання. Це корисно, коли потрібно вирішити, переносити 1 властивість зараз чи 5 у межах тієї самої фази.
6. Відтворіть цілі, події та власний трекінг
Відтворюйте елементи вимірювання один за одним. Почніть із цілей, бо вони визначають успіх. Потім перейдіть до відстеження подій, бо назви подій зазвичай найпростіше порівнювати в Matomo та Astrina поруч. Після цього налаштуйте воронки та власні виміри. Така послідовність робить перші звіти зрозумілими.
Якщо Matomo відстежує надсилання форми, відтворіть той самий тригер в Astrina. Якщо Matomo позначає покупку після екрана подяки, вирішіть, чи Astrina має позначати її на фінальному URL, на кліку кнопки чи на серверному підтвердженні. Технічний вибір має відповідати бізнесовому змісту. Це єдине, що справді має значення.
Власні виміри потребують особливої уваги. Поле на кшталт “тип тарифу” або “статус входу в акаунт” може змінити спосіб читання кожного звіту. Якщо Matomo зберігав це поле в одному місці, а Astrina зберігає в іншому, зафіксуйте відповідність із прикладами. Один приклад кращий за 10 розмитих нотаток. Наприклад, “тип тарифу = річний” має означати абсолютно те саме в обох системах.
Коли ви відтворюєте більш складні структури, тримайте список подій коротким. П’ять надійних подій кращі за 15 напіввикористаних. Це також пришвидшує подальшу перевірку. Додати ще завжди можна після першого чистого тижня.
7. Перевірте міграцію перед запуском
Тестування має відбуватися за чеклістом, а не інтуїтивно. Відкрийте сайт у чистому браузері, згенеруйте 3 перегляди сторінок, спрацюйте 2 події та пройдіть 1 шлях конверсії. Потім порівняйте дані Astrina з поведінкою, яку ви очікуєте від Matomo. Якщо є cross-domain трекінг, перевірте і його. Один відсутній linker може зламати весь шлях.
Перевірте фільтри та виключення ще до запуску. Якщо внутрішній трафік був виключений у Matomo, підтвердьте ту саму логіку в Astrina. Якщо staging-домен має не потрапляти в продакшн-звіти, перевірте саме цю умову. Один пропущений фільтр може зробити перший звіт більшим, ніж він має бути.
Допомагають також перевірки на різних пристроях і в різних браузерах. Форма може коректно відправлятися на десктопі й збиватися на мобільному. Подія чекауту може спрацьовувати в Chrome і зависати в Safari. Це дратує, але такі речі видно одразу, якщо перед переключенням протестувати 2 пристрої та 2 браузери.
Якщо ваша команда покладається на сповіщення або щоденні підсумки, вирішіть, чи налаштовувати їх до запуску, чи вже в перший тиждень. Окремий матеріал про те, чи варто обирати чи варто обирати аналітичні сповіщення, може допомогти з цим рішенням.
8. Перемкніть систему, моніторте та виведіть Matomo з використання
Призначте дату перемикання й оголосіть її. Не розмитий період. Саме дату. Якщо маркетинг, продуктова команда і розробка мають оновити посилання або дашборди, вони мають знати точний понеділок або четвер, коли Astrina стане активним джерелом.
У день запуску залиште Matomo працювати для порівняння. Такий період накладання зазвичай короткий, але корисний. Порівнюйте перегляди сторінок, події та конверсії протягом 3–7 днів, а потім шукайте причини будь-яких розбіжностей. Іноді відхилення нормальне: новий фільтр, інший тригер події або зміна способу підрахунку конверсії. Іноді це помилка. У будь-якому разі порівняння покаже, куди дивитися.
Уважно стежте за першими звітами. Перші 24 години часто показують базові речі: загальні перегляди сторінок, найпопулярніші сторінки, обсяг подій і те, чи працює шлях конверсії так, як очікується. Якщо щось виглядає не так, виправте трекінг ще до того, як скажете стейкхолдерам, що дані вже остаточні. Такий порядок економить ніяковість.
Виводьте Matomo з використання лише тоді, коли команда впевнена в Astrina і є задокументована причина перестати приділяти увагу старому акаунту. Деякі організації залишають Matomo у режимі лише для читання як історичне посилання. Інші закривають його після проходження 1 повного звітного циклу. Будь-який варіант підходить, якщо дані заархівовано, таблицю зіставлення збережено, а команда знає, де шукати наступного разу, коли звіт зміниться.
І ще одна практична порада: зберігайте старі скриншоти, таблицю зіставлення та дату запуску разом. Це й є слід доказів. Якщо через шість місяців хтось запитає, чому в другий тиждень змінилася конверсія, відповідь буде в 3 файлах, а не в пам’яті.
