Google Ads API v24.1 is a focused release, but it is not a minor one. It adds new reporting dimensions, expands experiment support, introduces additional security visibility, and gives Demand Gen advertisers more direct creative control. It also signals where Google wants advertisers and developers to tighten their workflows before larger operational changes, especially around reporting retention and experimental measurement, begin to affect production systems.
For engineering teams, agencies, SaaS platforms, in-house marketers, and analytics operators, the practical question is not simply what Google added. The more important question is what v24.1 changes in day-to-day execution. That includes what fields can now be queried, what campaign types can now be tested in a more structured way, what reporting logic should be updated, what error handling needs to be revised, and which implementation decisions should move from “we’ll get to it later” to “we should handle this in the next sprint.”
That is where this release matters. The official announcement gives the headline items. Short-form coverage highlights a few advertiser-facing takeaways. The release notes list the additions. What most teams still need is the connective layer: what changed, why it matters, who is affected, what should be prioritized, and how to think about the upgrade in terms of data quality, campaign control, and operational risk.
This guide is written for that purpose. It explains the release in plain English, ties the changes to real implementation scenarios, and turns the changelog into a practical working document for teams that rely on the Google Ads API in production.
What Google Ads API v24.1 changes at a high level
At a high level, v24.1 falls into six categories.
First, reporting becomes more useful in a few important ways. The addition of the mobile device platform segment lets teams separate iOS and Android performance at the campaign and customer reporting level. New experiment metrics add more statistical depth when comparing experimental arms. Vertical-ad reporting also gets additional segmentation and filtering support.
Second, Demand Gen gains a notable creative control improvement. Advertisers can now use classic display images in Demand Gen multi-asset ads, which makes it possible to upload static image creatives that serve as designed on the Google Display Network rather than being recombined into responsive-style formats.
Third, experiments become more mature. Google expands support for additional experiment types, adds new configuration support for YouTube custom video experiments, and gives developers more fields for reading and comparing experiment arms, especially for asset testing and Performance Max-related workflows.
Fourth, account security visibility improves with a new passkey field on customer user access. This does not replace broader authentication governance, but it gives platforms and enterprise teams a clearer way to understand whether passkeys are enabled for users who can take sensitive actions.
Fifth, Google is preparing developers for the coming 37-month retention limit on granular Google Ads and related measurement API reporting. The new date granularity error in v24.1 is part of that transition.
Sixth, a handful of smaller but meaningful additions appear in targeting and video integrations, including a new targeting error and support for ZEFR as a third-party viewability integration partner.
Taken together, v24.1 is less about one dramatic headline and more about improving precision in reporting, control, testing, and account hygiene.
Why this release matters more than quick summaries suggest
A lot of release coverage in ad tech follows a predictable pattern. A publication lists three or four bullet points, tells readers why they should care, and moves on. That is fine for awareness. It is not enough for decision-making.
What makes v24.1 more important than a skim suggests is that several of its changes affect systems that sit below the visible campaign layer. Reporting infrastructure, experiment analysis, asset workflows, and account governance are all areas where a seemingly small API release can have outsized consequences. If your organization runs dashboards, forecasting models, creative pipelines, automation rules, or client-facing reporting on top of Google Ads data, modest schema additions can shape how teams work for months.
The release also reflects broader product direction. Google is continuing to do three things at once:
It is increasing automation in campaign creation and optimization.
It is adding more ways to measure and compare that automation.
It is centralizing or formalizing controls that used to be looser, more manual, or less visible.
That combination matters. When platforms become more automated, advertisers need better reporting and testing controls if they want to understand what is happening. v24.1 adds pieces of that measurement layer. The new experiment metrics, mobile OS segmentation, Demand Gen static image support, and passkey visibility all fit that pattern.
For agencies, this is useful because it improves how client performance can be explained. For software vendors, it matters because customers increasingly expect productized clarity around experiments, creative behavior, and segmentation. For in-house teams, it matters because it makes it easier to connect ad system behavior to business analysis without relying as heavily on guesswork or manual workarounds.
The most immediately useful reporting update: mobile device platform segmentation
One of the clearest improvements in v24.1 is support for segments.mobile_device_.
That sounds simple, and that simplicity is exactly why it is useful. Many advertisers have long wanted cleaner visibility into how performance differs between iOS and Android. Device-level reporting alone is not always enough. When a team is analyzing app performance, ecommerce checkout behavior, lead quality, or even creative interaction patterns, operating-system-level differences can shape budget allocation and product decisions.
With v24.1, teams can segment campaign-level and customer-level reports by mobile device platform. In practice, that means performance can be broken out by values such as iOS and Android instead of being flattened into a broader mobile category.
This matters in several common situations.
For app advertisers, iOS and Android users often behave differently across install rate, in-app conversion rate, subscription value, and retention curve. If those users are grouped too broadly, teams may make the wrong optimization choice.
For ecommerce advertisers, checkout friction, wallet usage, browser behavior, and app deep-linking performance can differ by OS. That can affect conversion rate and average order value.
For agencies managing multiple brands, mobile platform reporting creates a better basis for diagnosing whether performance problems are market-wide or platform-specific.
For BI and analytics teams, it becomes easier to structure reporting so that operating system performance is not inferred indirectly through other dimensions.
The strategic value of this addition is not that it gives marketers more data for the sake of more data. It gives them a cleaner explanatory variable. When performance diverges across mobile traffic, operating system is often one of the first dimensions teams want to isolate. Now they can do that more directly.
What to do with mobile device platform data in practice
The best use of a new segment is usually not a one-off report. It is a new layer in decision-making.
Teams should start by auditing where mobile performance is currently reviewed. If dashboards only show desktop, tablet, and mobile, that may now be too coarse for key stakeholders. A reporting layer that separates iOS and Android can reveal whether issues are tied to app experience, checkout, tracking setup, creative rendering, or audience behavior.
The next step is to connect that reporting to action. If iOS traffic converts at a materially different rate than Android traffic, that should inform landing-page QA, app install campaigns, bid logic review, and possibly measurement validation. In some cases, the issue will be campaign performance. In others, it will be a downstream product or analytics issue that the campaign team merely surfaced first.
It is also worth reviewing attribution and conversion setup before drawing strong conclusions. A cleaner segment is only as helpful as the underlying measurement it is attached to. Teams that rush from segmented data to budget decisions without validating conversion quality can still make poor calls.
Where this new segment becomes especially valuable is in recurring reporting. It belongs in monthly business reviews, platform QA workflows, app campaign diagnostics, and any automated anomaly detection that flags sharp changes in mobile conversion patterns.
Demand Gen gets classic display image support, and that matters more than it looks
The Demand Gen update in v24.1 is one of the most practically significant items in the release.
Google added classic_display_images DemandGenMultiAssetAd. This allows advertisers to upload static image ads that can serve on the Google Display Network inside Demand Gen campaigns without requiring additional assets or responsive-style recombination.
For advertisers who have felt constrained by automation-heavy creative assembly, this is a meaningful change. It does not remove Demand Gen’s broader automated behavior, but it gives teams more direct control over how certain display creative appears.
That matters for a few reasons.
Brand governance is one. Some advertisers are comfortable giving the system flexibility in layout and asset combination. Others need specific image treatments, visual composition, or creative hierarchy to remain fixed. Static image support creates a cleaner option for those use cases.
Creative testing is another. When every result comes from combinations of multiple assets, it can be harder to isolate what actually drove performance. Classic image support gives teams a more controlled creative input.
Display adaptation is also important. Some brands already have proven display creatives that perform well outside of highly recombined responsive environments. Being able to use those in Demand Gen can reduce production friction and improve continuity across channels.
This addition is especially relevant for advertisers in regulated categories, visual-heavy verticals, premium brand environments, and organizations with tight creative approval processes.
What classic display images change for Demand Gen workflows
The immediate technical implication is straightforward: teams that manage Demand Gen ad creation via the API can now work with a new field that supports static image delivery in the appropriate context.
The more interesting implication is workflow design.
Before this update, many teams had to choose between leaning into automation or avoiding certain campaign setups when they wanted more creative control. Now they have a middle ground. That does not mean every advertiser should switch to static images by default. It means creative strategy can become more intentional.
A practical approach is to use classic display images in three situations.
The first is when a brand already has strong display creative and wants message consistency across channels.
The second is when teams need a cleaner creative test, with fewer moving parts in the asset combination process.
The third is when internal approvals or legal constraints make flexible asset recombination difficult.
This change also improves the conversation between paid media and creative teams. Instead of asking whether Demand Gen can or cannot support a particular creative approach, the better question now is which placements and objectives benefit from fixed static image treatment versus broader asset assembly.
That is a better strategic question, and v24.1 gives teams more room to answer it properly.
Security visibility improves with passkey support
Another notable addition in v24.1 is CustomerUserAccess.passkey_.
This field is read-only and indicates whether a user has a passkey enabled. On the surface, that sounds like a small administrative detail. In operational terms, it is useful for organizations that take account access controls seriously.
Google has been moving more aggressively toward stronger authentication standards, including passkeys for sensitive actions in some advertiser contexts. The addition of a passkey visibility field in the API gives enterprise teams, internal tools, and governance layers a cleaner way to understand whether users are aligned with that direction.
This matters for agencies managing many accounts, brands with distributed access models, and platforms that provide account audit or access review functionality. In all of those settings, account security is not just a login matter. It is part of compliance, change control, and operational continuity.
Being able to see whether passkeys are enabled gives teams another signal they can incorporate into user access audits. It will not replace policies around user provisioning, permission scope, or credential hygiene. It does make those reviews more complete.
In a mature environment, the field can be used as part of account governance reporting, internal admin tooling, and security readiness reviews for users who can approve billing changes, launch campaigns, or edit critical account settings.
Experiments are one of the biggest areas of improvement in v24.1
The experiment-related changes in v24.1 deserve special attention because they are likely to shape how advanced advertisers and platforms evaluate automation going forward.
Google added support for several new ExperimentTypeEnum values, including:
ADOPT_AI_MAXADOPT_BROAD_MATCH_KEYWORDSOPTIMIZE_ASSETSPMAX_REPLACEMENT_SHOPPING
Google also added configuration support for existing YOUTUBE_CUSTOM video_experiment field in Experiment.
In addition, ExperimentArm gained new fields such as asset_testing_info, asset_, and performance_max_.
Those additions matter because experiments are increasingly the structured way to answer questions that used to get debated informally. Should a team adopt broader automation? Should it move budget from standard Shopping structures toward a Performance Max alternative? Should a video or asset change be evaluated in a cleaner test framework? v24.1 makes those questions easier to operationalize through the API.
That is important because the advertising environment has changed. As more campaign types rely on automated optimization, traditional manual before-and-after comparisons are often too noisy or too weak to support confident decisions. Experimentation becomes more valuable when the platform itself is increasingly opaque in how it makes decisions.
This release does not solve all experimentation challenges, but it gives developers better tools to support more disciplined testing.
What the new experiment types mean in practical terms
Each experiment type points to a different strategic use case.
ADOPT_AI_MAX reflects Google’s ongoing effort to formalize testing around AI-assisted campaign or optimization settings. Teams evaluating whether to shift into more automated configurations need cleaner comparisons than anecdotal account stories.
ADOPT_BROAD_MATCH_KEYWORDS
OPTIMIZE_ASSETS is highly relevant for creative teams and platforms that want to test asset strategies in a more structured way, rather than inferring creative lift from mixed campaign performance.
PMAX_REPLACEMENT_SHOPPING is particularly important for retail advertisers. It suggests a more formal API-supported path to evaluating what happens when a Performance Max setup is used in place of an existing Shopping structure.
The broader lesson is that Google is continuing to move controversial or high-stakes tactical decisions into more measurable, experiment-friendly frameworks. Teams that ignore that shift may find themselves relying on less reliable methods while competitors use better testing discipline.
Experiment reporting becomes more useful, not just more available
One of the most important upgrades in v24.1 is the new support for experiment metrics across seven core metric families:
- Clicks
- Impressions
- Cost
- Conversions
- Cost per conversion
- Conversion value
- Conversion value per cost
For each family, the release supports fields that help compare control and treatment values, along with point estimates, margins of error, and p-values. There are also new conversion absolute change metrics with corresponding statistical fields.
This is a major improvement because many experiment discussions fail for one simple reason: teams can see raw performance, but they cannot evaluate it rigorously enough. A difference in clicks or conversions may look meaningful without actually being reliable. Better statistical support makes experiment interpretation more disciplined.
That helps in several ways.
It improves internal decision-making because teams can distinguish between apparent performance movement and statistically supported change.
It improves communication with stakeholders, because results can be framed more clearly and with less hand-waving.
It improves productization for agencies and software companies that want to build experiment dashboards or recommendations.
It also reduces the temptation to declare winners too early. That matters in advertising, where volatile short-term movement often produces false confidence.
The strongest teams will use this release as a reason to improve their experiment reporting interfaces, not just their API queries.
The new data retention-related error is a warning, not just a field note
Google recently announced that beginning June 1, 2026, granular performance statistics across Google Ads and related measurement APIs will move to a 37-month retention policy for daily, hourly, and weekly data.
In v24.1, Google added DateRangeError. to support that change.
This matters because it is not just a future policy footnote. It is a signal to developers right now. Teams that query large historical ranges with granular time breakdowns need to revisit how those workflows operate before the retention window begins to create failures or mismatched expectations.
This affects data warehouses, long-range historical reporting, year-over-year dashboards, audit tools, and any client-facing system that assumes daily or weekly granularity remains available indefinitely.
The key point is that retention policy changes often surface first as “why is this query failing?” support issues, when they should really be handled as architecture questions. If a business needs long-term granular data beyond the retained API availability, it should be storing that data in its own environment on an ongoing basis.
v24.1 gives teams the error support needed to prepare for that reality. The right response is not merely to catch the error. It is to redesign the reporting expectation behind it.
Additional reporting and vertical-ad changes worth knowing
Beyond mobile device platform and experiment metrics, v24.1 includes several other reporting-related updates.
Google added vertical ad segments such as vertical_ads_listing_user_ and vertical_ads_.
It also added support for filtering by user_rating, venue, and event_participant_display_ in VerticalAdsItemGroupRu for the SharedCriterion resource.
These are niche compared with the headline release items, but they matter for teams in verticalized ad environments where listing attributes influence targeting and reporting. More granular filtering and segmentation can improve inventory control, reporting precision, and product-specific campaign logic.
The broader takeaway is that v24.1 is not only about widely used campaign types. It continues Google’s pattern of adding more structure for specialized inventory and vertical-specific use cases. Teams in travel, local, event-related, or listing-heavy environments should review whether these additions enable more precise grouping, reporting, or troubleshooting than they had before.
Targeting and video updates that should not be ignored
Two smaller additions in v24.1 are still worth noting.
First, Google added CANNOT_EXCLUDE_ALL_ to CriterionErrorEnum. This is a practical safety-oriented targeting error. It helps prevent invalid targeting setups where exclusions remove all available targets. For teams building campaign setup tools or automated targeting logic, that is a useful guardrail.
Second, on the video side, Google published ZEFR as a third-party viewability integration partner and added channel_id to the youtube_video field in the DataLink resource.
The ZEFR update is relevant for measurement and verification workflows. The channel_id addition is useful because it improves how linked YouTube video data can be identified and structured. That can matter in video analytics, creator mapping, content governance, and any tooling that needs more explicit video relationship data.
Neither of these items will affect every advertiser. Both are the kind of addition that advanced integrations appreciate immediately.
A practical upgrade checklist for teams moving to v24.1
For most organizations, the move to v24.1 should be handled as a contained but deliberate upgrade project.
Start with client libraries. Google’s updated client libraries and code examples are already available, and they should be updated in a non-production environment first.
Next, inventory where your current implementation touches the parts of the API that changed. That includes reporting jobs, Demand Gen ad creation, experiment workflows, access governance tools, and any historical reporting jobs that rely on granular date ranges.
Then review your reporting layer. Add the new mobile device platform segment where it creates real analytical value. Evaluate whether experiment dashboards should be extended to support the new statistical metrics. Review any long-range granular reports that may eventually run into retention-related limits.
After that, look at creative workflows. If your team manages Demand Gen via the API, decide whether classic display images should be introduced into creative production and testing. This is not just a field addition. It can alter how creative teams work with media teams.
Then check experiment support. If your organization has wanted cleaner ways to test AI-driven settings, broad match adoption, asset optimization, or Performance Max replacement scenarios, v24.1 is a strong reason to formalize those workflows.
Finally, review governance and monitoring. The passkey field, targeting error, and new reporting limitations all point to better operational discipline. Teams that treat upgrades purely as engineering maintenance tend to miss these process benefits.
Example GAQL ideas teams can build around v24.1
A strong release guide should help readers think in implementation terms, not just feature terms. Here are a few practical query patterns teams can adapt conceptually in v24.1.
Campaign performance by mobile operating system
SELECT
campaign.id,
campaign.name,
segments.date,
segments.mobile_device_This kind of query helps isolate whether campaign performance varies materially between iOS and Android and whether those differences are stable over time.
Customer-level OS split for executive reporting
SELECT
customer.id,
segments.date,
segments.mobile_device_This is useful when leadership wants a top-level read on mobile platform behavior across an account rather than within one campaign.
Experiment arm comparison workflow
SELECT
experiment.id,
experiment.name,
experiment_arm.name,
metrics.clicks,
metrics.clicks_point_estimate,
metrics.clicks_margin_of_The exact implementation will depend on the reporting view and field compatibility in your use case, but this illustrates how v24.1’s experiment-oriented metrics can support more rigorous readouts.
These examples matter because many ranking pages summarize features without helping readers picture how they get used. Developers and technical marketers often need both.
What agencies, martech vendors, and in-house teams should prioritize first
The right priorities depend on how a business uses the API.
Agencies should focus first on mobile platform segmentation, experiment reporting, and Demand Gen creative control. Those are the changes most likely to influence performance analysis and client communication.
Martech vendors should focus on productizing the new experiment metrics, adding support for passkey visibility in admin tooling, and reviewing reporting architecture for date-retention implications. Customers will care less that a field was added and more that the platform helps them use it.
In-house performance teams should focus on where the new data changes decision quality. If they run app campaigns, mobile platform segmentation may be the first win. If they run retail or Performance Max-heavy programs, experiment support may be more urgent. If they operate in a tightly governed environment, passkey visibility and retention planning may matter more.
The common thread is this: v24.1 is most valuable when teams connect the release to an existing business problem. New features alone do not create advantage. Better decisions do.
FAQ
What is Google Ads API v24.1?
Google Ads API v24.1 is a point release of the Google Ads API that introduces new reporting capabilities, additional experiment support, Demand Gen creative enhancements, a new passkey visibility field, and supporting changes related to data retention, targeting, and video integrations.
When was Google Ads API v24.1 released?
v24.1 was released on May 13, 2026.
Is v24.1 a major release or a minor update?
It is technically a point release, but in practical terms it is more than a maintenance update. It adds functionality that can affect reporting logic, creative workflows, experiment frameworks, and account governance.
What is the biggest reporting change in v24.1?
For many teams, the biggest reporting addition is segments.mobile_device_, which allows campaign-level and customer-level reporting by mobile operating system. For experimentation-heavy teams, the expanded experiment metric support may be even more important.
What does segments.mobile_device_ actually show?
It allows reporting to distinguish mobile traffic by operating system, such as iOS and Android, rather than grouping all mobile users into one broad bucket.
Why is mobile device platform segmentation important?
Because performance can differ significantly between iOS and Android due to app behavior, checkout flow, browser behavior, attribution setup, device usage patterns, or audience composition. A mobile split is helpful, but an OS split is often more actionable.
Which advertisers will benefit most from the mobile platform segment?
App marketers, ecommerce brands, lead-generation programs with mobile-heavy traffic, and agencies that need cleaner diagnostic reporting across multiple accounts will likely see the most immediate value.
What is classic_display_images in Demand Gen?
It is a field added to DemandGenMultiAssetAd that lets advertisers upload static image creatives for use on the Google Display Network within Demand Gen campaigns. These images can serve as designed rather than requiring additional assets or being treated like a responsive combination.
Why does classic display image support matter in Demand Gen?
Because it gives advertisers more control over branding, layout, and creative testing. It is especially useful for teams that want fixed creative presentation, have strict brand guidelines, or want to test static creative without asset recombination noise.
Does classic display image support replace other Demand Gen asset options?
No. It adds another option. Teams can still use broader multi-asset and more automated creative approaches where those are appropriate.
What is CustomerUserAccess.passkey_?
It is a read-only field that indicates whether a user has a passkey enabled. It helps teams understand account access security status at the user access level.
Why would agencies or platforms care about passkey visibility?
Because account security is an operational issue, not just an IT issue. Agencies, enterprise teams, and software platforms may want to review whether users with important permissions are aligned with stronger authentication practices.
What new experiment types were added in v24.1?
Google added support for ADOPT_AI_MAX, ADOPT_BROAD_, OPTIMIZE_, and PMAX_REPLACEMENT_SHOPPING. It also expanded support for YouTube custom experiment configuration through video_experiment.
Why are experiment updates so important in this release?
Because modern Google Ads strategy increasingly depends on testing automation, asset changes, and campaign-structure shifts in a structured way. The API is becoming a stronger layer for formal experiment management and analysis.
What did Google add to ExperimentArm?
Google added asset_testing_info, asse, and performance_max_. These help support richer experiment representation, especially for asset testing and Performance Max-related use cases.
What are the new experiment metrics in v24.1?
v24.1 adds support for experiment metrics across clicks, impressions, cost, conversions, cost per conversion, conversion value, and conversion value per cost. It also supports point estimates, margins of error, p-values, and certain absolute change metrics for conversions.
Why do p-values and margins of error matter in Google Ads experiments?
Because raw differences alone are not always reliable. Statistical support helps teams judge whether performance movement is likely meaningful or just short-term noise.
What is REQUESTED_DATE_GRANULARITY_?
It is a new date range error added to support Google’s upcoming 37-month retention policy for granular reporting data. It helps indicate when a request asks for daily, hourly, or weekly granularity that is no longer supported for the requested historical range.
What should teams do about the new data retention policy?
They should review long-range reporting workflows now. If the business needs granular historical data beyond the API retention window, it should be stored in the company’s own data environment on an ongoing basis.
When does the 37-month retention policy matter?
It becomes operationally important when teams rely on daily, weekly, or hourly historical data older than the supported retention window. That especially affects data warehouses, reporting systems, audits, and year-over-year analysis tools.
What are the new vertical ad segments in v24.1?
Google added vertical_ads_listing_ and vertical_ads_, along with related filtering support for user_rating, venue, and event_participant_display_ in VerticalAdsItemGroupRu.
Who is most affected by the vertical ad additions?
Teams working in specialized listing-based or vertical-specific ad environments, such as event, local, or venue-related setups, are the most likely to benefit.
What is CANNOT_EXCLUDE_ALL_TARGETS?
It is a new error in CriterionErrorEnum that helps prevent invalid targeting configurations where exclusions would remove all available targets.
Why is that targeting error useful?
Because it provides a clearer safeguard for campaign setup tools, automated targeting logic, and validation layers. It reduces the chance that a system creates a broken or impossible targeting state.
What changed for video in v24.1?
Google published ZEFR as a third-party viewability integration partner and added channel_id to the youtube_video field in the DataLink resource.
Why does channel_id matter?
Because it gives teams a more explicit identifier for linked YouTube video relationships. That can help in analytics, mapping, content governance, and platform logic that depends on more precise YouTube entity handling.
Is v24.1 mainly for developers, or should marketers care too?
Both should care, but for different reasons. Developers need to implement and validate the changes. Marketers and analysts should care because the release affects reporting quality, creative control, experiment structure, and long-term data availability.
Do teams need to upgrade immediately?
That depends on their release calendar, but teams that want to use the new features or prepare cleanly for upcoming retention-related changes should not delay planning. Even if the upgrade is not immediate, the review work should start early.
What is the best way to test a v24.1 upgrade?
Use a staging or sandbox environment, update client libraries, review affected reporting and campaign workflows, validate field compatibility, and compare key outputs before and after implementation. Pay special attention to reporting, experiment tooling, and Demand Gen asset flows.
What is the biggest mistake teams make with point releases like v24.1?
Treating them as library updates instead of operational changes. The cost of that mistake is usually not an immediate outage. It is a slow accumulation of reporting confusion, missed feature usage, and preventable support issues.
Will v24.1 change campaign performance on its own?
No. The API release does not automatically improve performance. What it changes is visibility, control, and measurement. Performance improves only if teams use those new capabilities well.
Which part of v24.1 is likely to have the longest-term impact?
The answer will vary by business, but the experiment metrics and the retention-policy preparation may have the broadest long-term impact because they shape how organizations evaluate change and preserve historical reporting continuity.
Should teams update dashboards because of v24.1?
In many cases, yes. Mobile platform segmentation and experiment metric support are strong candidates for dashboard updates. Teams should also review whether historical granular reporting assumptions need to change.
Is this release especially relevant for Performance Max users?
Yes, particularly because of the experiment support additions and the general direction toward more structured testing around automated campaign types.
Is this release especially relevant for Demand Gen advertisers?
Yes. The classic display image support is one of the clearest practical enhancements in the release for creative workflow and brand-control purposes.
Is this release important for agencies with many client accounts?
Absolutely. Agencies benefit from better segmentation, stronger testing support, improved security visibility, and clearer planning for retention-related reporting changes across large account portfolios.
What should an executive or non-technical stakeholder take away from v24.1?
That Google is continuing to improve the infrastructure around automated advertising: more ways to measure it, more structured ways to test it, and more signals that advertisers should strengthen data governance and reporting architecture around it.
If your team uses the Google Ads API heavily, v24.1 is worth treating as a practical operations release rather than a background technical update. The mobile platform segment gives cleaner performance analysis. Classic image support in Demand Gen gives advertisers more direct creative control. Expanded experiment types and statistical metrics make testing more disciplined. The passkey field improves visibility into access security. And the new date granularity error is an early prompt to get historical data practices in order before the retention window becomes a real constraint.
None of those changes are flashy on their own. Together, they move the API in a direction that favors more mature advertisers: teams that want cleaner measurement, better testing structure, tighter governance, and fewer blind spots between campaign automation and business decision-making. That is what makes this release important.
About ALM Corp
ALM Corp helps brands, agencies, and marketing technology teams turn advertising platforms into reliable operating systems for growth. That includes paid media strategy, performance marketing execution, analytics, reporting architecture, creative support, and technology implementation that makes campaign data more actionable. For organizations working with the Google Ads API, that kind of support matters when releases like v24.1 affect reporting models, experiment frameworks, Demand Gen workflows, and long-term measurement planning. ALM Corp works at the point where media, data, and systems meet, helping teams upgrade more cleanly, report more accurately, and make better decisions from the tools they already rely on.
