Google Analytics API Открывает Данные о Конверсиях для Разработчиков

Google выпустил то, что можно назвать наиболее значимым изменением в Analytics API за 2026 год, — и произошло это без какого-либо пресс-релиза. 4 мая 2026 года Google открыл доступ к данным о кросс-канальных конверсиях через Google Analytics Data API, впервые сделав отчёт о конверсиях программно доступным. Техническая основа изменения — новое поле ConversionSpec в RunReportRequest — было тихо добавлено в v1 alpha на одиннадцать дней раньше, 23 апреля.

Это четвёртое обновление Analytics, выпущенное или расширенное Google в 2026 году: после январских трёх одновременных бета-версий, февральских сгенерированных инсайтов и апрельского Task Assistant. Четыре релиза примерно за четыре месяца — все без официальных анонсов — это темп, который важно учитывать всем, кто строит пайплайны атрибуции.

Что произошло

Главный факт: разработчики теперь могут вызывать runReport с параметром ConversionSpec и получать те же данные, которые ранее были доступны только в интерфейсе Google Analytics в разделе «Реклама > Эффективность конверсий». До этого обновления у данного отчёта не было программного эквивалента. Команды, создающие кастомные дашборды, пайплайны для хранилищ данных или интеграции с BI-системами, не имели поддерживаемого способа извлечения данных о конверсиях — об этом PPC Land написал в своём обзоре журнала изменений. Обходным путём был ручной экспорт из интерфейса — именно тот тип шага, который ломается при масштабировании.

Обновление распространяется как на клиентов Google Analytics, так и на клиентов Google Ads, однако функция остаётся в стадии alpha и широко не доступна. Этот момент важен: alpha у Google исторически означает нестабильные контракты и незаметные поломки, поэтому любое использование этого интерфейса в продакшн-среде преждевременно.

Контекст для понимания сроков: в январе 2026 года Google одновременно запустил три бета-функции — кросс-канальное бюджетирование, улучшенное управление веб-конверсиями для клиентов Ads и отчёт по анализу атрибуции конверсий. Релиз 16 января также ввёл настройки атрибуции для каждой конверсии отдельно, заменив прежнюю модель на уровне ресурса, где один выбор атрибуции применялся ко всем событиям конверсии. 10 февраля на главную страницу Analytics добавились сгенерированные инсайты, суммирующие три главных изменения данных с момента последнего визита пользователя — по обновлениям конфигурации, аномалиям и сезонности. 29 апреля появился Task Assistant — инструмент с подсказками в левой навигации, организующий задачи ресурса: подключение аккаунтов и устранение проблем с данными. Выпуск API замыкает этот круг: интерфейс стал умнее, и теперь данные наконец доступны через вызов API.

Техническая анатомия

В журнале изменений задокументированы три конкретных добавления. Первое: новое поле ConversionSpec в RunReportRequest принимает два параметра. conversionActions принимает идентификаторы действий-конверсий в качестве фильтра, а AttributionModel принимает одно из двух значений перечисления — DATA_DRIVEN или LAST_CLICK. Только две модели, никаких других. Это намеренное сужение.

Второе: поле Section добавлено в ResponseMetaData — оно определяет, из какого источника получены данные: SECTION_REPORT (стандартная отчётность) или SECTION_ADVERTISING (поверхность отчётности по конверсиям). Третье: метод getMetadata в v1 alpha теперь возвращает метаданные, специфичные для конверсий, включая поле conversions, которое сопоставляет идентификаторы действий-конверсий с отображаемыми именами через список объектов ConversionMetadata. Поле sections также добавлено в DimensionMetadata и MetricMetadata — оно явно указывает вызывающей стороне, применимо ли данное измерение или метрика в стандартной отчётности, в отчётности по конверсиям или в обоих случаях.

Последняя деталь — та, на которую инженерам следует обратить особое внимание. Не каждое измерение и метрика, работающие в стандартном отчёте, будут работать в отчётах по конверсиям, и конечная точка метаданных теперь документирует эти границы. Без этого поля вы бы обнаруживали границы, отлаживая неуспешные запросы.

Выбор модели атрибуции сам по себе интересен. Google начал депрекировать несколько rule-based моделей атрибуции с 2024 года, подталкивая экосистему к атрибуции на основе данных. Сохранение LAST_CLICK как допустимого значения здесь, несмотря на общую тенденцию к депрекации, сигнализирует о том, что Google рассматривает атрибуцию по последнему клику как базовую для кросс-платформенной сверки — но не как рекомендуемую основную модель. Источник не раскрывает, будут ли добавлены дополнительные модели позже, что важно: если перечисление останется на двух значениях на протяжении всей стадии alpha, вендоры, создающие инструменты сверки, например, с Conversions API Meta, получат более узкую поверхность для сравнения, чем им хотелось бы. Ограничение сегодня — две модели, без публичных обязательств по дорожной карте.

