MainWP Google Analytics - Плагин WordPress

Руководство по настройке MainWP Google Analytics для агентского контроля GA4 в WordPress

MainWP Google Analytics полезен не как очередной способ вставить счетчик на сайт, а как рабочий слой над уже настроенной аналитикой: он подтягивает данные GA4 в MainWP Dashboard, помогает переключаться между дочерними сайтами, смотреть ключевые метрики и включать аналитику в регулярные отчеты для клиентов. В этом руководстве разберем путь от проверки готовности до диагностики ошибок, чтобы расширение не осталось "еще одной вкладкой" в админ-панели.

Материал рассчитан на владельцев нескольких WordPress-сайтов, веб-студии, специалистов поддержки и администраторов, которые уже используют MainWP Dashboard и хотят видеть данные Google Analytics без постоянного входа в разные аккаунты GA4. Отдельно подчеркнем важное ограничение: расширение читает данные из Google Analytics, но не устанавливает код отслеживания на дочерние сайты. Код GA4 должен быть добавлен заранее через Site Kit, Google Tag Manager, тему, отдельный плагин или другой выбранный вами способ.

Ниже будут установка, выбор способа подключения, настройка сервисного аккаунта, ручное сопоставление GA4-свойств с дочерними сайтами, настройка виджетов, проверка данных, пример использования в агентском процессе, частые ошибки и похожие решения. Если вы только выбираете инструмент, читайте разделы про ограничения и альтернативы до установки - они помогут понять, подходит ли MainWP Google Analytics именно вашему процессу.

Какую задачу решает расширение в экосистеме MainWP

MainWP работает по модели центральной панели: отдельный WordPress-сайт с MainWP Dashboard управляет дочерними WordPress-сайтами через MainWP Child. MainWP Google Analytics добавляет к этой панели аналитический слой. Вместо того чтобы открывать Google Analytics, выбирать нужный аккаунт, искать свойство, затем повторять это для следующего клиента, администратор видит сводные показатели прямо в привычной панели обслуживания.

Это особенно заметно в агентской работе. Сайтов может быть много, у каждого клиента может быть свой Google-аккаунт, разные GA4-свойства и разные ожидания от отчетов. Расширение закрывает не всю аналитику, а конкретный ежедневный сценарий: быстро понять, есть ли трафик, какие страницы смотрят, откуда идут сессии, какие устройства и страны заметны в данных. Для глубокого анализа событий, воронок и рекламной атрибуции Google Analytics все равно остается основным инструментом.

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

Смысл расширения не в том, чтобы заменить GA4. Его роль другая: сделать аналитику частью регулярного обслуживания WordPress-сети. Если утром вы открываете MainWP, проверяете обновления, резервные копии, уязвимости и отчеты, то рядом с этим можно увидеть базовую динамику трафика без отдельного обхода Google Analytics.

Ключевая проверка перед стартом: если на дочернем сайте нет корректно установленного GA4-кода, MainWP Google Analytics не начнет собирать данные сам. Сначала убедитесь, что GA4 уже получает события на стороне сайта, затем подключайте расширение к этим данным.

Кому расширение подходит, а кому лучше выбрать другой подход

MainWP Google Analytics сильнее всего раскрывается там, где у администратора уже есть несколько сайтов в MainWP и повторяющаяся задача контроля. Для одного небольшого сайта установка отдельного MainWP Dashboard только ради просмотра GA4 обычно избыточна. Но если MainWP уже является центром обслуживания, аналитическое расширение становится логичным продолжением панели.

Подходящие сценарии

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

• У агентства есть несколько дочерних сайтов в MainWP, и администратор хочет видеть базовую аналитику в одном месте.
• Для клиентов готовятся регулярные отчеты, где нужны показатели Google Analytics через токены Pro Reports.
• Нужно подключать несколько Google Analytics аккаунтов или GA4-свойств и сопоставлять их с разными сайтами.
• Команда поддержки хочет быстро проверить, изменилась ли посещаемость после обновления темы, плагинов, шаблонов или структуры страниц.
• Владелец сети сайтов хочет не глубокую рекламную аналитику, а оперативный обзор посещаемости и источников.

Когда инструмент может быть лишним

