Google published a new reportData.query endpoint on August 12, 2026, letting Campaign Manager 360 developers retrieve performance data in a single synchronous call. A separate documentation update makes conversion categories a required field on Floodlight activities enabled for attribution.

Google shipped a reporting endpoint for the Campaign Manager 360 API on Wednesday, August 12, 2026, collapsing what had been a four-step retrieval sequence into one HTTP request. The announcement appeared on the Google Ads Developer Blog under the byline of Lindsey Volta, writing on behalf of the Campaign Manager 360 API Team. On the same day, Google Marketing Platform's Help Center carried a separate article describing a category system for Floodlightactivities, which introduces a required field for any activity with attribution switched on.

The two changes reached practitioners together, and they arrived as part of a wider set of interface revisions. Jonathan D'Souza-Rauto, a martech and adtech consultant, published a summary of four Campaign Manager 360 changes on LinkedIn and followed it with separate posts linking to the developer blog entry and the Help Center page. The summary post had drawn nine reactions and four comments at the point of capture. A global product strategy lead for Campaign Manager 360 responded to the link posts without written commentary.

Two of the four items D'Souza-Rauto described are covered by the published Google documentation. The other two are interface changes that the documentation attached to this article does not address, and they are reported here as a practitioner account rather than as confirmed platform behaviour.

What the reportData.query endpoint does

According to Google, the new endpoint allows developers to synchronously query campaign performance data and receive structured JSON directly in the response body. Three properties define it.

First, queries execute synchronously under a 60-second ceiling. Google positions this constraint as the feature rather than a limitation, describing the endpoint as suited to real-time dashboards and ad-hoc data explorations. Anything that cannot complete inside a minute is out of scope by design.

Second, report data comes back as structured JSON inside the HTTP response. According to the announcement, this removes file management overhead. No file is written, no download URL is issued, and no storage layer sits between the query and the consuming application.

Third, and most consequential for existing integrations, the endpoint drops the requirement to create a preconfigured Report resource before fetching anything. Dimensions, metrics and filters are specified directly in the request body. The report definition and the report execution become a single operation.

The workflow it replaces

The contrast Google draws is explicit. The existing Reports service requires developers to create and manage Report configurations, trigger a run of the report, poll for status updates, and then download the report file. Four discrete stages, each with its own failure modes: a stale configuration, a run that never completes, a polling loop that hangs, a download that times out.

That architecture made sense when reporting meant nightly batch jobs writing to a warehouse. It has aged less well against dashboard tooling that expects a query interface. Teams building internal reporting layers on top of Campaign Manager 360 have generally had to construct their own abstraction over the polling cycle, caching results and managing retry logic that the platform did not supply.

D'Souza-Rauto framed the shift in terms of the legacy method it displaces, describing the ability to pull a report through queries rather than the legacy Report ID method as "a game changer for anyone trying to automate CM360 reporting (at low volumes) or define workflows like QA processes." The parenthetical qualifier matters. Low volume is the operating range the 60-second ceiling permits, and quality assurance checks are precisely the kind of small, repeated, throwaway query that the four-stage service handled poorly.

Where the existing Reports service still applies

Google did not deprecate anything. The Reports service remains the recommended path for retrieval of large datasets, for scheduled jobs, and for applications that depend on downloadable report files in CSV or Excel format. The 60-second execution limit is the practical dividing line. A query spanning a year of placement-level delivery across a large advertiser will not return inside a minute, and the file-based service continues to exist for exactly that case.

This is a bifurcation rather than a migration. Google has spent the past two years consolidating advertising data operations onto fewer endpoints, and the Data Manager API has been the clearest expression of that pattern on the ingestion side. Reporting is moving in a different direction: two services, each tuned to a different access pattern, running in parallel.

Google directed developers to a Query Report Data guide covering request parameters, pagination and best practices, to a Reporting Overview comparing the two approaches, and to REST reference documentation for the endpoint. The blog post carried the labels dfa_api, dfa_reporting_api and reporting, placing it within the long-running DoubleClick for Advertisers API lineage that Campaign Manager 360 inherited.

