Tag: API

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

Digital Asset Management Activation: From Library to Delivery
Your DAM can be impeccably organized and still leave you with late campaigns. If engineers resize hero images, regional marketers re-upload files into local systems, or teams keep asking which logo is current, the library is working but the delivery chain around it is not.

Digital asset management activation closes the distance between an approved asset and its correct appearance on a page, product listing, email, social post, or partner platform. You do that by replacing manual handoffs with governed references, on-demand variants, direct integrations, and machine-readable rules that apply equally to people, applications, and AI agents.

Find the activation gap before you add another tool

A traditional DAM answers library questions: Where is the asset? Which version is approved? Who can use it? When does it expire? Activation answers a different set of questions: How does the approved asset reach its destination? Who changes it along the way? Does the destination receive the right size, crop, format, locale, and version? What happens when the approved original changes?

The activation gap is the work between approval in the DAM and verified delivery in the customer-facing channel. It includes every download, chat request, spreadsheet lookup, resize, local upload, approval check, and duplicate copy in that path. Those steps may look harmless individually. Together, they create delay and make it difficult to prove what actually went live.

Content demand makes that gap harder to ignore. In a 2025 Adobe survey of more than 1,600 marketers, 62% said demand had increased fivefold or more over the preceding two years. That survey result is directional, not a performance benchmark for your organization. Establish your own baseline from actual launches.

Start by tracing one recently published asset from approval to delivery. Choose a normal launch with real exceptions, not the cleanest workflow your team can demonstrate.
1. Record the asset identifier, approval state, approved revision, owner, market, usage constraints, and approval time.
2. List every person and system that touched the asset after approval.
3. Mark each point where the file was downloaded, copied, renamed, resized, reformatted, edited, or uploaded again.
4. Record where a person had to interpret an ambiguous field, confirm permission in chat, or decide which version was current.
5. Stop only when the asset has rendered correctly in the live destination and someone has verified it.
Measure the workflow with operational signals you can reproduce:
- Elapsed time from DAM approval to verified publication.
- Number of manual handoffs and download-upload cycles.
- Number of derived files stored as separate assets.
- Requests sent to design or engineering for routine channel variants.
- Incidents involving the wrong revision, market, rights state, or expiration status.
- Share of live placements that retain a traceable DAM identifier or governed delivery URL.
- Time required to replace or withdraw an asset across every destination.
You now have an activation backlog. Prioritize the handoff that appears most often or creates the most consequential errors. A portal redesign will not remove a download-upload loop. A new taxonomy will not remove an engineering resize request. Match the fix to the failure you observed.

Give every asset a machine-readable activation contract

Direct integrations move assets faster, but they also move ambiguity faster. Before a CMS, commerce platform, automation, or AI agent can select an asset safely, it needs an explicit contract describing what the asset is, where it may be used, and which transformations are permitted.

Define that contract for each asset class. A useful minimum includes:
- Identity: a persistent asset ID, asset class, owner, and relationship to the relevant product, campaign, page, or brand entity.
- Lifecycle state: clear values such as draft, under review, approved, published, withdrawn, and expired. Do not rely on a folder name to imply approval.
- Revision: an explicit approved revision and a record of what it replaced.
- Usage context: permitted brands, markets, locales, channels, campaigns, and destinations.
- Rights and timing: usage constraints, start and end dates where applicable, and the party responsible for renewal or withdrawal.
- Descriptive metadata: controlled terms and destination-ready descriptions that downstream systems can map to visible and machine-readable fields.
- Delivery policy: approved crops, aspect ratios, output dimensions, format rules, quality rules, and whether generative editing is allowed.
- Replacement behavior: whether consumers should always receive the current approved asset or remain pinned to a specific revision.
Required fields should be enforced when the asset changes state, not discovered by the publishing system later. An upload may remain a draft with incomplete metadata. Approval should fail if a field needed for safe activation is missing. Downstream systems should retrieve only records that satisfy their eligibility rules.

For SEO, AEO, and GEO teams, activation is an operational control rather than a ranking shortcut. It helps the CMS, page templates, feeds, and structured outputs receive the same stable asset reference and descriptive information. If your CMS emits structured data, map media fields from the governed asset record instead of maintaining a second, disconnected set of values in a plugin or spreadsheet.

Choose deliberately between current and fixed references

