События GA4: выбрать семейство и проверить измерение

Опубликовано 09/05/2026 · Обновлено 01/11/2026 · Данные и эффективность · 4 мин чтения · Автор Cyber Intelligence Embassy

Кратко

GA4 различает автоматические события, улучшенную статистику, рекомендуемые и специальные события. Реализация отличается; имя события не доказывает успешность бизнес-действия.

Вымышленная пустая аналитическая комната: два стола с чистыми карточками, латунные лампы и бордовая папка

В этой статье

Определить наблюдаемое действие

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

Разделять сбор и значимость

Событие GA4 можно отметить как ключевое. Это выбранная важность для анализа, а не доказательство продажи или прибыльности. Проверяйте дубликаты, значения и охват до отчётов; улучшенная статистика и автоматический сбор — разные семейства.

Четыре семейства событий GA4
Семейство	Примеры	Условие
Автоматическое	first_visit, session_start	Сбор предусмотрен базовой настройкой
Улучшенная статистика	scroll, file_download	Функция включена, взаимодействие поддерживается
Рекомендуемое	add_to_cart, purchase	Реализация документированных имён и параметров
Специальное	Действие конкретного продукта	Определить, если другие семейства не подходят

Источники и проверка

Проверено 1 ноября 2026 года

Пользовательские события должны описывать бизнес-факт.

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

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

Первичный источник: Google Analytics — Set up events. Связанный метод: прочитать практическое руководство.

Целостность соединений данных

Соединение таблиц может размножить строки и исказить суммы.

Строка заказов означает заказ, а строка позиций — товар в нём. До объединения проверьте повторяющиеся и пустые ключи.
Сгруппируйте позиции по ключу заказа. Соединение с этим результатом не повторяет сумму заказа для каждой позиции. Сверьте сумму с исходной таблицей заказов.
LEFT JOIN сохраняет заказы без позиций, но WHERE по правой таблице может их удалить. Отсутствие соответствия не означает нулевую сумму.

Воспроизводимый приёмочный случай

Вымышленный пример: данные не описывают клиента или наблюдаемый результат.

Посмотреть данные случая

{
    "orders": [
        {
            "id": 1,
            "total": 100
        },
        {
            "id": 2,
            "total": 200
        }
    ],
    "line_order_ids": [
        1,
        1,
        2
    ],
    "sum_before": 300,
    "sum_after_raw_join": 400
}

Ожидаемое решение

400 дважды учитывает заказ. Сначала сгруппируйте строки по заказу, чтобы получить 300. Проверить также два вымышленных заказа по 100: сумма 200. SUM(DISTINCT total) вернёт 100, удалив допустимое значение. Проверять идентификаторы и кардинальность соединения, а не устранять повторы сумм.

Воспроизводимые SQL-запросы

Вымышленный пример: заказы на 100 и 200 и три позиции для 1, 1 и 2. Запросы используют только VALUES; выполняйте их в тестовой среде.

WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;

WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
  SELECT order_id, COUNT(*) AS line_count
  FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;

Прямое соединение даёт три строки и 400. Предварительная агрегация возвращает два заказа и 300.

WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
       SUM(DISTINCT total) AS distinct_total
FROM orders;

При суммах 100 и 100 правильный итог — 200; SUM(DISTINCT total) даёт 100.

Процедура проверки

Определите детализацию заказов и строк.
Соедините заказ с двумя строками.
Сохраните ключи, количества и сверенные суммы.

PostgreSQL — Table expressions and joins

Достаточно SUM(DISTINCT total)?

Нет. Два заказа по 100 дают 200, а SUM(DISTINCT total) возвращает 100. Исправляйте связь ключей, а не удаляйте равные суммы.

Первичный источник: PostgreSQL — Table expressions and joins. Связанный метод: прочитать практическое руководство.

Кардинальность соединений, NULL и агрегаты

Подробные справочные заметки в этой версии доступны на английском.

Read the cardinality behind a published number

When a result combines sources, ask what one row represents and how keys were matched. An apparently correct sum can conceal two offsetting errors. Pair counts and identifier coverage provide additional evidence.

Document population before and after joining.
Do not infer causation from the total alone.
Connect the metric definition to actual retained rows.

Inspect pairs and aggregates in the workshop →

PostgreSQL 18 · Table expressions · PostgreSQL 18 · documentation reviewed 2026-10-23

PostgreSQL 18 · Aggregate functions · PostgreSQL 18 · documentation reviewed 2026-10-23

PostgreSQL 18 · Comparison functions · PostgreSQL 18 · documentation reviewed 2026-10-23