Google this week released version 24.1 of the Google Ads API, a minor version update that packs several technically consequential additions: a new mobile device platform segment, static image support for Demand Gen campaigns on the Google Display Network, passkey field detection, and a significant expansion of the Experiments framework to cover AI Max, Video, Demand Gen, and Performance Max campaign types. The announcement was published on May 13, 2026, on the Google Ads Developer Blog by Anash P. Oommen of the Google Ads API Team.

The v24.1 release follows the April 22, 2026 launch of v24, which introduced the CartDataSalesView reporting resource, nine new lead generation conversion types, and tag-based retail filters. Minor versions like v24.1 add new fields and capabilities without breaking changes, meaning developers can adopt them incrementally.

Mobile device platform segmentation

Perhaps the most straightforward addition in v24.1 is the segments.mobile_device_platform column, now available in both campaign-level and customer-level reports. The field uses a new MobileDevicePlatform enum with values for IOS and ANDROID, allowing API consumers to cleanly split performance data by the user's mobile operating system without relying on workarounds or post-processing logic.

Before this field existed, isolating iOS versus Android performance in programmatic reporting required either custom tagging, audience segments, or external data joins. The new column makes that separation native to the Google Ads API query layer. For teams managing large-scale mobile campaigns across both platforms - where bid strategies, creative performance, and conversion rates often differ substantially between operating systems - this is a meaningful reduction in reporting complexity.

The capability sits at both campaign and customer levels, which means it applies not just to individual campaigns but to aggregate account-wide views. That dual availability is useful for agencies managing multiple clients through manager accounts, where cross-account summaries by mobile platform were previously difficult to construct directly from the API.

Classic display images in Demand Gen

Starting with v24.1, the classic_display_images field in DemandGenMultiAssetAd accepts static image uploads for serving on the Google Display Network within Demand Gen campaigns. These images serve as-is, without being combined with other creative assets or dynamically assembled by Google's ad serving infrastructure.

This matters because Demand Gen campaigns have historically leaned heavily on automated asset assembly, where Google combines headlines, descriptions, logos, and images into responsive formats. The classic display image path offers advertisers a channel to serve fully controlled static creatives within the same Demand Gen framework, without those creatives being subject to asset combination. It preserves branding fidelity in contexts where the automated assembly would otherwise modify layout or visual relationships between elements.

Demand Gen campaigns run across YouTube, Discover, and Gmail. The Display Network placement through the classic_display_images field extends static ad serving into that inventory pool. Google launched four new Demand Gen capabilities in November 2025 including brand suitability controls and A/B experiments - the v24.1 addition builds further on that expansion by giving developers a programmatic path to static image uploads via the API.

Passkey field detection

Google now requires certain advertisers to authorize sensitive actions within their Google Ads accounts using a passkey rather than a password. The v24.1 release surfaces this requirement at the API level through a new boolean field, passkey_enabled, that indicates whether the authenticated user has a passkey configured.

The practical implication is narrow but important for developers building integrations that touch sensitive account operations. An API integration that attempts to authorize sensitive actions on behalf of a user who has not configured a passkey may encounter unexpected behavior or rejection. The passkey_enabled field allows programmatic checking of this state before attempting such operations, enabling developer-side conditional handling. Passkeys use cryptographic authentication tied to a device, eliminating shared secrets and reducing phishing exposure. The field does not require developers to implement passkey enrollment - it is read-only and informational.

Revamped Experiments support

The Experiments framework in Google Ads allows advertisers to split budget or traffic between an original campaign and a test variant, then measure performance differences over a defined period. If the experiment outperforms the control, the changes can be applied to the original campaign or used to replace it entirely.

Version 24.1 substantially expands the experiment types available through the API. According to the Google Ads Developer Blog, the release introduces support for AI Max experiments, Video experiments, Demand Gen experiments, and Performance Max experiments. The announcement notes that Video and Demand Gen experiments share the same API type.

Critically, the updated Experiments framework now supports direct retrieval and comparison of detailed performance metrics across individual experimental arms. That means clicks, conversions, and impressions can be queried per arm within a single API call, enabling side-by-side analysis without manually constructing the comparison from separate campaign-level queries. Previously, obtaining per-arm statistics required additional processing steps.

The AI Max experiment type is particularly notable given that AI Max for Search campaigns has been Google's primary vehicle for automated query expansion and keyword matching since it entered open beta. PPC Land covered Google's AI Max capabilities as part of the Think Week 2025 announcements, when the feature was reported to deliver 14% more conversions or conversion value at a comparable CPA or ROAS for most advertisers. Being able to formally A/B test AI Max configurations through the API - rather than relying on observational before-and-after comparisons - gives advertisers a structurally cleaner testing methodology.

