Источник первого привлечения пользователя, источник сеанса и зачёт ключевого события — разные представления. Полезный отчёт определяет эти уровни до сравнения каналов.
Задать общую основу
Определите период, часовой пояс, валюту, конверсию и окно атрибуции. Для покупок сверяйте события с заказами, проверяйте дубликаты и уточняйте учёт возвратов. Атрибутированная выручка — не маржа и не дополнительная прибыль.
Читать измерения GA4 по уровню
Таблица различает три уровня источников трафика. Смена модели атрибуции отчётов не меняет измерения пользователя и сеанса. Игнорирование этого различия может создать кажущееся противоречие.
| Уровень | Вопрос | Влияние выбора модели |
|---|---|---|
| Пользователь | Источник первого привлечения | Измерения этого уровня не меняются |
| Сеанс | Источник каждого сеанса | Измерения этого уровня не меняются |
| Событие | Зачёт ключевого события | Зависит от выбранной модели атрибуции отчётов |
Документировать расхождения до действий
Отмечайте изменения разметки, согласия, охвата и задержек конверсий. Храните определения и даты выгрузки вместе с отчётом. Расхождение платформ требует сверки границ, а не автоматического перераспределения бюджета.
Источники и проверка
- Google Analytics — Scopes of traffic-source dimensions
- Google Analytics — Minimize duplicate key events with transaction IDs
- Google Analytics — Get started with attribution
Многоканальные отчеты требуют достоверного подсчета.
Несколько каналов могут вносить вклад в один путь. Определите распределение кредитов в каждом отчете и источник подсчета уникальных результатов. Изучите окна, прерванное отслеживание и посетителей, возвращающихся без параметров кампании; прямой не обязательно означает отсутствие предыдущего вклада.
- Задокументируйте модель атрибуции и окно.
- Согласуйте уникальные результаты с кредитами каналов.
- Раскройте ограничения неотслеживаемых путей.
Следует ли суммировать продажи, атрибуционированные платформой?
Не как подсчет уникальных заказов. Каждый отчет может учитывать одну и ту же продажу; Представление согласований и пересечений.
Первичный источник: Google Analytics — Campaign URL data. Связанный метод: прочитать практическое руководство.
Часовые пояса и поздние события
Период отчёта зависит от времени события и правил закрытия.
- Храните время события, получения и деловой часовой пояс отдельно. В вымышленном примере 23:30 UTC — это 01:30 следующего дня при фиксированном смещении UTC+02:00. Тип PostgreSQL с часовым поясом не сохраняет исходное название зоны.
- Включайте начало и исключайте конец периода. Вычисляйте границы в деловой зоне до перевода в UTC. Проверьте смену сезонного времени, месяца и дату без времени: местный день не всегда равен 24 часам.
- Задайте допустимую задержку и момент закрытия отчёта. Повторите идентификатор, чтобы отличить новое событие от дубликата. Сохраните опубликованную версию и влияние исправления; watermark оценивает поступление и не гарантирует полноту.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}Ожидаемое решение
В указанном поясе событие относится к 9 октября. Сохраните также время UTC.
Процедура проверки
- Определите пояс отчёта и опорный момент.
- Повторите событие около полуночи.
- Сохраните UTC, местную дату и правило закрытия. Добавьте неоднозначное местное время при переводе часов; сохраняйте смещение и зону вместо угадывания конкретного момента.
Можно ли считать день получения днём события?
Только если это предусмотрено определением отчёта. Сохраняйте оба времени и объясняйте обработку поздних событий.
Первичный источник: PostgreSQL — Date/time types. Связанный метод: прочитать практическое руководство.