Floodlight activities gain a mandatory category layer

The second document covers a different part of the stack. Categories are labels applied to Floodlight activities to group them by the type of action they measure, and according to Google the selection allows more alignment between category features and data models across Search Ads 360, Campaign Manager 360 and Display and Video 360.

Google lists three benefits. Better organization gives a standardized way to group conversions. Cross-product consistency aligns Campaign Manager 360 and DV360 with how conversions are handled in Google Ads and Search Ads 360. The third is forward-looking: according to the documentation, classifying Floodlight activities "can enable more advanced and privacy-safe measurement and modeling features in the future."

That third benefit is the one worth reading closely. Conversion modeling depends on knowing what kind of event is being modeled, because the behavioural priors for a purchase differ from those for a newsletter sign-up. A taxonomy is a precondition for the modeling layer, not a filing convenience.

The 14 categories

The taxonomy splits into three groups.

Sales contains four values: Purchase, Add to cart, Begin checkout, and Subscribe (paid).

Leads contains seven: Contact, Submit lead form, Book appointment, Sign-up, Request quote, Get directions, and Outbound click.

More categories contains three: Page view, Qualified lead, and Converted lead.

Selecting a category after attribution is enabled is a required step when creating or editing Floodlight activities in Campaign Manager 360 or DV360. A Category column appears in the Floodlight activities summary and attribution views. According to Google, the default category is disallowed when creating new Floodlight conversion actions, which forecloses the usual escape route of leaving a required field at its placeholder value.

How categories propagate across products

Synchronisation behaviour is asymmetric, and the asymmetry is where operational risk sits.

Categories sync across Search Ads 360, Campaign Manager 360 and DV360 at the moment a Floodlight activity is created. Subsequent changes made in one product do not sync across the others. That single sentence governs everything downstream.

For Search Ads 360 specifically, a new Floodlight activity created in Campaign Manager 360 or DV360 pushes its category to all linked Search Ads 360 advertisers. Editing the category inside Search Ads 360 afterwards applies only to that one advertiser; it does not travel back to Campaign Manager 360 or DV360, nor sideways to other Search Ads 360 advertisers sharing the configuration. Editing the category later in Campaign Manager 360 or DV360 leaves existing conversion copies in Search Ads 360 untouched. One exception applies: a Search Ads 360 advertiser newly linked to a Floodlight configuration after a change was made in Campaign Manager 360 receives the most recent category from Campaign Manager 360.

The result is a system that can drift. An agency managing a shared Floodlight configuration across several Search Ads 360 advertisers can end up with the same activity carrying different category labels in different accounts, with no interface signalling the divergence.

DV360 behaves more simply. A category edit in Campaign Manager 360 is reflected in DV360, and DV360 is read-only for this field, so a DV360 user cannot alter the category of a Campaign Manager 360-owned Floodlight activity. Ownership determines authority.

Google also notes that where a Floodlight configuration is shared with a Search Ads 360 account, advertising accounts retain control of their own bidding settings. Category assignment and bidding control are handled separately.

Third-party imports and automatic assignment

Activities imported from sources such as Google Analytics or Firebase have their category set automatically from the event name. A purchase event is assigned the Purchase category. A first_open app event is assigned the Download category. According to Google, the category for these key system events is often not editable "in order to maintain measurement consistency."

The rationale is defensible. If a purchase event could be relabelled as a page view in one product, cross-product conversion models would train on contradictory inputs. Locking system events preserves the integrity of the taxonomy at the cost of flexibility for advertisers with unconventional event naming.

There is a wrinkle. Download does not appear anywhere in the list of 14 selectable categories in the same document. It exists as an automatic assignment for first_open events without being available for manual selection, which suggests either a documentation gap or a category reserved for system events. Google's page does not resolve the point.

Structured Data Files and the API

