Tag: API

Google Ads AI Transparency: A Practical Audit Framework

When Google Ads can rewrite the product title a shopper sees, knowing what you entered in Merchant Center is no longer enough. And when an AI coding assistant can generate integrations, troubleshoot failures, and query a live advertising account, working code is no longer sufficient proof that the work is correct.

You need an evidence chain: what the AI changed, what rules or schema supported the change, what actually ran or served, and what happened afterward. Two Google Ads developments make that easier: reporting for AI-generated Shopping titles and a schema-aware Google Ads API assistant. Used carefully, they let you audit automation without giving up its speed.

Treat Google Ads AI as two separate control problems

Google Ads AI acts at more than one point in the advertising workflow. The control you need depends on where the automation operates.

AI layer	What can change	Evidence available	Your control decision
Ad delivery	The product title presented in a Shopping ad	Original and customized titles plus impressions, product clicks, CTR, cost, and average CPC	Determine whether the generated wording preserves product identity and attracts useful traffic
API development	Integration code, GAQL queries, diagnostics, and reporting workflows	Google Ads-specific rules, GAQL validation, Protobuf schema inspection, and live query results	Determine whether the implementation is valid for the intended API version, account, and business question

The first layer is a message-governance problem. The second is a software-governance problem. Combining them under a vague instruction to “monitor the AI” produces weak reviews because the artifacts, risks, and owners are different.

Use the same principle for both: never approve an AI output without identifying the input, the transformation, and the observed result. A generated title is an output. So is a valid GAQL query. Neither tells you by itself whether the outcome serves your commercial intent.

Audit the product title shoppers actually see

A magnifying glass compares a source product record with an AI-processed shopping listing shown on a smartphone.

Google AI can create a customized product title and serve it when it considers that version more relevant than the advertiser-provided title. The original remains eligible to appear when Google considers it more relevant. The practical consequence is simple: your feed title is an input to ad delivery, not a guarantee of the final wording.

The Product titles report is beginning to appear in Google Ads, so availability may not be uniform across every account. Where it is available, it can place the original and AI-customized titles beside delivery and traffic metrics. That gives you something much more useful than a general notice that automation may alter copy: it gives you inspectable examples.

Review meaning before performance

Start by checking whether the generated title still identifies the product accurately. A higher CTR cannot repair a title that creates the wrong expectation.

Compare the identifying details. Check whether the generated wording preserves the brand, model, product type, variant, size, material, compatibility, or other detail a buyer needs to distinguish the item.
Look for a change in promise. Flag wording that implies a feature, bundle, use case, audience, or level of compatibility that the product page does not support.
Check brand and legal sensitivity. Route regulated claims, trademarks, guarantees, and tightly controlled brand language to the appropriate reviewer before treating the title as acceptable.
Inspect the landing-page match. A title may be technically accurate but still emphasize something the landing page does not make easy to find. That mismatch can attract a click while weakening the visit.
Classify the change. Record whether the generated title clarifies the product, rearranges existing details, introduces a new interpretation, or removes a distinguishing detail. This turns isolated examples into patterns you can act on.

When generated titles repeatedly clarify information that was buried or absent in your originals, treat that as a feed-quality hypothesis. Do not merely admire the AI version. Ask whether the original titles should communicate the same useful distinction more directly.

Read the metrics as observation, not a controlled test

The report can include impressions, product clicks, CTR, cost, and average CPC. Those measures answer different questions:

Impressions show how much exposure a title received. A dramatic-looking CTR difference attached to limited exposure deserves caution.
Product clicks show traffic volume, but not whether those visitors produced valuable outcomes.
CTR describes the rate at which impressions produced clicks. It can help you spot wording that attracts attention, but it does not establish why the difference occurred.
Cost and average CPC show the price of the traffic. They do not, by themselves, establish revenue, margin, lead quality, or profitability.

Do not label this comparison an A/B test unless you have a genuinely controlled experimental design. Google may select an original or customized title because it considers one more relevant in a particular serving context. Different contexts can therefore influence both which title appears and how it performs. The report reveals an association between a served title and its results; it does not automatically isolate the title as the cause.

Your decision should combine three checks: semantic accuracy, sufficient exposure, and downstream business value from your existing measurement setup. A title that earns more clicks but brings poorly matched visitors is not an improvement.

Make the API assistant prove technical validity

Google Ads API Developer Assistant v4.0.0 moves from the earlier standalone local-workspace structure to a globally available plugin architecture. It can supply Google Ads-specific rules, skills, and diagnostic commands across projects. The architecture is not compatible with previous releases, so adopting version 4 should be treated as a migration rather than a routine in-place update.

The assistant supports AI coding workflows in Antigravity and Claude Code. It can generate integration code for Python, Java, PHP, .NET, and Ruby. More importantly for reliability, it can inspect local Protobuf schemas and client-library code instead of depending entirely on what the underlying model remembers about Google Ads.

That grounding is most useful when you require it as part of the workflow. Use this review sequence:

Identify the intended API version. Record it with the task so a reviewer can distinguish current fields and enums from suggestions that belong to another version.
Inspect the relevant schema before accepting generated code. Confirm resource names, available fields, data types, and enum values against the active version.
Validate every GAQL query before execution. The local validator can check syntax, field compatibility, date segmentation, resources, metrics, date clauses, and zero-impression rules in one pass.
Review account and time context. Before a natural-language request runs against live data, verify the customer ID, manager-account relationship where relevant, date range, segments, metrics, and expected level of aggregation.
Read the generated code as code. Schema validity does not replace review of authentication, account selection, data handling, error paths, and whether the integration performs only the operations you intended.
Save a reproducible result. The assistant can return live results as a formatted table and can save ad hoc reporting output as CSV. Preserve the validated query with the output so another person can reproduce what was retrieved.

This approach is faster than asking a general-purpose model to guess at a broken query over multiple attempts. It is also safer because the query is checked against Google Ads-specific constraints before it reaches the account.

Use conversational troubleshooting as triage

The assistant can investigate offline conversion upload failures, manager-account hierarchy problems, and Performance Max listing filters. It can also help answer broader questions, such as which ads have problems and how those problems might be addressed.

Treat the response as structured triage. Ask it to identify the failing object, inspect the applicable schema, show the relevant error or rule, and separate confirmed findings from proposed fixes. Then review the recommendation before changing production code or campaign configuration. A conversational explanation is easier to consume than a raw error, but readability is not evidence.

Know what grounding does not prove

Schema inspection and local validation reduce a specific class of AI failure: invented fields, incompatible combinations, and version-mismatched configurations. They do not prove that the request reflects the business question you meant to ask.

Syntactic validity: Can the query be parsed? The validator can address this.
Schema validity: Do the resources, fields, metrics, types, and enums exist and work together for the active version? Schema inspection and Google Ads-specific rules can address much of this.
Account validity: Is the query running for the correct customer, through the intended manager hierarchy, over the correct dates? The assistant can help retrieve customer IDs and diagnose hierarchy issues, but you still need to confirm the intended account context.
Business validity: Does the output answer the decision you need to make? A perfectly valid cost query is still wrong if the decision depends on profitable conversions or qualified leads.

The same distinction applies to Shopping titles. Transparency shows you the generated wording and associated performance. It does not prove the wording is accurate, brand-safe, incrementally better, or responsible for the observed result.

Google says the plugin architecture improves speed and reduces resource and token consumption by loading only the rules and schemas needed for a task, with caching to avoid repeated lookups. Those efficiency claims are useful for adoption planning, but they are separate from auditability. Faster generation changes how quickly work arrives; it does not lower the review standard.

Build one evidence trail across marketing and development

Marketing and engineering specialists inspect a connected evidence trail linking product data, validated code, live advertising outputs, and archived outcomes.

You do not need a large governance program to make these tools accountable. You need a compact record that joins the AI output to the decision made about it.

For AI-generated product titles, record the product or internal SKU, original title, generated title, review classification, impressions, product clicks, CTR, cost, average CPC, relevant downstream outcome from your measurement system, reviewer, and decision. This is your internal audit log; it should not be confused with a claim that every field appears in the Product titles report.

For API work, record the customer context, intended API version, client language, user request, generated GAQL or code, validation result, schema fields inspected, date clauses, output location, reviewer, and deployment decision. If the work concerns an offline conversion upload, account hierarchy, or Performance Max listing filter, preserve the original failure details with the diagnosis.

Assign ownership by artifact:

The feed owner is accountable for the original product data and for recurring weaknesses exposed by generated titles.
The performance marketer assesses title accuracy, delivery metrics, traffic quality, and the business relevance of the comparison.
The developer owns API-version selection, schema verification, query validation, code review, and reproducibility.
The appropriate brand, compliance, or business owner approves wording or implementation decisions that exceed the marketer’s or developer’s authority.

Use event-based reviews instead of checking everything indiscriminately. Review when customized titles first appear, after meaningful feed changes, when a high-impression title changes the product’s meaning, before adopting the incompatible version 4 plugin architecture, before deploying generated integration code, and when a known troubleshooting case affects reporting or conversion data.

Key takeaways

Google may serve an AI-customized Shopping title instead of the title you supplied, so audit the message that appeared rather than assuming feed copy reached the shopper unchanged.
Use the Product titles report to inspect original and generated titles with impressions, product clicks, CTR, cost, and average CPC, but do not mistake an observational comparison for a controlled experiment.
Check semantic accuracy before celebrating performance. More clicks are not useful when the title attracts the wrong buyer or changes the product promise.
Require the Google Ads API Developer Assistant to inspect the active schema and validate GAQL before execution. A fluent answer without those checks is weaker evidence.
Separate syntax, schema, account context, and business intent. An implementation can pass the first two tests while still answering the wrong question.
Keep an internal record connecting each AI output to its input, validation evidence, reviewer, observed result, and final decision.

Start with the Shopping products receiving the most impressions and one API workflow where validation failures currently consume time. Establish the evidence record there, assign an owner, and make approval depend on inspectable proof. The aim is not to block automation. It is to shorten the distance between an AI-made change and your ability to understand, verify, and correct it.

References

August 26, 2026

Google Ads API v25.1: A Practical Measurement Playbook

If you pull Google Ads data into a warehouse, dashboard, or client-facing platform, adding fields is the easy part. The harder job is deciding which business question each field can answer without turning unlike signals into one misleading performance score.

Google Ads API v25.1 gives you several useful separations: original versus adjusted conversion value, attributed results versus incremental lift, internal performance versus category benchmarks, and total converters versus loyalty segments. Used carefully, those distinctions can make your reporting more explainable. Used carelessly, they can produce a wider dashboard that is no more trustworthy than the old one.

Key takeaways

Store original_conversion_value beside the corresponding adjusted value. The difference shows how conversion value rules and customer lifecycle goals are changing the values used downstream.
Treat Conversion Lift and Brand Lift as distinct measurement layers. Their API resources are read-only, and access is currently limited to allowlisted Google Ads accounts.
Use Product & Service Category benchmarks as context for investigation, not as automatic bidding instructions.
Keep brand sentiment separate from campaign outcomes. It can guide review and creator analysis, but it does not establish incremental impact.
Model loyalty tier, loyalty membership conditions, and conversion value as separate fields so you can explain who converted and why a value adjustment applied.
Although v25.1 is a drop-in upgrade for v25, you still need updated client libraries, code changes for the new capabilities, and semantic regression tests before using the data in decisions.

Build your measurement model around six different questions

The most important design choice is not which new metrics to retrieve. It is which question each capability answers. A clean measurement model keeps the following layers separate:

Business question	v25.1 capability	Appropriate use
What was the conversion worth before Google applied value adjustments?	original_conversion_value	Audit the effect of value rules and lifecycle goal adjustments.
Did advertising create incremental conversions or awareness?	Conversion Lift and Brand Lift resources	Inspect eligible lift studies, configurations, dimensions, and results.
How does performance compare with a relevant market category?	BenchmarksService with Product & Service Categories	Add competitive context to internal performance analysis.
What sentiment is associated with a creator or brand?	ContentCreatorInsightsService sentiment data	Support creator intelligence, brand review, and reporting workflows.
Which loyalty groups converted, and did membership affect value?	Loyalty tier segmentation and loyalty membership dimensions	Analyze converters by tier and explain membership-based value rules.
How might parental-status targeting affect planned reach?	ReachPlanService targeting	Use parental status in forecasting and plannable product discovery.

