GA4 Conversion Performance in the API: What to Automate First

Cross-channel conversion data has been readable inside Google Analytics since the Advertising section gained a Conversion performance report. Getting it out of that interface and into something you control was the awkward part. Download a CSV, or rebuild the same numbers by hand from standard reports, and hope nobody edited an attribution setting while you were away.

That changed on 4 May 2026. Google's changelog entry, Conversion support in the Data API, opened cross-channel conversion reporting to the Data API in alpha for Google Analytics and Google Ads customers. The same paid and organic reporting data that sits behind Advertising, then Conversion performance is now available programmatically.

It is alpha, and the eligibility notice is not decoration. The feature is not switched on for every property yet. Read on anyway, because the shape of the API tells you which conversion number Google now treats as canonical, and that matters whether or not you can call it today.

Why this report was worth exposing

The Conversion performance report is a pre-made detail report in the Advertising section. You choose conversions shared with a linked Google Ads account and evaluate how they perform. Two numbers matter, and Google is unusually explicit about both of them.

The All conversions figure attributed to your Google Ads account matches the All conversions figure in Google Ads, in the charts and in the table. That match is the point of the report. It is also why the same number has always been hard to reproduce anywhere else, because every other GA4 report applies its own identity logic before it counts anything.

The total can sit higher than Google Ads, and this is where most reconciliation arguments go wrong. Attribution settings in the property decide whether conversions receive credit from Google paid channels only, or from paid and organic channels. Choose paid and organic and the GA4 total picks up conversions from organic search and direct referrals. Google Ads counts Google paid channels and nothing else. Both figures are correct. They answer different questions, and the person asking for "the number" almost never says which one they mean.

One more detail, because identity debates are common. The Conversion performance report does not use your property's reporting identity. It measures users across devices in a way designed to match Google Ads. Standard reporting works the other way and respects the identity setting. Put conversion rows and standard rows into the same blended user count and they will not agree, because they were never counting the same population.

What the API actually returns

Conversion reporting runs on the v1alpha surface of the Data API, through the runReport method you already use. The endpoint is the alpha one:

POST https://analyticsdata.googleapis.com/v1alpha/{property=properties/*}:runReport

Three additions do the work.

conversionSpec on the request. Set the field, or request any conversion metric, and the report becomes a conversion report. Inside it, conversionActions takes a list of conversion action IDs, and an empty list means every conversion is included. attributionModel accepts DATA_DRIVEN or LAST_CLICK. Leave it out and you get DATA_DRIVEN.

section on the response metadata. The response states whether the rows came from standard reporting (SECTION_REPORT) or conversion reporting (SECTION_ADVERTISING). Worth checking when a single wrapper function serves both report types and you would rather label the output than infer it from the request you built.

conversions and sections on getMetadata. The metadata call returns a conversions list, and each entry carries a conversion action ID of the form conversionActions/1234 together with its display name from the interface. That is where the IDs for conversionActions come from, instead of hunting through the Admin panel. Dimension and metric metadata gain a sections field as well, which states whether a field is valid in standard reporting, conversion reporting, or both.

Check that last part before assuming a metric name carries over. The standard reporting surface renamed its conversion metrics back in 2024, replacing conversions with keyEvents, and the advertising surface has its own field set. One getMetadata call settles the question in seconds.

A request you can start from

The body below is the smallest useful version of a conversion request. Metric names are left as a placeholder on purpose.

{
  "dateRanges": [
    { "startDate": "2026-09-01", "endDate": "2026-09-19" }
  ],
  "dimensions": [
    { "name": "sessionDefaultChannelGroup" }
  ],
  "metrics": [
    { "name": "METRIC_REPORTED_FOR_CONVERSION_SECTION" }
  ],
  "conversionSpec": {
    "conversionActions": ["conversionActions/1234"],
    "attributionModel": "DATA_DRIVEN"
  }
}

Get the metric and dimension names from getMetadata first. Filter the fields whose sections field includes conversion reporting, pass those names, and the request behaves. Guess a name and you get an invalid argument error that tells you nothing about eligibility, which then sends people chasing the wrong problem for an afternoon.

Four jobs worth automating