Если у вас один сайт, нет MainWP Dashboard или весь анализ уже построен в Looker Studio, BigQuery, Google Analytics Exploration и рекламных кабинетах, расширение не заменит эту инфраструктуру. Оно также не подойдет как самостоятельный способ внедрения трекинга, потому что не вставляет GA4-тег в дочерние сайты. Для этого нужны Site Kit, Google Tag Manager, ручная вставка кода или другой плагин.

Еще один случай - строгие требования к конфиденциальности. Google Analytics связан с обработкой пользовательских данных, а MainWP только показывает уже полученные GA4-данные. Если проект принципиально отказывается от Google Analytics, лучше смотреть в сторону Fathom, Matomo или Independent Analytics, а не пытаться использовать MainWP Google Analytics как "более приватную оболочку" над Google.

Что проверить перед установкой на Dashboard-сайте

Главная ошибка при установке аналитических расширений - начинать с кнопки установки, не проверив окружение. В MainWP Google Analytics зависимостей больше, чем у простого визуального плагина: нужен MainWP Dashboard, подключенные дочерние сайты, рабочая GA4-аналитика на этих сайтах, доступ к Google-аккаунту или сервисному аккаунту, а также серверные функции PHP.

Проверка MainWP Dashboard и дочерних сайтов

Установите расширение только на сайт, где работает MainWP Dashboard. Документация MainWP отдельно подчеркивает, что add-ons ставятся на Dashboard-сайт, а не на дочерние сайты. На дочерних сайтах должен быть MainWP Child, нормальное соединение с Dashboard и уже установленный способ отправки данных в GA4.

Перед установкой пройдите короткий чек-лист:

• Dashboard-сайт работает на отдельной WordPress-установке, а не на перегруженном рабочем сайте клиента.
• Дочерние сайты видны в MainWP > Sites > Manage Sites и успешно синхронизируются.
• GA4-свойства созданы для нужных сайтов, а код отслеживания уже установлен и дает данные в Google Analytics.
• У администратора есть доступ к Google Analytics на уровне аккаунта или конкретных свойств, которые нужно подключить.
• Для JSON-подключения понятна политика хранения ключа: кто создает сервисный аккаунт, где хранится JSON-файл и кто имеет право его заменить.

Серверные требования и функции PHP

В актуальной документации MainWP для Google Analytics указаны требования к PHP на Dashboard-сайте и обязательные функции для работы расширения. Отдельно упоминаются bccomp, putenv и getmypid. Если хостинг отключил одну из них, данные могут не подтягиваться или подключение может вести себя нестабильно.

Для администратора это означает простую практику: перед подключением Google Analytics откройте информацию о сервере в MainWP, проверьте предупреждения и заранее уточните у хостинга, не отключены ли нужные функции. На небольшом количестве сайтов это может не проявиться сразу, но при автоматическом обновлении данных и отчетах проблема быстро станет регулярной.

Не храните JSON-ключ сервисного аккаунта в общих папках, переписках и задачниках. Это учетные данные для доступа к аналитике. Используйте защищенное хранилище команды и удаляйте старые ключи после ротации.

Установка расширения и первая проверка в MainWP

Установка зависит от того, как у вас организованы MainWP add-ons. Официальная документация описывает несколько путей: через MainWP > Add-ons > Manage Add-ons, через обычную загрузку ZIP в WP Admin > Plugins > Add New или вручную. Для обычной работы удобнее использовать интерфейс Manage Add-ons, потому что там проще найти интеграцию, установить ее на Dashboard-сайт и активировать лицензию для обновлений.

Базовый порядок установки

1. Откройте Dashboard-сайт, на котором уже установлен MainWP Dashboard.
2. Перейдите в MainWP > Add-ons > Manage Add-ons.
3. Найдите Google Analytics среди интеграций и установите расширение.
4. Активируйте расширение и убедитесь, что оно появилось в меню MainWP > Add-ons.
5. Если для обновлений требуется license/API key MainWP, проверьте статус активации в карточке расширения.

После установки не спешите подключать все аккаунты. Сначала откройте страницу расширения и убедитесь, что она загружается без ошибок, что вкладки Add Account, Manage Accounts, Visitor Data и настройки доступны. Если страница пустая, появляется критическая ошибка PHP или админ-панель зависает, проблему лучше решать до загрузки Google-ключей.

