# Чек-лист аудита GA4: 18 проверок достоверности отчётов

Проверьте GA4 по 18 пунктам: дубли событий, пропущенные конверсии и ошибки атрибуции. Определите приоритеты исправлений и повторите тесты.

Canonical page: https://cpcinsider.com/ru/insights/ga4-audit-checklist/
Author: Vladlens Kecko
Published: 2026-09-29
Updated: 2026-10-08


Чек-лист аудита GA4 проверяет путь от реального действия клиента до отчёта, на основе которого принимают решение. Пользователи в Realtime доказывают только поступление части данных. Это ещё не подтверждает правильный учёт покупок, заявок или источников рекламы.

Руководство относится к веб-сайту. Подготовьте доступ к GA4, настройкам тегов и тестированию сайта. Сравнивайте аналитику с CRM или заказами и заранее определите, кто публикует изменения. Для каждого теста записывайте ресурс, поток данных, устройство, выбор согласия и время.

Для точного сравнения используйте [руководство по сверке GA4 и Google Ads](https://cpcinsider.com/ru/insights/ga4-google-ads-conversion-discrepancies/). Для кампаний применяйте [шаблон UTM-меток](https://cpcinsider.com/ru/insights/utm-naming-convention/).

## Пример заполненного листа аудита GA4

Аудит должен объяснить ошибку, её последствия и способ проверки исправления. Ниже — учебный пример, а не результат клиента. Используйте вымышленные данные покупателя и храните доказательства вне публичных отчётов.

| Проблема | Результат контролируемого теста | Что проверить и исправить | Повторный тест |
| --- | --- | --- | --- |
| Дубль заявки | Одна принятая форма создаёт два события | Удалить повторный отправитель или триггер | Одна заявка — одно событие; обновление страницы его не повторяет |
| Нет стоимости покупки | В заказе есть сумма, в событии её нет | Проверить передачу стоимости и валюты | Сверить событие с тем же тестовым заказом |
| Платёжный сервис стал источником | Возврат после оплаты меняет источник | Проверить путь пользователя и настройки переходов | Повторить покупку и проверить обработанные данные источников |

Назначьте владельца и дату для каждой проблемы. Утечки персональных данных и ошибки событий бизнес-результата важнее оформления отчётов. Итог — воспроизводимые тесты и список оставшихся ограничений.

## 18 проверок GA4

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

| Проверка | Что подтвердить |
| --- | --- |
| 1. Доступы | Бизнес сохраняет нужные права, у бывших подрядчиков нет лишнего доступа |
| 2. Ресурс и поток | Рабочий сайт отправляет данные в правильный ресурс и веб-поток |
| 3. Валюта и часовой пояс | Настройки соответствуют бизнес-данным для сравнения |
| 4. Покрытие тегами | Посадочные, товарные, платёжные страницы и подтверждения отправляют нужные события |
| 5. Дубли установки | Плагин CMS, код сайта и GTM не отправляют одно событие несколько раз |
| 6. Просмотры страниц | Загрузка и переходы внутри приложения дают ожидаемую последовательность просмотров |
| 7. Определения событий | У каждого события есть бизнес-смысл и документированный триггер |
| 8. Успешные действия | Результат фиксируется после заявки или покупки, а не только по клику |
| 9. Повторные действия | Обновление, возврат и повторная попытка не увеличивают число результатов |
| 10. Ключевые события | Важные исходы выделены осознанно и отличимы от вовлечённости |
| 11. Ecommerce-параметры | ID покупки, сумма, валюта и товары совпадают с тестовым заказом |
| 12. Согласие | Начальное состояние и обновления работают при принятии и отказе |
| 13. Персональные данные | URL, заголовки и обычные параметры не раскрывают имена, email или телефоны |
| 14. Несколько доменов | Переход к контролируемому домену оплаты или записи сохраняет нужное измерение |
| 15. Нежелательные переходы | Платёжные и служебные домены не присваивают источник привлечения |
| 16. Внутренние фильтры | Исключается нужный трафик, а не реальные клиенты |
| 17. Источники кампаний | Названия, редиректы и связи с рекламными аккаунтами сохраняют полезные данные |
| 18. Сверка | Различия с CRM и заказами имеют объяснимые период, задержку и определение |

## Проверяйте один путь за раз

Включите отладку для тестового устройства через Tag Assistant или предпросмотр GTM. Посмотрите последовательность событий и параметры в [GA4 DebugView](https://support.google.com/analytics/answer/7201382?hl=en). Для анализа атрибуции используйте отчёты о привлечении; DebugView прежде всего проверяет реализацию.

Повторите на компьютере и телефоне:

- Откройте посадочную страницу и внутреннюю ссылку; проверьте последовательность просмотров.
- Отправьте форму с ошибкой; она не должна считаться успешной заявкой.
- Отправьте корректную форму и найдите запись в CRM или системе получателя.
- Обновите подтверждение и проверьте повторное событие успеха.
- В магазине совершите тестовую покупку и сравните её параметры с заказом.

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

## Найдите источник дублей

Перечислите отправителей: код сайта, CMS-плагин, GTM и серверную интеграцию. Ищите двух отправителей или триггер, который срабатывает и по клику, и после успешной отправки. Исправляйте отправителя или условие, а не маскируйте дубли в отчёте.

Названия ecommerce-событий и необходимые поля сверяйте с [документацией Google](https://developers.google.com/analytics/devguides/collection/ga4/ecommerce). Для каждого заказа используйте уникальный ID транзакции и тестируйте обновление страницы. [Руководство по валидации](https://developers.google.com/analytics/devguides/collection/ga4/validate-ecommerce) описывает обработку ID; не переносите эти правила автоматически на любое пользовательское событие заявки.

В [обсуждении GA4-аудитов на Reddit](https://www.reddit.com/r/GoogleAnalytics/comments/1qjygs8/how_are_you_auditing_ga4_setups_these_days/) участники подчёркивают проверку событий по реальным действиям. Это обмен опытом; конкретный вывод подтверждают воспроизводимый тест и документация реализации.

## Согласие и персональные данные

Проверьте нового посетителя, который соглашается, посетителя, который отказывается, и вернувшегося пользователя, меняющего выбор. По [инструкции Google для отладки согласия](https://developers.google.com/tag-platform/security/guides/consent-debugging) проверьте начальные значения, обновления и поведение тегов. Видимый баннер ещё не означает корректную передачу сигналов.

Посмотрите URL и параметры после отправки формы. Не передавайте email, телефон и имя в обычных полях аналитики, заголовках и адресах страниц; см. [рекомендации Google по PII](https://support.google.com/analytics/answer/6366371?hl=en). Специально предусмотренные функции пользовательских данных требуют отдельной корректной реализации.

## Исправьте источники, не скрывая проблему

Если вы контролируете несколько доменов одного пути, проверьте [междоменное измерение](https://support.google.com/analytics/answer/10071811?hl=en) и сохранение linker-параметра при редиректах. Для возвратов от платёжного провайдера оцените [нежелательные переходы](https://support.google.com/analytics/answer/10327750?hl=en). Исключение источника не заменяет правильно связанный путь.

Проверяйте ссылку из настоящего письма или объявления вместе с редиректами. Используйте последовательные названия входящих кампаний и не размечайте обычную внутреннюю навигацию как внешнюю кампанию.

До активации тестируйте фильтры внутреннего и developer-трафика. Google указывает, что [исключённые данные недоступны навсегда](https://support.google.com/analytics/answer/13296761?hl=en), а фильтры не исправляют историю. Сохраняйте дату включения.


Если платёжный сервис стал источником привлечения, перед изменением исключений используйте [проверку рефералов после оплаты](https://cpcinsider.com/ru/insights/ga4-payment-referrals/).

## Сверьте выборку и определите порядок исправлений

Сравнивайте конкретный период после обработки данных, согласовав часовой пояс, валюту, определение события и область атрибуции. GA4, Google Ads и CRM отвечают на разные вопросы; одинаковые суммы не всегда означают правильное измерение.

Иллюстративный пример: в CRM 10 принятых тестовых заявок, а в аналитике 20 успешных событий, потому что работают обработчик клика и триггер страницы подтверждения. Это конкретная ошибка реализации. Разницу из-за согласия или окна атрибуции нужно объяснить, а не компенсировать выдуманным событием.

Сначала исправляйте передачу персональных данных, потерю или дублирование бизнес-результатов и разрывы источников. Затем улучшайте названия и отчёты. Если данные влияют на рекламу, используйте также [аудит Google Ads](https://cpcinsider.com/ru/insights/google-ads-audit-checklist/) и [руководство по CRM-интеграции](https://cpcinsider.com/ru/insights/google-ads-crm-integration/).

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

### Достаточно ли Realtime?

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

### Нужно ли отмечать каждое событие как ключевое?

Выбирайте действия, важные для бизнеса. Сохраняйте различимость вспомогательной вовлечённости и отдельно проверяйте цели Google Ads перед использованием импорта для ставок.

### Исправятся ли старые отчёты после настройки?

Большинство правок меняет будущий сбор данных. Отметьте дату исправления и не сравнивайте периоды так, словно метод всегда был одинаковым.


Перед добавлением событий согласуйте определения и ответственных с помощью [плана измерений рекламы](https://cpcinsider.com/ru/insights/advertising-measurement-plan/).

Перед изменением целей изучите [основные и дополнительные конверсии Google Ads](https://cpcinsider.com/ru/insights/google-ads-primary-secondary-conversions/).


Если отчёт о привлечении показывает Unassigned, используйте [диагностику источника в шесть шагов](https://cpcinsider.com/ru/insights/ga4-unassigned-traffic/), чтобы отделить классификацию канала от пропущенных данных сеанса.


Для контролируемой проверки визитов команды используйте [инструкцию по фильтру внутреннего трафика GA4](https://cpcinsider.com/ru/insights/ga4-internal-traffic-filter/) до активации исключений.

## Найдите ошибки измерения, влияющие на решения

[Запросите бесплатный аудит эффективности](https://cpcinsider.com/ru/#audit) и укажите в заявке вопрос по GA4. Мы рассмотрим приоритеты измерения и обсудим следующие шаги. Для внедрения доступна [поддержка по аналитике, атрибуции и CRM](https://cpcinsider.com/ru/services/tracking-attribution-crm/).