Do not collapse these capabilities into a composite campaign health score. A strong benchmark, positive sentiment, and positive lift are different observations with different scopes. Combining them can hide the exact information a decision-maker needs.

Make original conversion value an audit layer

The new original_conversion_value metric exposes the value of a biddable conversion before conversion value rules or customer lifecycle goal adjustments. That distinction matters whenever the value used for reporting and optimization is not identical to the underlying conversion value.

For each compatible reporting grain, preserve at least three concepts in your own model:

Original value: the pre-adjustment value returned by original_conversion_value.
Adjusted value: the corresponding value after the applicable rules or lifecycle adjustments.
Adjustment delta: adjusted value minus original value, calculated in your reporting layer.

Report the absolute delta before reaching for a percentage. A percentage becomes undefined when the original value is zero and can look extreme when the denominator is small. If you do show a percentage, define how zero and missing values are handled instead of letting a dashboard silently convert them into zeros.

The delta is not evidence that Google changed a value incorrectly. It tells you that an adjustment occurred. Your next question is whether that adjustment matches the value rule or lifecycle policy your team intended. Where your system already stores rule metadata, expose it beside the delta so an analyst can move from detection to explanation.

Do not replace an established revenue or return-on-ad-spend metric with original_conversion_value in one step. That can change budget conclusions simply because the definition changed. Run original and adjusted value in parallel, reconcile known value-rule cases, and label both clearly before either number reaches automated budget logic.

Keep lift, benchmarks, and sentiment in their own lanes

Lift data needs its study context

Google Ads API v25.1 adds read-only resources for Conversion Lift and Brand Lift studies. You can inspect configurations, flight dates, associated campaigns, and conversion goals. The API also adds 24 Conversion Lift metrics, winner score metrics for statistical analysis, and Brand Lift dimensions covering age range, campaign, device, gender, and video.

Read-only is an important boundary. Build your integration to retrieve and explain study data, not to promise study creation or modification through these resources. Put configuration and result data in the same analytical view: a result without its flight dates, campaign scope, and conversion goal is easy to apply to the wrong period or objective.

Access is another boundary. Brand Lift and Conversion Lift API capabilities are currently limited to allowlisted accounts, and advertisers are directed to contact their Google representative for access. Check eligibility before committing a delivery date. In a multi-account platform, treat eligibility as an account-level capability rather than assuming that one successful request means every account is supported.

Your internal presentation should distinguish at least four states: supported with data, supported with no returned data, unavailable because eligibility has not been established, and failed because the request encountered an error. Those are product states you define in your application, not API status labels. Keeping them separate prevents an access limitation from being reported as a zero lift result.

Winner score metrics should retain Google’s metric names and definitions in your semantic layer. Do not relabel a winner score as probability, certainty, or incremental return unless the applicable definition supports that interpretation. The safe workflow is to display the score with its study scope, then let the measurement owner determine how it informs a campaign decision.

Category benchmarks provide context, not a target

BenchmarksService can now compare performance within specific Product & Service Categories and return aggregate cost and views alongside share-based measurements such as share of voice. The narrower category dimension can make a comparison more relevant than a broad benchmark group, but relevance still depends on whether the selected category represents the business being evaluated.

Before placing a benchmark beside an account metric, document the category, measurement window, metric definition, and any other comparability controls available in your query. If those elements differ, show the benchmark as external context rather than a direct performance gap.

A share metric and an aggregate volume metric also answer different questions. Share of voice describes relative presence, while aggregate cost and views add scale context. Show both when available. A low share in a large category may deserve a different response from the same share in a small category.

Do not let a benchmark variance trigger bid or budget changes automatically. The comparison may identify an issue worth investigating, but it does not tell you whether the right response is more spending, different creative, narrower targeting, or no change at all. Route the variance into an analyst review that also considers the account’s own goals and economics.

Brand sentiment is an intelligence signal

ContentCreatorInsightsService now supports brand sentiment distributions and summaries for creators and brands. That gives advertising platforms another signal for creator research and brand reporting, but sentiment should not be presented as conversion performance or causal campaign impact.

Use the distribution when you need to understand the mix behind a summary. A single summary can conceal whether sentiment is consistently moderate or sharply divided. The practical use is triage: identify creators or brands that warrant closer review, then examine the relevant campaign and brand context before acting.

Connect loyalty reporting to value-rule governance

Google Ads API v25.1 allows reporting metrics to be segmented by the loyalty program tier of users who converted. It also makes loyalty membership a primary dimension for conversion value rules, allowing you to identify when a loyalty membership condition was satisfied.

Those capabilities describe two related but different facts:

Loyalty tier segmentation tells you which tier is associated with a converting user.
Loyalty membership as a value-rule dimension tells you whether a membership condition was met when a conversion value rule was evaluated.

Do not infer the second from the first. A converter’s tier is an audience attribute; a satisfied rule condition is part of value-processing logic. Store them separately even if your first dashboard shows them together.

The most useful loyalty analysis combines tier segmentation with the original-versus-adjusted value audit. Start with these questions:

How many conversions and how much original conversion value came from each returned tier?
How much adjusted conversion value was reported for those same segments?
When a loyalty membership condition was satisfied, did the resulting delta match the intended value policy?
Are any apparent differences driven by a small number of conversions rather than a stable segment pattern?

Always report conversion volume beside value when reviewing tiers. A high average value from a small segment can dominate a ranking without providing a dependable basis for budget changes. You do not need an invented universal threshold; you need enough context for the owner of the loyalty program to judge the segment responsibly.

Parental-status targeting in ReachPlanService belongs in a different part of your model. It expands reach forecasting and plannable product discovery; it is not an observed conversion result. Keep forecast inputs and planned reach outside outcome tables so users cannot mistake a planning scenario for delivered performance.

Roll out v25.1 without changing metric meaning by accident

Google describes v25.1 as a drop-in upgrade for v25, but access to the new capabilities still requires the latest client libraries and corresponding code updates. Drop-in compatibility reduces migration friction; it does not replace testing of your transformations, labels, and downstream decisions.

Inventory the current integration. Record the v25 services, fields, generated client types, transformation jobs, dashboards, and automated decisions that could be affected.
Update the client library in an isolated change. Confirm that the existing extraction and build processes still work before requesting new resources or metrics.
Regression-test existing outputs. Run representative unchanged queries through the old and upgraded paths. Compare row grain, identifiers, null handling, totals, and field mappings.
Add one capability group at a time. Original conversion value, lift studies, benchmarks, sentiment, loyalty, and reach planning should enter separate staging models. This makes a semantic error easier to locate.
Model access explicitly. Check allowlist eligibility for lift features and make unavailable capabilities visible to the user. Do not coerce an unavailable response into zero.
Validate with known business logic. For accounts using conversion value rules or lifecycle goals, select known cases and verify that the original-to-adjusted relationship matches the configured intent.
Release reporting before automation. Let analysts inspect the new fields and definitions in read-only dashboards before any benchmark, sentiment, loyalty, or value delta changes bids, budgets, or alerts.

Give every new metric a short data contract. It should name the business question, API service or resource, reporting grain, raw and derived fields, eligibility requirement, refresh process, null policy, and downstream decision. That document is what stops an accurate field from becoming a misleading KPI six months later.

If you need one place to start, add original_conversion_value as a parallel audit field and trace its path through your warehouse and reports. Then add category benchmarks and loyalty segmentation as separate analytical views. Treat lift integration as its own workstream because account eligibility and study context must be resolved first. Your next API pull should not merely contain more columns; it should make the path from underlying value to business decision easier to explain.

References

Search Engine Land – Google Ads API v25.1 expands measurement and insights

August 20, 2026

Paid Media Conversion Measurement: What to Change Now

Your paid media dashboard can keep filling up while the measurement underneath it becomes less dependable. The practical fix is not another master metric. You need to strengthen how outcome events reach Microsoft Advertising and change how your team interprets branded-search activity in Google Ads.

Those are separate jobs. One improves event collection when browser signals are limited. The other exposes a consideration signal that sits between an ad impression and a conventional conversion. If you combine them indiscriminately, you can end up with a larger conversion total and a weaker understanding of performance.

Separate event collection from campaign interpretation

The most important distinction is between how an event is captured and what the event means. Microsoft Advertising’s Conversions API, or CAPI, changes the collection path. Google’s Branded Searches changes what behavior you can observe after an ad exposure.

Measurement component	What it records	How to use it	What not to infer
Microsoft UET	Activity captured in the browser	Maintain browser-side visibility and use it with CAPI	Do not assume browser collection alone covers every online or offline outcome
Microsoft CAPI	Online or offline events sent from your systems through a server-to-server connection	Improve signal coverage and connect outcomes that do not exist solely in the browser	Do not assume a second collection path automatically fixes event definitions or duplicate handling
Google Branded Searches	A search for your brand on Google or YouTube after someone sees an eligible ad	Assess whether YouTube or Demand Gen activity is followed by greater brand-seeking behavior	Do not treat the signal as a sale, a bidding target, or proof of incremental lift

This distinction should survive all the way into your dashboard. A server-recorded purchase or qualified offline outcome and a subsequent branded search may both carry a conversion label inside an ad platform, but they answer different questions. Combining them in one unlabeled total makes that total difficult to use for budgeting.

Create separate reporting groups for business outcomes, consideration actions, and measurement diagnostics. That gives each signal a job before anyone uses it to defend a campaign.

Add Microsoft CAPI without dismantling UET

An isometric website and server send conversion-event packets through separate browser and server routes to one measurement destination.

Microsoft CAPI is currently a beta capability, so your first implementation question is whether the account has access. The second is whether someone can own a server-side integration after launch. This is not a one-time tag installation; it needs an event definition, a connection to the systems where those events originate, and ongoing monitoring.

Keep UET in place. Microsoft recommends that advertisers combine CAPI with Universal Event Tracking: UET continues to observe browser activity, while CAPI sends data directly from your systems. Treat the two paths as complementary coverage, not competing implementations.

Confirm account eligibility and name a technical owner. If the beta is not available, finish the event design now so access does not become the start of the project.
Build an event register before writing integration code. For every event, record the business definition, originating system, online or offline status, browser collection path, server collection path, reporting purpose, and accountable owner.
Identify overlap between UET and CAPI. When the same real-world action can arrive through both paths, confirm Microsoft’s current deduplication requirements and define the identifier that ties the records together. Do not assume duplicate prevention happens automatically.
Test online and offline flows separately. Use known test cases and verify that the originating system, integration logs, and advertising report describe the same action.
Reconcile events at three stages: created in your system, sent by the integration, and acknowledged or reported downstream. A discrepancy then points to a specific handoff instead of becoming a general tracking mystery.
Document failure handling. Your owner should know where rejected or unsent events appear, how they are retried, and how a prolonged interruption becomes visible.

The event register matters because server-side transport cannot rescue an ambiguous conversion. If sales and marketing use different definitions of a completed outcome, CAPI can transmit that disagreement more reliably without making the resulting metric more useful.

Server-side collection is also a transport choice, not permission to send every available customer field. Moving data out of the browser does not remove your privacy, consent, security, or data-governance obligations. Limit the payload to the approved measurement purpose and have the appropriate internal owner review it before production use.

Reset how you report Google’s Branded Searches

An abstract ad panel leads to a magnifying glass over products, while only one branch continues to a separate checkout package.

Branded Searches measures a meaningful middle step: someone sees an ad and later searches for the advertiser’s brand on Google or YouTube. That can reveal demand that a click-only report misses, particularly when the ad creates memory rather than an immediate site visit.