Первичный тест без риска для клиентских данных

Выберите один сайт, где GA4 точно работает и где вы можете быстро проверить данные в analytics.google.com. Это будет контрольный сайт. Подключите сначала один аккаунт или одно свойство, сопоставьте его с этим дочерним сайтом и нажмите Refresh Data. Только после успешной проверки масштабируйте процесс на остальные сайты.

Такой подход экономит время. Если ошибку вызывает закрытый REST API, неверный JSON, недоступная PHP-функция или отсутствие прав Viewer в GA4, вы обнаружите это на одном тестовом сайте, а не после массового подключения всей клиентской сети.

Выбор способа подключения: Sign In with Google или Service Account JSON

В актуальной документации MainWP Google Analytics описаны два способа подключения: вход через Google и импорт JSON-файла сервисного аккаунта. Оба могут использоваться в одной установке, но для разных команд подходят разные сценарии. Выбор влияет на поддержку, безопасность, ротацию доступа и поведение при ограничениях хостинга.

Вход через Google

Путь через Sign In with Google удобен, когда Dashboard-сайт доступен извне, REST API не заблокирован и команда хочет меньше работать с Google Cloud Console. В MainWP это делается через MainWP > Add-ons > Google Analytics > Add Account: администратор выбирает вкладку входа, проходит авторизацию, выбирает аккаунты или проекты и подтверждает соединение.

Этот путь использует MainWP Bridge для безопасного процесса авторизации. Из-за этого есть важное практическое условие: если Dashboard-сайт закрыт HTTP basic auth, спрятан за дополнительной защитой или блокирует /wp-json/, процесс может не пройти. В документации MainWP для ошибки site secret not found прямо указана связь с недоступным или заблокированным REST API.

Когда выбирать Sign In with Google

• Dashboard-сайт доступен по нормальному публичному URL.
• REST API WordPress не отключен и не режется security-плагином.
• Команде проще управлять подключением через Google-аккаунт, чем через сервисные ключи.
• Нужно быстро подключить несколько аккаунтов без отдельной настройки Google Cloud проекта.

Сервисный аккаунт и JSON-файл

Путь через JSON подходит для более контролируемой инфраструктуры. Сначала в Google Cloud Console включаются необходимые API: Google Analytics Admin API, Google Analytics API и Google Analytics Data API. Затем создается сервисный аккаунт, скачивается JSON-ключ, а email сервисного аккаунта добавляется в Google Analytics с ролью Viewer на уровне аккаунта или конкретного GA4-свойства.

После этого JSON загружается в MainWP > Add-ons > Google Analytics > Add Account > Import JSON File. Если доступ выдан на уровне всего GA-аккаунта, сервисный аккаунт видит все свойства внутри него. Если доступ выдан на уровне отдельных свойств, шаг с добавлением email нужно повторить для каждого свойства. Это дольше, зато удобнее для клиентов, где нельзя давать доступ ко всей аналитической структуре.

Когда выбирать JSON

• Dashboard-сайт закрыт дополнительной авторизацией, и Sign In with Google не проходит.
• Нужно строго ограничить доступ к отдельным GA4-свойствам.
• Команда ведет учет сервисных ключей и умеет их ротировать.
• Один сервисный аккаунт должен обслуживать несколько клиентских свойств с ролью Viewer.

Нельзя сказать, что один путь всегда лучше. Для малого агентства вход через Google проще. Для более строгого обслуживания с разделением клиентов и доступов JSON часто понятнее. Главное - не смешивать их хаотично. Ведите таблицу подключений: какой сайт сопоставлен с каким GA4-свойством, каким методом подключен аккаунт, кто отвечает за восстановление доступа и когда ключ был заменен.

Сопоставление GA4-свойств с дочерними сайтами

После подключения аккаунта расширение должно понять, какое GA4-свойство относится к какому дочернему сайту в MainWP. По документации add-on умеет автоматически назначать свойства на основе совпадения URL, но в реальной сети сайтов автоматическое сопоставление стоит воспринимать как ускорение, а не как гарантию. Домены могут быть с www и без него, с разными протоколами, временными доменами, редиректами, staging-сайтами и отдельными property для поддоменов.