Сам отчёт об эффективности конверсий поддерживает два временны́х измерения — время конверсии и время взаимодействия, а метрика «Все конверсии» охватывает как основные, так и вспомогательные действия-конверсии. Отчёт учитывает настройки как ресурса Google Analytics, так и аккаунта Google Ads. Насколько API обеспечивает полное соответствие всем этим параметрам интерфейсу — разработчикам придётся проверять вручную на стадии alpha. Если делать прогноз, я ожидаю, что как минимум один пробел в паритете обнаружится в течение 60 дней после более широкого развёртывания.

Кто пострадает

Больше всего затронуты команды, построившие пайплайны «экспортируй и склеивай», потому что интерфейс был единственным источником данных. Аналитические группы по перформанс-маркетингу внутри iGaming-операторов, команды привлечения клиентов в финтехе и криптовалютные биржи, запускающие платный трафик в больших объёмах, — все они делали что-то вроде «войди в интерфейс, экспортируй CSV, загрузи в хранилище, сджойни в dbt». Теперь у этого рабочего процесса есть поддерживаемая замена, а значит, внутренний инструментарий, построенный вокруг него, быстро устаревает.

Вендоры — более интересная категория. Платформы атрибуции и компании, занимающиеся маркетинг-микс моделированием и берущие деньги за «извлечение данных о конверсиях GA» как за функцию, теперь имеют меньше конкурентного барьера. Если инженерная команда клиента может напрямую вызывать runReport с ConversionSpec и получать эквивалентные данные, ценность вендора-посредника сводится к тому, какой слой трансформации, смешивания или визуализации располагается сверху. Некоторые вендоры будут в порядке, потому что их ценность — в моделировании. Другие выстраивали ценообразование вокруг проблемы доступа к данным, а эта проблема решается самой платформой.

Команды Ads, которые жаловались на расхождения в отчётах между Google Ads и Google Analytics, также получают новый инструмент. При наличии настроек атрибуции для каждой конверсии отдельно (действуют с 16 января) и теперь программного доступа к данным конверсий по обеим моделям — DATA_DRIVEN и LAST_CLICK — в рамках одного пайплайна, диагностический цикл для вопроса «почему Ads показывает X, а Analytics — Y» становится значительно короче. Мы пока не знаем, как часто две модели будут расходиться на практике для конкретного ресурса, но сейчас это можно протестировать: получить обе, сравнить, автоматизировать оповещение.

Если события будут развиваться так, как я ожидаю, давление на ценообразование вендоров по функциям извлечения GA-конверсий должно стать заметным к третьему кварталу 2026 года, а как минимум один крупный вендор атрибуции перепозиционирует своё сообщение — от «мы подключаемся к GA» к глубине моделирования — до конца года.

Стратегия для перформанс-маркетинга

Для команд, управляющих пайплайнами платного привлечения, три действия на эту неделю. Первое: запросите доступ к alpha, если ваш аккаунт соответствует требованиям, но пока не переводите производственную отчётность. Alpha-контракты меняются, и в источнике явно указано, что функция широко недоступна. Создайте параллельный пайплайн, запускайте его одновременно с существующим потоком на основе экспорта и сверяйте данные.

Второе: используйте поле метаданных sections для измерений и метрик как жёсткий валидатор. Не предполагайте паритет со стандартной отчётностью. Напишите скрипт обнаружения, который вызывает getMetadata и выдаёт матрицу совместимости для вашего конкретного случая. Это сэкономит недели отладки, когда запрос возвращает пустые результаты, потому что измерение помечено только для SECTION_REPORT.

Третье: получайте как DATA_DRIVEN, так и LAST_CLICK в одном задании. Стоимость — один дополнительный вызов API. Ценность — постоянная линза сверки между Analytics и более широкой экосистемой Ads API, где атрибуция по последнему клику по-прежнему является распространённым кросс-платформенным базовым значением. Сохраняйте оба результата, храните оба, пусть BI-слой решает, какой из них показывать и для каких стейкхолдеров.

Для руководителей платформ в iGaming и финтех-операторах в особенности: настройки атрибуции для каждой конверсии, выпущенные в январе, — это более значимый долгосрочный инструмент, потому что события депозита и события регистрации почти никогда не заслуживают одинаковой модели атрибуции. Выпуск API позволяет этой детализации попадать в ваше хранилище данных, а не «умирать» в интерфейсе.

Ключевые выводы

• Alpha, не GA: ConversionSpec находится в v1 alpha начиная с 23 апреля 2026 года. Создавайте параллельные пайплайны, пока не переключайте продакшн.
• Только две модели атрибуции: доступны только DATA_DRIVEN и LAST_CLICK. Ограничение на кросс-модельное сравнение сейчас составляет два варианта.
• Разработка начиная с метаданных: используйте новое поле sections в DimensionMetadata и MetricMetadata для проверки совместимости перед написанием запросов к отчётам.
• Снижение конкурентного барьера вендоров: вендоры, продающие извлечение данных как функцию, теряют ценовую власть. Вендоры, занимающиеся моделированием и смешиванием данных, защищены.
• Следите за пробелами в паритете: источник не подтверждает полный паритет между интерфейсом и API. Ожидайте как минимум один пробел в течение 60 дней после более широкого развёртывания.