One URL that always resolves to the latest approved asset is useful when every placement should update together. A brand logo, evergreen product image, or corrected illustration may fit that pattern. The reference remains stable while the approved file behind it changes.

Other placements need an immutable, revision-specific reference. Campaign records, archived pages, contractual partner deliveries, and creative with time-limited rights may need to preserve exactly what was published. Silently replacing those files can create compliance, reporting, or evidentiary problems.

Support both behaviors. Use a current alias when automatic propagation is intentional and a fixed revision when reproducibility matters. Document the choice in the activation contract rather than leaving each destination to guess.

Generate channel variants from a governed original

Routine resizing should not create a new branch of your asset library. A 2023 Santa Cruz Software survey found that 76% of designers spent at least 20 hours per week resizing graphics. Do not treat that vendor-cited survey as a universal staffing benchmark. Check your own request queue and file history to see how much specialist time is being consumed by predictable derivatives.

The better operating model keeps one governed original and creates delivery variants when a channel requests them. A 6MB, 4000 by 3000 original can supply a 1920 by 1080 hero, a 400 by 400 thumbnail, a 1200 by 630 social preview, and a 750 by 1000 mobile treatment without storing four manually exported copies.

Build this around named transformation recipes rather than unrestricted editing parameters:
1. Preserve the original as the governed master. Do not let a destination overwrite it.
2. Define recipes by business purpose, such as product thumbnail, desktop hero, mobile hero, social preview, and partner feed image.
3. Specify dimensions, aspect ratio, crop behavior, focal-point handling, format, and quality in each recipe.
4. Let the CMS or delivery layer request the asset ID plus the recipe instead of uploading a separate file.
5. Log the master revision and transformation recipe used for each generated result.
6. Test what happens when the master changes, including cache refresh, rollback, and destinations pinned to an older revision.
Separate deterministic processing from creative generation. Resizing, format conversion, and approved crop rules can usually run as repeatable delivery operations. Background replacement, generative fill, and prompt-based edits change the creative meaning of the asset. Treat those outputs as governed derivatives that need an identity, lineage, rights review, and approval state of their own.

This distinction prevents a serious automation mistake: allowing a runtime request to create brand-new creative without review. AI can produce the variation, but it should not silently grant that variation permission to publish.

Connect publishing tools without weakening governance

A DAM portal is still useful for browsing, curation, review, and administration. It should not be the only route by which content enters or leaves the library. Requiring every user to find, download, transform, and re-upload an asset turns the portal into a manual transport layer.

Design the activation path so each system performs one clear job:
- Creative tools submit originals and required metadata to the DAM.
- The DAM controls identity, lifecycle state, rights, approval, and lineage.
- The CMS, commerce platform, email system, or partner application stores a governed reference rather than an unmanaged copy whenever its architecture allows.
- The delivery layer returns the approved revision in the requested transformation recipe.
- Monitoring records which asset, revision, recipe, and destination were involved.
Use a native integration when it removes a frequent context switch inside a tool where work already happens. Use a headless API when another application needs dependable read or write access. In both cases, define the allowed operations, required metadata, error behavior, authentication, and audit trail before connecting production systems.

Model Context Protocol, or MCP, adds another interface for AI-assisted workflows. An MCP server can expose DAM capabilities to compliant AI tools, allowing an assistant or automation agent to search for approved assets and request a valid rendition without navigating the portal.

MCP changes the interface; it does not replace governance. Expose narrow, task-specific capabilities such as searching approved assets, reading metadata, retrieving a fixed revision, or requesting an allowed variant. Do not give a general-purpose agent arbitrary update, approval, publication, or deletion rights merely because the connection supports them.

Apply eligibility filters before semantic relevance

Keyword-only search becomes unreliable when teams use inconsistent labels. Natural-language search can match meaning, visual search can find similar imagery, and video discovery can index visible content and spoken dialogue rather than relying only on titles. Those capabilities improve recall, but relevance alone is not enough for activation.

Filter the candidate set by hard business rules first: approved state, permitted destination, market, locale, rights window, brand, and required asset class. Rank the eligible results by semantic or visual similarity only after those conditions pass. A visually perfect result is still wrong if it is expired, unapproved, or licensed for another market.

Return enough context for the caller to make a safe choice. A search result should include its asset ID, revision, lifecycle state, intended use, market or locale constraints, rights status, and available recipes. An agent should also record which result it selected and which conditions were evaluated.