Как выполнить ручное назначение

Если автоматическое назначение не сработало или вы хотите проверить результат, откройте MainWP > Sites > Manage Sites, выберите нужный дочерний сайт и перейдите на страницу его настроек. В блоке Google Analytics выберите соответствующее GA4-свойство и сохраните настройки. После этого вернитесь в страницу данных расширения и выполните обновление.

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

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

Перед массовым назначением подготовьте простую таблицу соответствий. В ней достаточно колонок: клиент, домен, MainWP child site, GA4 property name, GA4 property ID, метод доступа, ответственный. В самой статье мы не указываем ваши ID, но в рабочем процессе они нужны. Когда у клиента возникает вопрос "почему в отчете мало трафика", такая таблица помогает быстро понять, не подключили ли вы пустое свойство, старый домен или тестовую версию сайта.

После сохранения назначения проверьте три вещи:

• На странице Visitor Data выбран правильный child site.
• Данные в MainWP совпадают по смыслу с соответствующим GA4-свойством за тот же период.
• В отчете клиента используются токены того сайта, который действительно сопоставлен с нужным GA4-property.

Мини-итог: подключение аккаунта еще не означает корректную аналитику. Рабочим результатом считается связка "дочерний сайт - правильное GA4-свойство - обновленные данные - проверенный отчет".

Visitor Data, виджеты и Page Settings: как читать данные без лишнего шума

После успешного подключения и назначения свойств основной рабочей зоной становится MainWP > Add-ons > Google Analytics > Visitor Data. Там администратор может выбрать дочерний сайт и смотреть набор виджетов. В документации указано, что виджеты можно включать и выключать через Page Settings, а также переставлять. Это не косметика, а важный способ сделать панель пригодной для регулярной работы.

Какие метрики смотреть первыми

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

Метрики устройств и стран полезны, когда сайт работает на локальный рынок или когда после редизайна появились жалобы на мобильный трафик. Среднее время вовлечения помогает увидеть не абсолютную "успешность", а изменение поведения: если после обновления шаблона или формы показатель резко меняется, стоит проверить страницы вручную.

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

Для технической поддержки достаточно компактной панели: пользователи, просмотры, источники, страницы, устройства. Для маркетолога полезно добавить страны и новые пользователи. Для менеджера клиентских отчетов важнее видеть графики, которые затем попадут в Pro Reports. Не пытайтесь включить все блоки для всех пользователей - перегруженная панель быстро перестает быть рабочим инструментом.

Используйте такой подход:

1. Оставьте на обзорной панели только виджеты, которые помогают принять действие.
2. Спрячьте редко используемые блоки через Page Settings, но не удаляйте саму связь с GA4.
3. Проверяйте спорные данные в Google Analytics, если по ним будет приниматься бизнес-решение.
4. Для каждого клиента зафиксируйте, какие метрики действительно важны в регулярном отчете.

Настройки обновления данных и связка с клиентскими отчетами

В разделе Settings & Data Refresh у расширения есть несколько параметров, которые напрямую влияют на удобство: интервал графиков, автоматическое получение данных, частота обновления и ручная кнопка Refresh Data. Важно не воспринимать их как "включить все на максимум". Чем больше сайтов, тем осознаннее нужно выбирать частоту обновления, потому что Dashboard-сервер выполняет запросы к внешним API и хранит результаты для отображения.

Интервал графиков

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

Автоматическое обновление

Параметр Fetch Google Analytics data automatically включает плановое обновление данных. Его стоит включать, когда виджеты и отчеты действительно используются. Если расширение установлено "на будущее", но никто не читает данные, автоматическое обновление только создает лишнюю работу для Dashboard-сайта и API.

Ручная кнопка Refresh Data полезна после переподключения аккаунта, замены JSON-ключа, ручного назначения GA4-свойства или исправления ошибки с REST API. После любого такого изменения сначала обновите данные вручную, затем уже оценивайте, нужно ли менять расписание.

Pro Reports и токены Google Analytics

Если вы используете Pro Reports, данные Google Analytics можно подставлять в шаблоны отчетов через токены. В документации MainWP перечислены токены вида [ga.visits], [ga.pageviews], [ga.bounce.rate], [ga.avg.time], [ga.new.visits], [ga.visits.chart] и другие. Это удобно, но требует дисциплины: токены показывают то, что доступно расширению по выбранному сайту и диапазону, поэтому неверное сопоставление property сразу портит отчет.

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

