Search ads attribution API: what each platform actually exposes

There is no single search ads attribution API. Each search platform exposes its own: the Google Ads API for reading conversions, the Google Data Manager API for uploading them back, the Microsoft Advertising API for Bing, and Apple's AdServices attribution API for App Store installs. You join them on click identifiers you store yourself, because none of them will join each other.

Why there is no single search ads attribution API

Attribution is not a property of an ad. It is a property of the measurement stack that saw the click. Google decides which impression, click or view gets credit and reports the result on its own terms. Microsoft and Apple do the same inside their own systems.

Nothing forces those three systems to agree on a model, a window or an identifier, so no vendor-neutral endpoint exists that you can simply ask. Every serious implementation is a small data engineering project with four sources and one join key.

That is also why vendor comparisons of this topic read strangely. They compare reporting dashboards when the actual work is reconciling identifiers and windows across platforms that were never designed to be reconciled.

What the Google Ads API actually returns

The Google Ads API is a reporting and management surface, not an attribution engine. Conversion numbers arrive as metrics: metrics.conversions, metrics.conversions_value, metrics.all_conversions and metrics.all_conversions_value. Segment by segments.conversion_action and you get one row per conversion action per campaign, which is as close to earned revenue as the API gets.

Two limits catch people on the first build. Google's conversion reporting guide states that including segments.conversion_action changes query granularity to one row per conversion action per campaign, and that rows where every metric is zero are excluded from the response. A campaign with no conversions disappears rather than appearing with a zero. The same guide notes that custom columns built in the UI cannot be retrieved through the API at all.

A query that works, taken from the shape Google documents: SELECT campaign.name, segments.conversion_action, metrics.conversions, metrics.conversions_value FROM campaign WHERE segments.date DURING LAST_30_DAYS.

Conversions are also not instant. Google publishes a separate data freshness guide for exactly this reason, and it applies to conversion metrics. A dashboard that queries live at 8am will disagree with the UI for the first hours of the day, and the disagreement is not a bug.

How do you query keyword-level conversions in the Google Ads API?

Keyword-level data lives on keyword_view, not on campaign. Filter the campaign channel to SEARCH, add the conversion action segment, and you get conversions per keyword per conversion action per day.

SELECT campaign.name, ad_group.name, ad_group_criterion.keyword.text, ad_group_criterion.keyword.match_type, segments.conversion_action, metrics.clicks, metrics.conversions, metrics.conversions_value FROM keyword_view WHERE campaign.advertising_channel_type = 'SEARCH' AND segments.date DURING LAST_30_DAYS ORDER BY metrics.conversions DESC

Three things to know before running it. First, segments.conversion_attribution_event_type is incompatible with several metrics: selecting it alongside clicks, cost_micros or impressions returns PROHIBITED_SEGMENT_WITH_METRIC_IN_SELECT_OR_WHERE_CLAUSE, which Google's API support team confirms on the developer forum is intended validation, not a bug to work around. Second, querying a client account needs the login-customer-id header. Third, Search returns fixed pages of 10,000 rows, so a large account wants SearchStream or explicit pagination instead of a single call.

This is the honest ceiling of keyword attribution. keyword_view tells you which keyword collected the conversion under Google's model and window. It does not reconstruct the search journey, and it will not reconcile with a last-touch model in your warehouse without a documented mapping between the two.

Why conversion uploads moved to the Data Manager API

Reading conversions is half of attribution. The other half is telling the platform that a lead closed three weeks later, and that write path has changed underneath a lot of integrations.

Google's offline conversion uploads on the Google Ads API are now gated. UploadClickConversions requests fail with CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE for developer tokens that sent no offline conversion upload requests between 17 December 2025 and 15 June 2026, and Google's documentation redirects those integrations to the Data Manager API (Google Ads API documentation, read November 2026).

Data Manager is the replacement, and its release notes show where this is heading. Version 1.2, published 6 August 2025, added offline conversions and enhanced conversions for leads through IngestEvents. Version 1.3 made the API generally available. Version 1.7, published 28 May 2026, added offline conversion events for Campaign Manager 360 and Search Ads 360 destinations, which is the first time one Google endpoint covers both the ad platforms and the marketing platform feeding them.

The consequence for anyone building now is simple. Treat the Google Ads API as the reader and Data Manager as the writer. Building an upload on UploadClickConversions buys you a migration inside twelve months and no new capability in the meantime.

The tagging side is where most of these projects actually fail. our conversion tracking setup guide for solo founders covers the event naming and dedup work that decides whether an upload has any chance of matching.

What does the Apple Ads attribution API return?

Apple's flow happens on the device. The AdServices framework issues an attribution token that the app hands to your server, and the server posts that token to Apple's attribution endpoint. The token has a 24 hour time to live, so a request that sits in a queue over the weekend returns nothing usable.

The payload is small and specific. Per Apple's AttributionToken documentation, attribution is true when the user clicked an Apple Ads impression up to 30 days before the download, or viewed it within 24 hours. claimType is Click for tap-through and Impression for view-through, and tap-through takes priority over view-through. Campaign, ad group, ad, keyword and creative arrive as identifiers rather than names, so you join them against the Apple Ads Platform API reports.