AI can help maintain the library by checking uploads, proposing controlled vocabulary, identifying missing metadata, and holding noncompliant files in draft. Introduce that autonomy in stages. Start with suggestions and validation. Move to automatic blocking only when the rules are deterministic and the team can inspect false positives. Keep publication behind an explicit approval state.

Prove activation with one bounded publishing workflow

A large DAM transformation can disappear into platform work. A bounded pilot makes the result visible. Choose one asset class, one destination, and one repeated source of friction. Good candidates include product images sent to an ecommerce CMS, campaign heroes sent to a web CMS, or approved social previews recreated for every launch.
1. Define the boundary. Name the point at which an asset becomes approved and the point at which delivery is verified. Exclude adjacent workflow problems unless they prevent the pilot from operating.
2. Capture the baseline. Measure elapsed time, manual touches, duplicate files, routine resize requests, errors, and replacement time for recent examples.
3. Specify the activation contract. Make required identity, state, rights, locale, destination, revision, and delivery fields explicit.
4. Create the smallest useful recipe set. Include only variants the selected destination actually consumes.
5. Connect the destination. Make it retrieve an approved reference and recipe directly. Preserve a controlled fallback while you validate the new path.
6. Add hard publication checks. Reject drafts, expired assets, disallowed markets, missing required metadata, and unsupported recipes before delivery.
7. Test change behavior. Replace an approved asset in a non-production environment, verify cache behavior, confirm fixed revisions remain fixed, and exercise rollback.
8. Compare the result with the baseline. Look for removed handoffs and errors, not merely a successful API response.
The pilot is ready to expand when the workflow meets concrete acceptance conditions:
- A user can publish the approved asset without downloading and re-uploading it.
- The destination retains a traceable asset ID or governed URL.
- Routine variants come from approved recipes rather than local exports.
- Draft, withdrawn, expired, or otherwise ineligible assets cannot pass the delivery gate.
- The team has tested both current and fixed-reference behavior.
- Logs identify the master revision and transformation applied to a live result.
- An owner can withdraw, replace, or roll back the asset without searching multiple unmanaged libraries.
Assign ownership along the same boundary. Creative owns the approved master and intentional composition. DAM operations owns metadata rules and lifecycle governance. Channel teams own destination requirements. Engineering owns interfaces, authentication, delivery reliability, caching, and observability. Brand, legal, or rights owners define the restrictions that publication checks must enforce.

Key takeaways
- DAM activation is the governed path from an approved original to a verified channel result.
- Measure manual handoffs, duplicate files, routine variant requests, errors, and replacement time before changing the architecture.
- Give every asset a machine-readable contract covering identity, status, revision, rights, context, and transformation policy.
- Generate predictable channel variants from the governed original instead of storing repeated exports.
- Use APIs, native integrations, and MCP as controlled interfaces; none of them substitutes for permissions, approval, or auditability.
- Apply approval, rights, market, and lifecycle filters before semantic or visual ranking.
- Prove the model with one asset class and one destination, then expand using measured results.
Choose one asset from a recent launch this week and draw its path from approval to live delivery. Circle every download, copy, resize, permission check, and upload. The first activation project is the smallest connection that removes the most repeated circle while preserving a clear record of what was allowed to publish.

References
- Search Engine Land – Your DAM solved the library problem. The activation problem is next.
July 22, 2026

Google Ads Shopping Defaults and Lead Form Access: An Audit Plan

Two Google Ads changes can put the same account at risk in opposite ways. Beginning August 31, Shopping campaigns gain local-inventory reach by default. At the same time, Lead Form assets may become accessible to advertisers previously excluded by a large spend requirement.

Treat both as access-control changes. One changes what your campaigns may serve; the other changes who may use a lead format. Neither removes the need for deliberate targeting, verified eligibility, and a reliable data handoff.

Key takeaways

Every Shopping campaign will have the Local products setting enabled beginning August 31. An API value of enable_local=false will no longer prevent local inventory from serving.
For an online-only Shopping campaign, enforce that intent with a listing scope whose product_channel is ONLINE, or exclude local inventory through the campaign’s Inventory filter.
The $50,000 lifetime-spend requirement has disappeared from Lead Form eligibility requirements, but that does not guarantee immediate access in every smaller account.
Plan new Lead Form assets around Search and Performance Max. Do not assume that an older Display or Video implementation remains supported without confirming it in the account.
Choose lead delivery before launch. Manual CSV downloads cover 30 days, while Google retains the data for 60 days and API exports can reach back as far as 60 days.

