Tag: API

Google FAQ Rich Results Retirement: A Practical Action Plan

You may still have FAQ sections, FAQPage JSON-LD, reporting filters, and client promises built around Google’s expandable FAQ listings. The listing has gone away, but that does not mean every FAQ or every line of FAQ markup should disappear with it.

Your job now is to separate the retired Google Search feature from the content and data that may still serve a purpose. That distinction will tell you what to remove, what to retain, and what to measure.

What Google retired, and when each dependency changes

Google ended support for FAQ rich results on May 7, 2026. The visible consequence is straightforward: adding valid FAQPage structured data no longer makes a page eligible for an FAQ rich result in Google Search.

The retirement also affects the tools around the feature. Google’s announced schedule separates the wind-down into three operational milestones:

Milestone	What changes	What you should do
May 7, 2026	FAQ rich results stop appearing in Google Search.	Stop treating FAQ markup as a Google rich-result opportunity.
By June 2026	Google planned to remove the FAQ search appearance, the dedicated rich-result report, and FAQ support in the Rich Results Test.	Replace reports, tests, and documentation that depend on those surfaces.
By August 2026	Google plans to remove FAQ rich-result support from the Search Console API.	Update API jobs before missing FAQ-specific data or filters can break them.

These milestones affect eligibility, reporting, testing, and API access. They do not delete the visible questions and answers on your pages. They also do not establish that FAQPage markup is harmful. The retirement notice alone is not evidence of a penalty.

Key takeaways

Stop approving FAQ schema work on the promise of a Google FAQ rich result.
Do not remove useful visible answers merely because the associated search enhancement has retired.
Keep the markup only when you can identify a remaining consumer or justify its maintenance cost.
Remove FAQ-specific dependencies from Search Console reports, alerts, dashboards, and API jobs.
Measure the change with page cohorts and query data, not a single sitewide before-and-after chart.

Decide whether to keep or remove FAQPage markup

There is no universal requirement to purge FAQPage from every site. The right decision depends on what consumes the markup, how it is maintained, and whether it remains accurate.

Decision	Use it when	Main risk to control
Keep it	A verified non-Google search engine, application, internal knowledge system, or publishing workflow consumes it, and the data stays synchronized with the visible page.	Do not assume another system uses the markup merely because it can parse JSON-LD.
Remove it	The only documented purpose was Google FAQ rich-result eligibility, or the implementation produces stale, duplicated, or misleading data.	Target `FAQPage` specifically so you do not erase unrelated structured data.
Keep it temporarily	You cannot yet identify every downstream dependency.	Give the uncertainty an owner and review date so temporary markup does not become permanent by neglect.

The phrase “other systems may use it” is not a business case by itself. Ask for evidence: a documented integration, a consuming application, a test that shows the data being ingested, or a named team that depends on the output. Without one of those, you are maintaining code for a hypothetical benefit.

Retention also has a cost. Automatically generated markup can drift away from the visible answer, survive after an FAQ is deleted, or duplicate data emitted by a theme and a plugin. That creates audit noise and makes future structured-data incidents harder to diagnose. If no verified consumer remains, removing that unused layer is a reasonable cleanup.

Audit the implementation before touching production

Find every emitter. Search templates, plugins, block settings, custom fields, tag-management rules, and rendered HTML for FAQPage. Check both server-generated source and JavaScript-rendered output.
Map pages to templates. Record the canonical URL, template or content type, markup generator, owner, and any known consumer. This distinguishes a centralized fix from hundreds of apparent page-level fixes.
Check for duplicate output. A page may receive one graph from an SEO plugin and another from its theme or page builder. Removing one does not necessarily remove the other.
Separate schema types. Confirm that the proposed change removes only the FAQ node and its intended relationships. Preserve unrelated Article, BreadcrumbList, Product, organization, or other data unless your audit finds a separate reason to change it.
Verify visible parity. If you retain FAQ markup, each marked-up question and answer should still correspond to content a visitor can access on that page.
Test a representative sample. Include different templates, locales, device-rendering paths, and pages with nested structured-data graphs. A successful test on one hand-built page does not prove that a shared template is safe.

If you remove the markup, use a staged release or a small controlled page group where your publishing system allows it. Capture the prior output first, verify that the visible FAQ still works, and compare the full structured-data graph before and after deployment. A broad search-and-delete operation can remove braces, graph relationships, or neighboring schema that were never part of the retirement.

Repair Search Console reports and API jobs before they fail silently

An obsolete accordion-shaped module is disconnected from a linked browser, structured-data, reporting, and API workflow on a worktable.

The reporting change deserves as much attention as the markup. A dashboard can keep loading while an FAQ filter returns no rows, a chart becomes permanently flat, or an alert stops firing. That is more dangerous than an obvious error because the report still looks operational.

Inventory every place where FAQ search appearance is used: saved Search Console views, exported workbooks, business-intelligence models, scheduled reports, client templates, annotations, anomaly alerts, and API queries. For each dependency, decide whether to remove the component, replace it with page-level reporting, or preserve the historical series as a closed metric.

Preserve available history. Keep any existing FAQ-specific exports with their original date range and definitions. Historical data remains useful for explaining why an old report or traffic pattern differs from a new one.
Retire the metric explicitly. Label the series as discontinued rather than allowing it to fall to zero without explanation. A zero can be misread as an implementation failure.
Remove brittle filters. Update queries and transformation steps that expect an FAQ appearance value. Jobs should handle its absence without discarding otherwise valid Search Console rows.
Test empty and missing states. Confirm that dashboards, alerts, and API pipelines behave correctly when FAQ-specific data is unavailable, not merely when its value is zero.
Update stakeholder language. Replace promises to “earn FAQ rich results” with goals you can still observe, such as answering a query clearly, improving organic engagement, or reducing duplicated support content.

Do not merge the date of Google’s presentation change with the date you remove code. Record both. Otherwise, a later analyst may blame a traffic movement on your deployment when the search feature had already disappeared, or attribute a template change to Google when it happened weeks later.

Measure the traffic effect without inventing causation

An analyst compares two separate streams of abstract signals using transparent dividers and balanced measuring instruments.

FAQ rich results could occupy extra search-result space and influence click behavior, so affected pages deserve closer monitoring. A sitewide organic trend will not isolate that effect. Most pages never had the same FAQ visibility, query mix, ranking stability, or search-result competition.

Build a page cohort from URLs that carried FAQ structured data and, where your historical records allow it, distinguish pages that actually received FAQ search appearances from pages that were merely eligible. Eligibility is not the same as an impression.

Choose a comparison group. Use pages with a similar purpose and query profile that did not depend on FAQ presentation. The comparison will not create a perfect experiment, but it is more informative than comparing the whole site with itself.
Track impressions, clicks, click-through rate, and average position together. A click-through-rate decline while impressions and position remain broadly stable is more consistent with a presentation change than a simultaneous loss of rankings and visibility.
Inspect page-query pairs. Brand queries, broad informational searches, and long-tail questions can behave differently. Page totals can hide one group falling while another grows.
Annotate both the Google milestones and your deployments. Include the retirement, reporting changes, content edits, template releases, migrations, and other material SEO work in the same analysis window.
Follow the business outcome. Check whether affected pages still generate the actions that matter, such as product discovery, qualified visits, support deflection, leads, or sales. A presentation loss matters differently when click volume changes but useful outcomes do not.

A before-and-after chart cannot prove that FAQ retirement caused a change. Rankings, seasonality, query demand, competing search features, and your own releases can move at the same time. Use the cohort analysis to identify where investigation is warranted, not to manufacture certainty the data cannot support.

Keep the answers, but remove the obsolete SEO promise

A useful FAQ section can still solve a reader’s next problem. It can clarify eligibility, compatibility, pricing logic, implementation constraints, returns, terminology, or a decision that would otherwise send the visitor back to search. None of that value depends on an expandable Google result.

Review FAQ content as content, not as a schema container. Keep a question when it represents a real decision or recurring point of confusion. Rewrite it when the answer is vague, promotional, outdated, or dependent on information that appears elsewhere. Remove it when it exists only to repeat a keyword or restate the main body.

Use the wording a reader would recognize, but do not create several near-identical questions for minor keyword variations.
Answer the question in the opening sentence, then add conditions, exceptions, evidence, or a next step.
Name the product version, location, customer type, plan, or other qualifier whenever the answer changes across those boundaries.
Link to a deeper page when the reader needs a procedure or full explanation; do not compress a complex guide into an evasive two-line answer.
Assign an owner to answers that depend on policies, features, prices, or other changeable facts.
Keep marked-up data synchronized with visible content if you decide to retain the JSON-LD.

The same discipline helps answer-engine and generative-search work, but do not replace one unsupported promise with another. FAQPage markup is not a guaranteed route into an AI answer, citation, or model response. Clear visible content, precise scope, consistent entity information, and accessible supporting detail are useful publishing practices; none guarantees selection by a search engine or model.

Be especially careful with thin FAQ pages created solely to win the retired enhancement. If a page contains unique information or attracts useful demand, improve it. If it duplicates a stronger resource, consider consolidation only after checking its traffic, links, internal references, and destination. Do not delete or redirect a URL merely because its structured-data feature disappeared.

Turn the retirement into a controlled cleanup

Start with a single inventory that joins code, content, reporting, and ownership. Give every FAQ implementation one status: retain for a verified consumer, remove as Google-only legacy code, or investigate because the dependency is unknown.

Resolve the unknown group first. It carries the greatest operational risk: deleting it may break an unrecorded integration, while leaving it indefinitely creates unmanaged data. Once every row has an owner and reason, update the template, reporting pipeline, documentation, and stakeholder expectations as one change set.

Your next concrete action is simple: search a rendered sample of each major page template for FAQPage, record what generates it, and write down who still consumes it. If no one can answer the last question, you have found the first dependency to investigate.

References

CrushPress.AI – Google Ends Support for FAQ Rich Results – Here’s What You Need to Know

May 8, 2026

Google Ads Optimization Starts With Conversion Measurement

If campaign performance looks unstable, resist the next bid or budget change. Google Ads cannot optimize around the outcome you intended; it can only react to the conversion signal it receives. A missing purchase, duplicated form submission, or low-intent contact counted as a lead turns CPA and ROAS into confident-looking answers to the wrong question.

Your first job is to make the signal trustworthy. Then you can use cross-channel reporting, search-term evidence, and negative keywords to improve performance without confusing a tracking change for a marketing win.

Define the signal before you optimize the spend

A conversion name such as “form submit” is not a measurement specification. It does not tell you whether the form was accepted, whether a duplicate was removed, whether the person was qualified, or whether the event represents a business outcome at all.

For every action currently treated as a conversion, write down:

Business outcome: What changed for the business: a completed order, an accepted lead, a booked appointment, or another explicit result?
Completion condition: What observable event proves that outcome occurred? A button click alone rarely proves that the receiving system accepted the transaction.
Funnel stage: Is this a final outcome, a qualified intermediate action, or a diagnostic engagement signal?
Identity and deduplication: Which order, lead, or internal event ID prevents one outcome from being recorded twice?
Value: Does the action carry revenue, an approved proxy value, or no monetary value? Document the reason rather than silently assigning one.
System of record: Which backend, CRM, booking system, or commerce platform can confirm that the outcome was real?
Owner: Who investigates when the platform count and the operational record diverge?

The correct measurement boundary depends on the surface. Where your account uses calls, lead forms, or message assets, the ad interaction may move contact intent closer to Google Ads. That does not make every tap, open, or connection a qualified lead. Decide what must happen after the interaction before it earns that label.

Conversion path	Useful completion boundary	Reconciliation evidence
Website purchase	The order is accepted, not merely started	Order ID, status, value, and currency in the commerce system
Website or lead-form submission	The receiving system accepts a valid submission	Lead ID and the later qualification or rejection status
Call or message	The contact meets your documented business rule	Platform reference or timestamp matched to a disposition in the operating system
Micro-conversion	The engagement action actually occurs	Analytics event used for diagnosis, not automatically treated as revenue