It is still a consideration action, not an end-of-funnel outcome. Google formally places it under the Consideration goal, and its current rules create several reporting traps that you should resolve before presenting the number.

The default conversion window is seven days. You can set it from one to 30 days.
YouTube and Demand Gen are currently listed as eligible campaign types.
Performance Max is not included in the current eligibility list, even though it appeared when the conversion type was originally announced.
Brand mapping must be configured. A missing or incomplete setup can prevent the measurement from working.
Branded Searches is treated as a primary conversion action, but it cannot be selected as a bidding optimization goal.
The metric appears in Results and All Conversions rather than the standard Conversions column.
You can inspect it at campaign, ad group, and asset levels, as well as through Report Editor.

These eligibility, attribution, and reporting rules mean that a missing number is not automatically a demand problem. Check campaign type, brand mapping, conversion window, and report column before diagnosing the creative or audience.

Choose the window for comparability, not a bigger count

The seven-day setting is an attribution boundary. It determines how long a subsequent branded search can qualify after the relevant ad exposure; it is not a waiting period before the data becomes useful.

Start with the seven-day default unless your measurement plan supports a different choice. If you change it, record the effective date and avoid comparing the new count directly with a period measured under the old window. Extending the eligible period can change the volume even when the campaign itself has not changed.

Use the signal to investigate influence, not claim causation

A search that follows an impression establishes sequence inside Google’s measurement framework. By itself, it does not prove that the search would never have happened without the ad. That distinction separates attribution from incrementality.

Describe the metric internally as observed branded-search behavior after ad exposure. Do not rename it brand lift, incremental search, or acquired demand. If your decision requires a causal claim, an attributed sequence is not a substitute for a controlled lift design.

The primary-conversion label deserves similar care. In this case, primary does not mean the action can steer bidding, and it does not place the metric in the usual Conversions column. Build a dedicated report from Results or All Conversions, then keep the signal separate from the outcome conversions used to judge commercial return.

For Performance Max, treat support as unconfirmed unless the current interface or Google guidance available to your account explicitly establishes otherwise. Its absence from the current campaign list is a reason to verify, not a reason to copy the YouTube or Demand Gen setup and assume equivalent coverage.

Put every measurement change behind a written contract

A measurement contract is a short operating record for each signal. It prevents platform terminology from becoming your business definition and makes reporting changes auditable. Create one before you alter dashboards, goals, or stakeholder reports.

Signal name and plain-language definition
The real-world action represented
Originating system and collection path
Eligible platforms and campaign types
Attribution or conversion window
Required setup dependencies
The platform columns and reports where it appears
Whether bidding can use it
Whether the signal represents an outcome, consideration action, or diagnostic
The owner responsible for implementation and validation

For Microsoft, the contract should distinguish UET, CAPI, and any event that can arrive through both. It should also show whether each event is online or offline and how overlap is controlled.

For Google Branded Searches, record YouTube and Demand Gen as the currently listed campaign types, the selected one-to-30-day window, the brand-mapping dependency, the Results and All Conversions reporting locations, and the prohibition on bidding optimization. Mark Performance Max as requiring verification rather than silently treating it as eligible.

Then use a fixed decision hierarchy. Business outcomes answer whether the investment produced value. Consideration signals help explain movement toward those outcomes. Collection diagnostics tell you whether the measurement path worked. A diagnostic should not determine budget, and a consideration action should not be presented as revenue.

Before approving a period-over-period comparison, verify that the following conditions remained stable:

The eligible campaign set did not change.
The conversion window did not change.
Brand mapping remained active.
The same reporting column or report was used.
UET and CAPI coverage remained stable, or any change was annotated.
Duplicate handling was verified after integration changes.
The business definition of each outcome remained the same.

If one of those conditions changed, annotate the break and report the affected periods separately. A clean-looking trend line is less useful than an honest discontinuity.

Key takeaways for your next measurement review

Microsoft CAPI is a beta server-side measurement path, not a replacement for UET.
Design duplicate handling before sending the same action through browser and server paths.
Use CAPI to support online and offline event coverage, but keep one documented business definition for every conversion.
Google Branded Searches currently applies to YouTube and Demand Gen; do not assume Performance Max eligibility.
The Branded Searches default window is seven days and can be adjusted from one to 30 days.
Report Branded Searches as a consideration signal from Results or All Conversions, not as a bidding goal or proof of incremental lift.

Your next measurement meeting should end with two named owners and two concrete outputs: a technical plan for UET plus CAPI coverage, and a reporting contract for Branded Searches. Once those are explicit, you can add signal without weakening the decisions built on it.

References

August 18, 2026

Google Ads Automated Language Matching: What to Change Now

If you run multilingual Google Ads campaigns, the language setting you once treated as a boundary is about to stop doing that job on Search. Leaving your campaigns untouched may not break delivery, but it can make language allocation harder to predict and language-related waste harder to diagnose.

Your immediate task is not to find a replacement checkbox. It is to make every eligible ad and destination unmistakably suitable for the language journey you intend, preserve the controls that still matter in Performance Max, and give your reporting enough structure to expose mismatches.

Know exactly where the language setting stops applying

Beginning in late September, campaign-level language targeting will disappear from Search and AI Max for Search campaigns. Google will instead match Search ads largely from the language of the ads and signals indicating which languages a user understands.

Campaign or placement	What happens to selected languages	What you should control
Standard Search	The campaign-level setting no longer controls matching	Ad language, ad-group clarity and destination language
AI Max for Search	The campaign-level setting no longer controls matching	Ad language, eligible ad groups and destination language
Performance Max on Google Search	The selected campaign languages no longer apply to Search delivery	Search-facing creative and destination language
Performance Max on YouTube, Display, Discover and Gmail	Selected languages continue to guide delivery	Campaign language settings as well as multilingual assets
Shopping ads within Performance Max	Language settings do not affect these ads	The product and destination experience rather than the campaign language selector

The Performance Max distinction is the easiest place to make an expensive mistake. Do not remove its language settings merely because they no longer govern Search inventory. Those settings continue to guide YouTube, Display, Discover and Gmail delivery.

The opposite warning applies to standard Search. An existing language criterion may remain visible, but visibility does not mean enforcement. Do not use it as proof that a campaign can reach only people associated with the selected language.

Rebuild multilingual control around the ad-to-page journey

Three color-coded customer pathways connect abstract speech waveforms to matching search ads and landing pages while a marketer adjusts one route.

Google can use the language of the search term, a user’s language settings and other preferences to estimate what that person understands. A user whose interface is set to one language may still receive an ad in another language if their behavior supports that match. Your campaign setting will no longer override that judgment on Search.

That makes the ad itself a routing signal. It also makes language consistency a practical control surface: the promise in the ad, the page it opens and the next action should all work for the same reader. Audit that path in this order:

Inventory every active Search ad by its actual language. Do not classify an ad from its campaign name. Read the headline, description, extensions or assets, and call to action.
Record the destination language. Check the page headline, primary offer, form fields, validation messages and conversion action. A translated ad does not create a supported journey when the page or form switches languages.
Identify mixed-language ad groups. If clean diagnosis matters, separate ads by intended language at the ad-group level. This gives you a clearer record of which language candidate received traffic and what happened afterward.
Keep campaign separation only when it serves another business control. Separate budgets, markets, offers or conversion goals can still justify separate campaigns. Duplicating campaigns solely to select different Search languages no longer creates a reliable language boundary.
Document the Performance Max exception. Mark which selected languages must remain because the campaign also serves YouTube, Display, Discover or Gmail.
Add language to launch QA. Treat an ad, its destination and its conversion path as one test case. Approving only the translation of the ad leaves the costly part of the journey unchecked.

Clear structure matters when more than one campaign or ad group is eligible. Google says AI-based ad-group prioritization will choose the candidate with the most relevant language. You cannot force that decision with the former Search language control, but you can avoid giving the system ambiguous or poorly supported candidates.

Make landing-page language an operating requirement

A language change in the campaign interface used to feel like a targeting task. The new model makes it a content-operations task as well. Ad creative and destination pages now carry more of the burden for Search language matching, so page ownership can no longer sit outside the campaign migration.

For each language you actively advertise, define what a complete supported experience means. At minimum, the user should be able to understand the offer, evaluate the main terms and complete the primary action without an unexplained language switch. If the business cannot support that journey, pause or remove the corresponding ad rather than hoping the old campaign criterion will suppress it.

Use language-specific destination paths where they already fit your site structure. They make QA and reporting easier because a landing URL can be reconciled with the language label on an ad group. The URL does not need to become a targeting theory; it needs to help your team answer a concrete question: did the intended ad open the intended experience?

Translation alone is not enough when the offer changes by market. Check prices, availability, legal terms, fulfilment language and contact options wherever they appear in the conversion path. Those checks are not new Google Ads controls. They are safeguards against paying for a click whose promise the destination cannot fulfil.

Monitor language matching without waiting for a perfect report

Two analysts inspect color-coded routes between generic ad tiles and landing pages, with one mismatched connection highlighted in red.

Automated matching can change which eligible language candidate receives traffic. Build a baseline before the rollout so a later shift is visible. The baseline does not need a new platform metric; it needs stable labels and a repeatable review.

Label ads and ad groups by intended language. Use one naming convention across the account so reports can be grouped without rereading every ad.
Record performance by that label. Compare impressions, spend, clicks, conversions and conversion value where those measures apply to your objective.
Review search terms against the served ad language. Read the whole query before classifying it. Brand names and borrowed words can appear inside queries written in another language.
Reconcile destination paths. Flag cases in which a language-labelled ad opens a page intended for a different language.
Use downstream evidence. Unsupported-language form submissions, calls or support requests can reveal a mismatch that click metrics alone will not explain.
Separate Performance Max observations by placement where your reporting allows it. A Search-delivery change should not automatically be blamed on the language settings that still guide the campaign’s other channels.

Set alerts from your own baseline rather than borrowing a universal percentage. The available information does not establish a normal amount of language reallocation or a safe variance threshold. Your alert should identify a material change in your account, not pretend that every advertiser will experience the same shift.

When you find a problem, change one controllable layer at a time: the eligible ad, the ad-group structure or the destination. That preserves enough evidence to tell whether the correction worked. Rebuilding campaigns, rewriting ads and changing pages simultaneously may stop the immediate symptom, but it will leave you unable to identify the cause.

Update Google Ads API workflows by campaign type

API users have a concrete migration requirement. Stop sending language criteria when creating or updating Search campaigns. Attempts to add or update CampaignCriterion.language for Search will return ContextError.OPERATION_NOT_PERMITTED_FOR_CONTEXT.

Existing Search language criteria may remain but will no longer affect targeting. You may remove them, but cleanup is optional. If another internal system reads those objects, decide whether retaining inert criteria would mislead operators before choosing to leave them in place.

Do not apply the same rule indiscriminately to Performance Max. Its language setting still influences non-Search channels, so Performance Max will not return the same context error. Branch the workflow by campaign type instead:

Exclude language criteria from new Search campaign requests.
Remove language mutations from Search update jobs and templates.
Allow existing Search criteria to remain only if your interface clearly marks them as non-operative.
Preserve supported Performance Max language operations for the channels where they still matter.
Test both create and update paths so error handling does not hide unrelated failures behind the expected context error.
Update internal documentation, validation rules and campaign builders that still describe Search language selection as an enforceable control.

This is more than an API compatibility fix. If an internal campaign tool continues showing a required Search language selector, users may believe they established a boundary that Google no longer observes. Removing that false assurance is part of the migration.

Key takeaways

For Search and AI Max for Search, stop treating campaign-level language selection as a targeting restriction.
For Performance Max, preserve selected languages because they still guide YouTube, Display, Discover and Gmail, even though they no longer govern Search placements.
Use deliberately separated ad languages, clearly matched destinations and consistent labels to make automated decisions easier to diagnose.
Keep separate multilingual campaigns when budgets, markets, offers or goals require them, not merely to recreate a language switch that no longer controls Search delivery.
Remove Search language mutations from API workflows, while retaining campaign-type logic for Performance Max.