Replace the local-inventory toggle with an explicit scope

A generic campaign control panel connects through adjustable gates to an online warehouse and several local storefronts on a simplified city map.

The old Shopping control was simple: an integration could set Campaign.ShoppingSetting.enable_local to false. That value is becoming ineffective. Google will treat the setting as true for every Shopping campaign, regardless of the value an integration submits.

The dangerous case is not necessarily a visible campaign failure. It is false confidence. A configuration file may still contain enable_local=false, leading your team to believe that local inventory is excluded when Google is enforcing a different result.

With Google Ads API v25.1 or later, attempting to set enable_local to false returns ContextError.OPERATION_NOT_PERMITTED_FOR_CONTEXT.
With versions earlier than v25.1, existing code may continue to run, but the false value is ignored and Google treats the setting as true.
The change applies to Shopping campaigns. Do not automatically rewrite configurations for other supported campaign types: enable_local continues to function for Performance Max and Demand Gen.

Audit the intent of each campaign before changing code. A clean migration follows five steps:

Classify every Shopping campaign. Mark it as online only, local and online, or intentionally separated by inventory and budget. Do not infer intent from the current value of enable_local; that value may be an inherited template default.
Find every place that writes the old field. Check API integrations, campaign builders, bulk-operation scripts, internal templates, and automated account provisioning. Record the API version used by each workflow.
Move online-only enforcement into listing scope. Use CampaignCriterionService to create a listing scope with product_channel set to ONLINE. This makes the inventory boundary explicit instead of relying on a campaign setting Google will ignore.
Use the Inventory filter where campaign-level separation is easier to manage. Exclude local inventory there when a campaign must remain online only. If online and local products require separate budgets, preserve that separation through campaign structure and inventory filtering.
Validate the result, not merely the deployment. Confirm that each campaign’s effective inventory scope matches its classification. For v25.1 or later, also verify that no automation is generating the context error.

This is more than an API cleanup. Google is moving the meaningful control from a Boolean switch to inventory selection. Your campaign documentation, approval process, and automated tests should name the selected product channel directly.

Treat Lead Form access as provisional until the account confirms it

The disappearance of the $50,000 Google Ads spend requirement materially lowers the stated barrier to Lead Form assets. It does not prove that every qualifying smaller account has already received access. Do not promise the format in a media plan, client scope, or launch schedule until the intended account can create and attach the asset.

The remaining eligibility route centers on advertiser reputation and Advertiser Verification. The spend levels associated with that route are more than $1,000 per account or $15,000 across accounts. Treat those amounts as eligibility checks, not campaign objectives. Increasing spend solely to cross a threshold is not a sound substitute for confirming access.

Use this pre-launch check for each account:

Confirm Advertiser Verification. Identify whether it is complete and whether any unresolved account-status issue could affect reputation-based eligibility.
Test actual asset access. Have an authorized account user verify that the Lead Form asset is available in the account. A removed requirement is not the same thing as a universal rollout guarantee.
Confirm the campaign type. Search and Performance Max are the two currently listed options. Video is no longer listed. Display is also omitted from the supported overview, although a separate requirements passage still references it. Treat Display as unresolved until the account interface and current requirements agree.
Check each target country. Eligibility has expanded into more than two dozen additional countries, including Bahrain, Croatia, Estonia, Jordan, Kuwait, Morocco, Qatar, Serbia, Slovenia, and Tunisia. A multi-country account should validate availability market by market instead of reusing an old eligibility list.
Decide whether to use OTP verification. It is available as a lead-quality control. Measure its effect on both completed submissions and accepted leads rather than assuming that adding verification automatically improves the final pipeline.

This distinction prevents a common planning error: lower eligibility friction does not remove implementation constraints. Your account still needs the right status, a supported campaign type, an eligible country, and a lead-delivery process that works after the form is submitted.

Design the lead handoff before you activate the asset

Lead access is only useful when a submission reaches the person or system responsible for follow-up. Google supports manual CSV downloads, email notifications, Zapier, webhooks, and the Google Ads API. Choose a primary delivery method and a recovery path before the first live submission.

