How to Measure Agentic Checkout Without Inventing a Funnel

Short answer: Start with the actual checkout route and the evidence each system can observe. A cart transfer is a handoff, not a completed order. A native checkout purchase is a different event, and a missing downstream event is unknown until it can be reconciled. Build a cohort of permitted, distinct handoffs and resolve outcomes at a stated cutoff before calculating coverage.

An AI shopping surface recommends a jacket. The shopper transfers the cart to a retailer, changes the delivery method and checks out. In a second journey, the purchase completes within the shopping surface. Both may be described as agentic commerce, yet the platform, merchant, payment provider and customer may see different parts of each journey. A dashboard that joins them into one smooth funnel can be more misleading than no dashboard at all.

This guide is for ecommerce, retail, B2B and startup teams designing or evaluating a bounded commerce integration. Growthcraft Editorial prepared this original synthesis with AI assistance; personal review by Akshay is not claimed. It describes proposed practices rather than a claim of a client deployment. All numbers are synthetic. Vendor access, supported surfaces, specifications and regional eligibility can change.

Five decisions to get right

• Separate a transfer to the merchant's cart from a purchase completed in a native checkout.
• Write the measurement contract before collecting events: one unit, route, cohort, owner, cutoff, currency and evidence source.
• Reconcile distinct eligible attempts to confirmed outcomes, known non-completions and unresolved cases; unknown is not zero.
• Carry permitted attribution and buyer preferences through the exact integration, while retaining human confirmation and merchant-side validation.
• Compare revenue and outcomes in aligned cohorts; a reported purchase or attribution tag does not prove incremental sales.

Use the agentic checkout reconciliation framework to plan the handoff and the outcome coverage calculator to check a mature cohort. For the broader discovery-to-purchase context, read AI shopping agents and growth.

Why the reporting boundary matters now

Google's Merchant Center UCP analytics guide, updated 27 October 2026, describes separate reports for transfer to merchant cart and native checkout. It defines cart transfers as clicks to transfer a cart to the merchant's site and says that it cannot track further activity after that transfer. Its native checkout reporting includes purchases and cancellations because the purchase occurs within Google. This is a product-specific reporting boundary, not proof that every retailer or country has access. Google: monitor your UCP integration.

Google also documents an experimental v1alpha Merchant Reports API view for UCP performance. An alpha interface is subject to change; eligibility, access permissions, report fields and integration coverage must be verified for the account and market in question. Google requires a date condition for these queries. An API field existing in documentation does not establish that an individual merchant has usable data. Google: UCP agentic performance reports, reviewed 29 October 2026.

Map two routes before drawing a funnel

1. Transfer route: an eligible buyer invokes a cart transfer on the external surface. The merchant receives a cart or link, but a click, an arrival, a validated cart, a checkout and a paid order are separate observations. Google says its UCP transfer reporting stops following the cart after transfer. The merchant must rely on its own permitted evidence for later steps.
2. Native route: a supported surface presents a checkout within its experience. The merchant still owns the integration and relevant order operations; completion, payment status, cancellation, fulfilment and returns need explicit authoritative sources. A buy-button click is not a completed purchase.

Do not subtract native purchases from all transfer clicks and call the difference abandonment. These are different routes and may involve different populations, time windows or data availability. If a platform reports aggregates without journey-level identifiers, do not manufacture person-level matches. A platform count can be useful for trend review even where no lawful event-level join exists.

Design a measurable cohort

A reconciliation contract should name the source system, channel and actual route; what makes a handoff eligible; its opaque unique ID if one is available; the start and end of the cohort window; the time zone; the observation cutoff; and the person responsible for exceptions. Specify whether the unit is a click, a cart, a checkout attempt, an order or a buyer. A shopper may try twice, and one cart may contain several products: none of these units is automatically interchangeable.

For a merchant-operated ledger, keep an internal event ID, a permitted source reference, route and capability version, timestamps, current resolution state, source-of-truth reference and a missingness reason. Document identity matching as exact, ambiguous or unavailable. Never store email addresses, phone numbers, session tokens or raw conversation text in URLs or ordinary analytics events. The ledger must have access controls, a retention policy and a responsible owner.

Choose mutually exclusive outcomes at the cutoff. A useful starting set is confirmed completed, confirmed not completed and unresolved. Record a status as confirmed only when an appropriate authoritative source supports it. An expired or cancelled checkout can be known not completed, but only if the evidence and definition justify that conclusion. Missing webhook delivery, an absent matching ID or a time-out can be unresolved. Keep later refunds and fulfilment separate from initial checkout status.

Worked example: a synthetic transfer cohort

A retailer's permitted merchant-side integration records 100 distinct eligible transfer handoffs for one country and seven-day cohort. This is not inferred by matching anonymous aggregate Google clicks. After a defined seven-day observation window, its ledger has 72 confirmed completed orders, 18 confirmed not completed attempts and 10 unresolved attempts. All values are fictional.

Outcome coverage is (72 + 18) ÷ 100 = 90%. Confirmed completion among all eligible handoffs is 72 ÷ 100 = 72%, with 10% unresolved. If all unresolved cases eventually become non-completions, the completion rate is 72%; if all become completions, it is 82%. These are arithmetic bounds for this specific unresolved cohort, not a statistical confidence interval or a forecast.

