CrushPress.AI

Tag: API

  • Google-SerpApi Scraping Lawsuit: An SEO Team Playbook

    Google-SerpApi Scraping Lawsuit: An SEO Team Playbook

    Your rank tracker can keep returning data while the legal and commercial assumptions underneath it have already become a business risk. If your dashboards, client reports, competitive research, or AI visibility monitoring depend on SerpApi or another reseller of Google results, you need an exposure map before a court outcome, not a prediction of who will win.

    Google’s claims remain contested, and filing a lawsuit does not prove them. But the dispute targets the collection method, the content being collected, and the resale of that content. Those issues can affect service continuity, field coverage, pricing, and historical comparability long before they establish a legal rule.

    What the lawsuit does and does not establish

    Google is not merely objecting to someone looking at a public results page. It alleges that SerpApi evaded security measures and crawling controls to collect and resell search-result content. More specifically, Google accuses SerpApi of:

    • Circumventing technical protections and standard crawling controls.
    • Disregarding website directives intended to limit content access.
    • Using cloaking, rotating bot identities, and large bot networks to avoid detection.
    • Taking licensed material from search features, including images and real-time data, and selling access to it.

    Those are Google’s allegations, not findings of fact. SerpApi denies wrongdoing, argues that public search data should remain accessible, and has invoked the First Amendment in defending its position. It also warns that restrictions of this kind could damage an open web.

    Do not turn that disagreement into either of two unsupported conclusions: that every form of SERP collection is unlawful, or that anything visible in a browser is automatically unrestricted. The real questions are more specific:

    • How was the data accessed?
    • Which technical controls or publisher directives applied?
    • Does the result contain material licensed from another provider?
    • What exactly is being stored, transformed, displayed, and resold?
    • Which party assumes the risk if access is restricted?

    This distinction matters when you evaluate a supplier. A provider’s broad statement that its data is public does not answer a narrower allegation about evading controls or redistributing licensed content. You need enough provenance to understand the service you are buying, even if the provider cannot disclose its entire technical system.

    Audit your SERP dependency before the data changes

    Analysts trace branching data connections from a generic search-results source to rank tracking, reports, research, storage, alerts, and AI monitoring tools.

    Start with operational exposure rather than courtroom speculation. The goal is to identify what would break if a provider removed fields, reduced request volume, changed its collection method, raised prices, or stopped serving a particular Google feature.

    1. Find direct and indirect dependencies. Search your scripts, workflow automations, data warehouse jobs, dashboards, reporting templates, and vendor integrations for SerpApi and other SERP data services. A platform can expose search data without making its upstream supplier obvious, so ask embedded vendors as well.
    2. Separate the data classes. Record whether each workflow uses organic links, snippets, images, knowledge features, shopping information, local results, or real-time features. The lawsuit’s emphasis on allegedly licensed feature content makes a generic label such as “Google data” too vague for risk review.
    3. Map every downstream commitment. Note which datasets feed internal research, executive reporting, client deliverables, automated alerts, product features, or contractual service levels. A low-volume feed can still be critical if a customer-facing report depends on it.
    4. Capture a baseline. Preserve your field dictionary, query settings, market and device assumptions, freshness expectations, failure rate, and representative outputs, subject to your retention rights. Without a baseline, a provider-side methodology change can look like a ranking or visibility change.
    5. Assign a fallback. Name the replacement method, the owner who can activate it, and the reporting limitation it introduces. “Find another API” is not a fallback plan unless you have tested how its definitions and coverage differ.

    Classify the dependency by the consequence of failure, not by the number of API calls:

    DependencyPractical responseImportant limitation
    Ad hoc researchSave query definitions and identify a manual sampling method.A small manual sample may not reproduce the provider’s location, device, or personalization assumptions.
    Recurring internal dashboardTest a second data path and annotate any supplier or methodology change.Two providers may label positions and search features differently.
    Client or executive reportingDocument the dependency, establish a change-notice process, and prepare a reporting caveat.Combining incompatible series can create a false trend.
    Customer-facing product featureReview the contract, test graceful degradation, and define who can activate the contingency.A legal remedy after disruption will not restore immediate availability.

    For information about your own site’s Google performance, a first-party source such as Google Search Console may cover part of the need. It does not reproduce a complete results page or provide a like-for-like replacement for competitive SERP monitoring. Treat it as one layer of a fallback, not a universal substitute.

    When you test an alternative, overlap the old and new methods before combining their data. Compare query interpretation, country and location handling, device type, result-feature definitions, missing fields, freshness, and error behavior. If the series are not comparable, start a new baseline and mark the break instead of presenting it as an SEO movement.

    Put collection provenance into vendor review

    Two reviewers inspect a transparent data chain linking generic web collection, a vendor server, and an analytics workstation beside blank compliance documents.

    Do not ask only, “Is this legal?” That invites a sales assurance rather than a useful explanation. Ask questions that expose the collection path, rights assumptions, and continuity plan:

    1. What is the origin of each data class? Ask the provider to distinguish directly collected Google output, third-party licensed data, transformed data, estimates, and information obtained through another supplier.
    2. How does the service respond to access restrictions? You do not need instructions for evading controls. You do need to know whether the provider stops, substitutes data, reduces coverage, or changes methods when access is limited.
    3. Which fields may contain third-party licensed material? Images and real-time features deserve separate treatment from ordinary organic URLs because Google has specifically raised licensed-content allegations.
    4. What changes first under pressure? Ask whether a restriction would affect certain countries, devices, result types, request volumes, freshness levels, or historical exports before the entire service failed.
    5. How will customers be notified? Request the provider’s process for communicating collection-method changes, field removals, legal restrictions, and material coverage loss.
    6. Can you export your history and metadata? Historical values without query settings, timestamps, markets, device assumptions, and field definitions may be impossible to interpret after migration.
    7. How does the contract allocate risk? Have qualified counsel review warranties, indemnities, termination rights, notice obligations, permitted uses, and retention terms in the context of your actual implementation.

    A vendor contract cannot guarantee uninterrupted access to an external platform. It can clarify responsibility, but you still need a technical fallback. Keep those two workstreams separate: counsel assesses legal exposure, while your data and SEO teams protect continuity and measurement quality.

    Answers that should slow your decision

    • “The data is public.” This does not explain whether technical controls were bypassed or whether some fields contain licensed material.
    • “Everyone collects search results.” Industry prevalence does not tell you how this provider operates or what rights attach to each data class.
    • “Customers have never had a problem.” That does not establish a continuity plan, a notification process, or a contractual remedy.
    • “Our method is completely legal.” An unqualified conclusion is less useful than a written explanation of the access model, relevant rights, and scope of the assurance.
    • “We cannot discuss any aspect of collection.” A provider may protect proprietary details, but complete opacity prevents you from performing even basic supplier-risk review.

    If your own collection code, or a method disclosed by a supplier, appears to bypass access controls or conceal bot identity, do not expand that deployment until qualified legal counsel has assessed the actual facts. This operational checklist cannot determine whether a particular system is lawful.

    Protect AI visibility and SEO reporting without changing strategy

    The provenance question extends beyond a direct SerpApi account. Reddit has separately accused SerpApi, Perplexity, Oxylabs, and AWMProxy of participating in an indirect scraping chain involving Google results. Reddit says it planted a trap item visible only to Google’s crawler that later appeared in Perplexity results. SerpApi denies the allegations.

    That claim does not prove how every named party obtained every item. It does illustrate why data lineage matters: your dashboard may receive information through several suppliers, and the company selling you the final metric may not be the company collecting the underlying result.

    For an AI visibility, AEO, or GEO platform, document the measurement chain with the same care you would apply to a rank tracker:

    • Label whether each metric comes from a directly observed model response, a Google result, a third-party dataset, or an inferred score.
    • Retain the query or prompt, timestamp, market, device, search feature, and model or product identifier when those fields are available.
    • Require a methodology changelog so a collection change cannot quietly become an apparent visibility gain or loss.
    • Keep observed facts, such as whether a brand appeared, separate from proprietary scores or estimates.
    • Rebaseline a metric when its supplier, collection path, feature definition, or model surface changes materially.
    • Do not use Google SERP coverage as an unlabeled substitute for direct measurement of an AI system. Search visibility and model-response visibility answer different questions.

    The lawsuit itself is not evidence of a Google ranking update, a change to structured-data processing, or a new standard for earning AI citations. Do not rewrite content, remove JSON-LD, or change your internal-link strategy because litigation was filed. Change the governance around the data used to judge those activities.

    Predefine the events that will trigger action: a supplier notice, unexplained field loss, a sustained change in failure behavior, a restriction on a result type, a material pricing change, or a change in collection methodology. Then name who decides whether to continue, degrade the report, activate a fallback, or start a new measurement baseline. That prevents a technical incident from turning into an improvised legal and client-communication decision.

    Key takeaways

    • Google’s claims against SerpApi are contested allegations, not a judgment that all SERP data collection is unlawful.
    • Your immediate exposure is operational as well as legal: access, fields, prices, and historical comparability can change before the case is resolved.
    • Audit direct APIs and hidden upstream suppliers across dashboards, reports, automations, and AI visibility tools.
    • Ask how each data class was obtained, which rights apply, what degrades under restriction, and how methodology changes are disclosed.
    • Use overlapping tests and explicit baseline breaks when changing providers; otherwise a measurement change can masquerade as an SEO trend.
    • Keep your content and schema strategy tied to search performance evidence. The lawsuit calls for stronger data governance, not reactive optimization changes.

    Your next move is concrete: inventory every workflow that depends on full Google results, classify its business impact, and send the seven provenance questions to each supplier. You do not need to predict the verdict to make your measurement stack less fragile.

    References

  • Google Ads API Optimization: A Safe AI-Assisted Workflow

    You have a Google Ads performance question, but answering it means choosing fields, writing GAQL, handling authentication, and turning the result into something the team can review. AI assistance can remove much of that technical friction. It cannot decide whether broader reach, a higher bid, or a new keyword strategy makes financial sense for your business.

    The useful approach is to separate observation from action. Use the Google Ads API Developer Assistant to investigate performance through read-only queries, validate what it returns, and save repeatable analysis. Put any change to budgets, bids, targeting, or keywords through a deliberate human approval process.

    Separate faster analysis from automated optimization

    Google Ads API Developer Assistant v1.0 is a Gemini CLI extension that can translate natural-language requests into GAQL, answers, and Python code built around the google-ads-python client library. This makes it useful when you understand the business question but do not want to reconstruct every query from memory.

    The assistant can also execute read-only API calls from the terminal, display results in formatted tables, export tabular data to CSV, and place generated code in a saved_code folder. Those capabilities shorten the path from a question to an inspectable result.

    That is analysis assistance, not an optimization strategy. A table can show which campaign recorded the most conversions. It cannot determine whether those conversions were valuable, whether lead quality deteriorated, or whether the campaign consumed more budget than the outcome justified. Those judgments depend on business definitions and constraints that sit outside a generic performance query.

    Keep the boundary explicit: the assistant retrieves and organizes evidence; an accountable person decides what the evidence means and whether the account should change.

    Key takeaways

    • Begin with reporting and diagnosis. Do not treat generated output as permission to change the account.
    • Include the account scope, date range, dimensions, metrics, filters, sort order, and desired output in every request.
    • Review generated GAQL and Python as untrusted code before running or reusing it.
    • Treat Google Ads Recommendations as hypotheses to investigate, not instructions to accept.
    • Keep changes to budgets, bids, targeting, and keywords behind human approval and a defined rollback path.

    Ask questions that lead to decisions, not just reports

    A vague request such as analyze my campaigns leaves too many choices to the assistant. It does not identify the problem, the period, the level of detail, or the decision you need to make. The result may be technically valid and still be operationally useless.

    Start with the decision. If you are deciding where to investigate a conversion decline, ask for a result that isolates campaign performance over a named period and includes the metrics needed to distinguish lower volume from higher cost. If you are checking a Google recommendation, request the evidence that would support or contradict its underlying claim.

    Use this prompt pattern: Within [account or campaign scope], for [date range], return [dimensions] and [metrics]. Apply [filters], sort by [metric], and provide [GAQL, Python, a terminal table, or CSV]. Explain the row grain, field choices, and assumptions before the result.

    Each part prevents a common analytical mistake:

    • Scope prevents a manager account, client account, campaign type, or status from being included unintentionally.
    • Date range makes the comparison reproducible. Relative periods are convenient for exploration, while explicit periods are easier to audit later.
    • Dimensions determine what one row represents. Adding a date, device, or other segment can change the grain and produce many rows for a campaign.
    • Metrics determine whether you can connect activity to a business outcome. A ranking by conversions alone does not show the cost or value behind those conversions.
    • Filters remove irrelevant entities, but an overly narrow filter can hide the reason performance changed.
    • Output determines whether you get an explanation, a reusable query, executable code, or an artifact another person can inspect.

    Prompts you can adapt

    • For the previous 30 days, rank campaigns by conversions. Return the GAQL first, explain the selected fields, and then produce a read-only Python script using google-ads-python.
    • Compare campaign cost and conversion performance across two explicitly named periods. Show the row grain and flag any filter that excludes paused or removed entities.
    • Generate a read-only query that provides evidence for or against a recommendation to expand keyword matching. Separate the requested output by campaign so the account owner can review exposure and outcomes.
    • Run this approved query, display a terminal table, and export the same rows to CSV. Include the account scope and date range in the output description.

    The first example closely matches a documented use case: a request for campaigns with the most conversions in the last 30 days can produce both a GAQL query and an optimized Python script. The important addition is the review instruction. You want to see what the assistant plans to ask the API before you rely on the answer.

    Inspect five things before execution: the customer being queried, the dates, the row grain, the filters, and the metric definitions. Then look for a sanity check. Compare a small part of the result with a familiar Google Ads view or an existing trusted report. A plausible table is not proof that the query answered the question you intended to ask.

    Configure Developer Assistant v1.0 for repeatable work

    The documented prerequisites for v1.0 include a Google Ads API developer token, a configured google-ads.yaml file, Python 3.10 or later, Gemini CLI, and a local clone of the google-ads-python library. A setup script handles the library cloning step.

    Do not stop once the assistant returns its first successful table. A useful setup makes the same request behave consistently for different operators and on different days.

    1. Validate the connection with a known read-only question. Choose a result you can verify in the Google Ads interface. This separates authentication or account-scope problems from query-design problems.
    2. Define project conventions in GEMINI.md. The assistant uses GEMINI.md and configuration files as project context when tailoring code. State the expected client library, output conventions, code location, naming rules, and read-only default.
    3. Require an explanation before execution. Ask for the GAQL, selected resources, filters, dates, and row grain in plain language. A reviewer should be able to understand the intended request without reverse-engineering the code.
    4. Keep credentials out of prompts and generated files. Use the supported configuration mechanism. Review saved files before sharing them or adding them to version control.
    5. Review generated Python before running it. Check imports, customer selection, request type, file paths, exception handling, and whether the code does anything beyond retrieval and export.
    6. Preserve a verified query as a smoke test. Run it after configuration or dependency changes. If its known output or shape changes unexpectedly, investigate the environment before trusting new analyses.

    Project context is leverage. Good instructions make repeated analysis more consistent; incorrect instructions make the same mistake repeatable. Keep GEMINI.md short enough to review, specific enough to guide the assistant, and under the same change-control discipline as other project configuration.

    The saved_code folder is most valuable when it becomes a reviewed library rather than a dumping ground. Give each retained script a clear purpose, record its account scope and required inputs, and distinguish experimental output from approved reporting code. Remove ambiguity before another person schedules or modifies it.

    Turn Recommendations into an evidence-backed test queue

    Google Ads Recommendations are prompts to evaluate. They are not proof that the proposed change fits your economics. A suggestion may be informed by patterns across accounts while missing a constraint that matters in yours. For example, an account using Exact and Phrase match keywords may receive a Broad Match suggestion even when its budget or niche requires tighter control.

    The Optimization Score is easy to misread as a performance grade. It reflects how recommendations are being handled, and dismissing a recommendation can affect the score in the same way as applying it. You do not need to accept an unsuitable change merely to clear the prompt or improve the displayed score.

    Use the API assistant to build an evidence packet for each recommendation:

    1. Restate the claimed problem. Is the recommendation trying to expand reach, improve efficiency, repair setup, or remove a limitation?
    2. Request the relevant account evidence. Define the entities, period, metrics, and filters that would show whether that problem exists.
    3. Write down the business constraint. Include budget limits, acceptable lead quality, geographic restrictions, inventory realities, or other rules that the platform cannot infer reliably.
    4. Set success and failure criteria before making a change. Decide what result would justify keeping the change and what result would trigger reversal.
    5. Choose a reversible test. Limit the blast radius and preserve the prior state so the account can be restored if performance or traffic quality deteriorates.
    6. Assign an owner. One person should approve the change, monitor the agreed evidence, and decide whether to keep or roll it back.

    Auto-apply deserves stricter treatment because it can remove that review gate. The documented control path is Recommendations, All Campaigns, and Auto-Apply Settings, where you can confirm that unwanted selections are unchecked. Check the setting at the account level instead of assuming that an earlier choice still reflects current policy.

    This is a financial control, not interface housekeeping. Automatically applied suggestions can affect reach, spending, bids, or keyword behavior. Enable a category only when you have defined who owns it, what changes it permits, how the effect will be monitored, and how the prior state can be recovered.

    Do not give every interface notice the same urgency. Blue or yellow notices can represent suggestions, while red or purple notices can indicate issues such as billing errors or disapproved ads. Investigate actual delivery or account-access problems before spending time on an optional optimization prompt.

    Run one controlled loop from question to verified change

    A reliable optimization process leaves a trail from the original question to the final decision. It should be possible for another person to see what was queried, what came back, why a change was approved, and whether the expected result appeared.

    1. Name the decision. Write the question in a form that could change an action: which campaigns need investigation, whether a recommendation deserves a test, or where a recurring report shows an exception.
    2. Specify the evidence. Add account scope, dates, dimensions, metrics, filters, and output format to the prompt.
    3. Generate before executing. Read the proposed GAQL and code. Correct ambiguous fields, unintended segments, and overly broad scope.
    4. Run read-only. Display the result in the terminal and export CSV when another reviewer or a longer audit trail is needed.
    5. Validate the result. Compare a small slice with a trusted interface view or established report. Confirm that each row represents what you think it represents.
    6. Form a testable explanation. State what appears to be happening, what evidence is still missing, and which reversible change could test the explanation.
    7. Approve and implement separately. Use your normal controlled account-management process for changes. Do not turn generated analysis code into mutation code simply because the first output looked correct.
    8. Run the same query again. Reuse the reviewed query so the before-and-after comparison is based on the same scope, fields, filters, and row grain.

    Label saved queries and exports with enough context to make them interpretable later. At minimum, preserve the account scope, analysis period, purpose, and important filters alongside the artifact. A file called campaign_report.csv creates less accountability than an export tied to a specific question and approved query.

    Automate stable retrieval only after the query has survived review and repeated validation. Keep recommendations and account mutations gated. The cost of manually approving a consequential change is small compared with the cost of allowing a misunderstood prompt, broad filter, or unsuitable recommendation to alter spend without supervision.

    Start with one recurring question your team currently answers by hand. Define it precisely, run it read-only, verify the output, and retain the approved query. Once that loop is dependable, add the next question. The real efficiency gain comes from reusing trusted analysis while keeping financial decisions under human control.

    References

  • Google Ads and Shopping Changes: What to Prioritize Now

    Google Ads and Shopping Changes: What to Prioritize Now

    You’re deciding which Google changes deserve engineering time, which belong in your Shopping plan, and which are still too speculative to enter a forecast. The answer isn’t to treat every announcement, test, and rumor as equally actionable.

    The clearest opportunity is first-party data infrastructure. Local Shopping labels deserve feed preparation and controlled observation. Gemini advertising belongs on a watchlist, not in a committed media plan. That order will help you improve what is available without budgeting against a product that doesn’t exist.

    Key takeaways for advertisers

    • Prioritize the Data Manager API when separate integrations are creating duplicated work or inconsistent first-party data flows.
    • Treat merchant city and town labels in Shopping ads as an observed test. Prepare accurate local inventory data, but don’t forecast an uplift or assume every eligible impression will show the label.
    • Keep Gemini separate from AI Mode in your planning. Google’s stated position is that the Gemini app has no ads and there are no plans to add them.
    • Classify every platform change as available, experimental, or unconfirmed before assigning budget, engineering effort, or performance targets.

    First-party data deserves the engineering time

    Illuminated data pathways connect customer touchpoints to a protected central data hub and several activation modules.

    Google’s Data Manager API is the most concrete change because it solves an operational problem you may already have: audience data, offline conversions, and other first-party signals reaching Google through separate connections. The API is designed to provide one integration point across Google Ads, Google Analytics, and Display & Video 360.

    That consolidation matters when your team maintains one job for customer lists, another for offline conversion uploads, and additional platform-specific logic for authentication, retries, or refreshes. A shared route can reduce that maintenance burden. It can also make ownership clearer when a data flow fails.

    The API supports three jobs that directly affect campaign operations: uploading and refreshing audience lists, sending offline conversions, and supplying richer signals for bidding. Those capabilities don’t guarantee better performance. They give Google’s automated systems more useful inputs, and you still need to verify whether those inputs change measurement or campaign outcomes in your account.

    Use a bounded migration sequence rather than moving every data flow at once:

    1. Inventory the current routes. Record which process sends each audience or conversion type, how often it runs, who owns it, and what happens when records fail.
    2. Choose one well-understood flow. Start with an audience list or offline conversion type whose current volume, update pattern, and business meaning are already known. A familiar baseline makes discrepancies easier to find.
    3. Define the data contract before building the endpoint. Agree on identifiers, event names, time fields, refresh frequency, correction handling, and ownership. A unified API won’t reconcile two teams using different meanings for the same conversion.
    4. Validate the new and existing routes side by side. Compare submitted, accepted, rejected, and delayed records where those measures are available. Do not send the same event through both routes unless you have verified how duplicates are prevented.
    5. Check reporting before changing bidding. Confirm that conversion totals, audience freshness, and processing delays behave as expected. Only then should you evaluate whether richer signals help automated bidding.
    6. Retire an old connection only after reconciliation. Keep a rollback path until the new route has completed its normal refresh and correction cycles without unexplained gaps.

    This sequence protects the part of the account with financial consequences: measurement. If an integration drops conversions, submits duplicates, or changes event meaning, bidding can optimize against a distorted picture. Parallel validation is less expensive than discovering the problem after an automated campaign has reacted to it.

    The strongest adoption case is a team already maintaining several Google connections. If you have one stable data flow and little engineering overhead, consolidation may be less urgent. Start with the operational cost you can document, not the assumption that a new API automatically creates incremental revenue.

    Local Shopping labels make feed accuracy visible

    A retail employee scans a product beside organized shelves, a tablet, a stockroom, and a local pickup counter.

    Some Shopping ads using local inventory data have displayed the merchant’s city or town above the product title. The placement gives shoppers a proximity cue without requiring a separate local ad format. It is distinct from fulfillment labels such as In-store, Pickup later, and Curbside pickup.

    That distinction is important. A city label tells the shopper where the merchant is located. By itself, it doesn’t promise immediate availability, same-day collection, or a particular fulfillment method. Your inventory and pickup information still need to carry those meanings accurately.

    Google has not published rollout, eligibility, or technical requirements for the location-label test. You therefore shouldn’t look for an undocumented switch, promise the placement to stores, or build a performance forecast around it. The practical move is to make the local inventory setup reliable enough to benefit if the label appears.

    • Check store and product coverage. Confirm that the intended locations and locally available products are present in the systems supplying your local inventory data.
    • Standardize location names. Resolve inconsistent city or town naming across store records before those differences become visible to shoppers or fragment your analysis.
    • Audit location and fulfillment separately. A correct city label cannot compensate for stale availability or pickup information, and a pickup label does not confirm that the displayed city is the location you intended to promote.
    • Record observed appearances. When your team sees the label, capture the market, store, query context, device, and date. That record will help you distinguish a limited test from a broader change.
    • Measure at the local level. Compare results by store or market where activity is sufficient, rather than blending exposed and unexposed locations into an account-wide average.

    A recognizable or nearby location could make a merchant feel more relevant than a distant seller. That is a plausible shopper response, not a guaranteed click-through or store-visit lift. Let observed exposure and local results establish the value before you change budgets.

    Gemini advertising is not a 2026 media plan

    Claims that the Gemini app would receive dedicated ad placements in 2026 prompted a direct denial from Google. Its stated position was that there are no ads in the Gemini app and no plans to change that.

    That doesn’t settle how every Google AI experience will be monetized indefinitely. It does settle what belongs in a responsible plan based on the information available: no Gemini inventory, targeting assumptions, pricing model, creative specification, eligibility rule, or measurement framework should appear as a committed line item.

    Keep Gemini and AI Mode in separate rows of your channel plan. Ads associated with AI Mode do not prove that the Gemini app will use the same inventory or commercial model. Product names, interfaces, and user behavior may look related while their advertising availability remains different.

    A useful planning boundary is simple:

    • Available inventory can receive budget when your account is eligible and its economics fit the campaign.
    • An observed test can receive monitoring, data preparation, and a measurement plan, but not assumed reach or revenue.
    • A denied or unconfirmed product stays on a watchlist until Google supplies an official product path, eligibility details, and reporting expectations.

    You can still prepare strategically. Decide which customer questions, product attributes, and conversion events would matter in a conversational ad environment. Do not assume, however, that current Google Ads audiences, Shopping feeds, or Data Manager integrations will automatically transfer to a future Gemini product. No documented product connection supports that implementation decision.

    Use one evidence rule for every platform change

    The three developments require different actions because their evidence states are different. Put them in a change register that your paid media, ecommerce, analytics, and engineering teams can read without translating headlines into strategy on their own.

    Platform changeDocumented statusAction nowDo not assume
    Data Manager APIAvailable across Google Ads, Google Analytics, and Display & Video 360Pilot one audience or offline conversion flow and reconcile it before consolidationThat a new connection fixes weak data or guarantees a performance gain
    Shopping merchant location labelObserved test using local inventory data; rollout and requirements are unannouncedAudit local feeds, standardize locations, and prepare store-level measurementUniversal exposure, a configuration switch, or an automatic traffic lift
    Gemini app adsGoogle denied that ads are present or plannedKeep the possibility on a monitored watchlist2026 inventory, pricing, formats, targeting, or compatibility with AI Mode

    For each entry, record the affected surface, evidence status, business dependency, owner, next action, and condition that would justify changing the status. An official availability notice could move a test into implementation. Repeated sightings without documentation may justify broader measurement, but not a guaranteed forecast. A rumor should not advance because it has been repeated.

    Start with the first-party data inventory because it can improve infrastructure you already use. Then audit local feeds so your stores are ready for location-led Shopping presentation. Remove Gemini placements from committed projections unless Google replaces its denial with a real product announcement. That gives you a plan based on executable changes rather than imagined inventory.

    References

  • A Practical Playbook for Google’s Ads Measurement Changes

    A Practical Playbook for Google’s Ads Measurement Changes

    Your Google advertising stack can collect more data and still produce weaker decisions. That is the risk when lifecycle audiences, automated campaign reporting, and developer support are treated as unrelated features owned by different teams.

    You need one operating loop that connects customer qualification, media delivery, business outcomes, and incident response. The goal is not merely to enable Google’s new options. It is to know what the data means, which decision it supports, and how you will recover when the pipeline fails.

    Key takeaways

    • Define what makes a customer valuable or disengaged before building the Google Analytics audience. A template can apply your rule, but it cannot choose the right commercial rule for you.
    • Validate ecommerce events and audience inputs before increasing spend. Faulty purchase data can distort audience membership, dynamic remarketing, and campaign evaluation at the same time.
    • Use the new Performance Max Search Partners segment as a diagnostic view. Separate reporting shows where activity occurred; it does not, by itself, prove that the activity caused incremental revenue.
    • Evaluate high-value acquisition and customer re-engagement separately. They target different behaviors and should not be judged through one blended campaign average.
    • Replace informal forum troubleshooting with a documented support packet containing identifiers, logs, reproduction steps, expected behavior, and exact errors.

    Define customer value before Google Analytics does the grouping

    A strategist organizes anonymous customer tokens by engagement and value before they enter an automated grouping system.

    Google Analytics now provides suggested audiences for High-Value Purchasers and Disengaged Purchasers. The first can use purchase count or lifetime value, including an LTV percentile field. The second uses the number of days since a customer’s last purchase.

    Those templates remove configuration work, but they do not settle the important business questions. A frequent buyer is not necessarily a profitable buyer. A customer who has not purchased recently is not necessarily disengaged if the normal buying cycle is long. If you accept a convenient threshold without examining the underlying behavior, Google can execute the wrong definition very efficiently.

    Build each audience in this order:

    1. Choose the business behavior you want to influence. For high-value acquisition, decide whether repeat purchasing, lifetime value, or both represent the customers you want more of. For re-engagement, define inactivity relative to the normal interval between purchases.
    2. Check whether Analytics receives the events and values needed to enforce that definition. Reconcile recorded purchases and values with your commerce records before trusting the resulting audience.
    3. Inspect audience membership for obvious mismatches. If customers enter too early, remain too long, or qualify after low-value behavior, revise the definition before activation.
    4. Separate acquisition from re-engagement. One goal seeks new people who resemble valuable customers; the other seeks another purchase from someone who already has a relationship with the business.
    5. Write down the success condition before launching. High-value acquisition should ultimately be assessed against the quality of newly acquired customers. Re-engagement should be assessed against recovered purchasing behavior, not merely ad clicks or return visits.

    This order matters because an audience is both a targeting asset and a measurement claim. Calling someone a high-value customer asserts that your data captures value correctly. Calling someone disengaged asserts that enough time has passed to make intervention appropriate. Review those assertions whenever pricing, product mix, subscription behavior, or the normal repurchase cycle changes.

    Dynamic remarketing still depends on clean inputs

    Google is also moving display dynamic remarketing into Analytics. With Google’s recommended ecommerce event collection in place, Analytics can share the relevant data with a linked Google Ads account when personalized advertising is enabled. That allows product-based ads to be shown to previous site visitors without constructing the entire remarketing setup elsewhere.

    There are two gates to check before treating this as operational. The technical gate is whether ecommerce events and product information arrive consistently and map to what you actually sell. The governance gate is whether personalized advertising is intentionally enabled under your organization’s consent and data-use rules. A linked account is not proof that either gate is healthy.

    Run a test path through a real product interaction and purchase flow. Confirm that the expected ecommerce events appear, their values are credible, and the linked Ads account receives the intended data. If audience counts or remarketing behavior change unexpectedly, investigate collection first. Raising a budget while the qualifying data is unreliable can turn a tracking defect into wasted ad spend.

    Read the PMax Search Partners row without overreading it

    Performance Max channel reporting now breaks out Search Partners in its channel performance tables. You can see how that inventory contributes to overall results, compare it with other PMax channels, and identify the spend associated with it.

    This closes a visibility gap, but visibility is not the same as control or causality. A separately reported channel can appear efficient because of the customers it reaches, the conversions credited to it, or its role in a longer journey. The row tells you where activity was reported. It does not automatically tell you what would have happened without that activity.

    Use a three-stage reading sequence:

    1. Start with allocation. Determine whether Search Partners spend is material enough to affect the campaign-level result and whether its direction changed alongside the overall campaign.
    2. Move to outcomes. Compare the segment with the business result the campaign is meant to produce, such as qualified leads, purchase value, or repeat revenue. Traffic volume alone cannot establish value.
    3. Test the incremental claim. Ask whether the activity appears to add outcomes or merely receives credit for demand that another channel might have captured. Where the financial consequence is meaningful, use an appropriate experiment or a carefully designed analysis rather than declaring incrementality from the reporting row.

    Keep a change log beside this analysis. Record material adjustments to budgets, conversion definitions, assets, feeds, audience signals, and campaign goals. Otherwise, a shift in the Search Partners row can be mistaken for an inventory effect when the campaign’s inputs changed at the same time.

    Also resist ranking every PMax channel from best to worst using one blended efficiency figure. Channels can play different roles in discovery, consideration, and conversion. The useful question is whether the newly visible activity supports the campaign’s intended economic outcome at an acceptable cost, not whether its row wins an internal leaderboard.

    When the data is weak or mixed, preserve the uncertainty. A report that exposes previously hidden spending gives you a better investigation target, not an obligation to make an immediate budget change. Changing bids or budgets on inconclusive evidence can cost money; waiting for a decision-grade pattern is the safer action.

    Replace forum memory with an incident-ready support process

    Two technical specialists document a broken data pipeline and assemble diagnostic evidence for a structured support handoff.

    Google set January 28, 2026 as the cutoff for support-agent replies to new posts in three advertising developer forums. Existing discussions were retained as reference material, while replies to existing threads would move into a new email conversation with support. Your operating process should no longer depend on receiving an answer through a new Google Groups post.

    The replacement paths are product-specific, and the evidence expected from you is more structured:

    ProductSupport routeDiagnostic material to prepare
    Google Ads APIOfficial Google Ads API supportRequest ID plus complete request and response logs
    Google Ads ScriptsOfficial Ads Scripts supportScript name, customer ID, execution logs, and UI error messages
    Campaign Manager 360 APICampaign Manager 360 support teamProfile or account IDs, API method, and request and response logs

    Every ticket should also contain a plain description of the failure, the expected behavior, exact reproduction steps, relevant code, and the complete error message. Prepare that structure before an incident. During a bidding, reporting, or automation outage, the slowest part is often reconstructing what happened across scattered logs and messages.

    A reusable incident packet should contain:

    • A short statement of what failed and which business process is affected.
    • The affected product, account, profile, customer, script, or API operation.
    • The expected result and the actual result.
    • Steps that reliably reproduce the behavior, including the smallest relevant code sample.
    • Request and response evidence, execution logs, interface errors, and the exact error text.
    • A record of recent deployments or configuration changes that could be related.
    • The internal owner who can answer follow-up questions and verify a proposed resolution.

    Keep sensitive logs in an access-controlled location, and remove credentials or tokens before sharing material. Support needs diagnostic context, not access secrets.

    The public forums also served as a searchable memory of unusual failures. Direct support conversations will not recreate that shared knowledge automatically. Preserve the solutions your team repeatedly needs in an internal runbook: the symptom, affected system, confirmed cause, resolution, and any condition that would make the fix unsafe to reuse.

    Google’s Advertising and Measurement Community Discord remains available for general discussion, but it is not an official support channel. Use community conversation to discover terminology, similar symptoms, and possible lines of investigation. Use the official route for account-specific diagnosis, tracking, and resolution.

    Run one control loop across audiences, delivery, and support

    The three changes become useful when they are reviewed as one system. Analytics determines who qualifies for activation. Google Ads determines where automated campaigns deliver and attributes results. APIs and scripts move data or automate decisions between systems. Support becomes the recovery path when any connection breaks.

    Use this sequence during account reviews:

    1. Verify input health. Check purchase events, values, product information, and the fields used to classify high-value or disengaged purchasers.
    2. Verify activation. Confirm that the intended Analytics audiences are available to the correct linked Google Ads account and that personalized advertising is deliberately enabled where dynamic remarketing is required.
    3. Inspect delivery. Use PMax channel reporting to see whether Search Partners activity or spend has changed enough to investigate.
    4. Judge business outcomes. Separate customer acquisition from re-engagement and assess each against the behavior it was designed to change.
    5. Record the decision. Note whether you changed an audience rule, campaign input, budget, or measurement definition, and state what evidence would cause you to revisit it.
    6. Test recoverability. Make sure the owner can produce the correct support packet without searching across several disconnected systems during an outage.

    This sequence prevents several common misdiagnoses. If a lifecycle audience suddenly shrinks, validate collection before blaming demand. If Search Partners spend changes, examine business outcomes and concurrent campaign changes before reallocating money. If an automated report fails, preserve request IDs and logs before rerunning or modifying the job in ways that erase the original evidence.

    Start with one account. Audit its lifecycle definitions, locate Search Partners in the PMax channel table, and assemble a complete support packet for one critical integration. Once that path works from data collection through incident recovery, turn it into the standard your other accounts must meet.

    References

  • Marketing Is Becoming AI Systems Engineering: What to Build

    Marketing Is Becoming AI Systems Engineering: What to Build

    Your team can use AI to produce campaigns, briefs and content faster. That does not automatically make the operation faster. If reviewers cannot trace a claim, teams keep correcting the same errors, or nobody knows which instruction produced an output, the saved production time simply moves into review and repair.

    This is not mainly a prompting problem. It is a systems problem. As marketing moves toward engineering and AI-shaped roles, the practical advantage comes from designing reliable inputs, decision rules, interfaces, controls and feedback loops. You do not need to turn every marketer into a software engineer. You do need to make the marketing operation understandable enough to test, govern and improve.

    Production is no longer the only bottleneck

    A conventional campaign workflow is often organized around deliverables. A strategist writes a brief, a creator makes an asset, a reviewer approves it, an operator publishes it and an analyst reports on it. The handoffs may be inefficient, but each person can usually explain what they did.

    AI changes that structure. A model may summarize research, infer an audience, select supporting facts, generate variants, assign metadata and recommend distribution. What looks like a single content-generation step can contain several hidden decisions. When those decisions are not explicit, a fluent output can conceal a weak premise, an outdated input or an unsupported claim.

    The unit of management therefore has to change from the asset to the decision pipeline. For every AI-assisted workflow, you should be able to answer:

    • What business decision or customer action is this workflow meant to support?
    • Which information is allowed to influence the output?
    • Which decisions are fixed rules, and which are left to a model?
    • What must be true before the output can move to the next stage?
    • Who owns the result when several tools and teams contributed to it?
    • What signal will cause the system to stop, fall back or be revised?

    This distinction also prevents needless use of generative AI. A product name stored in an approved catalog should be retrieved exactly, not recreated from a prompt. A required JSON field should be validated by software, not judged by whether its formatting looks plausible. Generative models are useful where interpretation or variation is valuable. Deterministic rules are better where the correct result is already known.

    A quick diagnostic is to pick a live campaign and trace one customer-facing claim backward. If you cannot identify its approved origin, the transformation that produced it, the validation it passed and the person accountable for releasing it, you have found a system gap. Rewriting the prompt may hide that gap for a while, but it will not close it.

    Map the marketing operating system before buying more tools

    An isometric marketing workflow connects source materials, planning, AI creation, human review, distribution and feedback while isolated tool modules sit at the edge.

    Tool selection is easier after the workflow is visible. Start at the point where an objective is accepted, not where somebody opens an AI interface. End where performance evidence changes a later decision, not where an asset is published. That wider boundary exposes missing inputs, duplicated approvals and feedback that reaches a dashboard but never reaches the system.

    The layers every workflow needs

    LayerDecision to makeWorking artifactFailure signal
    IntentWhat outcome and audience are in scope?Workflow brief with acceptance criteriaOutput is polished but unrelated to the business decision
    KnowledgeWhich facts, policies and examples are approved?Source registry with owners and review conditionsClaims cannot be traced or conflict across outputs
    LogicWhich rules, model calls and exceptions transform the inputs?Decision map and versioned instructionsSimilar inputs follow inconsistent paths
    DeliveryWhere may the result be written, published or activated?Channel specification and permission policyContent reaches the wrong destination or bypasses review
    QualityWhat must pass before the next action?Evaluation cases, validators and approval policyReviewers repeatedly catch the same preventable defect
    FeedbackWhich outcome should change the next decision?Monitoring view and change logPerformance is reported but workflow behavior does not improve

    The knowledge layer deserves particular attention. A source of truth does not have to be one enormous document. It means that each important fact has an authoritative home, a responsible owner and a clear way to resolve conflicts. Product specifications may belong in a catalog, brand language in a controlled library and legal restrictions in an approval policy. Copying all of them into an unowned prompt creates another version that can drift.

    Next, mark each decision as deterministic, probabilistic or human. Eligibility rules, required fields, naming conventions and permission checks are usually candidates for deterministic handling. Drafting, clustering and interpreting ambiguous language may need probabilistic handling. Decisions involving strategic tradeoffs, sensitive claims or material consequences should retain accountable human judgment.

    Then make the interfaces explicit. An input contract should state which fields are required, what format they use, where their values come from and what happens when information is missing. An output contract should define the expected structure, permitted destinations, prohibited content and validation requirements. A JSON schema, a CMS field definition or a structured brief can all serve as a contract. The point is to make failure visible instead of allowing each stage to guess what the previous stage meant.

    Control AI with contracts, evaluations and observability

    A transparent AI workflow passes content through an input gate, sensor-filled inspection chamber and human-supervised release gate, with source trails and a repair loop.

    A prompt is configuration, not a complete control system. It can express the desired behavior, but it does not prove that the right input arrived, that the output is grounded, or that the next tool used the result safely. Reliable workflows place controls around the model rather than expecting the model to control itself.

    Test behavior before granting action

    Build an evaluation set from the situations the workflow must handle. Include routine requests, ambiguous instructions, missing fields, stale or conflicting information, prohibited claims and inputs that should trigger escalation. The expected result does not need to prescribe exact wording. It can define pass-or-fail conditions such as using an approved fact, preserving a required field, refusing an unsupported request or routing an exception to a reviewer.

    Evaluate separate qualities separately. Structural validity, factual grounding, audience relevance, brand compliance and channel suitability are different questions. A single quality score makes diagnosis difficult: the score can improve while a business-critical failure remains hidden. Record the failure category so the team knows whether to repair the knowledge, rule, prompt, integration or approval step.

    An AI-based evaluator can help triage outputs, but it is not independent proof. When similar model behavior produces and judges an answer, the same blind spot can affect both stages. Use deterministic validation wherever the requirement can be expressed as a rule, compare factual claims with approved information, and preserve human review for consequences that cannot be reduced to formatting checks.

    Log enough context to reconstruct a failure

    Useful observability lets you connect an outcome to the state of the system that produced it. For each run, retain the input reference, knowledge version, workflow or prompt version, model or service used, validation result, approval state and destination. Protect those records according to the sensitivity of the data they contain. A performance dashboard alone is not observability if it cannot show which system change preceded a failure.

    Define stop and fallback behavior before activation. If a required input is absent, the workflow can request it rather than inventing it. If a validator fails, the output can remain a draft. If a service is unavailable, the workflow can route work to a manual queue instead of silently skipping a control. Every automated action should also have a named owner who can pause it and a recovery path appropriate to the change it makes.

    Match autonomy to consequence:

    • For reversible internal suggestions, review samples and monitor recurring failure types.
    • For customer-facing content, require validation against approved facts and a clear publication policy.
    • For audience selection, material budget changes or actions that alter customer records, keep permissions narrow and require accountable approval before execution.
    • For workflows involving personal data, regulated claims, contractual promises or legal obligations, involve the appropriate privacy, legal, compliance or financial owner before activation. A technically valid output can still create exposure.
    • For destructive or difficult-to-reverse actions, use a staging environment, explicit confirmation and a tested rollback path rather than direct autonomous access.

    Do not expand a workflow’s permissions because a handful of outputs looked good. Expand them only after the system handles ordinary inputs, edge cases and failures in a way the responsible owner can inspect and accept.

    Redesign roles around system ownership, not prompt writing

    The engineering shift does not require renaming every marketer as a developer. It requires assigning responsibilities that campaign-oriented teams often leave implicit. A small team may combine several responsibilities in the same person, but each responsibility still needs an identifiable owner.

    • System owner: defines the workflow’s purpose, acceptable behavior, boundaries and business outcome. This person decides when the system should change or stop.
    • Knowledge owner: maintains approved facts, policies, examples and review conditions. This person resolves conflicts instead of allowing the model to choose between competing versions.
    • Workflow builder: connects tools, expresses rules, manages permissions and designs fallback behavior. This may be a marketing operations, automation or engineering responsibility.
    • Evaluator: creates test cases, classifies failures and checks whether changes improve the intended behavior without breaking another requirement.
    • Operator or analyst: monitors live performance, investigates anomalies and turns business feedback into proposed system changes.

    The handoff between these responsibilities matters more than the job titles. Before launch, everyone should know who can change an instruction, who can approve a new knowledge source, who reviews exceptions, who can grant write access and who can stop the workflow. If those answers live only in informal conversations, the operation will become harder to govern as automation spreads.

    Measure reliability as well as output

    Asset volume becomes less informative when generation is inexpensive. Track whether the system produces usable work and supports the intended business decision. Depending on the workflow, useful operating measures may include first-pass acceptance, rework by failure category, unsupported-claim incidents, manual intervention, recovery time and cost per approved result. Pair them with the actual marketing outcome; a technically stable pipeline that does not improve customer or business behavior is still the wrong system.

    This also changes career development. If you are an individual contributor, learn to map a process, write acceptance criteria, structure information, inspect a run log and design a useful edge case. If you manage or hire people, test whether they can diagnose a broken workflow. Give them a scenario with conflicting inputs, an invalid output and an unclear owner. Ask what they would inspect first, which control they would add and how they would know the repair worked. That reveals more than asking for a favorite prompt.

    Key takeaways and a safe place to start

    • AI-driven marketing systems engineering means designing the full decision pipeline, not merely adding generation to an existing task.
    • Use deterministic rules for known requirements and probabilistic models where interpretation or variation creates value.
    • Give every important fact an approved home and owner before placing it inside an automated workflow.
    • Define input and output contracts so missing data, invalid structure and prohibited actions fail visibly.
    • Evaluate edge cases, log system versions and set stop conditions before granting a workflow permission to act.
    • Assign ownership for the system, knowledge, implementation, evaluation and live operation even when one person holds several responsibilities.

    Begin with a workflow that is frequent enough to observe, bounded enough to map and reversible enough to recover. Drafting a brief from approved material or classifying incoming requests is easier to contain than a workflow that publishes claims, changes spend and updates customer data in the same run.

    1. Draw the current workflow from accepted objective to feedback, including manual copying, approvals and exception handling.
    2. Choose one recurring failure or delay. Do not redesign every stage at once.
    3. Name the approved inputs and their owners, then write the input and output contracts.
    4. Create evaluation cases for normal, ambiguous, missing, conflicting and prohibited inputs.
    5. Run the AI-assisted version in shadow mode: let it produce recommendations or drafts without publishing, spending or changing records.
    6. Compare its behavior with the acceptance criteria and classify every meaningful failure by cause.
    7. Grant only the permissions needed for the next bounded action, with monitoring, an approval rule and a recovery path.
    8. Version every material change and rerun the evaluation set before promoting it into the live workflow.

    At your next planning session, bring a workflow map instead of a list of AI tools. Pick the decision that causes the most repeated repair, make its inputs and rules explicit, and build the controls around it. That is where AI stops being an isolated productivity feature and becomes dependable marketing infrastructure.

    References