Reconcile GA4 against Google Ads on a schedule. The report exists so the two accounts can be compared, and comparison is a job nobody does weekly by hand. Pull the Google Ads attributed conversion total for the last complete week, compare it with what Google Ads reports for the same dates, and alert when the gap passes a tolerance you chose deliberately. A gap usually means a conversion action was renamed, a lookback window moved, or a data import stopped landing. All three are cheap to fix and expensive to discover during a quarterly review.

Compare attribution models on identical data. Send the same request twice, once with DATA_DRIVEN and once with LAST_CLICK, then diff the rows. The delta is the credit that moves between models, which is the real content of most channel performance arguments. Without the API it is two exports, a manual join, and a spreadsheet nobody trusts by Thursday.

Watch the conversion configuration itself. getMetadata returns the conversion actions a property exposes. Store that list daily and diff it. A conversion action that was renamed, added or retired changes what every conversion report means, and it stays invisible in a dashboard that only charts totals.

Feed a client-facing view that will not drift. Because the API returns the same data as the report, a scheduled job can rebuild the view in a sheet or a warehouse table with the model and the date range recorded in the output. Be careful about the tool you point at it. Looker Studio's GA4 connector runs on the standard reporting surface and will not pick up an alpha field on its own, so the realistic route is a script writing to a table or sheet rather than a direct connector.

One more use, less obvious than the others: evidence. When someone asks whether an attribution setting explains a difference between two reports, you can answer with two API responses and a diff instead of an opinion. That is a better use of an afternoon than another meeting about whose export was right.

What it will not give you

A few expectations are worth dropping before you build on this.

The conversion report is aggregated. You get counts by the dimensions you request, not click paths or user-level rows. Anyone expecting touchpoint sequences should stay with path exploration or the BigQuery export. The API reports what the interface reports and nothing deeper, which is fine for reconciliation and useless for journey analysis.

It will not create or repair a conversion action. A key event reaches this report only once it is configured as a conversion and shared with a linked Google Ads account, and that setup lives in the Google Analytics interface, not in the API. An empty conversions list from getMetadata is a configuration answer rather than a permissions answer.

It is also not a replacement for the Google Ads API. The Google Ads API reports conversions inside Google Ads' own model, which is what bidding acts on. This report shows paid and organic conversion data under GA4's attribution settings, which is what channel planning needs. Treating the two as interchangeable guarantees the same argument next quarter.

The catches

Alpha means alpha. The v1alpha surface can change shape, and the client libraries treat it as separate infrastructure. The Go and Node.js libraries ship an AlphaAnalyticsDataClient alongside the v1beta client for exactly this reason. Do not make an alpha request the only copy of a number that ends up on a client invoice.

Eligibility is decided per property. Every page of the documentation carries the same notice, that the feature may not be available to your property and the team is expanding it. A refusal may mean eligibility rather than a mistake in your request, so check eligibility before you spend a day debugging auth.

The attribution setting decides your headline number. Same traffic, same conversion actions, two properties, two totals. Write the setting into your notes for each account so nobody re-opens the argument every month.

An API does not repair a consent gap. If a large share of UK visitors decline analytics and advertising storage, the report reflects the data that survived consent, and pulling it hourly does not change that. What automation buys you is consistency: the same query, the same settings, the same date logic every week, so a move in the number means a move in the data rather than a change in how somebody pulled it.

What to do this month

1. Call getMetadata against the alpha endpoint on a property you report on. If conversions comes back populated, you have eligibility and the conversion action IDs in one response.
2. Record the attribution setting for every property you report on, and note whether the total is paid only or paid and organic. This single line of documentation prevents more arguments than any dashboard.
3. Build one reconciliation job: GA4 conversion total against Google Ads All conversions for the same period, run weekly, with a tolerance you can defend.
4. Store the conversions list daily and diff it. Renamed actions are easy to catch this way and painful to find later.
5. Keep the alpha call out of the critical path. If the surface changes, the standard report still exists and the business keeps running while you patch the job.

The short version

The Conversion performance report used to be somewhere you looked. Now it is a source you can pull, at least for properties Google has enabled. The value is not an extra chart. It is that paid and organic conversion data can be reconciled on a schedule against the account that owns the spend, with the attribution model named in the request instead of buried three clicks deep in a settings page.

If your GA4 and Google Ads conversion totals have never agreed and nobody can explain why, the most useful thing this API does is make the disagreement reproducible. Reproducible problems get fixed. Vague ones get carried into next quarter.