.svg)
Вы строите отчёт по воронке за квартал, получаете красивые цифры, делаете выводы - и только через неделю замечаете маленькую иконку в интерфейсе Google Analytics. Значок щита с предупреждением: «Отчёт создан на основе X% сессий». Значит, цифры, которые вы уже показали команде, посчитаны не по всем данным, а по их части. Выводы могут быть неверными.
Это и есть инструментальное сэмплирование - одна из самых незаметных проблем в веб-аналитике. Инструмент молча решает, что считать все события слишком дорого, берёт часть и экстраполирует результат. Аналитик видит красивый отчёт, не всегда замечает пометку и делает выводы как будто по реальным данным.
В этой статье разберём, когда и почему это происходит, как распознать проблему до того, как отчёт ушёл к руководству, и какие конкретные способы дают полные данные без потери точности.
Коротко:
- GA Universal и GA4 автоматически включают выборку при сложных запросах или больших диапазонах дат - без явного предупреждения на видном месте.
- Погрешность при выборке 10-30% может кардинально изменить вывод по сегменту или каналу.
- Распознать проблему можно по иконке щита в интерфейсе GA или по нестабильным цифрам при повторных запросах одного отчёта.
- Самый надёжный способ работать с полными данными - экспортировать сырые события в BigQuery и делать запросы напрямую.
- Более простые обходные пути: сократить период, убрать вторичные измерения, использовать несэмплированные отчёты (если есть доступ к GA 360).
- Amplitude и Яндекс Метрика тоже используют выборку - просто говорят об этом по-разному.
Что происходит внутри, когда GA считает не всё
Google Analytics не хранит каждое событие бесконечно долго в оперативно доступном виде для произвольных запросов. Когда вы запрашиваете отчёт с сегментом, длинным периодом или нестандартными измерениями, система оценивает объём данных, который нужно обработать. Если он превышает внутренний порог, GA берёт случайную часть сессий и масштабирует результат на весь объём.
В Universal Analytics пороги были такими: до 500 000 сессий на уровне представления за выбранный период - данные полные, выше - включается выборка. При этом точный процент зависел от запроса: иногда система брала 90% данных, иногда 10%. В GA4 механика немного изменилась: пороги привязаны к событиям, а не сессиям, но принцип тот же.
Важно понимать: это не ошибка и не баг. Это осознанное инженерное решение Google ради скорости. Полный перебор миллиардов строк в реальном времени дорог. Выборка даёт ответ за секунды. Проблема в том, что для общих трендов это работает нормально, а для анализа конкретных сегментов, каналов или воронок - нет.
Когда погрешность становится проблемой
Представим e-commerce проект с 2 млн визитов в месяц. Аналитик строит отчёт за полгода по конверсиям в разрезе UTM-кампаний с дополнительным сегментом по устройствам. GA обрабатывает запрос на основе 15% сессий. Кампания с реальными 120 конверсиями может показать 90 или 150 - в зависимости от того, какие сессии попали в выборку. Разница в 25-30 конверсий меняет вывод об эффективности канала.
Ещё хуже ситуация с малыми сегментами. Если вы смотрите на пользователей из конкретного региона или с редким источником трафика, их может оказаться так мало в выборке, что цифра становится статистически бессмысленной - хотя выглядит как нормальное число в отчёте.
Где риск выше всего: сравнение каналов по конверсиям, анализ воронок с сегментацией, любые отчёты за период больше 3 месяцев, когортные отчёты с нестандартными измерениями. Именно здесь выборка искажает результат сильнее всего.
Как распознать, что отчёт посчитан по части данных
В Google Analytics Universal есть значок щита в правом верхнем углу отчёта. Зелёный - данные полные, жёлтый или красный - работает выборка. Там же показан процент охвата: например, «на основе 34,2% сессий». Это единственный явный сигнал.
В GA4 ситуация сложнее. В стандартном интерфейсе отчётов индикатор есть, но менее заметен. В Explore (Исследования) выборка включается чаще и обозначается значком молнии в правом верхнем углу с подписью «Результаты могут основываться на выборке данных».
Есть и косвенный признак: если один и тот же отчёт при повторном открытии даёт немного разные цифры - это почти точно выборка. Случайная подвыборка каждый раз чуть другая, и результаты слегка расходятся.
Простые способы снизить влияние выборки без смены инструмента
Не всегда нужно сразу идти в BigQuery. Есть несколько приёмов, которые работают прямо в интерфейсе GA.
Сократить период анализа
Выборка включается, когда объём данных за период превышает порог. Если вместо полугода запросить данные за каждый месяц отдельно, каждый запрос может остаться в зоне полных данных. Это неудобно, но иногда достаточно для первичного анализа.
Убрать вторичные измерения
Каждое дополнительное измерение в отчёте увеличивает сложность запроса. Если убрать лишние разбивки и оставить только то, что нужно для конкретного вопроса, отчёт может переключиться в режим полных данных.
Использовать стандартные отчёты вместо кастомных
Стандартные отчёты GA чаще остаются несэмплированными, потому что Google предварительно агрегирует для них данные. Кастомные сегменты и нестандартные комбинации измерений - главный триггер выборки.
GA 360
Платная версия Google Analytics повышает порог выборки до 1 миллиарда сессий и даёт доступ к несэмплированным отчётам напрямую. Для большинства проектов это избыточно по цене, но для крупных e-commerce и медиа это реальный вариант.
BigQuery как источник полных данных
Самый надёжный способ работать без ограничений выборки - выгружать сырые события в Google BigQuery и делать запросы напрямую к полному набору данных. В GA4 эта интеграция доступна бесплатно: в настройках ресурса есть раздел «Связь с BigQuery», после включения которого все события начинают поступать в хранилище.
После настройки каждое событие хранится как отдельная строка. Никакой агрегации, никакой выборки - только то, что реально произошло. Запросы пишутся на стандартном SQL.
Пример запроса для подсчёта конверсий по источникам без выборки:
Вакансии для аналитиков
SELECT traffic_source.source, traffic_source.medium, COUNT(*) AS conversions FROM `project.dataset.events_*` WHERE event_name = 'purchase' AND _TABLE_SUFFIX BETWEEN '20240101' AND '20240630' GROUP BY 1, 2 ORDER BY conversions DESC
Этот запрос вернёт точные цифры по всем событиям purchase за первое полугодие - без какого-либо масштабирования.
Схема данных GA4 в BigQuery задокументирована Google: каждая строка содержит поля event_name, event_params (массив с параметрами), user_pseudo_id, traffic_source, device и другие. Первый раз с этой структурой непривычно работать, но через несколько запросов логика становится понятной.
Стоимость: BigQuery тарифицирует по объёму обработанных данных. Для среднего проекта с несколькими миллионами событий в месяц запросы обходятся в несколько долларов. Первые 10 ГБ в месяц - бесплатно.
Как обстоит дело в других инструментах
GA - не единственный инструмент, где аналитик сталкивается с этой проблемой. Разные продукты решают её по-разному.
| Инструмент | Когда включается выборка | Как получить полные данные |
|---|---|---|
| Google Analytics 4 | Сложные запросы в Explore, большие периоды | BigQuery export, GA4 Data API с квотами |
| Universal Analytics | Больше 500 000 сессий за период в произвольных отчётах | GA 360, разбивка по коротким периодам |
| Amplitude | Графики и воронки на больших объёмах; применяется автоматически | Raw Data Export, прямые запросы через Amplitude SQL |
| Яндекс Метрика | Логи доступны только через API Logs или Яндекс DataLens | Logs API - сырые данные без выборки |
| Mixpanel | Выборка на очень больших объёмах в отчётах Insights | Data Export API, интеграция с хранилищем |
Общий паттерн везде один: быстрый интерфейс работает с агрегатами или выборкой, а полные данные доступны через экспорт или специализированный API. Это не случайность - это архитектурный компромисс между скоростью ответа и точностью.
Яндекс Метрика в этом смысле немного честнее: стандартные отчёты в интерфейсе строятся по агрегированным данным, и это явно задокументировано. Logs API даёт сырые хиты - это аналог BigQuery export для экосистемы Яндекса. Подключается через личный кабинет и позволяет забирать все события без ограничений.
Практический сценарий: воронка конверсий в BigQuery
Представим продуктовую команду, которая хочет понять, на каком шаге оформления заказа уходит больше всего пользователей. В GA4 они строят воронку в Explore, период - последние 90 дней. Выборка включается и показывает 67% охвата. Это означает, что потери на каждом шаге воронки посчитаны по двум третям данных.
Решение: строят ту же воронку через BigQuery. Запрос считает для каждого user_pseudo_id последовательность событий - view_item, add_to_cart, begin_checkout, purchase - и считает уникальных пользователей на каждом шаге. Никакой выборки, данные за 90 дней, точные числа.
Разница в цифрах оказывается существенной: шаг между begin_checkout и purchase показал 61% конверсию в GA Explore и 54% в BigQuery. Семь процентных пунктов - это разница между «всё нормально» и «надо срочно разбираться».
Когда выборка не проблема
Не всегда нужно стремиться к стопроцентному охвату. Есть ситуации, где выборка не искажает вывод значимо.
Если вы смотрите на общий тренд трафика за длинный период, а не на конкретные сегменты - выборка в 80-90% даёт достаточно точную картину. Если вы хотите сравнить два больших канала (органика против платного), и оба хорошо представлены в выборке, разница между ними будет примерно правильной.
Проблема начинается при работе с малыми сегментами, при сравнении каналов с сильно разным объёмом, при анализе конверсионных воронок и при любых задачах, где точность на уровне процентных пунктов влияет на решение.
Чеклист: как работать с данными и не попасть в ловушку выборки
- Перед каждым отчётом в GA проверяй значок щита или молнии - он показывает, идёт ли выборка и какой процент данных охвачен.
- Если охват ниже 70-80%, не делай выводов по конкретным сегментам - только по общим трендам.
- Для воронок, конверсионных отчётов и сравнения каналов используй данные из BigQuery, а не из интерфейса Explore.
- Настрой экспорт GA4 в BigQuery заранее - данные накапливаются с момента включения, ретроспективно их не восстановить.
- При анализе длинных периодов сначала проверь, можно ли разбить запрос на короткие отрезки без потери смысла.
- Если работаешь с Яндекс Метрикой - используй Logs API для задач, где важна точность по отдельным событиям или пользователям.
- Документируй в отчётах, какой источник данных использовался: интерфейс GA или прямой запрос к сырым данным.
- При передаче отчётов команде или руководству указывай, если данные получены через выборку - это часть честной аналитики.
Альтернативы BigQuery: когда хранилище недоступно
Не у каждой команды есть возможность быстро поднять BigQuery. Иногда нет прав на создание проекта в Google Cloud, иногда нет бюджета, иногда вся инфраструктура уже на другом стеке. В таких случаях есть несколько промежуточных решений, которые дают более точные данные без перехода на полноценное хранилище.
Первый вариант - Google Analytics Data API (GA4 API). Он позволяет запрашивать данные программно через Python или любой HTTP-клиент. Важный нюанс: API тоже применяет выборку, но у него есть параметр samplingLevel, с помощью которого можно запросить максимальную точность. При этом запрос будет выполняться дольше, зато охват будет выше, чем в стандартном интерфейсе.
Второй вариант - Looker Studio (бывший Google Data Studio) с прямым подключением к GA4. Для простых отчётов с ограниченным набором измерений Looker Studio часто остаётся в зоне полных данных дольше, чем Explore в самом GA4. Это не гарантия, но на практике помогает при работе с периодами до двух месяцев.
Третий вариант - разбивка запроса на части через скрипты. Если вы умеете писать на Python, можно автоматически запрашивать данные по неделям или по отдельным сегментам, а потом склеивать результат. Каждый маленький запрос с большей вероятностью попадёт в зону без выборки. Библиотека google-analytics-data для Python делает такой подход вполне рабочим без сложной инфраструктуры.
Практический совет: если у вас пока нет BigQuery, начните с малого - настройте автоматический еженедельный экспорт нужных отчётов через GA4 API в Google Sheets или CSV. Это не полная замена сырым данным, но уже убирает зависимость от интерфейсной выборки для регулярных задач.
Как выборка влияет на конкретные типы задач
Разные аналитические задачи по-разному чувствительны к погрешности от неполного охвата данных. Полезно понимать, где риск высокий, а где можно работать с тем, что дают стандартные отчёты.
| Тип задачи | Чувствительность к погрешности | Рекомендация |
|---|---|---|
| Мониторинг общего трафика по неделям | Низкая | Стандартные отчёты GA достаточны |
| Сравнение двух крупных каналов (органика vs контекст) | Средняя | Проверить охват; при 80%+ вывод обычно корректен |
| Анализ конверсионной воронки по сегментам | Высокая | Только сырые данные или GA4 API с максимальной точностью |
| Оценка эффективности малого канала или кампании | Очень высокая | Только BigQuery или Logs API; интерфейс ненадёжен |
| Когортный анализ удержания за 90+ дней | Высокая | Сырые данные обязательны; выборка искажает когорты |
| Общий отчёт для руководства по выручке | Низкая | Достаточно агрегированных данных, если период короткий |
Логика простая: чем меньше сегмент и чем важнее точность на уровне отдельных пользователей или событий, тем выше цена погрешности. Мониторинг тренда прощает неточность в 5-10%. Решение о перераспределении бюджета между каналами - нет.
Типичные ошибки при работе с неполными данными
Даже опытные аналитики иногда попадают в одни и те же ловушки, когда не учитывают ограничения инструментов.
Первая ошибка - сравнивать периоды, у которых разный процент охвата. Один месяц посчитан по 90% данных, другой - по 40%. Динамика будет выглядеть как реальное изменение, хотя на самом деле это артефакт разной выборки. Перед любым сравнением «период к периоду» стоит проверить, одинаков ли охват.
Вторая ошибка - доверять абсолютным числам из отчётов с выборкой. Выборка масштабирует пропорции, но не гарантирует точность абсолютных значений. Если в выборке оказалось больше конверсионных сессий, чем их реальная доля, финальная цифра будет завышена.
Третья ошибка - не документировать источник данных в отчёте. Через месяц никто не вспомнит, был ли этот отчёт из интерфейса GA с частичным охватом или из прямого запроса к сырым данным. Это создаёт путаницу при повторных обращениях к историческим данным и при перепроверке выводов.
Четвёртая ошибка - считать, что проблема касается только больших проектов. На самом деле выборка может включиться даже при относительно небольшом трафике, если запрос достаточно сложный: много измерений, длинный период, несколько вложенных сегментов. Размер проекта - не главный фактор, главный - сложность запроса.
FAQ
Что такое сэмплирование данных в аналитике простыми словами?
Это когда инструмент обрабатывает не все данные, а случайную часть, и масштабирует результат на весь объём. Например, GA обрабатывает 20% сессий и умножает цифры на 5. Это работает для общих трендов, но даёт погрешность при детальном анализе сегментов.
Как понять, что в отчёте Google Analytics используется выборка?
В Universal Analytics - по значку щита в правом верхнем углу отчёта. В GA4 - по значку молнии в разделе Explore. Оба показывают процент охваченных данных. Косвенный признак - цифры слегка меняются при повторном открытии одного и того же отчёта.
Как настроить BigQuery без сэмплирования для GA4?
В настройках ресурса GA4 перейдите в раздел «Связи с продуктами» - «BigQuery». Выберите проект BigQuery, укажите регион и включите экспорт. После этого события начнут поступать в хранилище ежедневно. Данные доступны через стандартный SQL в консоли BigQuery или через любой совместимый инструмент.
Amplitude тоже использует выборку?
Да. Amplitude применяет выборку на больших объёмах при построении воронок и графиков в интерфейсе. Для точного анализа есть Raw Data Export - выгрузка сырых событий в S3 или другое хранилище. Также доступны прямые запросы через Amplitude SQL в корпоративных тарифах.
Какая погрешность в аналитических отчётах считается приемлемой?
Зависит от задачи. Для мониторинга общего трафика - охват 80% и выше обычно достаточен. Для принятия решений о конверсионных воронках, бюджетах каналов или продуктовых изменениях - нужны полные данные или хотя бы охват 95%+. Если выборка ниже 50%, выводы по сегментам статистически ненадёжны.
Можно ли избежать выборки полностью, не переходя в BigQuery?
Частично - да. Сокращение периода, удаление вторичных измерений и использование стандартных отчётов вместо кастомных снижают вероятность включения выборки. Несэмплированные отчёты доступны в GA 360, но это платная версия с высоким ценником. Полностью избежать ограничений в бесплатном интерфейсе не получится - только снизить их влияние.
Что делать, если данные в BigQuery и в GA расходятся?
Это нормально. Расхождения связаны не только с выборкой, но и с тем, что GA агрегирует данные с учётом обработки спама и ботов, а BigQuery содержит сырые события. Небольшое расхождение в 1-3% - ожидаемо. Большое расхождение стоит проверить: возможно, часть событий не попадает в экспорт из-за настроек фильтров или задержки обработки.
Итог
Инструментальная выборка в аналитике - это не теоретическая проблема, а реальный источник неверных выводов. GA, Amplitude и Метрика применяют её по умолчанию в определённых условиях, и аналитик должен уметь распознать этот момент до того, как отчёт попал в презентацию.
Самое важное: знай, откуда пришли цифры в твоём отчёте. Если это интерфейс GA с выборкой 30% - это одна история. Если это прямой запрос к сырым событиям - другая. Разница может составить несколько процентных пунктов конверсии, а это уже решение о бюджете или продуктовом приоритете.
Настрой экспорт в BigQuery заранее, пока данные ещё нужны. Потом восстановить историю не получится.