Build a conversion hierarchy, not a bag of events

Put final business outcomes at the top, qualified intermediate outcomes below them, and diagnostic events at the bottom. Use the highest-quality signal that can support the decision you are making. More event volume is not automatically better input. Promoting a page view or unverified click to “conversion” status may make an automated system look busier while moving it farther from revenue.

If a campaign does not yet produce enough final outcomes for stable decisions, preserve the distinction. Report the lower-funnel result and the supporting signal separately. A volume constraint is useful information; relabeling weak intent hides it.

Audit the conversion chain before interpreting CPA

An isometric chain connects an ad, click, landing page, customer action, tracking sensor, and verified conversion while a magnifying glass reveals a broken link and duplicate signal.

A conversion can fail at several points between the customer’s action and the report. Checking only whether a tag fired leaves most of that chain untested. Audit the complete path in this order:

Outcome: Complete the intended action and confirm that the business system accepted it.
Trigger: Verify that the conversion condition occurred once, at the right moment, with the expected identifier and value.
Transport: Check that the event moved through the applicable browser, tag, server, API, consent, and integration layers.
Platform record: Confirm that the event appeared under the intended conversion action rather than a similarly named action.
Reconciliation: Match the platform record to the order, lead, appointment, call, or message disposition in the system of record.

Use a controlled test record and document its expected result before running it. For purchases or other actions that can create a charge, use an approved test or staging method. Do not place an unrecoverable live transaction merely to validate reporting.

Your test matrix should cover the paths where implementation defects tend to hide:

Desktop and mobile completion paths.
Direct landing-page visits and the redirects used by campaign traffic.
Cross-domain steps, if the journey moves between domains.
Form success, validation failure, and repeated clicking.
Confirmation-page reloads and browser back-button behavior.
Each enabled call, form, or messaging route.
Accepted, rejected, cancelled, refunded, duplicate, and spam outcomes where those states affect business value.

Record the test ID, timestamp and time zone, device or browser, conversion action, expected value, observed platform result, and backend ID. Use internal identifiers rather than personal data. This creates evidence that another person can inspect without repeating the transaction.

Classify mismatches before fixing them. A missing conversion points toward an absent trigger, failed transport, incorrect mapping, consent behavior, or unavailable integration. A duplicate points toward repeated triggers or weak deduplication. A conversion recorded under the wrong action points toward naming or configuration drift. These defects require different fixes; a general “tracking issue” label is too vague to be actionable.

Do not demand identical totals from systems that use different dates, time zones, attribution rules, inclusion rules, or value conventions. Align those definitions first. Then investigate the unexplained remainder. When you repair a material defect, preserve the old data, annotate the repair time, and define the first clean reporting window. Rewriting history without a documented method can make the next optimization decision less reliable than the last one.

Use cross-channel reporting as a control view, not absolute truth

Once your conversion definitions are stable, a unified reporting layer can reduce the time spent assembling channel exports. Google’s Analytics Data API can provide paid and organic conversion data in one programmatic view that mirrors the Conversion performance report in the Analytics interface.

The capability is in alpha, and access is not universal. Verify eligibility for the exact Analytics property before making it a production dependency. If the property does not expose the feature, keep the same internal reporting contract and populate it from the available interface reports until API access arrives. That lets you improve the operating model without pretending an unavailable feature exists.

Your reporting contract should make every row interpretable. At minimum, document the property or account, conversion-name mapping, channel classification, date and time-zone logic, attribution convention, value and currency treatment, extraction time, and the period in which late revisions are accepted. These are not decorative metadata. They explain why two legitimate reports can disagree.

A unified view centralizes attributed conversion reporting; it does not prove that a channel caused the outcome. Attribution can move credit between touchpoints without changing the number of real orders or qualified leads. Read the data in layers:

Confirm total business outcomes and value in the operational system.
Confirm that Analytics received the intended conversion actions.
Inspect how paid platforms recorded and attributed those actions.
Use the cross-channel view to understand where credit was assigned.

If channel credit changes while backend outcomes stay flat, investigate attribution, classification, or tracking before declaring growth. If backend outcomes increase while reported conversions do not, investigate measurement loss. If both move in the same direction and the definitions remain stable, you have a stronger basis for changing spend.

Automation is most useful for surfacing exceptions: a conversion action disappears, a value field becomes empty, one channel changes abruptly, or the cross-channel total stops reconciling within your normal operating pattern. Let the pipeline find the anomaly. Keep the decision about bids, budgets, and exclusions attached to business context.

Turn trusted conversion data into negative-keyword decisions

An analyst adjusts filter gates that block irrelevant abstract search-query tokens while relevant tokens continue toward a conversion beacon and budget coins.

Negative keywords become safer after measurement is credible. Before that point, a relevant query can appear unproductive simply because its outcome was missed or classified under the wrong action. Excluding it would reduce waste in the report while potentially blocking valuable demand in the market.

Review each candidate search term by cause:

Clearly misaligned: The words indicate the wrong product, service, audience, location, or intent.
Relevant but early: The term belongs to the buyer journey but is being judged against an outcome it is unlikely to produce immediately.
Relevant and expensive: The term has consumed enough budget without producing the defined outcome.
Uncertain: The sample is sparse, the buying cycle is incomplete, or measurement quality is in doubt.

Choose the negative match type according to the scope of the exclusion. Use negative exact match for a specific long-tail query, negative phrase match for a related query family, and negative broad match for words that identify a misaligned audience. Start with the narrowest scope that solves the problem. A broad exclusion can block adjacent demand, so export the current negatives and record the intended scope before making bulk changes.

Your threshold should reflect the account’s job. A growth-focused campaign needs room to discover demand and can tolerate more exploration. One practical trigger is to review a query after it has spent more than three times the target CPA over 90 days without a conversion. Treat that as a decision trigger, not an automatic deletion rule: confirm tracking health, intent, and buying-cycle timing first.

An efficiency-focused account can use a stricter, budget-based trigger tied to the amount you are willing to spend on one query without an outcome. A 30-day window can be too aggressive outside a short promotion. A 90-day window is a balanced starting point, while a 365-day view can be more appropriate for a long buying cycle. Keep the threshold and window together in the decision log; either one without the other is ambiguous.

Competitor queries also need an explicit policy. Do not exclude them merely because they are competitor terms, and do not preserve them merely because automation might find a conversion. Decide whether that intent fits the offer, economics, and brand strategy. Then judge the terms under the same documented evidence rules as other traffic.

Use this approval sequence for every material negative:

Confirm that the relevant conversion actions were healthy during the evidence window.
Classify the query’s intent and its alignment with the ad and landing page.
Check spend, outcomes, target CPA, and buying-cycle maturity.
Select exact, phrase, or broad scope deliberately.
Record the query, scope, date, evidence window, reason, owner, and rollback condition.
Review affected traffic after the change for both reduced waste and unintended demand loss.

The search-terms report is not a weekly deletion queue. Review it regularly, but add negatives when the evidence and account objective support the decision. Calendar-driven exclusions can teach the campaign a narrower version of your market than you intended.

Run an optimization cadence that protects the signal

Separate measurement maintenance from performance optimization. If you change the conversion definition, negative-keyword scope, bid strategy, and budget in one cycle, the next report cannot tell you which change mattered.

Decision layer	Question to answer	Action
Measurement health	Did a defined action stop, duplicate, move, or change value?	Repair and annotate the signal before interpreting performance.
Business quality	Do orders, lead dispositions, and other backend outcomes support the platform signal?	Correct qualification, deduplication, or value mapping.
Demand quality	Are search terms aligned with the offer, ad, and landing page?	Approve narrow, evidence-based exclusions or improve the message and destination.
Economics	Does clean data support the target CPA, value, and budget decision?	Change bids or budgets only after the earlier layers pass.

Rerun a conversion smoke test after a site release, tag change, CRM integration change, form replacement, checkout update, or contact-route change. On each reporting refresh, check for missing actions, unexpected duplicates, empty values, naming drift, and abrupt channel changes. Review search terms and lead quality at a regular operating interval, but make exclusions only when the chosen evidence window has matured.

Keep one change log for both measurement and media decisions. Each entry should contain the timestamp, owner, hypothesis, affected campaigns or actions, evidence window, expected metric movement, and rollback condition. The log gives you a clean way to distinguish a genuine performance shift from a new definition, delayed data, or implementation failure.

Key takeaways

Define conversions as business outcomes with explicit completion, deduplication, value, and reconciliation rules.
Test the full path from customer action to backend record; a fired tag is only one link in the chain.
Use unified paid and organic conversion reporting as a control view, while preserving attribution and availability caveats.
Choose negative-keyword scope, aggression, and evidence windows according to the campaign’s growth or efficiency objective.
Repair measurement and validate business quality before changing exclusions, bids, or budgets.

Before your next budget change, select one important conversion action and run it through the complete audit. Reconcile it to the business record, document the clean-data start time, and only then review the search terms consuming the most budget. That sequence gives the next optimization decision a signal worth trusting.

References

May 6, 2026

Google Ads API v20 Sunset: Upgrade Before June 10, 2026

If any reporting, bidding, or campaign-management workflow still calls Google Ads API v20, June 10, 2026 is a hard failure boundary. Any request sent to v20 after the cutoff will fail, so a healthy dashboard or successful scheduled job on June 9 does not prove that you are ready for June 10.

Your job is to find every remaining v20 request, move each affected workflow to a newer version, and produce evidence that the replacement works in production. That requires more than changing a version string. It requires an inventory, representative testing, a staged cutover, and monitoring that can distinguish fresh data from stale output.

Know exactly what will fail at the cutoff

The sunset applies at the API request boundary. It does not, by itself, mean that a Google Ads account or campaign disappears. It means a workflow loses access whenever the request it needs still targets v20.

The business consequence depends on what that request does:

Reporting and data pipelines can stop collecting new data, leaving dashboards, attribution processes, or client reports with gaps.
Campaign automation can stop reading or applying intended changes, including workflows connected to bidding and campaign management.
Internal tools can fail when a user opens a screen, requests a report, or submits a change that depends on v20.
Third-party platforms can break even when your own code is current, because the version choice may live inside the vendor’s backend.

A failed reporting job is not always visually obvious. A dashboard may continue showing its last successful dataset unless it also displays data freshness. A failed write does not necessarily leave an account in a safe or paused state; it may simply leave the previous campaign settings in place. Review each workflow’s retry, alerting, and failure behavior so that an API error cannot masquerade as a successful run.

Translate every technical dependency into an operational consequence. Instead of recording only “reporting service uses v20,” document which report stops, who consumes it, how quickly stale data becomes harmful, and who owns recovery. That mapping tells you which migrations must move first.

Key takeaways

Google Ads API v20 requests will fail after June 10, 2026; the deadline is not a warning-only deprecation milestone.
Inventory observed API traffic and stored configuration. Either view alone can miss a dependency.
Test complete workflows on a newer API version, not merely authentication or one sample request.
Run read-only comparisons in parallel where useful, but do not duplicate campaign-changing requests across versions.
Cut over early enough to observe a full operating cycle and restore v20 temporarily if the new implementation fails before the sunset.

Build an inventory that includes hidden and dormant calls

An isometric enterprise system shows visible services and faint hidden connections to legacy jobs, dormant components, and recovery infrastructure.

Start with actual traffic, then reconcile it against code, configuration, schedules, and vendor dependencies. An application list assembled from memory will miss old scripts, shared services, and jobs owned by teams that no longer think of themselves as Google Ads API users.

Recent API activity in Google Cloud Console can help identify the methods and versions used by your projects. Review every relevant project rather than only the one associated with your main campaign application.

List the environments and projects. Include production, staging, reporting infrastructure, serverless jobs, shared integration projects, and systems managed by another team.
Inspect recent activity. Record which projects still produce v20 traffic and which methods they call.
Cover the complete job cadence. Your observation period must include infrequent workloads such as weekly, monthly, or manually triggered jobs. Zero traffic during an idle period proves nothing.
Search stored configuration. Look for literal v20 references, version selectors, client-library dependencies, deployment variables, request builders, infrastructure definitions, and copied scripts.
Attach an owner to every dependency. An unidentified service is not ready merely because it appears inactive. Someone must decide whether it should be migrated, retired, or verified as unused.