Performance Max experiments through the API are similarly significant. Google's addition of channel-level reporting for Performance Max in API v23 gave developers visibility into where Performance Max campaigns actually deliver impressions. Combining that transparency with formal experiment support in v24.1 means developers can now both see and test Performance Max configurations with considerably more granularity than was possible six months ago.

Demand Gen experiments at the API level have a longer history. Demand Gen experiments were introduced in the Google Ads interface in October 2023, with a maximum of two arms per experiment. The v24.1 release brings the API-level implementation of that feature into alignment with the current experiment type roster, including the newer campaign types.

Data retention error code

The final addition in v24.1 is a new error code tied to the forthcoming 37-month data retention policy for Google Ads reporting. According to the Google Ads Developer Blog, starting June 1, 2026, Google Ads and related measurement APIs will transition to a 37-month retention window for granular performance statistics at daily, hourly, and weekly granularity. To handle API requests that fall outside this window, v24.1 introduces DateRangeError.REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED.

PPC Land reported on the 37-month retention policy announcement when Google published the documentation on May 1, 2026, noting that the change represents a significant contraction from the 11-year retention window Google established less than 18 months prior. That 11-year policy itself was announced in October 2024 and took effect November 13, 2024.

The error code is a forward-compatibility addition. Developers running historical backfill queries or long-horizon reports against the API will encounter REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED once data older than 37 months falls outside the retention window after June 1. Any integration that does not handle this error will break silently or surface unhandled exceptions. Teams with automated reporting pipelines pulling historical daily or hourly data should plan code changes before the June 1 cutoff.

Release logistics

Developers who want to use v24.1 features must upgrade their client libraries and update client code - all updated libraries and code examples were published alongside the announcement. Google has scheduled a live walkthrough of the release through multiple channels: the #ads-api channel on Discord, the Ads Developers YouTube Live, and LinkedIn Live, all on May 14, 2026, at 10 AM Eastern Time. The session will also be recorded and posted to YouTube.

The v24.1 release fits within the monthly release cadence Google adopted in January 2026 when it launched v23. PPC Land covered the developer token backlog Google disclosed in February 2026, when surging interest in the API - driven in part by the Google Ads API MCP server and the Ads API Developer Assistant - caused processing delays for Basic and Standard Access applications. That context is relevant here: the audience building integrations with the API has grown substantially, and releases like v24.1 reach a larger developer base than comparable minor releases from two years ago.

Under Google's versioning lifecycle, v24 will remain supported until approximately May 2027. The v24.1 minor release does not alter that timeline. Developers on older supported versions do not receive the new fields automatically - they must upgrade to v24.1 to access segments.mobile_device_platform, classic_display_images, passkey_enabled, and the expanded experiment types.

For development teams managing large-scale Google Ads integrations, the Experiments expansion is likely the most operationally significant item in v24.1. The ability to retrieve per-arm statistics directly, combined with support for AI Max and Performance Max experiment types, brings programmatic A/B testing closer to parity with the breadth of testing available in the Google Ads web interface. The mobile segmentation field and the static image path for Demand Gen address narrower but persistent gaps that required workarounds before.

Timeline

Summary

Who: Google's Ads API Team, specifically Anash P. Oommen, published the v24.1 release announcement on the Google Ads Developer Blog. The update affects all developers and technical marketing teams building programmatic integrations with the Google Ads platform.

What: Google Ads API version 24.1 introduces five substantive additions: a segments.mobile_device_platform segment for iOS/Android reporting splits; the classic_display_images field enabling static image uploads to the Google Display Network within Demand Gen campaigns; a passkey_enabled boolean field indicating passkey authentication status; expanded Experiments support covering AI Max, Video, Demand Gen, and Performance Max experiment types with per-arm performance metric retrieval; and the DateRangeError.REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED error code tied to the June 1, 2026 data retention policy change.

When: The announcement was published on May 13, 2026. A live walkthrough event is scheduled for May 14, 2026, at 10 AM Eastern Time. The data retention error code becomes operationally relevant on June 1, 2026.

Where: The release applies globally to all developers and advertisers using the Google Ads API. The Demand Gen static images capability affects inventory on the Google Display Network. The passkey requirement is currently limited to certain advertisers.

Why: The v24.1 release addresses several distinct gaps in API coverage. Mobile platform segmentation removes the need for workarounds to separate iOS and Android performance data. Static Demand Gen images offer programmatic access to a creative format that preserves full branding control. The Experiments expansion enables structured A/B testing for AI Max and Performance Max campaign types that lacked formal API-level testing support. The passkey field and data retention error code prepare developers for forthcoming platform security and policy changes.

Share this article
The link has been copied!