If five of the 72 completed orders are later fully refunded, 67 are not fully refunded at that later cutoff. That is not necessarily the same as 67 profitable orders: taxes, shipping, partial refunds, costs and order adjustments require their own contract. Keep the earlier 72-order snapshot reproducible and record the later outcome date. A 72% observed completion rate does not prove the AI surface caused the purchases.

The surprising currency trap in the reporting API

Google's alpha documentation explains that purchase and cart value fields are Price objects with an amount and currency, while metrics such as buy-button clicks and cart transfers do not have an inherent currency. Mixing count fields with value fields can split returned rows by currency or omit rows without purchase values. Google recommends one currency-independent query for counts and a separate query for value metrics by currency. Do not sum the currency-segmented click rows to reconstruct an overall click count unless the provider explicitly supports that aggregation.

For example, review a counts-only extract for the same account, date and country, then review value rows separately with currency included. Keep USD and EUR separate; a cross-currency total needs an explicit exchange-rate source, conversion date, rounding and finance approval. Average order value is not a simple sum across currencies or across daily averages. A proper combined average needs compatible total values and order counts in a defined currency. Neither report establishes which individual transferred cart produced an order.

Record the query, report version, account, date filter, extraction time, data maturity, dimensions, units and any missing rows. Re-run a comparable completed period when the provider refreshes data; do not treat an absent row or unavailable field as an exact zero without evidence. Inspect the provider's current query examples and restrictions before implementation.

Preserve attribution without promising causality

In Shopify's documented Cart MCP, update_cart replaces the full cart state rather than patching it. Fields omitted from the update can be removed; if attribution is needed, resend the intended attribution state and set it before converting a cart to checkout. The cart's location context is an estimate and is not the authoritative shipping address. These are Shopify-specific behaviors: validate the version and the actual merchant integration before applying them elsewhere. Shopify Cart MCP documentation.

A retained utm_source or other allowed reference can help an operations team locate a journey, but it is not proof that the agent created incremental demand. References can be lost, repeated, overwritten or unavailable; changes in consent and browser handling can reduce visibility. Test allowed synthetic journeys, compare the cart's intended state before and after updates, and monitor the share of eligible handoffs with a verified downstream reference. When a reference is absent, preserve the unknown state instead of assigning it to the most convenient channel.

Buyer choices do not travel automatically

Shopify's 16 October 2026 changelog describes buyer consent support for Cart MCP and Checkout MCP when the dev.ucp.shopping.buyer_consent extension is negotiated with UCP version 2026-08-25. It says integrations using earlier versions or not declaring the extension are not affected by that change. It also states that, if consent is not sent, shop defaults depend on the buyer's country, and an unknown country defaults to opt-out. Check the exact provider behavior, available choices and policies in the current integration. Shopify buyer consent changelog.

Consent for analytics, preferences, data sharing and marketing can have different purposes and states. A completed purchase is not an automatic permission to send marketing messages. Capture only choices the buyer actually made and keep the source, purpose, state, policy version and update time where appropriate. Involve your privacy owner for each market and channel; the protocol does not replace a legal review or a compliant customer experience.

Build for uncertainty, not a perfect callback

For each write, record a stable operation reference and use a provider's documented idempotency mechanism where supported. A timeout after submission could mean that the merchant processed the request but the response was lost. Before repeating a consequential write, inspect the destination using the supported status or lookup mechanism. Preserve uncertain outcomes for review and use bounded retries only for conditions the provider identifies as retryable.

OpenAI's checkout specification documents checkout-session states, an idempotency key and merchant order webhooks for its integration. Validate signatures and follow the current specification; a response acknowledgement is not the same as fulfilment or a final retained order. OpenAI Agentic Checkout specification.

Mechanisms differ even within one vendor's products. Shopify's 13 October 2026 Shop MCP launch note says webhooks were not available at launch and instructs agents to poll get_checkout. That observation is specific to that product and launch state; it does not mean all Shopify or UCP integrations lack webhooks. Pin the version, review the latest docs, limit polling to the provider's guidance and give unresolved cases an owner. Shopify Shop MCP launch note.

A bounded implementation sequence

1. Choose one pilot: one eligible merchant, market, product group and supported checkout route. Confirm actual access, owner, policies and the ordinary human fallback.
2. Draw the evidence map: for each event, name the generating system, timestamp, unit, identifier, source of truth and what cannot be observed. Mark aggregate-only data explicitly.
3. Specify transitions: document validation, buyer approval, cart or checkout handoff, payment confirmation, cancellation, order updates and refund observation separately. Track unknown and late outcomes.
4. Test synthetic cases: cover a successful handoff, no downstream match, duplicate callback, timeout after a successful write, changed cart, absent consent, unknown country and partial or full refund. Verify authorized fallback paths without placing real orders.
5. Operate and review: inspect unresolved age, duplicate rates, evidence gaps and a sample of confirmed cases. Compare completed equivalent periods and define who can pause the integration or correct the mapping.

Read the companion framework, use the coverage calculator for compatible counts, and explore forward-deployed marketing support for a scoped data, integration and evaluation engagement.

Sources and limits

Primary provider documentation linked above was checked on 29 October 2026. The Google API is alpha; Shopify's version-specific behavior and individual merchant eligibility should be rechecked before implementation. The example is synthetic, the framework is an editorial synthesis, and no particular client result, deployment, legal approval, ranking or sales increase is claimed.