Как встроить аналитику в регламент обслуживания WordPress-сети

Расширение начинает приносить пользу не в момент установки, а когда становится частью повторяемого регламента. У многих команд MainWP уже используется для обновлений, резервных копий, мониторинга доступности, проверки безопасности и клиентских отчетов. MainWP Google Analytics добавляет к этому еще один слой: после технического действия можно не только убедиться, что сайт открылся, но и посмотреть, не сломалась ли измеряемая активность.

Хороший регламент не требует смотреть все виджеты каждый день. Он разделяет ситуации по глубине проверки. После небольшого обновления плагинов достаточно открыть несколько приоритетных сайтов и проверить общую активность. После редизайна, смены темы, внедрения cookie-banner, изменения формы заявки или переноса домена нужен более подробный контроль: GA4, публичная часть, источники, важные страницы и отчетные токены.

Ежедневный обзор

Ежедневный сценарий должен быть быстрым. Администратор открывает MainWP Dashboard, проверяет технические предупреждения, затем смотрит Google Analytics виджеты по сайтам, где недавно были изменения. Цель - найти аномалию, а не провести маркетинговый анализ. Если трафик обычный, источники не пропали, важные страницы получают просмотры, а виджеты обновляются, сайт уходит из списка внимания.

Для этого режима удобно держать короткий набор вопросов:

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

Недельная проверка качества данных

Раз в неделю полезно смотреть не только технические ошибки, но и качество цепочки измерения. Откройте несколько сайтов из разных типов: корпоративный сайт, блог, магазин, локальный лендинг. Сверьте MainWP с Google Analytics, убедитесь, что выбран один и тот же период, и проверьте, что отчетные токены не возвращают пустые значения. Такая проверка быстро обнаруживает проблему, которую ежедневный обзор может пропустить: сайт работает, но аналитика ушла в старое property или cookie-banner перестал пропускать события.

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

Проверка после крупных изменений

После переноса домена, смены темы, установки нового способа отслеживания или перехода на другой cookie-инструмент проверяйте аналитику как отдельный пункт релиза. В MainWP это удобно фиксировать в регламенте: изменение выполнено, кеш очищен, публичная часть проверена, GA4 получает события, MainWP обновил данные, Pro Reports токены не пустые. Если один из пунктов не прошел, отчет клиенту лучше не отправлять до выяснения причины.

Практическое правило: чем ближе изменение к публичной части сайта, тегам, кешу, cookie-согласию и URL-структуре, тем внимательнее проверяйте GA4 и сопоставление property в MainWP.

Документация подключений: что записывать, чтобы не потерять контроль

Когда подключен один сайт, настройки можно помнить. Когда сайтов больше десяти, память становится источником ошибок. MainWP Google Analytics особенно чувствителен к путанице в доступах: Google-аккаунты, сервисные аккаунты, property, домены, staging, разные клиенты и отчетные шаблоны легко смешиваются. Поэтому лучше сразу завести внутренний реестр подключений.

Это не должна быть сложная база данных. Достаточно таблицы в закрытом рабочем пространстве команды. Главное - не хранить в ней сам JSON-ключ и секреты. В таблице должны быть только сведения, которые помогают понять, как восстановить связь и кто за нее отвечает.

Такой реестр особенно полезен при увольнении сотрудника, передаче клиента, ротации сервисного ключа или смене Google-аккаунта владельца. Вместо того чтобы искать в переписке, "какой JSON мы загружали", команда видит метод подключения и понимает, какие действия нужны: выдать Viewer новому сервисному аккаунту, загрузить свежий JSON, переподключить Sign In account или просто обновить данные.

Как работать с клиентскими доступами

Если клиент владеет Google Analytics аккаунтом, лучше не просить у него пароль. Попросите добавить нужный Google-аккаунт или service account email с минимально достаточной ролью. Если доступ нужен только к одному сайту, property-level доступ обычно аккуратнее, чем доступ ко всему аккаунту. Если у клиента много сайтов в одном GA-аккаунте и все они обслуживаются вашей командой, account-level доступ может быть удобнее, но решение должно быть осознанным.