Categories can be managed through Structured Data Files and through the API, and Google states this route is likewise required for activities enabled for attribution. In bulk edits, a new category field appears and becomes mandatory when Attribution enabled is set to TRUE. The same field has been added to the Floodlight Activity resource.

For teams running bulk trafficking operations, this is the change with the most immediate technical footprint. SDF templates and API integrations that construct Floodlight activity payloads will need the field populated wherever attribution is on. A pipeline that omits it fails validation.

Filtering and reporting

Categories function as a filter inside the Campaign Manager 360 trafficking workflow, with multiple categories selectable simultaneously, and they appear as a visible dimension in the Activities table.

On the reporting side, two dimension names carry the data. DV360 Instant reports expose it as Floodlight Activity Conversion Category. Campaign Manager 360 reports expose it as Activity Conversion Category, available in the Standard report type. The naming diverges between products even though the underlying field is shared.

A terminology rename and a settings rebuild

Beyond the two documented changes, D'Souza-Rauto reported a rename running through the Campaign Manager 360 interface. According to his account, "Floodlight Activities / Activities Groups / Activity Tag Strings are no more," replaced by Floodlight Conversions, Conversion Groups and Conversion Tag Strings. He attributed the change to alignment with the wording used across other Google products and with how pixels are described more generally.

The Help Center article on categories, published in the same window, still uses the older vocabulary throughout: Floodlight activities, Floodlight Activity resource, Activities table. Documentation lagging an interface rename is common enough, but the gap is worth noting for anyone matching interface labels against support pages or API field names. The Floodlight Activity resource referenced in the categories documentation retains its original name.

The fourth item concerns how conversion settings are configured. D'Souza-Rauto described settings consolidated into a Count and Value parameter pair sitting alongside the Enhanced Conversions checkbox, calling the arrangement "a carbon copy of how Google Ads operates," with "no more bespoke distinction between Counter vs Sales tags."

That distinction has been structural in the DoubleClick lineage for years. Counter tags recorded that an action happened; Sales tags recorded transaction value and item quantity. Advertisers picked one at tag creation, and the choice constrained what could be measured afterwards. Folding both into parameter settings on a single conversion object removes a decision made at setup time and defers it to configuration. It also brings the ad server's conversion model closer to the one used in Google Ads, which has never carried the counter and sales split.

The bidding rationale

On why categories are becoming compulsory, D'Souza-Rauto offered an interpretation that goes further than Google's documentation. He wrote that the move is aimed at bringing "more algorithmic signals to the machine learning behind bidding in the Google platforms," and drew a comparison with how Meta trains on aggregated data through its Pixel and Conversions API. He tied the requirement specifically to events used with Search Ads 360 for search and DV360 for programmatic.

Google's own framing is narrower. The Help Center article cites organization, cross-product consistency and future measurement capability, and refers to enabling "more advanced and privacy-safe measurement and modeling features in the future" without naming bidding as the destination. The two readings are compatible. A classified conversion taxonomy is the kind of input that automated bidding systems consume, and Google has built category-aware conversion goals into Google Ads and Search Ads 360 already. But the causal claim that categories exist to feed bidding models is inference, not something Google has stated in the material published on August 12, 2026.

Why this matters for the marketing community

Category settings for Floodlight activities are not new in principle. Google introduced them as part of the Q3 2025 reporting changes, scheduled for July 7, 2025, with the stated aim of aligning Campaign Manager 360 and DV360 with the category functionality that already existed in Google Ads and Search Ads 360. At that point the documentation flagged that existing Floodlight activities would require category assignment before editing. What the August 2026 Help Center article adds is the completed operational picture: the specific taxonomy, the synchronisation rules, the SDF and API requirements, and the reporting dimensions.

The reporting endpoint lands in a platform that has been steadily reorganising its data surfaces. Floodlight and Inventory Availability reports were migrating from legacy offline reporting to instant reporting from June 2026, in a phased rollout initially affecting 10% of users, as part of a roadmap of twelve platform changes running through August 2026. Earlier in the year, Inventory Availability reports moved into the DV360 Instant Reporting interface alongside new campaign-level and placement-level dimensions for Unique Reach Overlap reports. The direction of travel is consistent: fewer offline file handoffs, more immediate query access.