Traffic inspection and configuration inspection answer different questions. Traffic tells you what ran. Configuration tells you what may run later. Keep both in the migration register.

Dependency surface	What to locate	Useful readiness evidence
Custom applications	Version settings, client dependencies, request construction, and deployment configuration	Representative requests succeed on the target version and production activity no longer shows v20
Scheduled data pipelines	Job definitions, orchestration schedules, exports, and downstream consumers	A complete scheduled run finishes with fresh, complete output
Campaign automation	Read and write paths, retry behavior, approval controls, and alerts	A controlled test produces the intended state once and failures reach an owner
Third-party platforms	Vendor-owned connectors, reporting modules, and automation features	The vendor confirms the production version and you verify your own affected workflows
Dormant or manual tools	Occasional scripts, archived repositories, runbooks, and analyst utilities	The tool is migrated, formally retired, or blocked from future v20 use

Ask vendors for feature-level confirmation

A generic claim that a platform “supports the Google Ads API” is not enough. One module may be current while a less visible exporter or automation feature still uses v20. Ask the provider:

Which API version does each feature used by your account call in production?
Has every v20 workload been migrated, or only the primary integration?
When will the production cutover occur?
How can you verify that your tenant is using the newer version?
What happens to queued jobs, retries, and cached reports if a request fails?

Keep the response with your migration record, then test the feature yourself. Vendor confirmation transfers information, not operational responsibility.

Migrate the workflow, not just the version label

Choose a newer supported API version that works with your client stack and the capabilities your workflows need. Use Google’s release notes and upgrade guides to identify required changes. Do not assume that editing a version constant is sufficient: client dependencies, available fields, request structures, generated types, and response handling may also need attention.

A practical migration sequence looks like this:

Capture a baseline. Record representative inputs, expected outputs, normal completion signals, and current error behavior for each workflow. Use stable comparisons where possible because live campaign data can change during testing.
Update the client and application together. Change the supported client dependency, version configuration, request construction, and any code affected by the official upgrade guidance. Check deployment manifests and runtime variables as well as the repository.
Test authentication and simple reads. Confirm that the application can connect using the credentials and account scope it will use in production. Connectivity is only the first gate, not the completion criterion.
Exercise representative read workflows. Run the same account scope, date range, filters, pagination path, and downstream transformation used by the real job. Compare required fields, completeness, row-level invariants, and freshness rather than relying on a single successful response.
Test writes under controlled conditions. Do not change live spend merely to prove connectivity. Use an approved test environment, test account, or non-spend-altering path where your setup supports one. Verify that the intended resource changes once and that retries cannot duplicate an action.
Validate downstream consumers. A successful API response does not prove that a dashboard, warehouse load, bid process, notification, or internal interface can consume the new output correctly.
Release in stages. Move a bounded set of workloads first, watch their results, and expand only after the expected operating signals remain healthy.

Parallel validation is useful for read-only workloads. You can run equivalent reporting requests on v20 and the target version, then compare the resulting datasets while v20 remains available. Avoid sending campaign-changing requests through both versions: duplicate writes can produce real account changes and financial consequences. For write paths, use a controlled test followed by a staged production rollout.

Preserve a temporary rollback path during the early cutover, but recognize its expiration date. Before June 10, a rollback to v20 may buy time to fix a problem. After the sunset, v20 is no longer a viable recovery plan because its requests will fail. Your post-cutoff contingency must keep the newer version in place, disable the affected workflow safely if necessary, and route the failure to a named owner.

Define readiness with production evidence

Engineers monitor abstract requests moving through a replacement processing lane with checkpoints, a separated legacy lane, and a rollback route.

“The code was upgraded” is a progress update. It is not a definition of done. Close the migration only when you have evidence across configuration, runtime traffic, workflow output, and ownership.

Every known application, script, scheduled job, and integration has an owner and an explicit migrate-or-retire decision.
Each active workflow completes successfully on the selected newer API version using representative accounts and request types.
Production configuration and deployed client dependencies point to the intended version.
No v20 activity appears across the relevant Cloud projects during a period that covers the full operating cadence of the workflows.
Reporting outputs expose freshness and completeness, so stale data cannot look current.
Campaign-changing automation has controlled retry behavior and a human receives actionable failure alerts.
Third-party features have been confirmed by the provider and verified through your own account-level test.
The rollback plan works before the cutoff, and the post-cutoff contingency does not depend on v20.
Campaign owners, analysts, engineers, and support staff know when the cutover occurred and where failures will be reported.

Be careful with negative evidence. Seeing no v20 requests is meaningful only if every relevant workload had an opportunity to run. A monthly exporter that has not reached its schedule can remain invisible until after the deadline. Pair runtime inspection with the dependency register, then record the last successful target-version execution for every retained workflow.

Set your internal cutover early enough to run a complete operating cycle while v20 can still serve as a temporary fallback. Name the owner, start the inventory, and schedule the target-version validation now. The date that matters internally should be the day you can prove v20 is gone, not June 10 itself.

References

Search Engine Land — Upgrade Google Ads API: Avoid Service Interruptions by June 10

May 1, 2026

How to Give AI Agents Live Marketing Data Without Losing Control

If your AI workflow begins with exporting campaign data, pasting it into a chat, and explaining the same business context again, you do not have an agent. You have a capable analyst waiting for a manual data delivery.

The fix is not a longer prompt. You need a controlled path from your marketing systems to the agent, with enough current context to support a decision and enough guardrails to stop a bad decision from becoming an expensive action.

Live means decision-ready, not merely connected

Live marketing data does not have to mean that every event reaches the agent within milliseconds. It means the information is refreshed before the decision it supports becomes stale. A pacing decision may need current spend and budget data. A lead-quality decision may need the latest CRM disposition. A promotion may need inventory availability before the agent recommends sending more traffic to it.

That distinction matters because access alone is not enough. An agent can be connected to Google Ads and still make a poor decision if it cannot see what happened after a conversion. It can be connected to a CRM and still misread performance if campaign identifiers do not match. It can see inventory data and still act on an item whose availability record is old.

A familiar failure starts with a keyword that appears healthy inside the ad platform. It has useful volume and an acceptable cost per acquisition. The CRM, however, shows that the resulting leads are being disqualified. Without that downstream outcome, the agent will keep treating the keyword as successful and may continue spending until a person reconciles the systems. Repeated exports and delayed cross-checks preserve this blind spot; they do not create automation.

System	What the agent can learn	Decision it can improve
Ad platform	Spend, conversions, volume, and campaign performance	Where traffic appears efficient
CRM	Qualification, sales progression, and lead disposition	Whether reported conversions have business value
Inventory system	Availability and stock constraints	Whether demand should be increased for a product

Before integrating anything, write down the decision the agent will support and how fresh each input must be for that decision. If you cannot define when the data becomes too old to trust, the word live is doing no useful work.

Build a decision context, not a giant data dump

Raw marketing inputs pass through filtering and verification stages before a compact bundle of relevant context reaches an AI reasoning system.

An agent rarely needs unrestricted access to every field in every marketing system. It needs a compact, reliable view of the variables that determine one decision. Sending more data without defining its meaning can make the workflow harder to inspect and easier to misconfigure.

Build that view from the decision backward:

Name the decision. Be precise: recommend a bid change, flag a lead-quality problem, pause promotion of unavailable inventory, or produce a daily exception list.
List the evidence required. Separate platform metrics from business outcomes. A conversion count is not the same thing as a qualified lead, a sale, or an item that can still be fulfilled.
Choose the join keys. Decide how campaign, ad group, keyword, click, lead, customer, product, and order records connect. If systems use different identifiers, define the mapping before the agent sees the data.
Normalize time and meaning. Record the reporting window, timezone, attribution context, currency, and status definitions relevant to the decision. The agent should not have to infer whether two similarly named fields measure the same event.
Attach provenance and freshness. Return the originating system and update time with the value. The agent needs to distinguish a current zero from a missing or stale record.
Define conflict behavior. Decide which system controls when records disagree. If the CRM says a lead is disqualified while the ad platform counts a conversion, the workflow should preserve both facts and use the business outcome for the decision you defined.

This turns integration into a data contract. Each input has a source, definition, identity, update time, and permitted use. That contract also gives your team something concrete to test when the agent behaves unexpectedly.

Use MCP as the connection layer, not the policy

The Model Context Protocol, or MCP, provides a standardized way for an AI client to connect to external tools and data sources. In a marketing workflow, an MCP implementation can expose ad performance, CRM outcomes, and inventory information through a consistent interface instead of forcing you to create a separate conversational integration for every system. This can remove much of the manual handoff that keeps an agent from working with current data.

MCP does not decide what a qualified lead means, repair broken campaign identifiers, choose a safe budget policy, or determine whether the agent should be allowed to change a bid. It is the connection layer. Your data contract and control layer still carry the business logic.

Expose narrow tools that correspond to real tasks. A useful initial tool set might let the agent read campaign performance, retrieve CRM dispositions, check product availability, and generate a recommendation. A later tool could execute a preapproved campaign rule. A generic tool with unrestricted account access is harder to audit and creates a much larger failure surface.

The tool description should also tell the agent what the result does not prove. For example, ad-platform conversions describe recorded conversion events; they do not by themselves establish lead quality. Inventory availability can constrain promotion; it does not establish campaign profitability. Clear boundaries reduce the chance that the model treats one system’s partial view as the complete business outcome.

Put enforceable guardrails between reasoning and action

Proposed AI actions pass through layered permission, validation, spending-limit, audit, and human-approval controls before reaching marketing systems.

Read access and write access are different risk decisions. A mistaken read may produce a bad recommendation. A mistaken write can change bids, pause campaigns, redirect spend, or promote stock that is not available. Do not grant unrestricted write access merely because the agent has produced sensible analysis in a chat window.

A prompt is not a permission system. Instructions such as be careful or do not overspend can influence behavior, but they do not enforce account boundaries. Operational constraints need to sit around the agent, where the integration can reject an action that falls outside policy.

Define every write-capable action with these controls:

Permission: Specify whether the agent can read, recommend, or execute. Default new workflows to read-only.
Scope: Restrict access to the relevant accounts, campaigns, markets, products, and action types.
Preconditions: Require the necessary data sources to be available and fresh before an action can run.
Policy limits: Encode the budget, bid, status, and inventory rules the action must satisfy. The surrounding system, not the model’s prose, should enforce them.
Approval: Route high-impact or ambiguous changes to a person. The agent should return the proposed action, supporting evidence, and reason for escalation.
Auditability: Record the inputs, tool calls, decision, approver when applicable, and resulting change.
Recovery: Preserve enough prior state to reverse a change when the platform and action type allow it.

Roll out those permissions in stages. Begin with read-only analysis and verify that the agent retrieves the right records. Next, let it recommend actions while a person compares those recommendations with actual decisions. Then allow only bounded, reversible writes with enforced preconditions. Expand the scope after the data and control layers have proved reliable, not merely after the model has written persuasive explanations.

Test the data path before judging the agent

When an agent produces a questionable answer, teams often adjust the prompt first. That is useful only if the required evidence reached the model correctly. A polished prompt cannot recover a missing CRM record, an incorrect join, or inventory data that failed to refresh.

Test the pipeline with cases that reveal those failures:

Freshness: Can you see when each source last updated, and does the workflow stop when a required input is stale?
Coverage: Are all in-scope campaigns, leads, products, and accounts represented, or does the connector silently omit some records?
Identity: Can a conversion be connected to the correct lead or order and then traced back to the responsible campaign entity?
Semantics: Do conversion, qualified lead, sale, availability, and revenue have explicit definitions in the systems that provide them?
Missing data: Does the agent distinguish no activity from unavailable data? Treating both as zero can trigger the wrong action.
Conflicts: What happens when two systems disagree? The workflow should surface the disagreement rather than silently choosing whichever value arrived first.
Failure mode: If the CRM or inventory service is unavailable, does the agent stop, fall back to recommendation-only mode, or request review? Continuing with partial context should be an explicit policy choice.