Start with the account inventory and the API branch before late September. Then run the ad-to-page language audit while the old structure is still familiar. You cannot restore the removed Search control, but you can make every language candidate intentional, measurable and supportable before automated matching decides where it belongs.

References

Search Engine Land — Google Ads is removing language targeting from Search campaigns

August 13, 2026

Campaign Manager 360 Real-Time Reporting API Guide

You need Campaign Manager 360 performance data inside a dashboard while someone is still looking at the screen. The traditional create-run-poll-download workflow can do the reporting, but it makes an interactive product carry the machinery of a batch job.

The reportData.query endpoint gives you a shorter path: describe the data you need in the request and receive structured JSON synchronously. That can simplify dashboards and ad-hoc analysis considerably. It does not mean every reporting workload should move, nor does the word “real-time” guarantee that every underlying metric is updated instantly.

The reporting flow is now a direct request-response path

The traditional Campaign Manager 360 reporting flow is built around generated reports. Your application creates a Report resource, runs it, polls until processing finishes, and downloads the resulting file. That sequence remains useful when the file is part of the deliverable, but it introduces several states that an interactive application must manage.

Create or identify the report configuration.
Start the report run.
Poll for completion.
Download and parse the generated CSV or Excel file.
Transform the result into the shape required by your interface or analysis.

With reportData.query, developers can instead specify dimensions, metrics, and filters in the request body and receive structured JSON in the response. You do not have to create a Report resource before asking for the data.

Define the dimensions that determine the result’s grain.
Select the metrics needed by the dashboard or analysis.
Apply filters that keep the request focused.
Submit the synchronous query.
Map the returned JSON into your application’s data model.

The practical gain is not simply fewer API calls. Your application no longer has to model a report job, persist its status, poll it, retrieve an artifact, and parse that artifact before it can show a result. For a user-driven dashboard, removing that orchestration can make both the code and the experience easier to reason about.

Keep the distinction precise, though: reportData.query simplifies the retrieval path. It does not make the Reports service obsolete, remove the need for a reporting data model, or turn an unfocused query into a fast one.

Choose the endpoint by workload, not by which API is newer

Two data-reporting routes show a short interactive query path beside a larger multistage batch-processing path.

The clearest implementation decision is based on how the result will be consumed. Use reportData.query when a person or application needs a structured answer immediately. Keep the Reports service when the workload is large, scheduled, or expected to produce a downloadable file.

Decision factor	reportData.query	Reports service
Interaction model	Synchronous request and response	Create, run, poll, and download
Response format	Structured JSON in the API response	Generated CSV or Excel file
Best fit	Interactive dashboards, real-time reporting experiences, and ad-hoc analysis	Large datasets, scheduled reporting, and file-based workflows
Configuration	Dimensions, metrics, and filters are supplied directly with the query	A Report resource defines the report before retrieval
Execution consideration	A query can run for up to 60 seconds	Completion is handled as an asynchronous report job

Four questions usually settle the choice:

Is a person waiting for the answer? A dashboard refresh, filtered table, or investigative view is a strong candidate for reportData.query.
Is the output itself a CSV or Excel deliverable? Keep the Reports service rather than retrieving JSON only to recreate the same file workflow.
Is this a large or scheduled extraction? The existing Reports service remains the preferred route.
Does the same system have both interactive and batch needs? Use both paths. A hybrid architecture is a deliberate workload split, not an incomplete migration.

This prevents a common architectural mistake: replacing a sound batch process merely because a more convenient interactive endpoint exists. The new endpoint solves a different access pattern. It should take over the requests that benefit from synchronous JSON while the Reports service continues handling work that benefits from generated files and asynchronous execution.

Design interactive queries that remain useful under pressure

A direct endpoint removes report-job ceremony, but your dashboard still needs a disciplined query layer. The following design choices determine whether reportData.query feels responsive and trustworthy in production.

Start with the user’s question, not every available field

Define one question for each dashboard component. A campaign summary, a filtered placement table, and a diagnostic drill-down do not need to share one universal request. Give each component the smallest dimension grain, metric set, and filter scope that answers its question.

Write down a compact query contract before implementation:

The decision or question the result supports.
The dimensions that determine what one result row represents.
The metrics the interface will actually display or calculate with.
The filters controlled by the application and the filters controlled by the user.
The behavior the user sees while the request is running.
The fallback shown when the request cannot return a usable result.

This contract helps you notice accidental scope growth. If a new chart needs a different grain, give it a separate query rather than quietly expanding an existing request and making every dashboard refresh carry the extra work.

Treat 60 seconds as a ceiling, not a target

The endpoint allows queries to run for up to 60 seconds. That accommodates meaningful interactive analysis, but a dashboard can still feel broken long before the request reaches its limit.

Design the interface for a genuinely synchronous operation. Show a clear loading state, keep unrelated controls usable, and decide what happens if the request takes longer than the user’s workflow can tolerate. Where appropriate, retain the last successful result and label it as such rather than replacing useful data with an indefinite spinner.

Do not hide a consistently slow query behind a longer loading message. Narrow its dimensions, metrics, or filters. If the workload is inherently large rather than accidentally broad, route it to the Reports service.

Do not equate synchronous retrieval with instant measurement

“Real-time” describes the reporting access pattern here: your application submits a query and receives data directly instead of waiting for a generated report file. That alone does not establish how quickly every underlying campaign event becomes available as a reportable metric.

If freshness affects an operational decision, verify it for the dimensions and metrics you use. Give the dashboard an “as of” indicator based on information your implementation can substantiate, and avoid labels such as “live” or “instant” unless you have validated what those words mean for that view. This keeps a faster retrieval method from creating a stronger freshness promise than the data supports.

Put a stable adapter between CM360 and the interface

Structured JSON is easier to consume than a downloaded file, but your UI should not become a direct reflection of a vendor response. Map the response into an internal model with names and types that make sense to your application.

Keep the API request definition in one reporting layer rather than duplicating it across dashboard components.
Validate that the returned structure contains what the component needs before rendering it.
Centralize metric labels and formatting so the same measure is not presented differently across views.
Record the query definition alongside operational logs so a bad result can be traced to its dimensions, metrics, and filters.
Version your internal contract when a dashboard changes its grain or meaning.

This adapter also preserves your options. The UI can consume one internal shape even if some views use reportData.query and other data arrives through the Reports service.

Separate no data, zero, slow, and failed

These states can look similar in an empty chart, but they mean different things:

No matching data: the selected dimensions and filters produced no rows.
Measured zero: the query returned a legitimate result whose displayed metric is zero.
Still running: the application has not received the synchronous response yet.
Failed request: the application cannot present the requested result.
Last successful result: a previous result remains visible while its replacement is unavailable.

Model and label these states explicitly. Otherwise, an API problem can be mistaken for campaign performance, or an empty filter result can be presented as a technical failure.

Also control how often the interface sends requests. Trigger queries on deliberate actions, avoid submitting a new request for every unfinished input change, and reuse identical results for an appropriate period when your freshness requirements permit it. The right reuse period is a product decision; the existence of a synchronous endpoint does not require every screen interaction to generate a new API call.

A low-risk rollout keeps the batch path intact

Parallel reporting pipelines pass through a controlled traffic junction and comparison stage, with a return route to the established batch system.

You do not need to redesign the entire reporting stack to benefit from reportData.query. Start with one view where report creation, polling, or file parsing is clearly getting in the way of an interactive experience.

Inventory the current flow. Identify where the application creates the Report resource, starts the run, polls, downloads the file, parses it, and transforms it for display.
Classify the use case. Confirm that a person or interactive application needs the result directly. Leave scheduled, large, and file-based jobs in the Reports service.
Write the query contract. Specify the exact dimensions, metrics, filters, expected result grain, loading behavior, and failure behavior for the selected view.
Build the response adapter. Convert the returned JSON into the internal shape already expected by the interface, or introduce a stable model that both reporting paths can use.
Verify meaning, not just transport. Compare the new view with the existing reporting output for the same requested scope. Investigate differences before assuming that receiving JSON means the migration is complete.
Exercise the slow and empty paths. Confirm that the interface remains understandable if a query runs for a substantial part of the allowed window, returns no matching data, or fails.
Switch only the interactive read path. Keep existing scheduled reports and downloadable exports running until there is an independent reason to change them.

Measure the rollout by what it removes from the interactive path: report-resource management, polling, file retrieval, and parsing. Do not judge it by how much legacy reporting code you can delete. If that code still supports a valid batch workload, retaining it is the correct design.

Campaign Manager 360 reporting API FAQ

Is reportData.query a streaming API?

No. Its documented interaction is a synchronous query that returns structured JSON. Your application requests a defined result; it is not described as subscribing to a continuous stream of campaign events.

Does “real-time reporting” mean every metric is instantly current?

Not on the evidence available for this endpoint. The direct synchronous response removes the generated-report workflow, but that does not by itself define the freshness of every underlying metric. Validate freshness for your use case before making a user-facing promise.

Should an existing Reports service integration be migrated completely?

No. Keep the Reports service for large datasets, scheduled jobs, and workflows that require CSV or Excel downloads. Move only the interactive and ad-hoc requests that benefit from direct JSON.

What is the best first use case?

Choose one narrowly scoped dashboard view whose user currently waits for a report job or whose implementation exists mainly to download and parse a file. Define its dimensions, metrics, and filters; build the JSON adapter; then compare its output with the established reporting path before expanding the rollout.

Your next step is small and concrete: identify one interactive report, write down the exact question it answers, and determine whether a synchronous query can answer it within the endpoint’s 60-second window. If it can, migrate that read path. If it is fundamentally a large export or scheduled artifact, leave it where it belongs.

References

Search Engine Land – Google adds real-time reporting endpoint to Campaign Manager 360 API

August 12, 2026

How to Measure AI Search Visibility With Your SEO Data

You have an AI visibility score. It fell. Now comes the awkward question: did fewer systems recommend your brand, did a narrow group of prompts change, or did your tracking method move the goalposts?

Until you can connect each score change to a stable prompt set, stored answers, cited URLs, and SEO or on-site outcomes, the number cannot guide useful work. The measurement system below gives you that chain, so you can decide whether the response belongs in content, technical SEO, distribution, competitive analysis, or analytics.

Key takeaways

Measure a fixed, versioned set of audience prompts. If the prompt set changes, the resulting score is not directly comparable with the previous score.
Keep brand presence, citations, competitive share of voice, search performance, and business outcomes separate. They answer different questions.
Store the full answer and its citations for every prompt run. A percentage without retrievable evidence is difficult to audit or act on.
Join cited URLs to Google Search Console, GA4, your content inventory, and competitive SEO data. That is where an AI observation becomes a diagnosis.
Use MCP to reduce report-building and export work, but validate its queries and definitions. Easier access to data does not make the interpretation automatically correct.

Stop asking one visibility score to explain everything

A brand mention is not a citation. A citation is not a visit. A visit is not a conversion. Combining all of them into one proprietary score may produce a tidy trend line, but it hides the point at which performance actually changed.

AI share of voice is commonly framed around how often AI answers mention your brand across a relevant set of questions. That is useful, but only after you define relevant. The reported 17.2% presence figure on that measure is context, not a universal target. Your prompt mix, markets, platforms, competitors, and collection method determine what your own percentage means.

Measurement layer	Primary metric	Question it answers	Common misreading
Brand presence	Share of eligible prompt runs that mention the brand	Do AI answers include us?	Counting repeated mentions in one answer as several wins
Owned citation	Share of eligible runs that cite an owned domain	Is our site being used as supporting material?	Assuming every citation sends a visit
Competitive share of voice	Brand appearances divided by all appearances for a fixed peer set	Who occupies the answers in this market?	Changing the competitor set between reporting periods
Search response	Google Search Console queries, impressions, clicks, and page performance	What is moving in conventional search around the affected topics and pages?	Claiming that AI visibility caused an SEO change merely because both moved
Site outcome	Landing-page visits, engagement, and defined conversions in GA4	Did measurable visits produce useful behavior?	Treating exposure without a click as though it never happened