После завершения обслуживания не забывайте закрывать доступы. MainWP Dashboard может оставаться у агентства, но Google Analytics принадлежит клиенту. В нормальном offboarding-процессе нужно отключить сервисный аккаунт, удалить лишних пользователей из GA4 и зафиксировать, какие отчеты были переданы.

Практический пример: утренняя проверка агентства после обновлений

Представим типовую задачу: агентство обслуживает 18 WordPress-сайтов в MainWP, обновления плагинов выполняются по регламенту, а утром специалист поддержки проверяет, не пострадали ли ключевые клиентские сайты. MainWP Google Analytics в этом сценарии не заменяет тестирование страниц, но дает ранний сигнал: где трафик резко просел, где изменилась доля устройств, где после обновления важная страница перестала получать просмотры.

Цель

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

Подготовка

• Все сайты подключены к MainWP Dashboard и синхронизируются.
• GA4-код установлен на дочерних сайтах и проверен в Google Analytics.
• Google Analytics аккаунты подключены к расширению через вход Google или JSON.
• Для каждого сайта выбрано правильное GA4-свойство в настройках child site.
• На странице Visitor Data включены виджеты просмотров, пользователей, страниц и источников.

Шаги проверки

1. Откройте MainWP > Add-ons > Google Analytics > Visitor Data.
2. Выберите первый сайт из списка и нажмите Refresh Data, если данные могли устареть после переподключения.
3. Сравните текущую динамику с обычным диапазоном для этого сайта. Не ищите идеального совпадения с прошлым периодом - ищите резкие провалы и странные всплески.
4. Откройте виджет страниц и посмотрите, не исчезла ли важная посадочная страница из просмотров.
5. Проверьте источники сессий. Если исчез органический или рекламный источник, это повод открыть GA4 и Search Console.
6. Повторите проверку для сайтов, где были обновления темы, кеша, форм, SEO-плагинов или скриптов аналитики.

Ожидаемый результат

В конце проверки у специалиста должен быть не "отчет ради отчета", а короткий список действий: какие сайты без аномалий, какие требуют ручного просмотра, какие нужно проверить в GA4, где возможен конфликт кеша, тега или доступа. Для клиента это превращается в спокойное объяснение: обновления выполнены, аналитика доступна, подозрительные изменения проверены.

Нюанс, который часто мешает

Данные Google Analytics не всегда появляются мгновенно, а блокировщики рекламы, согласие на cookies и дубли GA4-тегов могут менять картину. Если MainWP показывает меньше данных, чем ожидалось, сначала проверьте не расширение, а саму цепочку измерения: установлен ли тег, нет ли дублей, не блокируется ли скрипт, поступают ли события в GA4, выбран ли тот же период.

Как проверять результат после настройки

Проверка результата нужна не только после первой установки. Ее стоит повторять после обновления расширения, изменения способа подключения, ротации JSON-ключа, смены домена, переезда сайта, установки cookie-banner, настройки кеша или перехода на другой способ вставки GA4-тега.

Проверка на стороне Google Analytics

Откройте нужное GA4-свойство и убедитесь, что оно получает данные от сайта. Для быстрой проверки используйте режим реального времени или стандартные отчеты за недавний период. Если в Google Analytics нет данных, MainWP тоже не сможет показать корректную картину. В этом случае проверяйте установку тега, согласие на cookies, фильтры, блокировки и дублирующие плагины.

Проверка на стороне MainWP

В MainWP проверьте четыре уровня:

• Аккаунт подключен. В Manage Accounts нет статуса disconnected или требования переподключения.
• Сайт сопоставлен. В настройках child site выбран правильный Google Analytics property.
• Данные обновлены. После Refresh Data виджеты не остаются пустыми без объяснимой причины.
• Отчет читает те же данные. Токены Pro Reports соответствуют выбранному сайту и периоду.

Проверка публичной части сайта

Так как расширение не вставляет код отслеживания, проверка публичной части остается на вас. Откройте страницу сайта в приватном окне, примите или отклоните cookie-согласие в соответствии с вашей политикой, проверьте наличие GA4-запросов через инструменты браузера или выбранный отладчик тегов. Если используется кеш, очистите его после изменения способа вставки кода. Если установлен не один аналитический плагин, убедитесь, что они не добавляют один и тот же тег дважды.