Evaluate the system against the decision it was built to improve. For a lead-quality workflow, inspect whether it identifies campaigns producing disqualified leads. For an inventory-aware workflow, inspect whether it avoids recommending more demand for unavailable products. Fluent explanations are useful for review, but they are not evidence that the underlying joins and controls work.

Key takeaways

Live data is data that arrives before the supported decision becomes stale; it is not simply data behind an API.
An agent needs business outcomes from systems such as the CRM and inventory platform, not only the conversion view inside an ad platform.
Start with one decision and build a defined data contract for its evidence, identifiers, timing, provenance, and conflict rules.
MCP can standardize how AI clients reach tools and data, but it does not replace data modeling, permissions, or business policy.
Keep new agents read-only until you have validated retrieval, joins, freshness, and failure behavior.
Enforce write limits outside the prompt, and log the evidence and action so a person can inspect what happened.

Choose one recurring marketing decision that still depends on an export or spreadsheet reconciliation. Map the platform metric, downstream business outcome, join key, freshness requirement, and permitted action. That small, inspectable workflow is the right place to prove live data access before you give an agent broader reach.

References

CrushPress.AI – Unlocking AI Marketing Potential with Enhanced Data Access

April 30, 2026

Modern Marketing Analytics and Reporting That Drives Action

Your dashboard is green, the meeting starts soon, and you still cannot answer the question that matters: what changed, why did it change, and what should the team do next?

That is a reporting-system problem, not a chart problem. Modern marketing analytics should connect business outcomes to channel activity, preserve the definitions behind every metric, expose uncertainty, and deliver the next decision without forcing someone to reconstruct the analysis during the meeting.

Start with the decision, not the available data

Most bloated reports begin with a harmless question: what data can we pull? Every available metric gets added, the dashboard becomes comprehensive, and the decision it was meant to support disappears.

Reverse the sequence. Before choosing a connector, chart, or reporting platform, write a one-sentence measurement brief:

This report helps [owner] decide [action] at [cadence] by comparing [outcome] with [baseline], using [drivers] to explain the result and [guardrails] to prevent a bad trade-off.

A paid media lead might need to reallocate campaign budget each week. A content lead might need to decide which topics deserve an update, expansion, or new format. An SEO lead might need to distinguish a visibility problem from a conversion problem. These decisions require different evidence even when they draw from the same underlying data.

Assign every metric a role. If a metric has no role, remove it from the primary report.

Metric role	Question it answers	Marketing example	How it should affect action
Outcome	Did the work produce the intended business result?	Qualified conversions, pipeline, revenue, retained customers	Determines whether the strategy is working
Driver	What directly influenced the outcome?	Qualified traffic, landing-page conversion rate, lead acceptance	Identifies where to intervene
Diagnostic	Where did performance change?	Campaign, query group, page type, audience, device, video	Narrows the investigation
Guardrail	What must not deteriorate while the team optimizes?	Acquisition cost, lead quality, unsubscribe rate, brand demand	Prevents a local gain from becoming a business loss

This hierarchy corrects a common reporting mistake. Impressions, views, clicks, and engagement can be useful drivers or diagnostics, but they do not automatically become business outcomes because they are easy to retrieve. Likewise, a channel-level return figure is not trustworthy unless the report states what counts as a conversion, which costs are included, and how credit is assigned.

Record five items beside every primary outcome: its definition, owner, data system, update cadence, and attribution rule. If attribution is involved, also state the model, lookback window, reporting timezone, currency treatment, and whether the metric uses event time or processing time. There is no universally correct attribution model. There is only a model that is explicit enough to interpret and consistent enough to compare.

Set action rules before looking at the latest result. The rule does not need an invented universal threshold. It can be operational: investigate when an outcome moves outside its expected range, when a guardrail worsens, when the data is stale, or when two systems no longer reconcile. Precommitting to the rule reduces the temptation to invent a convenient explanation after seeing the chart.

Standardize the data before you visualize it

Different shapes of marketing data pass through a modular processing system and emerge as standardized units for visualization.

A polished dashboard cannot repair inconsistent definitions underneath it. If paid media uses platform-reported conversions, analytics uses attributed sessions, sales uses accepted opportunities, and finance uses recognized revenue, placing the figures on one page does not make them comparable.

Create a small data contract for each reporting dataset. It should specify:

Grain: what one row represents, such as one campaign-day, page-query-day, video-day, lead, opportunity, or order.
Keys: the fields that uniquely identify a row and connect it to other datasets.
Dimensions: the controlled names for channel, campaign, market, device, content type, audience, and funnel stage.
Metric definitions: the exact event or business state counted by each field.
Time rules: timezone, date field, reporting window, and treatment of late-arriving records.
Freshness: when the data should be available and how the report signals a delayed refresh.
Ownership: who approves definition changes and who responds when a pipeline fails.
Lineage: where the data originated and which transformations changed it.

Grain is the detail most likely to prevent a silent reporting error. Joining campaign-day costs to lead-level conversions can multiply spend when several leads share the same campaign and date. Aggregate both datasets to a compatible grain before joining them, or model the relationship so the cost appears only once. After every join, compare row counts and totals with the inputs.

Separate period reporting from cohort reporting. A period view answers what happened during a selected date range. A cohort view follows people, accounts, campaigns, or content acquired in a particular period through later outcomes. A recent acquisition cohort may look weak simply because its conversions have not had time to mature. Label incomplete cohorts instead of presenting them as final.

Run a compact quality checklist before publishing any result:

Reconcile source totals using the same date range, timezone, filters, and conversion definition.
Test whether fields declared unique are actually unique.
Check for missing dates, unexpected nulls, duplicate records, and values outside possible ranges.
Compare current dimensions with the approved taxonomy so renamed campaigns or channels do not create false categories.
Display the latest successful refresh time in the report itself.
Mark provisional data and document whether upstream systems can restate earlier periods.
Preserve raw extracts or reproducible snapshots so a changed connector does not rewrite history without explanation.

Do not hide a reconciliation gap with a calculated adjustment. If two systems answer different questions, label the difference. If they should match and do not, hold the affected conclusion until you know why. A visible limitation is manageable; an invisible one becomes a decision error.

Give dashboards, code, APIs, and AI separate jobs

A modern reporting stack does not require one tool to extract, clean, model, visualize, explain, and distribute everything. It works better when each layer has a narrow responsibility:

Source layer: advertising platforms, analytics products, CRM records, commerce systems, search data, video analytics, and approved research inputs.
Ingestion layer: connectors, APIs, exports, or controlled uploads that retrieve data without changing its business meaning.
Raw layer: immutable or reproducible copies of the retrieved records.
Transformation layer: code or managed queries that clean names, join datasets, apply definitions, and create tested calculations.
Semantic layer: approved dimensions, metrics, relationships, and attribution labels shared across reports.
Presentation layer: dashboards, tables, charts, written analysis, and exported snapshots designed for a specific audience.
Delivery layer: scheduled distribution, access controls, alerts, meeting workflows, and an archive of what stakeholders received.

Dashboards are effective presentation surfaces when stakeholders need filters, recurring monitoring, and a shared view without access to every backend system. A Looker Studio report can, for example, connect YouTube Analytics data, support customized views, and distribute scheduled PDF snapshots. That makes it useful for a channel owner who needs repeatable visibility rather than a custom analysis every morning.

Keep the dashboard when its data volume is manageable, the transformations are simple, refreshes complete reliably, and an analyst can trace a wrong number back to its origin. Move complex logic upstream when the same calculated field is copied across pages, manual updates recur, refreshes become fragile, or debugging requires a long sequence of interface clicks. Broad datasets and accumulated business logic can make a dashboard slow to change, difficult to debug, and vulnerable to dataset limits.

Code is a better home for repeatable extraction, normalization, backfills, joins, tests, and calculations that need review. It gives you files that can be compared, versioned, and rerun. That does not mean every marketing team needs to replace every dashboard. A practical architecture keeps a familiar dashboard at the front while moving fragile transformations into a controlled pipeline behind it.

APIs are retrieval mechanisms, not guarantees of completeness. For every API connection, record the account or property queried, requested fields, filters, pagination behavior, expected refresh schedule, and the response received when data is unavailable. Keep credentials outside report code, grant only the access required, and plan for permission revocation. A successful request proves that data arrived; reconciliation proves that the right data arrived.

AI coding assistants can reduce the effort required to scaffold connectors, transformations, tests, and report components. Natural-language specifications can help tools such as Claude Code and OpenAI Codex assemble multistep reporting workflows. Treat the generated work as a draft implementation. Review the query grain, inspect joins, run tests, protect secrets, and compare outputs with authoritative systems before a generated number reaches a stakeholder.

Use AI differently in the analysis layer. Ask it to identify anomalies worth investigating, draft plain-language explanations from approved metrics, or translate a validated analysis for different audiences. Do not let it infer causation from a correlated chart or invent a reason for a movement that the data cannot explain. The final narrative should distinguish among a measured fact, an analyst interpretation, and a proposed test.

Design separate views for decisions, operations, and diagnosis

Three connected analytics workspaces show separate areas for executive decisions, operational monitoring, and detailed diagnosis.

One dashboard should not try to answer every question for every person. An executive wants to know whether the business outcome changed and whether intervention is needed. A channel operator needs enough detail to choose the intervention. An analyst needs access to definitions, segments, and reconciliation evidence.

Build three layers, even if they live in the same reporting product:

Decision view: the primary outcome, comparison period or baseline, guardrails, material changes, confidence limits, and the requested decision.
Operating view: the drivers a channel owner can change, organized by campaign, content group, market, audience, or other actionable unit.
Diagnostic view: deeper segments, data-quality checks, metric definitions, lineage, and enough detail to reproduce the conclusion.

Put context next to the metric it qualifies. A global note at the bottom of a long report will not protect a chart at the top from misinterpretation. Each primary view should show its date range, comparison basis, filters, timezone, attribution label, refresh timestamp, and any material gap in coverage.

Add a short narrative block to every decision view:

Result: what changed in the outcome.
Driver: which measured movement best explains the change.
Confidence: what is known, what remains uncertain, and whether the data is complete.
Action: the decision or test now recommended.
Ownership: who will act and when the result will be reviewed.

Be strict about causal language. If a campaign change and a conversion change occurred together, say they coincided unless the measurement design supports a stronger claim. If an experiment or another credible identification method isolates the effect, explain that method. Precision in the wording is part of analytics quality.

Annotations should capture business events that a chart cannot know: a campaign launch, budget change, tracking migration, site release, promotion, pricing change, consent update, or outage. Store the event date, owner, affected scope, and a brief description. An annotation is a lead for investigation, not automatic proof that the event caused the movement.

Distribution needs the same discipline as analysis. A scheduled PDF is a fixed snapshot, so include its reporting window and data cutoff. Link it to the interactive view when recipients may need filters or diagnostics. Archive material snapshots used for recurring business decisions; otherwise a later refresh can leave the team debating a number that no longer appears on screen.

Access is part of report design. Stakeholders should not need administrative access to every marketing platform simply to read an approved result. The reporting team, however, must document which account and permission power each connection. With YouTube Analytics, a report builder who does not own the channel may need Manager permission and the Channel ID entered through the connector’s advanced settings. Test delegated access with the actual reporting identity instead of assuming that a visible channel in YouTube Studio will automatically appear in the reporting connector.

Migrate one recurring report and operate it like a product

A wholesale reporting rebuild creates too many simultaneous unknowns. Start with one recurring workflow that consumes meaningful time, has a known audience, and regularly produces a decision. A pre-meeting channel report, weekly SEO performance brief, or campaign pacing view is a better migration candidate than an enterprise-wide measurement platform.