Define presence at the prompt-run level: the brand is either present or absent in an eligible answer. Count the brand once per answer, even if it appears several times. Define citation rate the same way, then maintain a separate URL-coverage measure for the distinct pages cited. This prevents a verbose answer from outweighing a concise one.

An eligible run is one in which the platform returned an answer that could reasonably address the prompt. Log blank responses, errors, refusals, and unavailable features as collection failures rather than silently removing them. Publish the eligible-run count beside every rate. Otherwise a strong percentage can conceal poor coverage.

Do not average unlike surfaces into a single headline number. Keep results for ChatGPT, Gemini, AI search features, markets, and languages segmented unless they used the same prompt definitions and collection rules. You can add a portfolio view later, but the underlying segments must remain visible.

Build a prompt panel you can run again without changing the test

Your measurement denominator should come from customer decisions, not from a convenient keyword export. A search keyword and a conversational prompt can express the same need differently, so use search data to inform the panel without copying every query verbatim.

Cover the decisions where AI visibility could matter:

Category discovery: questions that ask which products, services, methods, or providers fit a situation.
Problem solving: questions that describe a symptom, obstacle, or desired outcome without naming a category.
Consideration: comparisons, alternatives, suitability questions, and trade-offs between approaches.
Validation: questions about evidence, trust, implementation, compatibility, limitations, or risk.
Action: questions that indicate the person is ready to choose, configure, contact, buy, or adopt something.

Keep a stable core panel for trend reporting and a separate discovery panel for emerging questions. New discovery prompts can graduate into the core panel at a documented boundary. Do not insert them into historical calculations and then present the resulting movement as improved visibility.

Each prompt record should preserve enough context to reproduce and inspect the observation:

A permanent prompt ID, exact prompt text, intent class, audience, topic, and funnel decision.
The platform, product surface, visible model or mode, market, language, and device context where relevant.
The date and time, signed-in or personalization state, and any location setting used.
The full raw answer, every displayed citation, each destination URL, and the first-mention order for tracked brands.
Presence, owned citation, competitor appearances, answer eligibility, and collection-error fields.
The prompt-panel version and the extraction or classification rule used to turn the answer into metrics.

Generative answers can vary between runs. A screenshot proves that your brand appeared once; it does not establish a durable ranking. Run the panel under consistent conditions, preserve each observation, and aggregate only after collection. If you edit a prompt, create a new version instead of overwriting its history.

Classification needs the same discipline. Decide in advance whether product names, parent companies, common abbreviations, misspellings, and partner domains count as your brand. Maintain an alias list for every tracked company. Apply it to all periods, including competitors, or apparent share-of-voice movement may come from inconsistent naming rather than changed answers.

Join AI observations to page, query, and outcome data

The raw AI log tells you what appeared. It rarely tells you why. The most useful join key is usually the cited URL because it connects an answer to a page you can inspect, compare, and improve.

Normalize cited URLs. Resolve known redirects and standardize protocol, hostname, fragments, parameters, and trailing slashes. Preserve both the observed URL and normalized destination so you do not erase evidence of a broken or outdated citation.
Match pages to Google Search Console. Pull the queries, impressions, clicks, and search positions associated with cited and affected pages for consistent reporting windows. Keep branded and non-branded query groups separate.
Match landing pages to GA4. Review traffic channels, referrers, engagement, and the conversions your property actually defines. Normalize GA4 landing-page paths carefully when they omit the hostname or include query parameters.
Add content attributes. Attach page type, template, topic cluster, author or owner, publication status, locale, directory, and last material update. These dimensions reveal whether a change is concentrated in a content system rather than an isolated URL.
Add competitive SEO context. Compare ranking pages, keywords, referring-domain trends, estimated traffic, and new or redirected sections where your SEO platform exposes them. Keep estimated third-party metrics distinct from first-party analytics.

Once those records are connected, read combinations of signals rather than treating each chart independently:

Presence rises while owned citations stay flat: the brand is entering answers, but the domain is not becoming a more frequent supporting destination. Inspect which external pages are cited and what evidence or format they provide.
Presence is flat while owned citations rise: your competitive visibility may look unchanged, but your site is gaining a stronger role in the answer. Track that separately instead of dismissing it.
Visibility rises while measurable visits stay flat: this is not automatically a contradiction. A citation can be displayed without being clicked, and analytics only records visits that reach and are classified by the property.
AI visibility and search performance fall in the same directory: investigate shared content quality, technical access, templates, intent fit, and competitive changes. The overlap is a diagnostic lead, not proof that one channel caused the other.
A competitor gains across a concentrated page type: group its new and growing pages by directory, locale, and template before blaming a sitewide algorithm change. Directory-level investigation can expose focused service sections, maturing international content, and previously dormant acquisition redirects that a top-line domain graph conceals.

Do not force Ahrefs estimated traffic, Search Console clicks, GA4 sessions, and AI prompt appearances into a shared unit. They are different observations collected with different methods. Join them for diagnosis, but retain the original metric names, date windows, and definitions.

Use MCP as a data-access layer, not an accuracy layer

MCP is an open standard that lets an AI assistant connect to external tools and data. In an SEO workflow, that can replace a large amount of report navigation, exporting, spreadsheet stitching, and manual pivoting across systems such as Ahrefs, Google Analytics, and Google Search Console.

The important boundary is simple: an MCP connection can retrieve and reshape only what the connected service exposes. It does not create missing data, repair weak tracking, reconcile incompatible definitions, or know which business interpretation you intended. Plain-language access makes precise instructions more important, not less.

Use this control sequence for every consequential analysis:

Limit access. Start with the narrowest practical account, property, and read-only permission set. Use the service’s supported connection flow rather than placing credentials inside a prompt.
State the data contract. Name the property or site, timezone, date windows, comparison logic, dimensions, metrics, filters, attribution assumptions, and expected grain of each row.
Retrieve intermediate tables before requesting a narrative. Inspect the AI visibility observations, Search Console rows, GA4 landing pages, and competitive data separately before asking the assistant to join them.
Require audit fields. Ask for row counts, excluded records, null values, failed joins, normalized keys, metric definitions, and any truncation reported by the tool.
Reconcile a sample in the native interface. Check selected properties, dates, pages, and totals against the system of record. If they disagree, resolve the query definition before interpreting the trend.
Save the analysis recipe. Preserve the request, tool, connection, panel version, retrieval time, output, and transformation rules. A repeatable query is more valuable than a polished answer that cannot be reconstructed.

Useful MCP requests define the output instead of merely asking what changed. For example:

From Google Search Console, compare the selected periods by normalized page and query, group results by directory, and return raw values alongside the calculated change.
Join owned URLs cited in the AI prompt log to GA4 landing pages, retain citations with no matched visits, and report engagement and defined conversions without replacing nulls with zero.
Using competitive SEO data, identify pages first observed in the selected window, group them by directory and page type, and return their ranking keywords and estimated traffic as separately labeled metrics.
Across the tracked prompt panel, list the domains cited most often by intent class and show the exact prompt IDs and answers behind each count.

A GA4 connection through its Data API can also bypass the interface’s 5,000-row export limit. That removes an export bottleneck; it does not remove the need to check property settings, API fields, filters, and metric meanings.

Turn the report into a controlled decision

Your reporting view should make it possible to move from a changed metric to the underlying evidence without opening another deck. Include the following in every reporting cycle:

The prompt-panel version, platforms, markets, languages, run conditions, and collection window.
Eligible, failed, and excluded run counts before any visibility percentage.
Brand presence, owned citation rate, competitive share of voice, distinct cited URLs, and their raw numerators and denominators.
Movement by intent, topic, audience, product line, locale, and platform rather than only a blended total.
The prompts and stored answers responsible for the largest gains or losses.
Cited-page joins to Search Console, GA4, the content inventory, and competitive SEO metrics.
A change log for publishing, redirects, canonicals, internal links, structured data, campaigns, and tracking configuration.
A confidence note describing prompt changes, collection failures, incomplete joins, or platform conditions that weaken the comparison.

Then choose the response that matches the layer where the movement occurred:

If losses cluster around a specific intent: compare the winning answers and cited pages for that intent. Look for missing definitions, evidence, examples, entity relationships, eligibility details, or decision criteria rather than performing a sitewide rewrite.
If the brand is mentioned but the site is not cited: inspect the destinations AI answers do cite. Improve the page that should answer the question directly, make claims supportable, expose authorship and relevant dates, and strengthen internal pathways to primary material.
If a cited URL is stale or redirected: verify the redirect, canonical destination, indexability, and replacement content before removing anything. Preserve a working path for the citation instead of deleting the old page and hoping the answer updates.
If conventional search falls while AI visibility is stable: investigate the SEO decline on its own terms. An unchanged AI score does not rule out query loss, ranking changes, SERP changes, seasonality, or technical problems.
If the score moves only after the prompt panel or extraction rule changed: label it as a measurement break. Recalculate comparable history where possible; otherwise begin a new reporting series.
If you change JSON-LD: make the structured data match the visible page and use it to clarify real entities and relationships. Do not call subsequent visibility movement a schema win unless the affected prompts and cited pages changed under otherwise comparable measurement conditions.

The cleanest first move is to create the prompt registry and evidence table before adding another dashboard. Run the same panel, preserve the answers, normalize the citations, and join those pages to the SEO and analytics systems you already use.

For the next cycle, choose one intent segment with a verified change and make one traceable content or technical response. Log it, rerun the comparable panel, and inspect the same page and outcome data. If a metric cannot reveal its denominator, raw answer, cited URL, and collection rule, keep it out of the decision scorecard.

References

August 12, 2026

Google Data Manager Audience Updates: A Practical Playbook

If you own a Customer Match sync, the dangerous outcome is no longer only a failed request. The Data Manager API can now process valid records while warning about invalid optional fields, and one audience operation can clear an entire list. Those capabilities reduce manual cleanup, but they also expose integrations that reduce every run to a simple green or red status.

For you, this is an operating-model change as much as an API change. Build observability first, put destructive audience actions behind explicit controls, and only then widen the user-provided data you send. That order gives you evidence and a recovery path before the higher-risk capabilities go live.

Key takeaways

Audience refreshes are simpler but more consequential: RemoveAllAudienceMembers can clear a list in one operation or remove members added before a supplied timestamp. Treat full clearing and cutoff-based clearing as separate modes with separate safeguards.
A successful request may still contain data-quality problems: invalid optional fields can produce field-level warnings while valid records continue through ingestion. Your monitoring needs a completed-with-warnings state.
Address support has widened for Google Analytics destinations: street address, city, and state or province can accompany previously supported information such as name, postal code, and region. This is not a reason to collect or transmit fields without a defined purpose.
User-provided data has a conditional identifier role: it can satisfy identifier requirements for certain multi-source events when other identifiers are unavailable. Do not generalize that fallback to every event type.
AI-assisted implementation has official scaffolding: Google has added Data Manager API agent skills to its Google Skills GitHub repository, but generated code still needs human review around audience selection, timestamps, privacy, and warning handling.

Make audience replacement a controlled operation

A technician monitors two audience-data containers connected by a guarded transfer system with a separate rollback reservoir.

The RemoveAllAudienceMembers method supports both complete clearing and timestamp-based removal. Do not expose those behaviors through one vaguely named refresh command. Give each mode an explicit name in your own integration so an operator, scheduler, or AI coding agent cannot confuse them.

Internal operation	Use it when	Required safeguard
Full clear	You intend to rebuild every current membership from an authoritative dataset.	Validate the exact audience target and retain the input, query, or export required to rebuild it.
Remove before timestamp	You intend to retire memberships added before a defined boundary.	Record the serialized cutoff and its timezone, then calculate the expected cohort in your own system before making the call.

A full clear should begin only after the replacement dataset is ready. If extraction fails and returns no rows, an automatic clear-first workflow can turn an upstream outage into an empty audience. Your job must distinguish between a valid business result of no qualifying members and a technical failure that merely produced an empty file.