Нормальная проверка результата: GA4 получает данные, MainWP показывает данные по тому же сайту, виджеты обновляются, отчетные токены заполняются, а публичная часть сайта не содержит дублирующих тегов.

Ограничения, приватность и безопасная эксплуатация

MainWP Google Analytics работает с данными стороннего сервиса, поэтому у него есть не только технические, но и организационные ограничения. Не стоит обещать клиенту, что установка расширения улучшит SEO, ускорит сайт или сделает аналитику "точнее". Расширение помогает читать и показывать данные. Качество данных зависит от GA4-настройки, согласия пользователей, корректности тега, блокировщиков, фильтров, доменной структуры и доступа.

Расширение не добавляет код отслеживания

Это нужно повторить отдельно, потому что именно здесь часто возникает путаница. MainWP Google Analytics не устанавливает GA4-код на дочерние сайты. Если клиент спрашивает, почему после установки в MainWP нет статистики, ответ начинается не с MainWP, а с проверки установки Google Analytics на самом сайте. Для вставки тега используйте инструмент, который соответствует вашей политике: Site Kit, Google Tag Manager, ручной код в теме или специализированный плагин.

Доступы должны быть минимально достаточными

Для сервисного аккаунта документация MainWP описывает роль Viewer. Это разумная базовая модель: расширению нужно читать данные, а не управлять настройками GA4. Если клиент дает доступ вручную, лучше выдавать его на уровне конкретного свойства, когда это возможно, особенно если в одном Google Analytics аккаунте много проектов разных владельцев.

Приватность и согласия

Google Analytics может требовать юридической и технической настройки согласия в зависимости от аудитории сайта и применимых правил. MainWP не решает этот вопрос за сайт. Если на проекте используется cookie-banner, consent mode или региональные ограничения, проверяйте, как они влияют на данные. В отчетах лучше не обещать абсолютную точность, а объяснять, что данные аналитики отражают измеряемую часть поведения пользователей.

Производительность Dashboard-сайта

Расширение тянет данные из внешнего API и показывает их в виджетах. Для небольшой сети это обычно не проблема, но в больших сетях не стоит включать слишком частое обновление без причины. Если Dashboard расположен на слабом shared-хостинге, проверьте системные требования MainWP, лимиты памяти и время выполнения. При росте сети лучше переносить Dashboard на более подходящую инфраструктуру, чем искать проблему в каждом отдельном add-on.

Почему данные не появляются и как искать причину

Диагностика MainWP Google Analytics должна идти по цепочке: сайт отправляет данные в GA4, Google-аккаунт или сервисный аккаунт имеет доступ, MainWP подключен к аккаунту, child site сопоставлен с property, Dashboard может обновить данные. Если перескакивать через шаги, легко лечить не ту проблему.

Sign In with Google показывает site secret not found

Симптом: процесс входа через Google не завершается, появляется сообщение про отсутствующий site secret или соединение не регистрируется.

Возможная причина: WordPress REST API на Dashboard-сайте заблокирован, фильтруется security-плагином, закрыт HTTP basic auth или недоступен по /wp-json/. Документация MainWP связывает эту ошибку именно с доступностью стандартного REST API endpoint и MainWP Bridge.

Что проверить: доступность Dashboard-сайта извне, правила security-плагинов, ограничения хостинга, HTTP basic auth, доступ к /wp-json/.

Как исправить: разрешите REST API для Dashboard-сайта и повторите подключение. Если HTTP basic auth нужен постоянно, используйте импорт JSON-файла вместо входа через Google.

Когда откатить: если для безопасности Dashboard должен оставаться закрытым и исключение для Bridge недопустимо, не ослабляйте защиту ради удобства. Перейдите на JSON-подключение.

JSON загружен, но аккаунт остается disconnected

Симптом: JSON-файл принимается, но в MainWP аккаунт не подключается или данные не загружаются.

Возможная причина: сервисный аккаунт отключен, ключ был удален или повернут, в Google Analytics не добавлен email сервисного аккаунта, роль не дает доступа к нужному свойству, не включены нужные API в Google Cloud Console.