Delivery method	Best fit	Control to put in place
Email notifications	A straightforward alert for a low-complexity workflow	Use a monitored inbox and name the person responsible for missed or delayed notifications.
Zapier	No-code routing into CRM platforms and other business applications	Monitor connection status and failed automation runs; access to thousands of applications does not guarantee that a particular field mapping is correct.
Webhook	Direct delivery into a system you control	Monitor endpoint failures, authentication, field validation, and retry handling.
Google Ads API	Managed exports and account-scale workflows	Track credentials, scheduled-job health, and the 60-day export limit.
CSV download	Manual review, reconciliation, or short-term recovery	Download within 30 days; the manual window is shorter than Google’s 60-day storage period.

Google stores Lead Form data for 60 days, but manual CSV downloads remain available for only 30 days. API exports can access up to 60 days. Those are operational deadlines, not archival guarantees. Your CRM or another controlled business system should become the durable system of record.

Run a controlled handoff test before activation:

Submit a test through each campaign type and country configuration you intend to use.
Verify that every required field arrives in the correct destination and maps to the expected CRM field.
Confirm that the lead receives an owner and enters the intended follow-up workflow.
Document who investigates a failed email, Zapier run, webhook request, or API export.
Schedule reconciliation frequently enough that a failure cannot remain hidden beyond the 30-day manual-download window.

A notification is not the same as successful ingestion. Your acceptance test should end only when the submission appears in the destination system with the correct fields and owner.

Build one control sheet for defaults, eligibility, and retention

The durable fix is an account-level record of intended behavior. Keep it alongside your campaign launch checklist and include:

Campaign name, type, market, and accountable owner.
Intended Shopping inventory: online, local, or both.
The enforcement layer: an ONLINE listing scope, an Inventory filter, or a documented mixed-inventory decision.
Google Ads API version, integration owner, and the location of any remaining enable_local write operation.
Advertiser Verification status and the date Lead Form access was confirmed in the account.
The supported campaign type and country used for each Lead Form asset.
Primary lead-delivery method, fallback method, and failure-monitoring owner.
The 30-day CSV deadline, 60-day storage limit, and date of the latest successful handoff test.

Finish the Shopping review before August 31: remove unexplained uses of enable_local=false and replace every intentional online-only rule with an enforceable scope or filter. Then test Lead Form eligibility separately in each account. If access is present, activate it only after a complete submission reaches its assigned destination.

References

July 20, 2026

Choosing an AI Model in 2026: Performance, Cost and Fit

The strongest AI model on a leaderboard is not automatically the right model for a product, research program or engineering team. Cost, latency, deployment control and input formats can matter as much as raw reasoning performance.

A comparison reported by First Page Sage Blog evaluated 42 large language models and ranked 15 of them using benchmark, pricing and technical data available in June 2026. Its findings offer a useful starting point, provided buyers treat the ranking as a decision aid rather than a universal purchasing order.

How the source built its model ranking

The source weighted eight factors: the Artificial Analysis Intelligence Index at 25%, SWE-bench Verified at 20%, GPQA Diamond at 15%, and context window, output speed and blended API cost at 10% each. Supported modalities and open-weight availability each accounted for the remaining 5%.

Those measures address different questions. SWE-bench Verified tests the resolution of real GitHub issues in a standardized environment, while GPQA Diamond focuses on graduate-level science questions. Context size indicates how much material a model can accept in one call; it does not, by itself, prove that the model will use every part of a long prompt effectively. Speed affects interactive experiences, and open weights can support self-hosting or fine-tuning without dependence on a single API vendor.

When public data was missing, the source applied a conservative below-average score. That choice makes a complete ranking possible, but it can also push models with incomplete reporting below models with more extensive published results.

Key takeaways

Claude Fable 5 led the composite ranking. First Page Sage reported an Intelligence Index score of 60, 95.0% on its standardized SWE-bench source and a blended price of $7.70 per million tokens.
GLM-5.2 stood out among open-weight choices. It was reported at 82.8% on SWE-bench Verified, with a $0.90 blended cost and an MIT license.
Qwen 3.7 Max was the speed leader. Its reported output rate of 198 tokens per second makes it especially relevant to interactive products.
DeepSeek V4 Flash had the lowest estimated blended price. The source listed it at about $0.15 per million tokens, while noting that its Intelligence Index score was unavailable.
No single benchmark settles the decision. Capability, latency, price, modalities, context and deployment requirements need to be considered together.

Match the model to the workload

