CrushPress.AI

Category: Google Shopping

  • Google Commerce and Checkout Updates: A Merchant Playbook

    Google Commerce and Checkout Updates: A Merchant Playbook

    If your commerce strategy ends when a shopper clicks through to a product page, Google’s transaction layer creates a new gap. Products may now be discovered, evaluated and purchased within a Google experience, but only when your catalog data, payment processing and offer terms can support the same transaction.

    Your immediate decision isn’t simply whether to adopt AI shopping. You need to determine which offers are eligible, whether Merchant Center can express them accurately, whether your processor can complete the payment and whether the customer sees consistent terms from discovery through purchase.

    Google is turning some discovery journeys into checkout journeys

    Google’s Universal Commerce Protocol, or UCP, supports a native Buy button that can keep checkout on Google while the merchant remains the seller of record. The transaction can use credentials stored in Google Wallet, and the payment processor must support Google Pay tokens. Merchants implement the associated Merchant Center signal through the native_commerce attribute.

    This changes what commerce readiness means. In a conventional search journey, Google primarily needs enough reliable information to match a product with a query and send the shopper to the merchant. In a native checkout journey, the offer must also be executable. A discoverable product with an unsupported payment path, incomplete transaction data or conflicting terms isn’t transaction-ready.

    That distinction matters for SEO, AEO and GEO teams. Product schema and clear page content can help systems understand an offer, but they don’t replace a required Merchant Center attribute or payment integration. Treat page markup, catalog feeds and transaction infrastructure as connected layers with different jobs.

    A shorter path to payment may reduce friction in experiences such as Gemini and AI Mode, but conversion improvement is a possibility, not a guaranteed result. Merchant eligibility, offer quality, payment reliability and customer confidence still determine whether the shorter journey performs better.

    Separate transaction readiness from policy eligibility

    Generic products pass through separate compliance and transaction checkpoints before converging on a completed order package.

    Google’s broader checkout capability and its recurring prescription billing expansion affect different parts of the commerce stack. UCP is a transaction mechanism. The pharmacy change is a category-specific policy expansion for certified online pharmacies in the United States. Combining them into one implementation project can hide the gate that is actually blocking an offer.

    Commerce changeWhen it mattersRequired elementsWhat it changes
    UCP-powered checkoutWhen a merchant is preparing an on-Google purchase flownative_commerce in Merchant Center and a processor that supports Google Pay tokensThe shopper can use stored Google Wallet credentials while the merchant remains the seller of record
    Recurring prescription billingWhen a certified U.S. online pharmacy promotes an eligible subscription, bundle or consultationMerchant certification, an accurate subscription_cost value, transparent landing-page terms and fees, and continued Healthcare & Medicine policy complianceEligible prescription offers can use recurring billing, subject to Google’s category requirements

    For certified U.S. online pharmacies, the expanded policy covers recurring prescription purchases, qualifying bundles and recurring prescription-eligibility consultations. A bundle may combine medication with services such as coaching or a treatment program, but the medication must remain the primary product. A consultation may be offered on its own or alongside medication when its purpose is to assess prescription eligibility.

    The expansion doesn’t remove the existing certification or Healthcare & Medicine requirements. It also doesn’t turn an eligibility assessment into guaranteed access to a prescription. Describe the consultation as an assessment, make the recurring arrangement explicit and ensure the promoted offer matches what the customer can actually purchase.

    This gives you two independent questions to answer. First, is the offer allowed? Second, can your systems execute it through the intended Google experience? A policy-approved offer can still fail the technical test, while a technically complete transaction can still be ineligible for promotion.

    Build the commerce stack in the right order

    A layered digital commerce stack links catalog objects, account controls, payment processing, order management, and customer offers.

    Don’t begin by adding an attribute across the catalog. Start with one clearly defined offer and trace it from Merchant Center to the confirmed order. That limits the number of variables when something doesn’t match.

    1. Define the offer as a customer would understand it. Record the product being purchased, whether billing recurs, what the subscription costs, what a bundle contains, which item is primary, and which terms or fees apply. If the team cannot describe the offer consistently in one internal record, the feed and landing page are unlikely to agree.
    2. Create an offer-level eligibility matrix. Use one row per offer, not one row per business. Track the applicable market, certification status, policy eligibility, required Merchant Center attribute, processor status, landing-page match and review status. This prevents approval for one product from being treated as approval for an entire catalog.
    3. Confirm the payment path before activating native commerce. Ask the payment team or processor to verify support for Google Pay tokens in the intended flow. General support for a familiar wallet experience isn’t specific enough; the requirement concerns the tokens used to execute the UCP-powered transaction.
    4. Submit only the attributes that apply. Use native_commerce for the UCP checkout implementation. For an eligible recurring prescription offer, submit the subscription cost accurately through subscription_cost. Don’t copy a recurring-billing value to one-time products or enable a transaction signal before its corresponding payment path is ready.
    5. Make the landing page agree with the feed. A shopper should see the same product, recurring cost, bundle composition, fees and material terms represented in Merchant Center. For pharmacy bundles, the page must also make it clear that medication is the primary product rather than presenting the service as the main purchase.
    6. Test the seller-of-record handoff. Google may host the checkout interface, but the merchant retains the seller-of-record role. Confirm that your order system receives what it needs to identify, fulfill and support the purchase. A successful payment that produces an incomplete or unusable order isn’t a successful implementation.
    7. Reconcile measurement across systems. Establish a baseline for checkout starts, completed payments, failed payments and confirmed orders before rollout. Because an on-Google checkout can remove parts of the usual website journey, pageview-only reporting may not describe the full funnel. Reconcile Merchant Center activity, processor outcomes and order records instead of relying on a single web session.
    8. Request a review only after correcting the underlying issue. A previously disapproved pharmacy account can seek another review once it meets the expanded requirements. Preserve the corrected feed values, visible landing-page terms, certification status and payment confirmation so the team can verify that the reviewed configuration is the one actually in production.

    This sequence also clarifies ownership. SEO and content teams can define the offer and maintain page clarity. Feed specialists can implement Merchant Center attributes. Payments teams can validate token support. Compliance teams can determine whether a regulated offer is eligible. Analytics and commerce operations can verify that a paid transaction becomes a usable order. No single discipline can safely infer that the other layers are ready.

    Offer consistency is now part of transaction architecture

    Merchants often treat feed discrepancies as catalog housekeeping. Native checkout raises the consequence. Google isn’t only using the offer to decide whether and where it should appear; the offer data can help shape a transaction. A mismatch can therefore affect customer understanding, policy eligibility or the ability to complete the purchase.

    • The page describes recurring billing, but the subscription cost is missing or inaccurate. Correct the Merchant Center value and verify it against the live offer before requesting review.
    • The feed contains a native-commerce signal, but processor support hasn’t been confirmed. Hold activation until the payment path can accept the required Google Pay tokens.
    • A prescription bundle visually leads with coaching or a treatment program. Rework the offer so the medication is unmistakably the primary product, as the category policy requires.
    • A consultation is presented as if it guarantees medication. State its actual role: assessing prescription eligibility. Keep the assessment distinct from the outcome.
    • Terms or fees are technically present but difficult to find. Put them where the customer can understand the recurring commitment before proceeding. Mere presence isn’t the same as transparency.
    • A prior disapproval is treated as permanent. If a certified U.S. pharmacy now meets the expanded requirements, correct the offer and account configuration, then use the available review process.

    For regulated health offers, this isn’t only a conversion concern. Ambiguous billing, unclear eligibility language or a service-led bundle can misrepresent what a patient is buying. Keep medical and policy review in the launch path, and don’t use optimization work to soften or obscure a condition that determines access, cost or recurring payment.

    The same consistency principle applies outside healthcare. Use one governed offer record as the reference for feed data, landing-page copy, checkout configuration and internal review. When a price, fee, bundle or term changes, update each layer as one release rather than as separate content and engineering tasks.

    Key takeaways

    • UCP can place a native Buy action on Google, but the merchant remains the seller of record.
    • Merchant Center’s native_commerce attribute and processor support for Google Pay tokens solve different parts of the same checkout flow.
    • Certified U.S. online pharmacies can promote qualifying recurring prescriptions, bundles and consultations when they meet the expanded requirements.
    • Eligible pharmacy offers need accurate subscription_cost data, transparent terms and fees, continued certification, and compliance with existing Healthcare & Medicine policies.
    • Schema and page optimization support offer understanding; they don’t substitute for Merchant Center configuration, payment readiness or policy approval.
    • Measure confirmed orders and payment outcomes across systems because an on-Google transaction may not follow the website funnel your current reports expect.

    Choose one eligible offer and run it through the matrix before expanding the rollout. If its policy status, Merchant Center data, landing page, processor response and confirmed order all agree, you have a repeatable commerce path. If they don’t, the failed checkpoint tells you exactly which team should fix the next problem.

    References

  • Google Merchant API Migration: A No-Surprises Checklist

    Google Merchant API Migration: A No-Surprises Checklist

    If your Shopping or Performance Max campaigns rely on an API-fed catalog, the Merchant API migration is a delivery dependency, not routine backend maintenance. Letting a legacy Content API connection reach its cutoff can interrupt campaigns that depend on its product feed.

    The dangerous version of this failure is not always an obvious API error. Products may arrive through the new connection while feed labels, campaign structure, or bidding logic no longer match. Your migration is complete only when the new API writes the right product data and the campaigns consuming that data still behave as intended.

    Confirm whether your account is exposed

    Start in Merchant Center Next. Open Settings > Data sources and inspect the type shown for every product source. Any source marked Content API belongs in your migration inventory. Do not assume that an ecommerce app, scheduled file, or newer integration elsewhere in the account means the legacy connection has already been replaced.

    For each Content API source, record:

    • The Merchant Center account and data source name.
    • The application, connector, platform, or custom code that writes the product data.
    • The person or provider able to change and deploy that integration.
    • How updates are triggered, including scheduled jobs and manual runs.
    • The Shopping and Performance Max campaigns that consume the products.
    • Every feed label associated with the source and what that label controls.
    • The evidence you will require before declaring the migration complete.

    If a third-party platform manages the connection, ask for more than a general confirmation that it supports Merchant API. You need four explicit answers: which connection will be replaced, when the change will reach your account, whether feed labels will be recreated or mapped, and whether you must reconnect anything inside Merchant Center Next. The provider may own the deployment, but you still own campaign validation.

    The transition began in mid-2024, and the communicated migration path cited February 28 for beta participants and August 18 for other Content API users. Those month-and-day references are not safe planning dates without the applicable year and account context. Use the dated notice attached to your own account as the operative cutoff. If nobody can produce that notice, treat the connection as an active risk rather than assuming you have more time.

    Preserve feed labels before moving product data

    Generic retail products with colored geometric tags cross a bridge between two database structures with their tags still attached.

    Feed labels can be part of your campaign architecture. They may separate inventory or support bidding decisions, yet they do not transfer seamlessly during this migration. That creates a misleading success state: the new connection works, products appear, and the technical ticket closes, but a label-dependent campaign no longer addresses the same inventory.

    Build a label map before changing the connection. For each existing label, capture:

    • The exact current value, including spelling and capitalization.
    • A small set of representative products that should carry it.
    • The campaign structure or bidding rule that depends on it.
    • The value expected after migration.
    • The person responsible for checking it in the advertising account.

    Include products from every label and at least one product that intentionally has no label. That last case helps you distinguish a valid blank value from a failed transfer. Compare the same products before and after cutover instead of checking whichever items happen to be easiest to find.

    Do not rename, consolidate, or reorganize labels during the API migration unless the old structure makes the cutover impossible. Combining cleanup with migration destroys your baseline: when inventory changes, you will not know whether the API, the new label design, or the campaign edit caused it. Move the existing behavior first, prove parity, and schedule cleanup as a separate change.

    Run the migration as a controlled cutover

    A useful migration plan separates preparation, technical cutover, and advertising validation. It also names the person who can stop or reverse the change. Use this sequence:

    1. Assign two owners. The technical owner changes the integration. The paid media owner verifies labels, inventory coverage, and campaign behavior.
    2. Freeze unrelated changes. Avoid simultaneous feed restructures, label renaming, and major campaign edits from baseline capture through validation.
    3. Capture the baseline. Save the current data source type, label map, representative products, update process, and dependent campaigns.
    4. Configure the Merchant API connection. Update the system that actually writes product data, then reconnect the data feed where the migration flow requires it. A code deployment alone does not prove that Merchant Center is receiving the new writes.
    5. Preserve rollback material. Keep the previous configuration, mappings, and baseline evidence until validation finishes. Do not allow two uncontrolled connections to write conflicting versions of the same products.
    6. Send a controlled update. If the integration permits it, change a representative product through the real production path. Choose a field whose before-and-after state is easy to verify.
    7. Check every label path. Compare the representative products against the label map and confirm that dependent campaign structures still include the intended inventory.
    8. Observe a scheduled run. A successful manual request does not prove that the recurring job, connector, or automation has been migrated.
    9. Retire the legacy connection only after sign-off. Require approval from both the technical owner and the paid media owner.

    Define rollback triggers before cutover. Missing labels, a test update that never reaches Merchant Center, or a campaign structure that loses its intended inventory are reasons to stop and investigate. A rollback should restore a known configuration, not blindly reactivate every old process.

    Validate business behavior, not just API success

    An operator oversees parallel product-data pipelines as checkpoints verify deliveries to a storefront, campaign engine, and bidding controls.

    An authenticated request proves only that one request was accepted. End-to-end validation has three layers: the connection, the product data, and the campaign consuming that data.

    Connection validation

    • Confirm that Merchant Center Next shows the intended new data-source connection rather than the legacy Content API source.
    • Verify that a deliberately changed product value arrives through the new path.
    • Run or observe the normal scheduled process and confirm that it uses the same path.
    • Record the time, product tested, expected result, actual result, and validator.

    Product and label validation

    • Check the same representative products captured in the baseline.
    • Compare each expected label character for character.
    • Confirm that intentionally unlabeled products remain unlabeled.
    • Test an ordinary product update after the initial migration so you know the connection handles ongoing changes, not only the first import.

    Campaign validation

    • Inspect every Shopping or Performance Max structure that relies on a migrated feed label.
    • Confirm that each label still selects the intended inventory and that no expected subset has become empty.
    • Check that bidding logic tied to those labels still points to the right product group.
    • Have the paid media owner sign off independently of the developer or integration provider.

    Do not use immediate spend or revenue as your only acceptance test. Auction results vary, and business metrics can lag behind a configuration error. Structural checks – the right products, labels, and campaign relationships – reveal migration mistakes sooner. Performance monitoring should follow, but it cannot replace those checks.

    Keep the validation record with the integration documentation. It should show the old and new connection, the label mapping, the test products, the scheduled-run result, the dependent campaigns, and both approvals. That evidence gives you a precise starting point if a later feed or campaign problem appears.

    Key takeaways

    • A data source marked Content API in Merchant Center Next is a migration dependency that needs a named owner.
    • Moving products is not enough. Feed labels require an explicit before-and-after mapping because they may not transfer cleanly.
    • Separate the API cutover from feed cleanup and campaign restructuring so you retain a useful baseline.
    • Validate the new connection, a normal scheduled update, representative products, labels, and every dependent Shopping or Performance Max structure.
    • Use the dated notice for your own account to determine the applicable cutoff rather than relying on an unqualified calendar date.

    Open Merchant Center Next and inspect Data sources now. If Content API appears, assign a technical owner and a paid media validator in the same work item. Close that item only after a scheduled product update reaches the new connection and the label-dependent campaigns still address the inventory you intended.

    References

  • Google’s 2026 Multi-Channel Product ID Rule: Audit Guide

    Google’s 2026 Multi-Channel Product ID Rule: Audit Guide

    If your website and stores sell the same SKU, a single Google product ID may feel like the cleanest setup. It stops being the right setup when the offer facts sent to Google disagree across those channels.

    March 2026 is the implementation point attached to Google Merchant Center’s multi-channel product ID requirement. Online product attributes become the baseline. When the in-store version has a different price, availability, condition, or another relevant product detail, you need a distinct product ID for that version and must manage it separately in your feeds.

    The rule turns on channel differences, not the shared SKU

    The practical question is not whether the website and store sell the same physical product. Ask whether Google receives the same product facts for both ways of buying it.

    If the online and in-store details are aligned, this rule does not create a reason to split the item. If one or more relevant details differ, the in-store offer needs its own identity in the feed. That lets Google treat each channel version as a coherent set of facts instead of trying to reconcile conflicting values under one ID.

    Catalog situationAction under the ruleWhat to verify
    Online and in-store details matchNo channel split is indicated by this ruleConfirm the match comes from the systems that actually publish the feeds
    In-store price differsCreate and manage a distinct in-store version with a separate product IDCheck which system supplies each channel’s price
    In-store availability differsCreate and manage a distinct in-store version with a separate product IDConfirm that inventory updates continue to reach the correct version
    In-store condition differsCreate and manage a distinct in-store version with a separate product IDMake sure the difference is represented consistently at the source
    Several channel attributes differSplit the versions and manage each set of attributes independentlyRecord every difference so a later feed update does not merge them again

    Keep two distinctions clear. First, a separate Google product ID does not mean that the merchandise has become a different manufacturer product. Do not fabricate a GTIN, manufacturer part number, or other external identifier to satisfy a feed-management requirement. Second, separating online and in-store versions should not be read as a general command to create a new product ID for every physical store. The trigger here is the difference between channel versions.

    Build the audit around the online version as the baseline

    Retail data auditor comparing visual attribute fields for the same product on a desktop monitor and a tablet.

    A conventional duplicate-SKU report will not find this problem. The duplicated base SKU is expected. What matters is whether the attributes associated with that SKU change when the selling channel changes.

    Build a comparison file with one row for each online and in-store pairing. At minimum, include the base catalog key, the current Google product ID, channel, price, availability, condition, and the system that supplied each value. Add a result column that classifies the pair as aligned or different.

    1. Start with the products Google has already identified. Affected accounts began receiving notices and product-level indications before the deadline, so those items give you a concrete first queue.
    2. Expand beyond the flagged queue. Compare the full set of products distributed through your online and local feeds, especially if you use Local Inventory Ads or send the same catalog into several Google surfaces.
    3. Compare published channel values, not only the values in your master catalog. A price may look identical in the product information system while a later rule, promotion process, or inventory system changes the feed output.
    4. Classify each mismatch by attribute. Separate price, availability, condition, and other product-detail differences instead of using a single generic error label.
    5. Split only the pairs with a real channel difference. Leave aligned products alone unless another requirement gives you a reason to change them.
    6. Assign an owner to every unresolved mismatch. The person or team that controls the source data must be able to correct the feed generator, not just patch a submitted file once.

    Treat Google’s markings as a priority list, not a substitute for your own comparison. A product that has not been flagged can still belong in the audit if its channel attributes come from different systems or change frequently.

    Design the ID split so your catalog remains traceable

    Two channel-specific product records with different geometric identifiers linked back to one shared master catalog item.

    The difficult part is rarely generating another string. It is preserving the relationship between the online version, the in-store version, and the underlying catalog item after the split.

    Use an ID convention that your feed process can reproduce deterministically. A channel suffix can be understandable, but no particular suffix is established here as a Google-mandated format. The important operational properties are uniqueness, consistency, and a documented connection to the base item. Do not include mutable values such as the current price or availability in the ID; every routine change would otherwise create unnecessary identity churn.

    Maintain a crosswalk containing:

    • The base SKU or internal catalog key.
    • The online product ID.
    • The in-store product ID.
    • The attribute or attributes that require separation.
    • The source system for each channel’s values.
    • The owner responsible for correcting future mismatches.
    • The status of the feed change and its validation.

    This crosswalk protects reporting and troubleshooting. Without it, a team can see two Google IDs and mistake them for duplicate products, or see one internal SKU and merge channel records that must remain separate.

    Make the separation in the feed-generation logic whenever possible. A manual edit to an exported file may fix one submission, but the next automated run can restore the old shared ID. The durable fix is to route online facts to the online version and differing local facts to the in-store version before the files reach Merchant Center.

    Before a large rollout, verify a small, representative set through your normal feed-validation and account-diagnostic process. Include at least one price mismatch, one availability mismatch, and one fully aligned product if those cases exist in your catalog. That gives you a direct check that the split logic changes only the records it should.

    Avoid the changes that create more feed problems

    The fastest implementation is not a catalog-wide ID rewrite. It is a controlled exception process. Watch for these common errors:

    • Splitting every multi-channel item: the requirement is tied to differing product details. Rewriting IDs for aligned items adds work without addressing the stated trigger.
    • Using the shared SKU as proof that one ID is correct: a shared SKU establishes the relationship between the products, but it does not resolve conflicting channel attributes.
    • Changing only one exported feed: if another local inventory, catalog, or integration process still emits the shared ID, the inconsistency will return.
    • Overwriting the online baseline with local values: the required model uses online attributes as the standard and separates the differing in-store version. Repeatedly replacing one channel’s facts with the other’s does not create two coherent records.
    • Inventing a new manufacturer identifier: manage the separate Google product ID without falsifying GTINs or other identifiers assigned outside your organization.
    • Discarding the old-to-new relationship: preserve a crosswalk so reporting, investigation, and future corrections can connect both channel versions to the original catalog item.
    • Waiting only for an account warning: Google notifications help you prioritize, but your source systems are the reliable place to discover every channel difference you publish.

    If your catalog is large, prioritize products with known channel-specific pricing, products whose availability changes independently between online and physical stores, and products flowing through Local Inventory Ads. Those are the places where the rule’s trigger is easiest to establish from your own data.

    Key takeaways

    • Use the online product record as the comparison baseline for a product sold online and in stores.
    • Create a separate in-store version with a distinct product ID when relevant details such as price, availability, or condition differ by channel.
    • Do not split an aligned product merely because it is available through two channels.
    • Audit the attributes that are actually published, because downstream systems can introduce differences that are absent from the master catalog.
    • Preserve a crosswalk between the base SKU and both channel IDs, and make the change in the feed-generation logic rather than relying on a one-time file edit.

    Your next step is concrete: take the products already marked in Merchant Center, compare their published online and in-store attributes, and use that result to build a repeatable exception report for the rest of the catalog. Split confirmed mismatches, document the mapping, and leave genuinely aligned records intact.

    References