Build the replacement input first. Finish the source query or export before touching existing membership.
Check whether the result is plausible. Compare its volume and partition coverage with your own recent successful runs. Use a business-specific baseline rather than an arbitrary universal threshold.
Resolve the target from controlled configuration. Record the account, destination, and audience identifier. Avoid accepting an unverified free-text audience name at execution time.
Declare the removal mode. Require either full clear or before timestamp. If a timestamp is supplied, store the exact value used by the request.
Preserve the rebuild path. Retain the source query version, input reference, and run identifier under your normal data-retention controls.
Remove, rebuild, and verify as one runbook. Do not declare the refresh complete merely because the removal call succeeded; the replacement ingestion and its warnings are part of the same operational outcome.

The cutoff has a narrow meaning: it targets members added before the timestamp. It is not automatically a proxy for last purchase, last site visit, consent expiry, or customer inactivity. If your business rule depends on one of those events, calculate eligibility upstream instead of assuming membership age represents it.

Boundary behavior deserves a fixture test before production. Place known test members before, at, and after a chosen cutoff, run the operation against a disposable test audience where your environment supports one, and inspect the result. Also verify how your integration treats members that were updated or re-added; do not build a retention policy on an untested timestamp assumption.

Treat ingestion warnings as a real pipeline outcome

A validation machine sends most record packets into storage while diverting malformed fragments into an amber inspection channel.

Field-level warnings change the meaning of success. When an optional field is invalid, the API can continue processing valid records and return details about the field and validation problem. A 2-state dashboard that shows only succeeded or failed will hide exactly the defects this behavior was designed to reveal.

Represent at least three states in your own monitoring, even if your internal labels differ:

Failed: the requested ingestion did not complete successfully.
Completed with warnings: processing continued, but one or more fields failed validation.
Completed without detected warnings: the run completed and no warning was returned to your handler.

Persist enough context to diagnose a warning without copying raw customer data into general application logs. A useful warning record contains the internal run identifier, destination, field name, validation reason, occurrence count, deployment version, and first-seen time. If record-level correlation is available in your integration, use a restricted internal reference rather than a name, street address, or complete payload.

Your alerting should focus on changes in the data contract, not merely the existence of any warning:

Escalate a warning reason that appears for the first time after a mapping or formatter release.
Investigate a material increase in a known warning relative to that feed’s normal baseline.
Route recurring warnings to the team that owns the source field, not only the team that operates the API client.
Keep the run visibly degraded until the warning has been classified, even when usable records reached the destination.

Do not blindly retry the identical batch. An invalid optional value will remain invalid, and valid data may already have been processed. Correct the mapping, normalization, or source value first, then send the corrected data through your normal controlled ingestion path. This makes the next warning result evidence of whether the repair worked.

Expand address data only where the destination and purpose match

For Google Analytics destinations, the API now accepts street address, city, and state or province alongside fields such as name, postal code, and region. Keep that destination qualifier in your schema. Support in a Google Analytics path does not establish that every Data Manager destination should receive the same payload.

Newly supported for the stated Google Analytics use: street address, city, and state or province.
Already supported in the described address data: name, postal code, and region.

Do not collapse state or province and region into one source column merely because the labels appear related. Define what each field means in your data model, preserve country-specific semantics, and document the transformation applied before transmission. Missing values should remain missing; fabricated placeholders create a payload that may be syntactically complete but semantically false.

Before adding any address field, require a small data-contract record that answers five questions:

Where did the value come from? Name the source system and field, not just the downstream JSON property.
Which destination may receive it? Use a destination allowlist so the Analytics mapping cannot leak into an unintended advertising or analytics path.
What transformation is applied? Document trimming, formatting, or country mapping in code and tests.
What authorizes its use? Confirm that your collection notice, consent or other applicable control, and internal data policy cover sending the finer-grained address data to the configured destination. If they do not, leave the fields disabled until your privacy or legal owner approves the change.
How will you observe quality without exposing values? Track populated-field counts and validation-warning categories rather than logging raw addresses.

User-provided data can also satisfy identifier requirements for certain multi-source events when other identifiers are unavailable. The word certain matters. Encode the fallback as an eligibility decision: use the usual identifier path when it is available, use user-provided data only for event and destination combinations that support it, and hold records that satisfy neither condition. Never synthesize an identifier merely to make an event pass validation.

API acceptance is not a performance guarantee. A field passing validation does not prove that it improved audience size, attribution, or campaign results. Measure those outcomes separately, and keep the expanded payload only when it has a defined operational purpose and remains within your data-governance rules.

Roll out the changes in a sequence you can reverse

Do not combine destructive audience controls, new warning behavior, and additional user-provided address fields in one production release. Separate deployments make it possible to identify which change caused a data-quality or audience-maintenance problem.

Inventory each integration path. Mark whether it maintains a Customer Match list, sends data to Google Analytics, or performs both jobs. Record the actual Google Ads, Display & Video 360, or Google Analytics destination rather than assuming all Data Manager paths have identical needs.
Capture warnings on the existing payload. Deploy warning persistence and the completed-with-warnings status before altering deletion or field mappings. This gives you a baseline for current data defects.
Add a guarded removal wrapper. Expose full clear and before timestamp as distinct internal operations. Require a target, mode, recovery input, and explicit cutoff where applicable.
Exercise a fixed test matrix. Test a full clear followed by rebuilding, members before and around a cutoff boundary, a mixed payload containing an invalid optional field, and a warning response that must reach monitoring.
Add address fields by destination. Enable only approved Google Analytics mappings, preferably one mapped field at a time, so warnings can be traced to a specific change.
Test identifier fallback separately. Cover an eligible multi-source event with another identifier, an eligible event without one, and a configuration that is not eligible for the user-provided-data fallback.

Use Google’s agent skills as scaffolding, not authority

Google has also released Data Manager API skills in the Google Skills GitHub repository for AI-assisted coding environments. They can help an agent start an integration, but the agent should not decide which audience to clear, choose a business cutoff, approve new address use, or determine whether warnings are acceptable.

Give the coding agent a narrow implementation brief. For example: create an internal wrapper around RemoveAllAudienceMembers; require an explicit audience identifier and either a full-clear or before-timestamp mode; reject a missing cutoff in the second mode; emit structured warning data without raw user-provided fields; and add fixture tests for clearing, rebuilding, cutoff boundaries, and partial-warning ingestion. Then review the generated client types, request construction, authentication handling, and tests against the API materials and dependency versions actually installed in your environment.

Set production acceptance criteria

A scheduled full clear cannot run unless its replacement dataset and rebuild job are ready.
Every cutoff-based operation records the exact timestamp and timezone used by your integration.
Completed-with-warnings runs are visible in dashboards and alert routing.
Ordinary logs exclude raw names, addresses, and complete user-provided-data payloads.
Destination controls prevent expanded address fields from entering an unapproved path.
The recovery runbook has been exercised against a controlled audience fixture, not merely written down.

Start by capturing warnings from the payload you already send. Once that signal is reliable, introduce timestamp-based cleanup behind an explicit approval path, then prove the full-clear rebuild process with controlled data. Expand Analytics address mappings last. You will gain the automation benefits without making a destructive audience action or a sensitive-data change your first live test.

References

Search Engine Land – Google expands Data Manager API with smarter audience management

August 3, 2026

Conductor Content API for AEO: Build a Reliable Workflow
You do not need another place for writers to paste drafts. You need a controlled way to move a useful brief into a reviewed, publishable answer without losing evidence, ownership, or editorial judgment between systems.

That is the practical opportunity behind the Conductor Content API. Used well, it can bring AEO guidance into the tools where your team already plans, writes, approves, and publishes content. Used carelessly, it can turn an opaque score into an automated publishing rule. The difference is the workflow you build around it.

The API belongs inside your content system, not above it

The Content API is designed to generate, score, and optimize content for AI and traditional search inside your own stack. That describes its functional role. It does not mean that an API-generated draft, a higher score, or an optimization pass guarantees inclusion in an AI answer.

Treat it as a decision-support layer between your content inputs and publishing controls. Your content management system should remain the system of record. Your evidence library should remain the source of approved claims. Your editors should remain accountable for what reaches the public page.

The integration is most useful when your current problem is operational: briefs are interpreted differently by each writer, optimization happens late, drafts move between several tools, or teams cannot apply the same review criteria at scale. It is less likely to help when the real problem is missing expertise, weak evidence, unclear ownership, or pages that cannot be updated after publication. An API can accelerate a defined process; it cannot define the truth for you.

Before committing engineering time, identify the exact handoff you want to improve. Good candidates include creating a first draft from an approved brief, evaluating a draft before editorial review, or returning suggested changes inside a CMS. Avoid starting with a broad instruction such as “optimize all content for AEO.” It gives your team no stable input, acceptance rule, or safe stopping point.

Build the pipeline around an explicit content contract

Your first implementation artifact should not be an API call. It should be a content contract: the fields every request must contain, the outputs your system will retain, and the conditions a draft must satisfy before it can advance.

Define the inputs that make an answer trustworthy

A keyword and a desired word count are not an AEO brief. Give the pipeline enough context to produce an answer that is specific, attributable, and appropriate for the page. A practical internal request object should usually contain:
- A persistent content ID, so every request and revision can be traced to the same asset.
- The question or task the page must resolve, written in the language the intended reader would use.
- The audience and decision stage, including what the reader already knows and what they need to do next.
- A proposed canonical answer: the short, direct response the page must support rather than obscure.
- Approved evidence, including source URLs, factual notes, dates where freshness matters, and the claims each item supports.
- Named entities that must be represented unambiguously, such as products, organizations, locations, standards, or people.
- Claims that require specialist, legal, compliance, or brand review.
- The CMS content type, required fields, internal links, and any structured data fields populated downstream.
- An owner and a review trigger for information that can become outdated.
Keep those fields in your own data model even if the API uses different names. Your internal contract should outlive a particular endpoint or response format. Map it to the exact API specification available to your account rather than designing your entire content operation around an announcement-level description.

Separate generation, evaluation, and revision

Generation, scoring, and optimization solve different problems. Combining them into one invisible action makes failures difficult to diagnose. Keep them as observable stages:
1. Assemble the brief. Validate required fields before sending content anywhere. A missing approved source should stop a source-dependent claim from being generated.
2. Generate only where generation is useful. A new draft may benefit from generation. A carefully written expert page may need evaluation without being rewritten.
3. Score the draft. Store the result alongside the exact input and draft version that produced it. A score without its corresponding text is not auditable.
4. Apply selected recommendations. Present proposed changes as a revision or diff. Do not silently overwrite an editor’s draft.
5. Run your own acceptance checks. Validate facts, links, required CMS fields, accessibility, structured data inputs, and approval status before publication.
This separation also helps you locate the real problem. A weak draft may come from an incomplete brief, a misunderstood question, unsupported claims, or an optimization that removed necessary nuance. Repeatedly sending the same text through another optimization pass will not repair a bad input contract.

Before development begins, confirm the field schema, authentication method, error behavior, usage constraints, and versioning rules that apply to your access. Those details determine how you handle retries, validation, logging, and fallbacks; they should not be inferred from the product’s high-level positioning.

Use the score as evidence, not as the publishing decision

A content score is useful when it helps an editor notice a correctable weakness. It becomes dangerous when a team treats the number as a proxy for factual accuracy, authority, or guaranteed AI visibility.

Do not set an automatic publishing threshold until you have calibrated the result against content your own reviewers consider acceptable. During calibration, compare like with like. A product page, support answer, glossary entry, and long educational page perform different jobs; a raw score may not carry the same meaning across all of them.

For each evaluation, retain the draft version, request inputs, returned recommendations, any component scores the response provides, and the final editorial disposition. Record whether the editor accepted, modified, or rejected each recommendation and why. That history will show whether the integration catches useful issues or merely creates revision work.