The most useful way to read the reported results is by operating constraint. A team paying for failed reasoning has different priorities from one serving millions of short customer interactions.

Primary need	Model highlighted by the source	Reported reason to consider it
Maximum overall capability	Claude Fable 5	Highest composite and standardized coding scores in the dataset
Long-running software agents	Claude Opus 4.8	Strong coding and command-line results at a lower price than Fable 5
One multimodal platform	GPT-5.5	Text, vision, audio and image generation in one model
Low-cost open-weight coding	GLM-5.2	Strong reported SWE-bench performance, MIT licensing and a $0.90 blended price
High-speed user interfaces	Qwen 3.7 Max	Fastest confirmed output rate in the comparison
Scientific and multimodal research	Gemini 3.1 Pro	94.1% reported GPQA Diamond performance and support for text, vision, audio and video
Lowest API cost	DeepSeek V4 Flash	Lowest estimated blended price in the dataset
Self-hosted multimodal deployment	Llama 4 Maverick	Open weights and compatibility with major inference frameworks

Where benchmark comparisons need caution

The source explicitly warned that SWE-bench Verified results above roughly 80% should be interpreted carefully because of debate about saturation and practical utility. It also noted that standardized harness results may differ from developer-published figures produced with proprietary tools.

Several entries carry additional uncertainty. MiniMax-M3’s 80.5% SWE-bench result was flagged for possible training-data contamination. Grok 4’s Intelligence Index was estimated rather than officially confirmed, while Llama 4 Maverick lacked published SWE-bench Verified and GPQA Diamond figures in the materials reviewed. GPT-5.3 Codex also lacked a standardized SWE-bench Verified result, and the listed Intelligence Index figure was preliminary.

Pricing deserves similar scrutiny. A blended figure depends on the assumed balance of input and output tokens, while self-hosting introduces infrastructure and operational costs that an API price does not capture. Latency can also vary by provider even when the underlying model is the same.

A practical way to make the final choice

Define the task and the cost of an incorrect result.
Eliminate models that fail hard requirements such as data residency, modalities, context capacity or licensing.
Shortlist options using benchmark results that resemble the actual workload.
Run the same representative test set against every shortlisted model.
Measure quality, latency and total cost together, including retries and human review.

Model rankings will continue to move, but a repeatable evaluation process is more durable than any leaderboard position. The best deployment is the one that meets a clearly defined quality threshold at an acceptable operational cost.

Inspired by this post on First Page Sage Blog.

July 17, 2026

What Google’s Indexing API Really Tells Job Boards
Job listings have a timing problem: they can change or expire before ordinary crawling catches up. Google’s Indexing API appears to solve that problem by accepting notifications when eligible pages are created, updated, or removed.

The important limitation is that an accepted request confirms delivery of a notification, not the outcome a job board ultimately needs. Understanding that distinction helps teams measure the API accurately and avoid treating clean server responses as proof of search visibility.

A "Get started" panel warns that submissions undergo spam detection, then lists prerequisites, approval and quota requests, guidelines, and request submission.

A notification is only the first event in the chain

According to Search Engine Land, a successful API request means Google received the submission. It does not establish that Google crawled the page, added it to the index, displayed it in the Google Jobs experience, or generated traffic from it.

A filtered metrics table lists 204 Web Search Indexing API requests, 36 reCAPTCHA Enterprise API requests, and one Gemini for Google Cloud API request.

Those are separate stages with separate evidence requirements:

Two dark monitoring charts display intermittent HTTP 200 traffic near 3:00 AM and zero errors for the listed PublishUrlNotification API method.
- Submitted: The site’s system sent a notification.
- Accepted: Google returned a successful response to that request.
- Crawled: Google fetched the page.
- Indexed: Google made the page eligible to appear in search.
- Visible and productive: The listing earned impressions, clicks, or conversions.
A reliable reporting setup should preserve these distinctions. Otherwise, an operational metric such as API acceptance can be mistaken for an SEO result.

A documentation excerpt says the Indexing API is limited to JobPosting or BroadcastEvent pages and directs users to submit a form for more quota and approval.

Key takeaways
- The Indexing API is restricted to eligible job-posting and livestream pages; it is not a general acceleration tool for arbitrary URLs.
- An HTTP 200 response confirms receipt, not crawling, indexing, removal, ranking, or traffic.
- Notification metadata describes submissions rather than the current index status of a page.
- Quota availability and successful test requests do not necessarily prove that an account has production access.
- Job boards should validate structured data, API behavior, and search status as separate layers.
The API has a narrow, defined scope