Что проверить: статус сервисного аккаунта в Google Cloud, наличие JSON key, включение Google Analytics Admin API, Google Analytics API и Google Analytics Data API, роль Viewer в GA4 на уровне аккаунта или property.

Как исправить: включите сервисный аккаунт, создайте новый JSON key, добавьте email сервисного аккаунта в GA4 с ролью Viewer и загрузите новый JSON в MainWP.

Когда откатить: если ключ был создан не тем проектом или попал в общий доступ, удалите его в Google Cloud и создайте новый по нормальному процессу.

Свойство GA4 не видно для нужного сайта

Симптом: аккаунт подключен, но нужное GA4-свойство не выбирается или не сопоставляется с child site.

Возможная причина: у подключенного Google-аккаунта нет доступа к property, сервисный аккаунт добавлен только к другому свойству, домен отличается от URL child site, либо property еще не подтянулось после изменения доступа.

Что проверить: доступы в Google Analytics, точный property name и property ID, совпадение домена, наличие старых и новых доменов, ручное назначение в настройках child site.

Как исправить: выдайте доступ к нужному property, затем обновите данные и вручную выберите property в настройках сайта MainWP.

Когда откатить: если вы случайно выбрали property другого клиента, немедленно исправьте сопоставление и пересоздайте клиентский отчет.

Виджеты пустые, хотя GA4 работает

Симптом: в Google Analytics данные есть, но в MainWP Visitor Data виджеты пустые или не обновляются.

Возможная причина: устаревшее подключение, требуется Refresh Data, отключены нужные виджеты в Page Settings, выбран не тот child site, отключены PHP-функции bccomp, putenv или getmypid.

Что проверить: статус аккаунта в Manage Accounts, видимость виджетов, выбор сайта, логи MainWP, системные требования Dashboard-сервера.

Как исправить: переподключите аккаунт, нажмите Refresh Data, включите виджеты, попросите хостинг включить недостающие PHP-функции или перенесите Dashboard на подходящий сервер.

Когда откатить: если проблема появилась после обновления расширения, временно отключите автоматическое обновление данных и проверьте changelog и поддержку MainWP перед массовыми действиями.

Данные в MainWP и GA4 отличаются

Симптом: числа в MainWP не совпадают с тем, что пользователь видит в Google Analytics.

Возможная причина: разные диапазоны дат, разные метрики, задержка обновления, фильтры в GA4, согласия пользователей, блокировщики, дубли тегов, неправильное property или сравнение с другим отчетом GA4.

Что проверить: диапазон, сайт, property, источник данных, наличие дублей GA4-тега на публичной части, cookie-согласие, время последнего обновления в MainWP.

Как исправить: выровняйте период, обновите данные в MainWP, проверьте трекинг на сайте и сверяйте только сопоставимые метрики. Для бизнес-решений используйте GA4 как первичный источник, а MainWP как оперативную панель.

Когда откатить: если дублирующий тег появился после установки нового аналитического плагина, отключите один из способов вставки тега и очистите кеш.

Когда MainWP Google Analytics будет удачным выбором

MainWP Google Analytics стоит использовать, если вы уже управляете WordPress-сайтами через MainWP и хотите встроить базовый контроль GA4 в тот же ежедневный процесс. Его сильная сторона - центральный обзор, виджеты, сопоставление дочерних сайтов со свойствами и использование аналитических токенов в отчетах. Это не замена Google Analytics и не инструмент установки тега, а удобный мост между GA4 и обслуживанием сайтов.

Перед установкой проверьте Dashboard-сервер, доступность REST API, способ подключения, права Viewer, наличие GA4-кода на дочерних сайтах и список свойств для сопоставления. После настройки не ограничивайтесь тем, что виджет "что-то показывает": сверяйте данные с GA4, проверяйте токены в отчетах и фиксируйте соответствия сайт - property.

Если такой рабочий сценарий совпадает с вашими задачами, можно перейти к блоку загрузки и скачать MainWP Google Analytics, а затем протестировать расширение сначала на одном контрольном сайте. Такой запуск безопаснее массового подключения: вы увидите реальные ограничения своей инфраструктуры и сможете настроить процесс до того, как данные попадут в клиентские отчеты.