Freeze the current output. Save the existing report, its filters, definitions, recipients, delivery timing, and a few representative reporting periods. This becomes your comparison set.
Write the decision contract. Identify the decision, owner, cadence, outcome, drivers, guardrails, and action rules. Remove fields that do not support them.
Inventory data and permissions. Record every account, property, channel, connector, export, credential owner, and approval dependency. Confirm access using the service identity that will run the production workflow.
Build reproducible ingestion. Preserve raw data, log retrieval times, handle pagination and empty responses, and make reruns safe.
Encode transformations once. Normalize taxonomies, define joins, centralize calculations, and add tests for uniqueness, completeness, freshness, and reconciliation.
Rebuild the three reporting views. Keep the decision page concise, give operators actionable detail, and retain diagnostic evidence for analysts.
Run old and new systems in parallel. Investigate differences using matched definitions, filters, and time rules. Do not retire the old workflow until material discrepancies are explained and the team has a rollback path.
Document production ownership. Assign responsibility for data failures, definition changes, access reviews, report delivery, and stakeholder questions.

The parallel run matters because two reports can display plausible but different numbers. A discrepancy may come from timezone boundaries, attribution logic, late-arriving conversions, deduplication, renamed dimensions, incomplete pagination, or a genuine bug. Matching the old number is not always the goal if the old logic was wrong, but every difference should have an explanation.

Give the finished workflow a runbook. It should tell another qualified person how to trigger a refresh, locate logs, rerun a failed period, backfill data, rotate credentials, verify source totals, publish the output, and roll back a breaking change. Include the last known successful run and the owner of each upstream dependency.

Measure the reporting system itself. Track whether scheduled runs complete, whether data meets its freshness expectation, whether reconciliation tests pass, whether recipients receive the right artifact, and whether decisions and owners are captured. The point is not to create a dashboard about dashboards. It is to notice reliability problems before they become meeting problems.

Key takeaways

Define the decision, owner, cadence, outcome, drivers, guardrails, and action rule before selecting metrics.
Standardize grain, keys, definitions, time rules, freshness, ownership, and lineage before building charts.
Keep dashboards for accessible presentation; move repeatable extraction, complex transformations, tests, and backfills into code when interface logic becomes fragile.
Use AI to accelerate implementation and explanation, but validate grain, joins, permissions, calculations, and source reconciliation before publication.
Separate decision, operating, and diagnostic views so each audience gets enough detail without inheriting everyone else’s dashboard.
Migrate one recurring workflow, run it beside the existing report, explain every material discrepancy, and preserve a rollback path.

Choose the recurring report that causes the most avoidable pre-meeting work. Write its decision contract, mark every metric as an outcome, driver, diagnostic, or guardrail, and remove anything that serves no decision. That small redesign will show you exactly where the next improvement belongs: the definition, the data pipeline, the analysis, or the delivery.

References

April 21, 2026

Google Ads Security and Conversion Infrastructure Runbook

Your Google Ads stack can fail in two opposite ways: access becomes too loose to trust, or security controls become so brittle that the people and automations responsible for measurement are locked out. Meanwhile, a conversion tag can deploy cleanly and still measure the wrong action.

The practical goal is not merely to enable multi-factor authentication or create a Google Tag Manager tag. You need a traceable path from an authorized identity to a tested conversion event, with an owner and a recovery route at every handoff. This runbook shows you how to build that path without turning an access change or tagging shortcut into a campaign outage.

Key takeaways

MFA enforcement matters most when someone creates a new OAuth 2.0 refresh token. An integration that works now can still fail during reconnection, onboarding, or credential replacement.
Service accounts remain the better fit for supported automated or offline workflows, but they still need explicit ownership, limited access, and a tested handoff process.
A pre-filled Google Tag Manager configuration can remove transcription work. It cannot decide whether you selected the right container, conversion action, trigger, or counting logic.
Never revoke a working credential or remove a working conversion tag until its replacement has passed a controlled test. Otherwise, your rollback path disappears at the moment you need it.
Security and measurement should share one release record: identity owner, authentication method, Ads account, conversion action, GTM container, test evidence, publisher, and rollback decision.

Map authentication before MFA exposes a hidden dependency

A cutaway security system shows human, automated, and recovery access routes converging on one gateway, with one route blocked and a backup route remaining open.

Google’s announced rollout made MFA mandatory for new user-based Google Ads API authentication from April 21, with enforcement expanding over the following weeks. The important boundary is token creation: OAuth 2.0 refresh tokens that were already in use were not invalidated by the change, but fresh authentication requires the additional identity check.

That boundary explains why an account can look healthy until a routine maintenance task causes a failure. A scheduled process may continue using its existing refresh token, while a new employee, replacement integration, revoked credential, or reconnection attempt reaches the MFA gate. Passing today’s automated run is therefore not proof that your recovery workflow is ready.

Start with an authentication inventory. Do not begin by changing credentials. For every connection that can read from or act on a Google Ads account, record:

Workflow: the API job, reporting transfer, desktop tool, script, dashboard, or application that depends on access.
Authentication pattern: user-based OAuth or a service account.
Named owner: the person responsible for approving access, completing MFA, and handling recovery.
Operational owner: the person who can prove the workflow still runs correctly after an authentication change.
Credential event: what would force a new authorization flow, such as onboarding a user, replacing a connection, or rebuilding an integration.
Recovery route: who can restore access if the primary owner is unavailable, without sharing a personal password or MFA prompt.
Evidence: the last successful controlled authentication and the workflow result it enabled.

For user authentication, make the MFA rehearsal realistic. Use the same consent and token-generation path that the production workflow expects. Confirm that the designated person can complete the second factor, which may be a phone prompt or an authenticator app. Then verify that the resulting credential reaches the intended account and supports the intended workflow. A successful Google sign-in alone is not enough.

Choose user authentication or a service account deliberately

Keep user-based OAuth when the workflow is genuinely tied to a person’s authorization and an interactive sign-in is acceptable. Use a service account for a supported automated or offline workload when the connection should survive staff changes and should not depend on a person responding to an MFA prompt. Google left service-account workflows outside the new MFA requirement and recommends them for automated or offline scenarios.

Do not migrate to a service account merely to avoid MFA. A service account is a machine identity, not an exemption from governance. Confirm that the application supports it, grant only the access the workflow needs, document who owns that identity, and test what happens when its permissions or connection must be replaced.

Expand the inventory beyond custom API code. The same security change reaches authentication used by Google Ads Editor, Scripts, BigQuery Data Transfer, and Data Studio. If those tools are owned by different teams, give one person responsibility for the complete dependency map. Otherwise, each team may believe another team owns the failing sign-in.

Most importantly, do not revoke the working refresh token while you are only testing its replacement. Prove the new path first, record the result, and then retire the old credential through a reviewed change. Revoking first can stop reporting or automation without leaving you a quick way back.

Use direct GTM setup to remove copying, not judgment

Google Ads has tested a Set up in Google Tag Manager option inside the conversion setup flow. Where the option is available, you can select a GTM container and open a suggested, pre-filled tag configuration instead of manually carrying the conversion ID and label between products.

Treat this as a safer handoff, not an automatic implementation. It reduces opportunities for transcription errors, but it does not know whether your chosen website action represents a qualified lead, a completed sale, an internal test, or an accidental page view. It also cannot resolve a poor container naming convention or decide whether an existing tag will overlap with the new one.

The integration is described as a test, so do not make a launch deadline depend on the button appearing in your account. If it is absent, continue with the established manual setup and apply the same review process. Availability and implementation correctness are separate questions.

Confirm the conversion definition. Write down the user action that should count, where it occurs, and what must not count. Do this before opening GTM.
Match the account and container. Verify the Google Ads account, conversion action, website, GTM account, and container as one set. Similar client or environment names are not proof of a match.
Inspect the pre-filled values. Check the conversion ID and label against the intended conversion action even when Google populated them. Automation should reduce copying, not eliminate review.
Review the trigger separately. The tag configuration identifies where data should go; the trigger determines when it goes there. Confirm that the trigger represents the business event you defined in the first step.
Check for an existing implementation. Search the container for tags and triggers that already send the same action. Publishing a second path may produce duplicate events or conflicting behavior.
Test before publishing. Use GTM’s preview process and complete a controlled conversion path. Confirm that the tag fires on the intended action and remains silent on nearby actions that should not count.
Publish a traceable version. Record the conversion action, reason for the change, reviewer, test performed, and rollback instruction in the version description or release record.
Verify both ends. Confirm the expected firing behavior in GTM and then confirm that Google Ads recognizes the intended conversion setup. A passing browser-side test proves the trigger ran; it does not by itself prove that the account mapping is correct.

Avoid deleting the old tag before the new configuration has been verified. At the same time, do not publish two equivalent live paths and hope to compare them later. Modify the existing implementation when that is the cleanest route, or make the old and new triggers mutually controlled during the release. Your rollback should restore a known configuration, not create a second unknown one.

Operate access and tagging as one controlled release

Two specialists approve access and inspect a digital event as it passes through secure testing, monitored release, and rollback stages.

Authentication and conversion tracking are often assigned to different specialists, but they meet at the same operational boundary. The person publishing a tag needs reliable account access. The automation consuming conversion data needs a stable identity. The campaign owner needs confidence that the event still means what its name claims.

Use one release record for both sides. In a larger team, assign an access owner, GTM implementer, independent reviewer, and business owner for the conversion definition. In a smaller team, one person may hold several roles, but the checkpoints should remain separate. Pause between configuring, reviewing, publishing, and validating so that familiarity does not replace evidence.

Freeze unrelated changes. Keep other credential, container, and conversion-action edits out of the same release so a failure has a narrow set of possible causes.
Capture the known-good state. Record which automation currently succeeds, which tag and trigger currently fire, and which conversion action they serve.
Prove recovery access. Confirm that the named owner can complete a fresh user-authentication flow with MFA, or that the supported service-account workflow can be restored by its documented owner.
Stage the measurement change. Build or review the pre-filled GTM configuration without publishing it. Confirm the account, action, ID, label, trigger, and duplication check.
Run the controlled path. Exercise the actual conversion behavior and preserve enough evidence for another person to understand what was tested.
Publish and validate. Confirm the container version, the live firing conditions, the Google Ads destination, and the next successful dependent automation run.
Retire only what has been replaced. Revoke an old credential or remove an old tag only after the new path is proven and the rollback decision is documented.

Use the failure layer to choose your first check

When something breaks, identify whether the failure occurs at identity, authorization, container configuration, trigger logic, publishing, or destination mapping. Rolling back everything at once can hide the actual defect.

Symptom	Likely layer	First check
An existing API job runs, but a new connection cannot generate a refresh token	User authentication and MFA	Repeat the fresh consent flow with the named owner and confirm that the second factor can be completed.
A connection succeeds for one person but cannot be recovered by the team	Ownership and recovery	Check whether the workflow depends on one personal identity and whether a supported service-account pattern is more appropriate.
Editor, Scripts, a transfer, or a dashboard fails during sign-in	Shared authentication policy	Identify the actual Google identity behind the tool instead of treating it as an isolated application error.
The direct GTM option does not appear	Feature availability	Use the manual tag setup rather than delaying the release; the integration is being tested and may not be available in every flow.
The tag does not fire during preview	Container or trigger logic	Confirm the selected container, preview environment, trigger conditions, and exact user action.
The tag fires, but it points to the wrong conversion action	Destination mapping	Compare the conversion ID and label with the intended Google Ads action and account.
More than one tag fires for a single intended action	Duplicate implementation	Search for older tags, overlapping triggers, and parallel containers before changing the conversion definition.
The browser-side test passes, but the dependent automation fails	API authorization or workflow logic	Test the automation separately with its own identity and permissions; the GTM test does not validate API access.

At your next planned change window, exercise one fresh authentication flow and trace one controlled conversion from the user action through GTM to the intended Google Ads action. If either path lacks a named owner, test evidence, or a safe rollback, fix that gap before you scale the campaign or add another integration. Your infrastructure is ready when another authorized person can understand it, test it, and recover it without guessing.