Two suppressions matter. Ad groups that use age or gender targeting return attribution false, and from 1 September 2026 Apple no longer returns attribution claims for any ad group with those settings applied. Apple's own setup guide also records that the retired iAd attribution API has returned iad-attribution false since 7 February 2023, so any tutorial still using ADClient is describing a dead endpoint.

What you get is install and redownload attribution inside Apple's ecosystem. What you do not get is post-install revenue, which arrives through AdAttributionKit or your mobile measurement partner, never through the same call that attributed the install.

How Microsoft handles search attribution

Microsoft Advertising splits the job the same way Google does. Reporting comes from the Reporting service and campaign management entities, while conversion truth arrives either from Universal Event Tracking on your site or from an offline upload you push back into the account.

For offline conversions the order matters more than the code. Microsoft's documentation is explicit that the OfflineConversionGoal must be created through the Campaign Management API so the IsExternallyAttributed property is set, that you should wait two hours after creating the goal before calling ApplyOfflineConversions, and that conversion data can take up to six hours to appear in reporting. A pipeline that creates the goal and uploads in the same job loses its first batch silently.

October 2026 changed the write path again. Microsoft Advertising announced its Conversions API as generally available in its 28 October 2026 product update, sending events server to server from websites, apps, CRMs and point of sale systems alongside UET rather than replacing it. If you are choosing an integration today, CAPI is the surface with a forward roadmap and UET stays as the browser-side baseline.

Search Ads 360 when your conversions live in Floodlight

If you run search through Search Ads 360, the attribution data you want is a Floodlight report rather than a Google Ads report. The legacy Search Ads 360 API was decommissioned on 30 June 2024 and all new reporting goes through the Search Ads 360 Reporting API, while the Conversion API was left in place and is still supported for uploads.

The migration detail that costs teams time: Floodlight activity names map to segments.conversion_action_name, and several legacy columns have no replacement at all. Google's field mapping documentation flags values such as floodlightGroup, floodlightGroupId and dfaWeightedActions as behavior changes rather than simple renames, which means a straight column swap produces a report that looks correct and is quietly different.

The payoff is one schema across engines. Search Ads 360 normalises Google, Microsoft and other engines into the same conversion vocabulary, which is the only practical way to compare a Bing keyword with a Google keyword without rebuilding currency and time zone handling per engine.

Where the joins break

Once you have four surfaces, the work becomes reconciliation. These are the four places it usually fails.

• Click identifiers are not portable. Google gives you gclid, Microsoft gives msclkid, Apple gives you nothing comparable. Store whichever identifier arrives on the landing page in the same table as the conversion row, or you cannot join anything later.
• Windows differ and they are not all 30 days. Google sets the conversion window per conversion action. Apple uses 30 days for a click and 24 hours for a view, with 90 and 61 day windows for pre-order campaigns. Microsoft's default is 30 days and configurable. Applying one window uniformly will over-credit some platforms and under-credit others.
• Time zones and currency. Each platform reports in the account's own time zone and currency. Summing three accounts before normalising produces totals that never reconcile with finance, and the gap is arithmetic rather than attribution error.
• Rows and identities get dropped. Zero conversion rows vanish from Google Ads API responses, consent mode removes users from the pool entirely, and Apple suppresses age and gender ad groups. Your total will not match the platform UI, and chasing that difference is the most commonly wasted week in these projects.

What none of these APIs will tell you

Every API above reports conversions the platform believes it caused. None reports what would have happened without the ad, and none reports what your competitors were doing at the same moment. If a competitor doubled bids on your brand terms on Monday, your cost per acquisition moved for a reason no attribution API can show.

That gap is where competitive intelligence sits, and it is a different data class: public ad libraries, auction insights, creative change detection. Our comparison of an ad intelligence API against the Meta Ad Library API covers the build decision there, and our piece on what the Google Ads Transparency Center API actually is does the same for the transparency side.

Keep the two systems separate. Attribution explains your own performance. Competitive data explains the context your performance happened in. Teams that blend them into one dashboard spend their reviews arguing about whether a metric is broken or the market moved.

A pull order you can ship this week

If you are starting from nothing, this order gets you a number you can defend fastest.

• Step 1, decide the conversion you optimise for and where it is recorded. Every downstream system inherits that decision, and a vague event definition is the root cause of most reconciliation pain.
• Step 2, pull conversion reporting from the Google Ads API on campaign and keyword_view, segmented by conversion_action, for the last 90 days. Cache the result rather than querying live on every page load.
• Step 3, store click identifiers at landing page time, before any third party tag runs, in the same store your conversion events land in.
• Step 4, upload downstream conversions through the Data Manager API instead of the gated Ads API upload path, and log the request id for every batch.
• Step 5, add Apple and Microsoft only after the Google path reconciles with finance for one full month. Two half working pipelines are worse than one trusted one, because nobody knows which number to act on.

If you would rather not run four integrations yourself, an MCP server or an ad intelligence API can absorb the reading half of this work. Our guide to which keywords competitors bid on in Google Ads covers the competitive reading of the same keyword data, which is usually the second question after the attribution question is answered.

Frequently asked questions