Your human review should test qualities that no scalar score should be trusted to settle on its own:
- Answer proximity: Can the reader find a direct answer close to the question it resolves?
- Standalone clarity: Does the core answer remain understandable when read without the surrounding introduction?
- Claim support: Can the reviewer connect each material factual claim to approved evidence?
- Entity clarity: Are full names used where pronouns, abbreviations, or similar product names could create ambiguity?
- Qualification: Are conditions and limitations placed beside the claim they modify rather than buried at the end?
- Information access: Are important facts present in readable page text instead of existing only in an image, script, or interaction?
- Page integrity: Do the title, headings, canonical URL, internal links, and structured data describe the same primary subject?
- Editorial value: Does the page add a useful answer, explanation, decision rule, or evidence rather than merely restating common language?
Structured data belongs in this review, but it should be generated from verified CMS fields rather than invented from prose. Schema markup can make page entities and relationships more explicit. It cannot rescue an unsupported answer, and it does not guarantee that an answer engine will select the page.

Use a failed score to open a review, not to authorize an indiscriminate rewrite. If a recommendation conflicts with evidence, changes the intended audience, removes an essential caveat, or introduces a claim that is not in the brief, reject it. The purpose of optimization is to improve communication without changing what is true.

Pilot the workflow in shadow mode before it can publish

Choose one repeatable, low-risk content type for the pilot. A tightly defined template makes it easier to distinguish a useful optimization from normal variation between pages. Do not begin with regulated advice, high-value transactional pages, or a bulk rewrite of your archive.

Run the first version in shadow mode: send the same material through the proposed pipeline, but let the existing editorial process remain authoritative. Reviewers can compare the draft, score, and recommendations without allowing the integration to change a live page.

Measure the process before trying to attribute search outcomes. Useful operational measures include editorial acceptance, recurring rejection reasons, missing-input errors, manual revision effort, publishing failures, and the proportion of recommendations that survive review. Track traditional search performance and AI visibility separately, because they are different observations and neither automatically proves that an API-generated change caused the result.

The production design should also fail safely:
- Write generated and optimized text to a draft or revision, never directly over the current published version.
- Use a stable request identifier so a retry cannot create duplicate drafts or duplicate publishing jobs.
- Preserve the last approved version and the evidence attached to it.
- Keep credentials, private customer information, and unnecessary personal data out of content payloads.
- Require the relevant approval when a recommendation changes a factual claim, disclaimer, offer, or regulated statement.
- Stop the workflow when a required field, source, or validation result is missing instead of publishing a partial response.
- Keep optimization separate from deployment so an API error does not take down page delivery.
Expand only after the pilot tells you which inputs predict good output and which recommendations editors consistently trust. At that point, you can reuse the contract for another content type, establish a separate calibration set, and add automation around the decisions that have proved stable. Do not assume the first template’s thresholds or review rules transfer unchanged.

Key takeaways
- Place the Content API inside a governed content workflow; do not treat it as a replacement for your CMS, evidence library, or editors.
- Define the question, audience, canonical answer, approved evidence, entities, risk flags, owner, and CMS destination before requesting generation or optimization.
- Keep generation, scoring, optimization, validation, and publishing as separate, traceable stages.
- Calibrate scores by content type and use them to prompt review, not to guarantee quality or AI visibility.
- Introduce the integration in shadow mode, preserve revisions, and require explicit approval for material claim changes.
- Measure editorial usefulness and operational reliability before expanding the workflow or attributing search performance to it.
Your next step is small but consequential: write the content contract and one unambiguous acceptance gate before anyone builds the integration. If your team cannot state what a safe, publishable answer must contain, connecting an API will only automate that ambiguity. Once the gate is clear, the Content API can become a useful part of a measurable AEO operation rather than another disconnected scoring tool.

References
- Conductor Blog – Conductor Content API: Optimize Content for AEO, Anywhere
July 29, 2026

Google Ads Access and Compliance Controls: A Practical Runbook

If you manage Google Ads through an API, an agency workflow, or connected reporting tools, your next access failure may not be a broken integration. It could be a human user who cannot complete a new authorization because no trusted passkey is ready. A campaign approval can stall for a separate reason: the account has not completed the certification required for a particular use.

You need to manage those as two control planes. Authentication determines who or what can connect to Google Ads. Certification determines whether an account has completed a policy approval for a particular advertising activity. Keeping separate owners and status records for each makes both problems easier to prevent and diagnose.

Key takeaways

A passkey is required when a user generates a new OAuth 2.0 refresh token through the Google Ads API user-authentication workflow. This is not a blanket invalidation of every existing connection.
Existing OAuth refresh tokens continue working and do not need reauthorization solely because of this change.
A newly created passkey may face a seven-day security delay before it becomes fully trusted. Prepare it before a scheduled onboarding or authorization event.
Service-account automation is not affected, but Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio are included in the broader passkey rollout.
Some certification applications are moving into Admin > Policy > Account. Availability varies, and the Help Center remains the fallback when the in-account workflow is absent.

Treat authentication and certification as separate controls

An OAuth refresh token is a credential that lets an application obtain new access tokens without asking the user to sign in for every request. A certification is an account-level policy approval for a defined advertising use. Both can block work, but they answer different questions.

Control area	Question it answers	What you should record
Authentication	Can this user, service account, application, or connected tool authenticate?	Credential type, human owner, passkey readiness, token state, affected system, and last successful authorization
Certification	Has this Google Ads account completed the required policy application for the intended advertising use?	Customer account, certification type, submission route, accountable approver, submission status, and decision

A passkey cannot establish that you have the right to use copyrighted material. A Social Casino Games certification cannot restore an invalid OAuth credential. When a team tracks both under a vague label such as “Google access,” the wrong person receives the incident and the actual blocker remains untouched.

Assign an access owner and a policy owner for each account. They can be the same person in a small organization, but the responsibilities should remain distinct. The access owner manages identities, credentials, connected products, and authorization events. The policy owner confirms the intended ad use, controls certification submissions, and keeps the supporting internal approval trail.

Prepare new OAuth authorizations before they become urgent

The passkey requirement has a narrow but important scope. Under the announced rollout, which begins Aug. 5 and expands over the following weeks, a human following the Google Ads API user-authentication flow must use a passkey to generate a new OAuth 2.0 refresh token. Password-only authentication and familiar second-factor routes such as SMS codes and time-based one-time passwords no longer satisfy this particular workflow. A user without a passkey is prompted to create one.

Do not interpret that as an instruction to rotate every refresh token. Existing refresh tokens remain valid without reauthorization. Revoking a working credential merely to “comply” can create the exact new-token event for which your team is not yet prepared. Rotate or revoke a token when your normal security process requires it, but do not manufacture a migration that Google does not require.

The planning risk sits at the next authorization event. A newly created passkey may be subject to a seven-day security delay before Google fully trusts it. That means a user who creates a passkey when onboarding begins may not be able to finish the workflow on the date you promised.

Identify the human Google accounts expected to authorize new integrations or reconnect deliberately.
Have those users create their passkeys before the authorization window, not during it.
Put the possible seven-day delay into onboarding plans and change windows that depend on a new refresh token.
Keep existing refresh tokens in place while they remain valid and authorized.
Never paste a refresh token, passkey material, or other secret into a ticket, spreadsheet, or certification record. Track status and ownership, not secret values.

Also distinguish an expiring access token from a request for a new refresh token. A healthy OAuth integration normally uses its existing refresh token to obtain new access tokens. The passkey change does not mean a person must intervene every time a short-lived access token expires.

Build the runbook around the credential type

Three organized credential setups for a staff user, an application, and an agency account surround a central advertising platform device.

A single instruction that says “set up a passkey for Google Ads” is too broad to be operationally useful. Start by classifying every connection according to how it authenticates and who owns the authorization.

Create an inventory with the Google Ads customer or manager account, connected application, environment, credential type, human or service owner, and business purpose.
Mark each connection as user-authorized OAuth or service-account automation. Applications that use service accounts for automated workflows are not affected by the new user passkey requirement.
For user-authorized OAuth, record whether the current refresh token is working and whether the authorizing user has a passkey ready for a future authorization.
List connected Google Ads products separately. Google Ads Editor, Google Ads Scripts, BigQuery Data Transfer Service, and Looker Studio are also affected; a user accessing them without a passkey can be prompted to create one.
Add a named backup owner for the process, but do not create shared human accounts or copy credentials between people. The backup should know the recovery and reauthorization procedure, not possess another user’s secret.
Review the inventory before onboarding a client, changing the authorizing identity, or intentionally replacing a refresh token.

This classification also shortens incident triage. If a previously healthy API sync fails while using an existing refresh token, do not assume the passkey rollout invalidated it; existing tokens were explicitly left in place. Investigate the normal credential, permission, application, and account conditions. If a new user-consent flow cannot complete, check passkey readiness and the possible trust delay first. If service-account automation fails, the new user passkey rule is unlikely to be the cause.

Connected products deserve named owners even when the API integration itself is stable. A reporting team may meet the prompt in Looker Studio or BigQuery Data Transfer Service while the central API pipeline continues normally. Without a product-level inventory, that prompt can be misreported as an account-wide outage.

Turn in-account certifications into a controlled workflow

Compliance specialists move an account dossier through evidence review, approval, and secure archiving while an incomplete folder remains separated.

Google is gradually placing some certification applications inside Google Ads. Eligible advertisers may see the Social Casino Games workflow under Admin > Policy > Account. Not every account receives the option at the same time, so a missing menu is not evidence that an application was denied. Advertisers without the in-account option can continue using the existing Help Center process.

The interface rollout does not change the underlying advertising policy. It changes where some advertisers submit and manage the application. Existing Social Casino Games certifications remain valid, and pending applications are not affected. Do not submit a replacement merely because another account has gained the new interface.

A copyright-certification beta has also appeared as an account-level notice in Google Ads Manager. It opens a form that asks the advertiser to certify the right to use copyrighted content. Treat that availability as account-specific rather than universal.

Check Admin > Policy > Account in the exact customer or manager account involved.
If the appropriate certification workflow is present, record that the in-account route is available before submitting.
If it is absent, use the existing Help Center route instead of waiting indefinitely for the gradual rollout.
Check your internal register for a valid certification or pending application before creating another submission. Existing and pending Social Casino Games cases do not need to be restarted because of the interface change.
Record the account, certification type, submission route, submission date, accountable person, current status, and decision in a system your policy owner can review.
For a copyright attestation, route the submission to someone authorized to confirm ownership or licensing. The form records a certification; it does not create rights that the advertiser does not already hold. If the rights are unclear, pause the submission and have the appropriate rights or legal owner verify them.

Do not let the easier placement reduce the quality of your review. An in-account button makes submission more convenient, but convenience is not evidence. The person submitting should still be able to identify the account, the intended use, the authority for the claim, and the internal owner who approved it.

Before your next onboarding or certification deadline, create the two registers, classify every credential, and assign the two owners. Then have affected human users prepare passkeys early and check the exact account for its available certification route. The immediate job is not to reauthorize everything. It is to remove uncertainty about who can authorize access, who can certify compliance, and what happens when either control changes.

References

July 27, 2026

Google Ads Automation Updates: A Practical Measurement Plan

Your biggest Google Ads risk is no longer a lack of automation. It is allowing the platform to make a wider range of decisions while your reporting still collapses those decisions into one campaign total.

If you run Standard Shopping campaigns or maintain a Google Ads integration, you now have two different changes to prepare for. AI Max functionality in Standard Shopping remains an unconfirmed test, while Google Ads API v25 is a released engineering change. In both cases, the practical goal is the same: define what Google may decide, record what it actually does, and connect each decision to a business outcome.

Automation and measurement are changing at the same time

Standard Shopping has traditionally appealed to advertisers who want more direct control than Performance Max provides. That distinction could become less clear. A reported AI Max test in Standard Shopping includes conversational query matching, feed-based ad copy, Final URL Expansion, and the ability to choose between a Shopping ad and a text ad based on the query.