Search Engine Land reports that Google permits the API for pages carrying JobPosting structured data and for livestream pages using BroadcastEvent within a VideoObject. Blog posts, product pages, category archives, service pages, and other ordinary URLs are outside that stated use.

A dark code-style report contrasts a passed URL_UPDATED request and HTTP 200 response with a getMetadata HTTP 404 warning, highlighted by red arrows, "whaaaaaat," and a crying emoji.

For an eligible job page, the two relevant notification types are straightforward. URL_UPDATED can be sent when a listing is published or meaningfully changed. URL_DELETED can be sent when the listing has been removed and should no longer remain indexed.

A Request Indexing API Quota form says reviews usually take two to three weeks and warns that annotation and eligible-content requirements must be met.

Even here, the request is not a command. The source notes that Google’s documentation says the company may recrawl a URL after an accepted update request and may remove one after an accepted deletion request. That wording preserves Google’s control over what happens next.

A completed job indexing health check shows 12 passes, no failures, and two warnings beside a dark panel containing the full raw JSON response.

Metadata, sandbox access, and quotas require careful reading

The API’s getMetadata capability can help confirm the history of update and deletion notifications for a URL. It cannot answer the larger question of whether that URL is currently crawled, indexed, removed, or receiving exposure. Metadata is therefore useful for diagnosing the submission pipeline, but it is not an index-status report.

Access also has an onboarding dimension. Search Engine Land says Google’s quickstart documentation describes a default quota of 200 requests for onboarding and submission testing, with further approval required for usage and resource provisioning. A visible quota or apparently successful test can therefore create confidence without demonstrating full production service.

Organic visibility, paid media and artificial intelligence merge into one connected search ecosystem, where vivid data streams link a creative website with a powerful analytics dashboard.

The source also reports approval delays, but the evidence should be treated as observational rather than definitive. The article’s author said two job-board requests had received no response after six months in 2026. Alexander Chukovski reportedly said none of the job boards he worked with over roughly 10 to 12 months received a response. These accounts suggest that approvals may have become harder to obtain, but they do not prove that Google has stopped processing every request.

How job boards can validate the system responsibly

A practical audit should test the implementation in layers rather than seeking one all-purpose success signal:
1. Confirm that the URL represents a supported job posting and contains the required structured data.
2. Verify that update and deletion requests use the appropriate notification type.
3. Record response codes and notification metadata as evidence of API delivery only.
4. Check crawling, indexing, and search performance through appropriate search diagnostics instead of inferring them from the API response.
5. Track expired listings separately so removal can be verified rather than assumed.
The source highlights a free Job Indexing Health Check on SEOJobs.com that can review job schema and, in its fuller mode, API and Google Search Console responses. Whether teams use that tool or their own diagnostics, the sound approach is the same: measure each stage according to what its evidence can actually prove.

For job boards, the API can remain a useful notification channel. Its value becomes clearer, not weaker, once acceptance is treated as the beginning of verification rather than the finish line.

Inspired by this post on Search Engine Land.
July 16, 2026

Tag: API

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

Automation and measurement are changing at the same time

Key takeaways

Write an automation contract before enabling AI Max

Make every automated decision observable

Use API v25 to separate YouTube signals from business outcomes

Segment non-skippable ads by sub-format

Keep Shorts engagement diagnostic

Treat creator insights as conditional data

Separate retention optimization from customer acquisition

Put API and campaign changes into production safely

References

Find the activation gap before you add another tool

Give every asset a machine-readable activation contract

Choose deliberately between current and fixed references

Generate channel variants from a governed original

Connect publishing tools without weakening governance

Apply eligibility filters before semantic relevance

Prove activation with one bounded publishing workflow

Key takeaways

References

Key takeaways

Replace the local-inventory toggle with an explicit scope

Treat Lead Form access as provisional until the account confirms it

Design the lead handoff before you activate the asset

Build one control sheet for defaults, eligibility, and retention

References

How the source built its model ranking

Key takeaways

Match the model to the workload

Where benchmark comparisons need caution

A practical way to make the final choice

A notification is only the first event in the chain

Key takeaways

The API has a narrow, defined scope

Metadata, sandbox access, and quotas require careful reading