References

April 17, 2026

How to Align Ad Tools, Formats, and Conversion Tracking
Your campaign can be configured correctly inside every advertising platform and still produce a measurement mess. The ad attracts an interaction, the tag records an event, analytics classifies it differently, and the bidding system optimizes toward something nobody intended.

The fix is not another dashboard or another tag. You need one traceable chain from the format a person sees to the business outcome you want, with a clear role and a test at every handoff.

Key takeaways
- Define each conversion in business terms before configuring it in Google, Meta, Google Tag Manager, or an analytics property.
- Give ad formats, tagging, measurement, and automation separate jobs and separate acceptance tests.
- Treat every new ad format as a new measurement surface, especially when one unit presents several locations or choices.
- Reuse an established data layer through official platform templates where supported, but verify mappings and duplicate events before publishing.
- Do not increase spend until you can trace one test action from the page or app through the tag, platform, report, and optimization setting.
Build one conversion contract before touching platform settings

Advertising platforms encourage you to start with their menus: choose an objective, install a tag, select an event, and launch. That sequence is convenient, but it lets each platform define your measurement model. The same customer action can then become a primary conversion in one account, a secondary event in another, and an analytics event with a third meaning.

Start with a conversion contract instead. This is a short specification for what happened, why it matters, and how every system should represent it. For each event, record:
<!– wp:list {
April 8, 2026

Google Commerce Discovery and In-Search Checkout Strategy

You may be optimizing product pages for the click while Google is redesigning shopping around a different outcome: identify a suitable product, validate the choice, and potentially complete the purchase inside AI Mode or Gemini. That changes where ecommerce visibility is won.

You now need two connected systems. The first makes your catalog understandable and competitive during AI-assisted discovery. The second lets an approved product move through an in-search transaction without introducing price, availability, identity, or payment failures. Here is how to prepare both without confusing checkout access with search visibility.

The new commerce funnel starts in the product graph

A generic product sits at the center of a connected network of attributes, inventory, reviews, shipping, and related items.

A conventional SEO funnel assumes that search earns a click, the product page creates confidence, and the merchant site completes the sale. Google’s emerging commerce model can compress those stages. A user may describe a need conversationally, receive product recommendations, compare options, and check out without following the familiar sequence of search result, landing page, cart, and checkout.

The catalog is therefore more than a paid advertising input. Google’s Shopping Graph contains more than 50 billion product listings and supplies product information to AI Overviews, AI Mode, and Gemini. If your product record is incomplete, ambiguous, or inconsistent, strong product-page copy may never get the chance to influence the shopper.

This is already relevant to organic discovery, not merely a future checkout project. AI Overviews appeared in about 14% of observed shopping queries, up from roughly 2% in late 2024. A Peec AI analysis also found that up to 83% of products in sampled ChatGPT carousels reflected Google’s organic Shopping results, with 60% of those matches coming from positions 1 through 10. That analysis is useful directional evidence, not proof that every assistant, market, or query follows the same pattern. It does show why Merchant Center data belongs in your AI search strategy.

Commerce layer	Question it must answer	Typical failure to prevent
Product feed	Is this product a relevant match for the request?	Generic titles, missing identifiers, weak attributes, or unusable images make the product hard to match and compare.
Product page	Do the details support the product record and the buyer’s decision?	The page and feed describe different variants, benefits, prices, or availability.
Commerce integration	Can the selected product be purchased successfully in the Google experience?	The discovery record cannot be resolved to the correct variant, checkout state, identity, or payment flow.

Use those layers to triage problems correctly. Low discovery visibility is usually a matching and data-quality problem before it is a checkout problem. A visible product that cannot complete a transaction is an integration problem. A product that earns attention but not purchases may have a merchandising, offer, or expectation problem. Putting every weak result under the label of SEO hides the part that actually needs work.

Make the product feed an organic discovery asset

Many merchants let the paid media team own the only feed. That arrangement keeps campaigns running, but a feed shaped around bid relevance and advertising conventions is not automatically the best representation of how people search organically. Paid and organic outputs can share a catalog while applying different rules to titles, descriptions, and supporting attributes.

Build records around the language of product selection

The title is your highest-priority matching field. Write it so a person can identify the product without seeing the image or visiting the page. Start with the product type and add the attributes that genuinely distinguish the item, such as brand, material, capacity, size, color, compatibility, or intended use. The useful combination depends on the category. Do not force every possible modifier into every title, and do not repeat words merely to make the record longer.

A good test is to compare the title with the phrases a buyer would naturally use when narrowing a choice. If shoppers distinguish your products by capacity and compatibility, those attributes deserve more attention than internal collection names. If the title could apply equally to many products in your own catalog, it is probably too vague for an AI system to select confidently.

Use accurate GTINs where the product has them. Correct identifiers help Google match identical products, combine relevant information such as reviews, and understand that two differently worded listings refer to the same item. Well-matched products with accurate GTINs can receive up to 40% more clicks. Never invent an identifier or reuse one from a different variant.
Supply both clear standard images and useful lifestyle images. The standard image should make the product easy to identify. A lifestyle image should add context, scale, or use information rather than obscure the item. Image problems can also cause Merchant Center disapprovals, so treat asset validation as feed health, not decoration.
Use product_highlight for concise buyer benefits. Replace empty claims such as high quality with concrete outcomes. A statement about handling light rain during a commute tells the buyer more than an unsupported adjective.
Use product_detail for structured specifications. Put filterable facts such as dimensions, material, capacity, and compatibility into the structured field that represents them. Do not bury every decision-critical fact in prose.
Keep the feed and product page synchronized. A refined feed title cannot compensate for a page that represents a different variant, price, feature set, or availability state. The two surfaces should describe the same purchasable product.

Create a controlled organic output

You do not need two unrelated catalogs. You need one reliable product source and a controlled way to publish an organic-oriented output without letting paid campaign conventions overwrite it. Depending on your commerce stack, that may be a dedicated feed or a dedicated set of transformation rules. Either way, document which fields are canonical, which fields may vary by channel, and who approves each change.

The potential impact is material, but it should not be treated as a guaranteed benchmark. In one major ecommerce implementation, an organic feed produced a 10% month-over-month increase in organic listing click-through rate and a 4% increase in purchase rate. A product-level test recorded 92% higher free-listing revenue, 83% more visibility, and a 14% increase in add-to-cart rate. Another organic optimization set generated 35,000 impressions at a 1.4% click-through rate, which was 55% above the paid click-through rate for the same period. Those results establish that feed changes can be commercially important; they do not establish a universal lift for every catalog.

Run your own controlled evaluation:

Select a coherent product group with enough existing activity to measure.
Record its free-listing impressions, click-through rate, add-to-cart rate, purchase rate, and revenue before changing the feed.
Change one field family at a time when practical. A title test is easier to interpret if you do not simultaneously replace every image and description.
Keep a version log that connects each feed change to the affected product IDs.
Compare product-level outcomes, not only catalog-wide averages. A large category can conceal both strong winners and harmful rewrites.
Check paid performance separately. An organic improvement does not prove that the same wording should replace a paid title optimized for a different matching and bidding context.

The goal is not to make the organic feed sound conversational at any cost. It is to make the product record precise in the language buyers use while preserving exact identifiers, specifications, and variant distinctions.

Prepare for UCP without mistaking checkout for ranking

A product moves through connected price, inventory, identity, payment, and confirmation checkpoints in an abstract checkout system.

Google’s Universal Commerce Protocol, or UCP, connects product data, user identity, payment flows, and checkout so eligible purchases can be completed from product listings in AI Mode and Gemini. The initial rollout is gradual and U.S.-limited. Merchants must complete a technical integration, submit an interest form, receive approval, and then use Merchant Center onboarding tools.

Approval opens a transaction path; it does not establish a search-ranking benefit. Treat discovery eligibility and transaction readiness as separate workstreams unless Google explicitly documents a connection. A product still needs strong, consistent data to be selected. UCP then addresses whether the selected item can move through checkout inside the Google experience.

Google has also added a native_commerce attribute for UCP-powered purchase buttons. Do not treat that attribute as a shortcut around integration quality. A buy button attached to stale price, availability, or variant data creates a more immediate failure than a conventional listing because the shopper is already trying to transact.

Confirm the access path. Check Merchant Center for UCP onboarding availability and follow the interest and approval process. Do not promise a launch date internally until the account has access.
Assign a catalog system of record. Every purchasable variation needs a stable mapping between the feed record and the item your checkout can fulfill. Resolve duplicate identifiers and unclear parent-variant relationships before transaction testing.
Map the checkout data contract. Identify which system owns product identity, selected variant, price, availability, buyer identity, payment state, and transaction outcome. Document how a change in one system reaches the others.
Use the available sandbox. Merchant Center onboarding includes a testing sandbox, identity linking, and checkout APIs. Test successful transactions as well as unavailable products, changed prices, unresolved identities, declined payments, and interrupted requests.
Define operational ownership. SEO can improve matching, but commerce, engineering, privacy, security, payment, and customer-support owners need responsibility for the parts they control. Decide who pauses native checkout when catalog or transaction data becomes unreliable.
Activate only after reconciliation. The feed, product page, commerce system, and transaction response must resolve to the same product and offer. If they do not, keep the safer redirect-based journey until the mismatch is fixed.

This is where cross-team collaboration becomes practical rather than ceremonial. SEO contributes query language and matching logic. Commerce owns product truth and fulfillment constraints. Paid media teams often understand feed tooling and disapproval management. Engineering owns the integration path. Each team should have a named field or state to maintain, not a general instruction to support AI commerce.

Measure discovery and checkout as one journey, not one metric

In-search checkout weakens the old assumption that a successful search interaction produces a website session. When a customer can purchase inside an AI interaction without being redirected to the merchant site, traffic alone becomes an incomplete measure of both SEO and commerce performance.

Build a measurement chain that follows the product as far as your available data allows:

Catalog health: Track active products, rejected or disapproved items, identifier coverage, image issues, and unresolved feed-page discrepancies. A product excluded before matching cannot generate a meaningful visibility or conversion signal.
Discovery: Track impressions and click-through rate by product, product group, query class, and Google surface where those dimensions are available. Separate free listings from paid placements.
Consideration: Track the interactions you can observe between a product impression and checkout. Keep website engagement separate from native interactions so a change in surface mix does not look like a sudden behavioral collapse.
Transaction: Track checkout attempts, successful purchases, failures, and the product or variant involved. Preserve a reference that lets commerce and analytics teams reconcile the transaction with the originating product record.
Business outcome: Compare completed orders and revenue with website sessions and site-based orders. A decline in site traffic is not automatically lost demand if more transactions are completing elsewhere. It is also not automatically good news; you need reconciled purchase data to tell the difference.

Capture a baseline before enabling native checkout. After activation, segment results by surface and product group rather than comparing one blended total with the previous period. Otherwise, a shift from website checkout to Google checkout can be mistaken for an SEO loss, while a surge in product impressions can be mistaken for commercial growth without completed purchases.

Document your attribution rule as part of the integration. Decide how you will classify a purchase discovered in AI Mode, completed through native checkout, and fulfilled by your commerce system. The rule matters less than using it consistently and making its limits visible. Do not allow SEO, paid media, and commerce dashboards to claim the same order independently.

You should also watch for substitution. Native checkout may replace a transaction that would otherwise have occurred on your site, or it may capture demand that would have been lost through extra steps. Compare the full order picture rather than assuming every native purchase is incremental or every missing session represents cannibalization.

Key takeaways

Google commerce visibility begins with product data, so Merchant Center feed quality is now part of organic and AI search optimization.
Optimize organic titles around the attributes buyers use to identify and distinguish products, while preserving accurate GTINs, specifications, images, price, and availability.
Use a dedicated organic feed or controlled organic transformation rules instead of forcing paid and free listings to share every optimization decision.
Treat UCP as a checkout capability, not a ranking shortcut. Discovery quality must be solved before native transaction readiness can help.
Prepare stable product mappings, clear system ownership, sandbox failure tests, and a safe way to pause native checkout when data becomes unreliable.
Measure catalog health, discovery, transaction outcomes, and total orders together because website sessions no longer represent the entire shopping journey.

Start with a catalog reconciliation, not a checkout build. Choose a representative product family and align its titles, identifiers, attributes, images, page details, price, and availability. Then name the owner of every field and transaction state. That work improves discovery whether or not UCP access has reached your account.

When access becomes available, take the same reconciled products through the sandbox before expanding. You will learn more from a small group with traceable data and observable failures than from activating native checkout across a catalog whose product truth is still disputed.

References

April 8, 2026

How to Choose an Enterprise Custom Software Provider in 2026

You have budget, stakeholder expectations, and a shortlist of firms that all claim they can modernize the same systems. The risky decision is not who can produce software. It is who can understand your operating constraints, make sound tradeoffs, ship into your environment, and leave you able to run what you paid for.

For a 2026 procurement, use a selection process that exposes how each provider actually works. Match the provider to your dominant risk, give every candidate the same decision brief, test claims with artifacts and working sessions, protect your exit path in the contract, and run a pilot through the hardest part of the system.

Match the provider model to the risk you need to retire

There is no generally best enterprise custom software provider. A firm can be excellent at integrating known systems and poor at discovering an uncertain product. Another can design a strong customer experience but lack the governance needed for a sensitive migration.

Start by naming the dominant risk in the initiative. Do not begin with a preferred programming language or a list of recognizable firms. Technology matters, but it rarely explains why an enterprise program is difficult.

Your dominant risk	Provider model to examine	Evidence to request
The workflow, product, or user need is still uncertain	A product engineering partner with strong discovery capability	A discovery plan, examples of decisions changed by user evidence, a product leadership role, and a backlog that separates assumptions from validated requirements
The work crosses many internal and third-party systems	A systems integrator or integration-focused engineering firm	System context maps, API and data-contract examples, dependency management, cutover planning, and a reference project with comparable integration boundaries
A fragile legacy platform must change without interrupting operations	A modernization specialist	An incremental migration approach, dependency analysis, data reconciliation, rollback design, and evidence that old and new components can coexist during transition
The system handles sensitive or regulated data	A provider with mature security, privacy, and delivery governance	Named control owners, secure-development practices, audit artifacts, incident procedures, data-flow documentation, and clear subcontractor oversight
The architecture and backlog are already well defined, but capacity is constrained	A managed delivery squad or staff-augmentation provider	The actual proposed team, technical screening methods, onboarding plans, delivery accountability, and a clear boundary between your leadership duties and theirs

This distinction changes your shortlist. Staff augmentation can be appropriate when you already have product ownership, architecture, security, and delivery management. It is a poor substitute for those functions when they are missing. A large integrator may be well suited to a multi-system program but unnecessarily heavy for a focused product build. A specialist can reduce technical risk while still needing your organization to own business adoption.

Write a short risk statement before you contact providers: We need to achieve this operating outcome, and the hardest uncertainty is this constraint. If stakeholders cannot agree on that sentence, the procurement is not ready for a meaningful vendor comparison.

Apply non-negotiable filters next. These can include deployment environment, data location, security obligations, integration platforms, accessibility requirements, support coverage, language or time-zone needs, procurement rules, and restrictions on subcontracting. Treat them as pass-or-fail conditions. A polished proposal cannot compensate for a provider that is unable to operate inside your mandatory boundaries.

Give every candidate a brief that cannot be gamed

Vague requests produce proposals that look comparable but are built on different assumptions. One provider may include discovery, migration, testing, and production support. Another may quote only implementation. The lower number then reflects a narrower interpretation, not necessarily a more efficient team.

Your decision brief should give every candidate the same view of the problem while leaving room for them to challenge the proposed solution.

Current state: Describe the workflow, systems, users, data sources, ownership boundaries, and recurring failure points. Include diagrams where they exist, but mark anything that may be outdated.
Desired business outcome: State what must become observably different. Replacing a platform is an activity; removing duplicate entry, improving decision visibility, or enabling a new service is an outcome.
Scope boundaries: Identify what is included, what is excluded, and what remains undecided. Hidden exclusions tend to reappear as change requests.
Known constraints: List mandatory platforms, identity systems, integration protocols, data classifications, accessibility expectations, release controls, and operational windows.
Unknowns: Name uncertain data quality, undocumented interfaces, unresolved ownership, pending policy decisions, or dependencies on other programs. You are testing how the provider handles uncertainty, not whether it pretends uncertainty is absent.
Internal responsibilities: Name the people who own product decisions, architecture, security, data, operations, procurement, and acceptance. If a role is unfilled, say so and ask how the provider would cover or help establish it.
Commercial boundaries: Explain the available budget process, approval gates, target window, and any required pricing structure. Ask providers to separate assumptions, exclusions, optional work, and third-party costs.
Decision method: Tell candidates which evidence will be evaluated, who will participate, and which conditions are mandatory. This discourages proposals designed mainly to impress an executive audience.

Require a common response structure. Each proposal should identify the proposed first phase, the questions it will answer, the actual roles needed, major dependencies, technical unknowns, delivery governance, security responsibilities, acceptance approach, commercial assumptions, support model, and exit plan.

Do not reward false precision. A detailed estimate built before the provider has seen the systems can still be a guess with professional formatting. Ask what evidence supports the estimate, which assumptions have the greatest cost impact, how uncertainty is represented, and what event would trigger re-estimation. Compare the boundaries behind the numbers before comparing the numbers themselves.

Also let candidates disagree with your requested solution. A credible provider should be able to explain which requirement it would validate first, which architectural commitment it would delay, and which part of the proposed scope creates avoidable risk. Blanket agreement is not proof of collaboration.

Test delivery behavior, not presentation quality

Engineers, security specialists, and operations staff collaborate on a live integration test between legacy hardware and a modern gateway.

A proposal tells you what a provider wants to promise. Your evaluation needs to reveal how its team reasons when information is incomplete, dependencies conflict, or a release fails.

Create the scorecard before demonstrations begin. Otherwise, a charismatic presenter or attractive prototype can quietly redefine what matters. Choose criteria that reflect the consequences of your program, assign their relative importance, and define the evidence required for each rating.

Problem fit: Does the provider understand the operating problem, users, constraints, and adoption burden?
Technical judgment: Can the team explain architecture choices, integration boundaries, tradeoffs, failure modes, and migration sequencing?
Delivery discipline: Are decisions, risks, dependencies, testing, releases, and changes managed visibly?
Security and privacy: Are responsibilities embedded in delivery, or deferred to a review near launch?
Team quality: Have you met the people who will perform the work, and do their roles match the proposal?
Operational readiness: Will your organization receive the monitoring, documentation, deployment assets, and knowledge needed to operate the system?
Commercial clarity: Are assumptions, exclusions, third-party costs, change mechanisms, and support obligations understandable?
Independence: Can you retain, operate, modify, and transition the software without being trapped by undocumented knowledge or proprietary dependencies?

Have evaluators record their ratings independently before the group discussion. The goal is not mathematical certainty. It is to make disagreements visible. A security lead and a product owner may rate the same proposal differently for valid reasons, and those differences point to decisions the steering group must resolve.

Use a scenario workshop to expose the real team

Give shortlisted providers the same time-boxed scenario based on a genuine risk in your environment. For example, an upstream system begins returning incomplete records during a staged release, or a new identity requirement conflicts with the planned user journey. Ask each team to work through questions, options, ownership, validation, deployment, monitoring, rollback, and stakeholder communication.

Do not grade the workshop on whether the provider guesses your preferred answer. Notice whether the team:

asks about business impact before selecting a technical response;
separates known facts from assumptions;
identifies who has authority to make each decision;
considers data integrity, security, operations, and user impact together;
offers reversible steps while evidence is incomplete;
makes disagreement visible instead of hiding it behind consensus language; and
records decisions and unresolved questions in a form another team could use.

Follow every important claim with an evidence request

Use a simple chain: claim, artifact, reference, and working explanation. If a provider claims mature DevSecOps, inspect a redacted pipeline or control artifact and ask the proposed delivery lead to explain how exceptions are handled. If it claims expertise in legacy modernization, ask for a migration decision, the tradeoff behind it, and a client reference who can discuss the difficult part of the transition.

Reference calls are not character checks. Confirm whether the people presented during procurement remained involved, where the estimate changed, how bad news was communicated, which responsibilities stayed with the client, how production incidents were handled, and what the client had to rebuild or document after handover.

Red flags include unnamed delivery personnel, heavy reliance on sales demonstrations, estimates without assumptions, security deferred until the end, proprietary components without a transition path, undisclosed subcontracting, and an unwillingness to describe a failed decision. Strong providers do not need to pretend every previous engagement was frictionless.

Protect operability, data, and your exit before work starts

A team inspects a modular enterprise platform with a secure data vault, operational controls, backups, and a separate migration route.

The contract should do more than authorize development and payment. It should define how you inspect the work, accept it, operate it, change direction, and leave the relationship without losing control of the system.

Turn handover requirements into delivery requirements

Repositories and access: Specify where source code, configuration, infrastructure definitions, tests, documentation, and deployment assets reside. Your authorized personnel should have appropriate access throughout delivery, not only at the end.
Ownership and licensing: Distinguish custom work, pre-existing provider assets, open-source components, commercial dependencies, and third-party services. Record the licenses and restrictions that apply to each.
Acceptance: Connect acceptance to observable behavior, quality checks, security requirements, data reconciliation, operational documentation, and agreed non-functional needs. A feature being demonstrated is not the same as it being ready to operate.
Change control: Define how changes are raised, analyzed, approved, priced, scheduled, and recorded. Preserve the decision history so a later dispute does not depend on memories of a meeting.
Security and privacy: Assign responsibility for access, secrets, vulnerabilities, audit evidence, incident notification, data retention, deletion, and subcontractor controls.
Continuity: Address key-person changes, replacement standards, knowledge transfer, staffing visibility, and the conditions under which subcontractors can be added.
Operations: Define logging, monitoring, alert ownership, deployment procedures, backup and recovery responsibilities, support boundaries, and escalation paths.
Transition: Require current documentation, environment inventories, dependency registers, known-issue records, runbooks, credentials transfer procedures, and reasonable cooperation with an internal or replacement team.

Ambiguity in these areas can create financial exposure, operational disruption, security gaps, or loss of practical control over the software. Have qualified legal, procurement, security, privacy, and technical reviewers adapt the terms to your organization. This is especially important when sensitive data, cross-border processing, regulated workflows, or material business continuity risks are involved.

Separate AI used during delivery from AI embedded in the product

AI-assisted delivery needs its own due diligence. Ask which coding assistants, models, and external services the provider permits; what code, requirements, logs, or data may be sent to them; whether submitted material is retained or used for training; how access is controlled; and how usage is logged. Require human review, testing, provenance controls, and an incident path appropriate to the sensitivity of the work.

If the product itself contains an AI feature, the risk is different. Document the model or service dependency, data flow, evaluation method, acceptable and unacceptable behavior, human escalation, fallback behavior, monitoring, version-change process, cost boundaries, latency constraints, and what happens when the model or provider is unavailable.

Ask how your organization would replace the model, export relevant data, reproduce an evaluation, and investigate a harmful or incorrect output. A general corporate AI policy does not answer those product-level questions.

Use a pilot to test the hardest boundary, then decide

A useful pilot is a thin vertical slice through real delivery risk. It is not a disconnected interface mockup or a convenient feature chosen because it will look good in a demonstration.

Choose a workflow that crosses the boundaries most likely to cause trouble: identity, representative data, an important integration, business rules, deployment, observability, and operational ownership. Use controlled environments and approved data access. Do not expose production systems or sensitive data merely to make the pilot feel realistic.

The pilot charter should state:

the business and technical hypotheses being tested;
the risks and unknowns the work must reduce;
what is in scope and deliberately out of scope;
the acceptance tests and evidence required;
the security, privacy, and access rules;
the artifacts that must remain with your organization;
the commercial cap and approval mechanism;
the conditions for stopping, extending, or proceeding; and
the handover required even if the provider is not selected for the next phase.

Evaluate the working relationship as closely as the resulting code. Look at the quality of questions, the visibility of decisions, the treatment of uncertainty, the handling of defects, the completeness of tests, the repeatability of deployment, and the usefulness of documentation. Notice whether risks arrive early enough for you to act or appear only when they threaten a deadline.

At the decision gate, do not ask only whether the pilot works. Ask whether your team understands why it works, can see how it is operated, knows what remains uncertain, and could transfer it to another capable team. A successful demonstration with no durable knowledge is weak evidence for an enterprise partnership.

Key takeaways

Choose a provider for the dominant risk in your initiative, not for name recognition or the longest capability list.
Give every candidate the same problem, constraints, unknowns, responsibilities, and response format before comparing proposals.
Test claims through artifacts, scenario workshops, proposed-team interviews, and reference calls tied to comparable work.
Make repository access, ownership, security, operability, documentation, subcontracting, and transition obligations explicit before delivery begins.
Evaluate AI-assisted development separately from AI features embedded in the software.
Run a controlled vertical-slice pilot through the hardest system boundary, with acceptance and exit requirements defined in advance.

Your next move is to write the short risk statement and decision brief before adding another provider to the shortlist. Once every candidate is answering the same problem and producing the same kinds of evidence, the choice becomes less about sales confidence and more about whether you can trust the team with the system after the kickoff meeting is over.

References

First Page Sage – Top Custom Software Solutions for Enterprises in 2026

April 7, 2026

Google Ads AI Video: A Practical Workflow for Better Creative
If your Google Ads account has plenty of product images but little usable video, Veo gives you a practical way to close that gap. You can turn existing visual assets into short YouTube ads without waiting for a conventional production cycle.

The useful question isn’t whether AI can make a video. It can. The question is whether you can give it the right inputs, catch the wrong outputs, and measure the result without confusing generated creative with video your team produced. This workflow covers all three.

What Veo changes inside Google Ads

Veo reduces the smallest viable video project. Inside Google Ads Asset Studio, you can upload as many as three static images and generate a video of up to 10 seconds. The model adds motion, and customizable templates help turn the result into an ad suitable for YouTube.

That is a meaningful capability, but it is a narrow one. Veo is well suited to a concise product demonstration, a visual benefit, or a single promotional idea. A 10-second output is not a substitute for a customer story, a detailed explanation, or a campaign concept that depends on dialogue and multiple narrative beats.

Treat the tool as a creative multiplier, not a strategy generator. It can add movement to an idea you have already clarified. It cannot decide which customer problem matters, which claim is credible, or what the viewer should do next.

The accompanying Nano Banana integration expands the editing layer. You can change backgrounds, adjust text, and tailor creative for different audience interests. That makes iteration faster, but each edit still needs the same brand, product, and claim review you would apply to work from a designer.

Choose images that give the model a clear job

The quality of the source images determines how much ambiguity the model must resolve. A clean product shot with an obvious foreground, stable proportions, and a plausible type of movement gives it a constrained problem. A dense collage with several focal points, embedded copy, and conflicting perspectives gives it several problems at once.

Before uploading anything, score each candidate image against these criteria:
- One unmistakable subject: A viewer should know what the ad is about without studying the frame.
- Clear separation: The product, person, or focal object should be visually distinct from the background.
- Plausible movement: You should be able to describe what could move in one sentence, such as a package rotating, fabric flowing, or a camera pushing toward a product.
- Consistent product details: Packaging, colors, proportions, and visible features should agree across the images.
- Minimal baked-in text: Important copy is easier to inspect and revise when it is handled as an ad element instead of being embedded in a busy image.
- Enough visual space: Leave room for template copy, branding, or a call to action without covering the subject.
- Accurate context: The setting must not imply a use, feature, size, or outcome the product cannot support.
Do not upload three images merely because three are allowed. Every image should have a role. One might establish the product, another might show the relevant detail, and a third might place it in context. If two images contradict each other or compete for attention, use the stronger one and remove the ambiguity.

Clean consumer-product imagery is a particularly sensible starting point. Early testing shared by Ameet Khabra indicated that brands with clean images and an obvious logic for movement may benefit most. That is an early practitioner observation, not a universal performance rule, so use it to select an initial test rather than to predict a result.

Build a repeatable generation and review workflow

Generating first and deciding what the ad means afterward produces a folder of clips, not a campaign. Write the creative brief before opening Asset Studio, even if the brief is only four lines.
1. State the audience and problem. Name the person the ad is for and the single situation that makes the product relevant. Avoid a broad label such as “all shoppers.”
2. Choose one promise. A short video rarely has room for a feature list. Select the one benefit the viewer should retain after the clip ends.
3. Define the visible action. Describe what should move and why that movement helps communicate the promise. Motion should reveal, demonstrate, or focus attention; it should not exist only to make the image look active.
4. Select up to three source images. Give each image a purpose, remove weak duplicates, and confirm that the product details agree across the set.
5. Generate a restrained baseline. Start with the simplest version of the concept. A conservative baseline is easier to evaluate than an output containing simultaneous background, text, pacing, and visual-style changes.
6. Create one deliberate variant. Change one meaningful element: the input image, the setting, the visual emphasis, or the template treatment. Do not change everything at once.
7. Use Nano Banana for controlled edits. Swap a background or adjust the copy only after the core motion works. Treat each edit as a new creative that must pass review.
8. Label the asset before launch. Put the concept, generation method, and variant in the name. A structure such as product, benefit, Veo, and variant number will be more useful later than a filename such as “final-video-3.”
Inspect the output as an ad, not as a novelty

Watch the generated clip several times with a different purpose on each pass. First judge the message. Then inspect the product. Finally, check every frame that contains copy, branding, or a transition.
- Product identity: Does the same product remain recognizable from beginning to end?
- Shape and scale: Do proportions stay stable as the camera or object moves?
- Packaging and text: Are labels, logos, prices, and claims legible and accurate?
- Physical behavior: Does the movement make sense for the material and setting?
- Background integrity: Do shadows, reflections, edges, and contact points agree with the new environment?
- Message hierarchy: Can a viewer understand the product, benefit, and next action without pausing?
- Landing-page continuity: Will the person who clicks find the same product, offer, and promise on the destination page?
If the product changes shape, the label mutates, or the setting creates a false impression, reject the output. A polished transition does not compensate for a misleading frame. When the defect affects the central subject, a new generation from a clearer image is usually a sounder decision than layering more edits onto the mistake.

Separate creative testing from generation method

AI-generated video creates two questions that are easy to collapse into one: did the creative idea work, and did the generation method help? You need to preserve the origin of each asset if you want to answer either question.

Google Ads API v23.2 adds a VideoEnhancement resource that can distinguish Google-generated video from advertiser-provided video. If your team maintains a reporting pipeline, update the relevant client library and code before building analysis around that distinction. A dashboard cannot recover creative provenance later if the pipeline never captured it.

Keep a corresponding field in the creative log used by marketers. Record the asset name, source images, generation method, concept, edited element, campaign, and launch status. The API classification tells you where a video came from; the creative log tells you what hypothesis it was meant to test.

Run tests that lead to a decision

Begin each test with a sentence that can be proved wrong. For example: “A product-in-use image will communicate the benefit more clearly than an isolated pack shot.” Then preserve everything you reasonably can except the element named in that sentence.
- To test the generation method: Compare Google-generated and advertiser-provided videos with comparable messages, audiences, offers, and destinations.
- To test an input image: Keep the template and message stable while changing the source visual.
- To test a background: Keep the product, copy, and motion concept stable while changing only the setting.
- To test a message: Keep the visual treatment stable while changing the benefit or call to action.
- To test a template treatment: Use the same source images and promise, then vary the presentation rather than the underlying idea.
Choose the campaign goal and evaluation metrics before launch. Do not declare a winner because one clip looks smoother or receives an early burst of delivery. Judge it against the action the campaign is intended to produce, and document the decision so the next generation builds on a finding rather than restarting the experiment.

Google Ads AI video FAQ

Can Veo replace a conventional video production?

It can replace a narrow production task: turning up to three still images into a short, template-assisted video ad. It does not replace concept development, complex storytelling, accurate product demonstration, brand review, or footage that must document a real person, place, or event. Use it where the format matches the job.

What should you test first?

Start with a product that has clean photography, a single focal point, and an easily described motion concept. Generate one restrained baseline and one controlled variant. That pair will teach you more than a batch of unrelated outputs because you will know what changed.

Do you need Google Ads API v23.2 to create Veo videos?

No. Creation happens in Asset Studio. API v23.2 matters when you operate custom reporting and need programmatic visibility into whether a video was generated by Google or supplied by the advertiser. Teams that rely only on interface reporting can still adopt the same discipline by labeling assets and maintaining a creative log.

Your next move should be small and auditable: choose one image-rich product, write one clear promise, generate a baseline plus one variant, and record the origin of both assets before they enter a campaign. That gives you a usable ad and a test you can learn from.

References
- CrushPress.AI — Transform Your Marketing: Google’s Veo Brings AI Video Generation to Google Ads
- CrushPress.AI — Discover Google Ads API v23.2: Enhancements and Insights
March 27, 2026

Tag: API

What Google retired, and when each dependency changes

Key takeaways

Decide whether to keep or remove FAQPage markup

Audit the implementation before touching production

Repair Search Console reports and API jobs before they fail silently

Measure the traffic effect without inventing causation

Keep the answers, but remove the obsolete SEO promise

Turn the retirement into a controlled cleanup

References

Define the signal before you optimize the spend

Build a conversion hierarchy, not a bag of events

Audit the conversion chain before interpreting CPA

Use cross-channel reporting as a control view, not absolute truth

Turn trusted conversion data into negative-keyword decisions

Run an optimization cadence that protects the signal

Key takeaways

References

Know exactly what will fail at the cutoff

Key takeaways

Build an inventory that includes hidden and dormant calls

Ask vendors for feature-level confirmation

Migrate the workflow, not just the version label

Define readiness with production evidence

References

Live means decision-ready, not merely connected

Build a decision context, not a giant data dump

Use MCP as the connection layer, not the policy

Put enforceable guardrails between reasoning and action

Test the data path before judging the agent

Key takeaways

References

Start with the decision, not the available data

Standardize the data before you visualize it

Give dashboards, code, APIs, and AI separate jobs

Design separate views for decisions, operations, and diagnosis

Migrate one recurring report and operate it like a product

Key takeaways

References

Key takeaways

Map authentication before MFA exposes a hidden dependency

Choose user authentication or a service account deliberately

Use direct GTM setup to remove copying, not judgment

Operate access and tagging as one controlled release

Use the failure layer to choose your first check

References

Build one conversion contract before touching platform settings

The new commerce funnel starts in the product graph

Make the product feed an organic discovery asset

Build records around the language of product selection

Create a controlled organic output

Prepare for UCP without mistaking checkout for ranking

Measure discovery and checkout as one journey, not one metric

Key takeaways

References

Match the provider model to the risk you need to retire

Give every candidate a brief that cannot be gamed

Test delivery behavior, not presentation quality

Use a scenario workshop to expose the real team

Follow every important claim with an evidence request

Protect operability, data, and your exit before work starts

Turn handover requirements into delivery requirements

Separate AI used during delivery from AI embedded in the product

Use a pilot to test the hardest boundary, then decide

Key takeaways

References

What Veo changes inside Google Ads

Choose images that give the model a clear job

Build a repeatable generation and review workflow

Inspect the output as an ad, not as a novelty

Separate creative testing from generation method

Run tests that lead to a decision

Google Ads AI video FAQ

Can Veo replace a conventional video production?

What should you test first?

Do you need Google Ads API v23.2 to create Veo videos?

References