The reported implementation would preserve existing bidding and targeting settings while adding campaign-level controls for asset optimization, brand exclusions, and Final URL Expansion. Advertisers could reportedly disable URL expansion when they want traffic to remain tied to Shopping ads. That combination matters: it suggests Google may expand the decisions made inside Standard Shopping without forcing advertisers to migrate the campaign into Performance Max.

Do not treat those capabilities as settled product behavior. Google has not formally announced the Standard Shopping test, so availability, controls, and final functionality could change. Treat it as a scenario for which you can prepare, not a feature you should promise to a client or build into a forecast.

Google Ads API v25 is different. It adds new YouTube reporting, Shorts engagement metrics, creator insights, a loyalty retention goal, and a revised implementation of new customer acquisition goals. It also requires developers to update client libraries and code to use the new functionality, while the removal of legacy resources can affect compatibility. The API v25 changes therefore belong in an engineering release plan, not on a product-watch list.

Key takeaways

Prepare for AI Max in Standard Shopping, but preserve the distinction between a reported test and a released feature.
Treat query matching, message generation, destination selection, and ad-format selection as separate automation permissions.
Record feature settings alongside campaign results so you can explain why performance changed.
Use API v25 to deepen YouTube and lifecycle reporting rather than adding new metrics to an undifferentiated dashboard.
Upgrade integrations through staging and regression checks because legacy lifecycle resources have changed.

Write an automation contract before enabling AI Max

An automation contract is a short operating document that states which decisions the platform may make and which boundaries it must respect. You do not need legal language or a lengthy policy. You need an explicit answer for each decision layer before a campaign starts spending under new rules.

Decision layer	Potential automated behavior	What you should decide first
Query	Match Shopping inventory to conversational and long-tail searches	Which brand, intent, and relevance boundaries must be protected
Message	Create ad language from Merchant Center attributes	Which attributes are accurate, current, and safe to present as claims
Destination	Send a visitor to a page selected through Final URL Expansion	Which page types are eligible and whether expanded routing should be enabled
Format	Choose between a Shopping ad and a text ad	How each format will be identified and evaluated in reporting

Start with the feed. Materials, fit, durability, and other Merchant Center attributes may become inputs to generated ad copy. A feed value that was previously visible only in a product listing can therefore become a prominent advertising claim. Check those attributes for accuracy, consistency, and substantiation. Do not use automation to amplify language that merchandising or legal reviewers would reject on the landing page.

Then decide how much routing authority the campaign should receive. Final URL Expansion is not merely a media setting; it is permission to select a different part of your site as the destination. A technically valid page can still be commercially wrong if it shows the wrong product set, weak availability, conflicting prices, or a conversion path that was not built for paid traffic.

Verify that eligible pages show the same material product facts used in the feed.
Confirm that price, availability, promotional language, and conversion tracking remain correct on every likely destination type.
Use brand exclusions where matching or generated messaging could cross a brand boundary.
Keep Final URL Expansion disabled until broader destinations have passed the same review as product pages.
Document who may approve a wider set of destinations after the initial validation.

The downside of skipping this work is direct: budget can move to a page or message that does not represent the offer you intended to advertise. If you cannot verify destination eligibility, keep traffic constrained to the known Shopping path until you can.

Make every automated decision observable

Transparent routing gates direct product-shaped objects along illuminated paths while sensors record each decision point.

Aggregate campaign performance cannot tell you whether a change came from broader query matching, generated messaging, a different destination, a different ad format, or the bid strategy already in place. You need a record that separates inputs, permissions, delivery, and outcomes.

Measurement layer	What to record	Question it answers
Inputs	Feed revisions, attribute changes, landing-page changes, and tracking changes	Did the campaign receive different information?
Permissions	Asset optimization state, brand exclusions, Final URL Expansion state, bidding settings, and targeting settings	What was Google allowed to change or select?
Delivery	Available search-query detail, served ad format, selected destination, product coverage, and traffic mix	What did the system actually do?
Outcomes	Spend, conversions, conversion value, engagement, acquisition outcomes, and retention outcomes relevant to the campaign	Did the behavior produce the intended business result?

Capture the current state before changing a setting. Screenshots can help during a preliminary rollout, but a structured change record is more useful because it can be joined to reporting later. At minimum, store the account, campaign, setting name, previous state, new state, approval owner, deployment point, expected effect, and rollback condition.

Next, write a falsifiable hypothesis. Broader conversational matching, for example, is not a complete hypothesis. A usable version identifies the eligible product group, the type of demand you expect to reach, the outcome you expect that traffic to produce, and the signal that would show the expansion is commercially irrelevant.

Snapshot campaign settings, feed state, destination rules, and baseline reporting dimensions.
Choose the specific automation permission being evaluated.
Predefine the primary outcome and the business guardrails.
Change one permission at a time where the platform and campaign structure allow it.
Inspect query, format, and destination behavior before relying on the aggregate result.
Keep, constrain, or reverse the change based on the predefined outcome and guardrails.

Do not copy a universal efficiency threshold from another account. A defensible guardrail comes from your margins, sales cycle, conversion quality, inventory constraints, and tolerance for exploratory demand. The important discipline is to set it before seeing the result. A threshold invented after the test becomes a justification, not a decision rule.

Use API v25 to separate YouTube signals from business outcomes

Anonymous video engagement signals pass through separate data channels toward shopping, repeat-customer, and new-customer outcome scenes.

Segment non-skippable ads by sub-format

API v25 introduces the ad_sub_format_type segment for non-skippable in-stream YouTube ads. It can distinguish standard duration, ads up to 30 seconds, and ads up to 60 seconds. That dimension prevents materially different creative experiences from disappearing inside one format total.

Add the segment where it answers a real creative or delivery question. Compare performance within a consistent campaign objective and audience context. If duration, targeting, bidding, and creative concept all change at once, the new field gives you a cleaner label but not a causal explanation.

Keep Shorts engagement diagnostic

Comments, likes, and shares are now available for Shorts ad reporting. These metrics can show how viewers respond socially to a creative, but they are not substitutes for conversions, revenue, qualified acquisition, or retention. Use them to diagnose resonance and participation, then read them beside the outcome the campaign was funded to produce.

A practical Shorts view should keep delivery, engagement, and business results in separate groups. That structure stops a highly interactive ad from being declared successful when it misses the commercial objective, while still preserving the engagement data that can guide creative development.

Treat creator insights as conditional data

API v25 can expose creator-channel information including average views, engagement rates, likes, comments, and audience attributes. Non-public details depend on creators opting to share them. Build reports that make missing or unavailable creator data explicit rather than treating absent values as zero performance.

Creator metrics are best used to improve selection and contextual interpretation. They do not remove the need to measure the actual ad, audience, offer, and conversion path used in your campaign.

Separate retention optimization from customer acquisition

API v25 adds a loyalty retention goal with campaign- and account-level settings. It also supports bid adjustments and loyalty-member benefits in Product Listing Ads. This gives advertisers a way to optimize for keeping loyalty members rather than treating every valuable action as another acquisition event.

That distinction should survive all the way into your dashboard. Acquisition asks whether you gained the intended new customer. Retention asks whether an existing loyalty member stayed active or received an experience designed for that relationship. Combining them can make campaign efficiency look healthy while concealing which lifecycle objective produced the value.

New customer acquisition goals have also moved to Google’s unified goals framework, replacing legacy lifecycle goal resources. Before upgrading, map each existing resource, field, report, and internal label to its intended counterpart. Do not let an engineering migration silently redefine the business meaning of a goal.

Give acquisition and retention goals distinct names in campaign documentation and reporting.
Identify the first-party data and membership logic on which each goal depends.
Assign an owner to validate member benefits shown in Product Listing Ads.
Keep bid adjustments visible in the same change record as the lifecycle goal.
Check that executive dashboards do not merge retained members with newly acquired customers.

This is where media, analytics, customer relationship management, and engineering teams need one shared definition. The API can transport the goal, but it cannot resolve a disagreement about who counts as new, retained, or eligible for a member benefit.

Put API and campaign changes into production safely

Begin the API v25 migration with an inventory of affected client libraries, queries, resources, report schemas, calculated fields, dashboards, and downstream exports. Pay particular attention to code that depends on legacy lifecycle goal resources. New reporting fields are useful only after the existing integration remains trustworthy.

Map current dependencies and identify removed or replaced lifecycle resources.
Upgrade the supported client library and update code in a non-production environment.
Add the YouTube sub-format, Shorts engagement, creator, and loyalty fields only where a defined use case exists.
Run unchanged reports through regression checks and compare row structure, totals, null handling, and field meaning.
Test reports with and without the new optional dimensions so downstream users understand how segmentation changes the output.
Deploy with monitoring and a documented recovery path for failed jobs or incompatible consumers.

Use the same release discipline for campaign automation. A campaign ticket should state the setting before and after the change, eligible products and brands, permitted destination types, expected query behavior, primary outcome, guardrail, data location, approval owner, and rollback condition. This turns an AI feature from an opaque switch into a governed campaign change.

Your first move should be simple: capture the current state of the campaigns and integrations that would be affected. If the Standard Shopping test never reaches your account in its reported form, that record still improves your control over existing automation. If it does arrive, you will be ready to test it without sacrificing the ability to explain where an ad appeared, what it said, where it sent the visitor, and whether that decision helped the business.

References

July 23, 2026

Tag: API

Treat Google Ads AI as two separate control problems

Audit the product title shoppers actually see

Review meaning before performance

Read the metrics as observation, not a controlled test

Make the API assistant prove technical validity

Use conversational troubleshooting as triage

Know what grounding does not prove

Build one evidence trail across marketing and development

Key takeaways

References

Key takeaways

Build your measurement model around six different questions

Make original conversion value an audit layer

Keep lift, benchmarks, and sentiment in their own lanes

Lift data needs its study context

Category benchmarks provide context, not a target

Brand sentiment is an intelligence signal

Connect loyalty reporting to value-rule governance

Roll out v25.1 without changing metric meaning by accident

References

Separate event collection from campaign interpretation

Add Microsoft CAPI without dismantling UET

Reset how you report Google’s Branded Searches

Choose the window for comparability, not a bigger count

Use the signal to investigate influence, not claim causation

Put every measurement change behind a written contract

Key takeaways for your next measurement review

References

Know exactly where the language setting stops applying

Rebuild multilingual control around the ad-to-page journey

Make landing-page language an operating requirement

Monitor language matching without waiting for a perfect report

Update Google Ads API workflows by campaign type

Key takeaways

References

The reporting flow is now a direct request-response path

Choose the endpoint by workload, not by which API is newer

Design interactive queries that remain useful under pressure

Start with the user’s question, not every available field

Treat 60 seconds as a ceiling, not a target

Do not equate synchronous retrieval with instant measurement

Put a stable adapter between CM360 and the interface

Separate no data, zero, slow, and failed

A low-risk rollout keeps the batch path intact

Campaign Manager 360 reporting API FAQ

Is reportData.query a streaming API?

Does “real-time reporting” mean every metric is instantly current?

Should an existing Reports service integration be migrated completely?

What is the best first use case?

References

Key takeaways

Stop asking one visibility score to explain everything

Build a prompt panel you can run again without changing the test

Join AI observations to page, query, and outcome data

Use MCP as a data-access layer, not an accuracy layer

Turn the report into a controlled decision

References

Key takeaways

Make audience replacement a controlled operation

Treat ingestion warnings as a real pipeline outcome

Expand address data only where the destination and purpose match

Roll out the changes in a sequence you can reverse

Use Google’s agent skills as scaffolding, not authority

Set production acceptance criteria

References

The API belongs inside your content system, not above it

Build the pipeline around an explicit content contract

Define the inputs that make an answer trustworthy

Separate generation, evaluation, and revision

Use the score as evidence, not as the publishing decision

Pilot the workflow in shadow mode before it can publish

Key takeaways

References

Key takeaways

Treat authentication and certification as separate controls

Prepare new OAuth authorizations before they become urgent

Build the runbook around the credential type

Turn in-account certifications into a controlled workflow

References