On the ingestion side, the same consolidation logic produced the Data Manager API. Version 1.7, published on May 28, 2026, extended offline conversion event ingestion to Campaign Manager 360, Search Ads 360 and DV360 for the first time, adding a dclid field that let advertisers tie offline events back to display and video clicks. That release followed a unified ingestion architecture intended to replace separate pipelines for audiences, conversions and Analytics data. Reporting is now receiving a comparable simplification, though without the deprecation pressure that accompanied the ingestion migrations.

For measurement teams, the two announcements interact. A required category field means conversion data leaving Campaign Manager 360 carries a taxonomy label, and the reporting layer now exposes that label as a dimension. A dashboard built on the synchronous endpoint can segment Floodlight performance by conversion type without a nightly file drop. Whether that segmentation is trustworthy depends entirely on whether categories were assigned consistently across a shared Floodlight configuration, and the synchronisation rules make consistency something that has to be enforced rather than assumed.

Attribution changes have arrived at this stack repeatedly. Enhanced attribution was switched on automatically for Display and Video 360 and Campaign Manager 360 advertisers from September 30, 2024, appending a DCLID identifier to non-YouTube click events. In November 2025, Google added a gclsrc parameter to TrueView landing URLs and shifted Campaign Manager 360 to begin-to-render impression counting. Each change adjusted what the measurement layer records. The category field adjusts how those records are classified.

Agencies that treat Floodlight as a set of loosely named pixels accumulated over years now face a taxonomy that the platform enforces at the point of edit. The 14 values are fixed, the default is disallowed, and the field is mandatory whenever attribution is enabled. Naming conventions built internally over a decade will have to map onto Google's three groups, and where they do not map cleanly, someone has to decide which value is closest.

Timeline

Summary

Who: Google's Campaign Manager 360 API Team, with the developer blog post published under the byline of Lindsey Volta. Martech and adtech consultant Jonathan D'Souza-Rauto documented the accompanying interface changes publicly. The changes affect developers, agency ad operations teams, and measurement staff working with Campaign Manager 360, Display and Video 360 and Search Ads 360.

What: Two documented changes and two reported interface revisions. A new reportData.query endpoint in the Campaign Manager 360 API returns campaign performance data as structured JSON in a single synchronous call, with a 60-second execution limit and no requirement to create a preconfigured Report resource. A Help Center article defines 14 conversion categories for Floodlight activities across three groups, Sales, Leads and More categories, and makes category selection a required field for any activity with attribution enabled. Alongside these, a practitioner account describes a rename of Floodlight Activities, Activity Groups and Activity Tag Strings to Floodlight Conversions, Conversion Groups and Conversion Tag Strings, and a consolidation of conversion settings into Count and Value parameters beside the Enhanced Conversions checkbox, ending the Counter and Sales tag distinction.

When: The developer blog post was published on Wednesday, August 12, 2026. The Floodlight category documentation carries a 2026 Google copyright notice and surfaced publicly on the same date. Category settings for Floodlight activities were first introduced in July 2025.

Where: The endpoint applies to the Campaign Manager 360 API globally. The category field applies in Campaign Manager 360 and Display and Video 360 interfaces, in Structured Data Files, in the Floodlight Activity API resource, and in reporting through the Floodlight Activity Conversion Category dimension in DV360 Instant reports and the Activity Conversion Category dimension in Campaign Manager 360 Standard reports.

Why: The endpoint removes the configure, trigger, poll and download sequence for small and time-sensitive queries, while the existing Reports service remains recommended for large datasets and scheduled jobs. The category system standardises conversion classification across Google's advertising products, which Google frames as a precondition for more advanced and privacy-safe measurement and modeling features. D'Souza-Rauto attributes the mandatory categories to the need for more algorithmic signal in Google's bidding models, an interpretation that Google's published material does not state.