From Recommended to Executable: Auditing the AI Purchase Path

What happens when the best recommendation is not the easiest product to buy?*

The assistant recommends a product.

A merchant appears beneath it. A price is displayed. A checkout button makes the next step look obvious.

But several decisions have already been compressed into that small piece of interface:

Which product fits the buyer?

Which merchant should supply it?

Which offer is valid for this location, budget, and delivery requirement?

And how far can the purchase actually proceed?

These are not the same question.

OpenAI’s own description of Instant Checkout makes one distinction particularly clear: it states that checkout-enabled products are not preferred in product results, while Instant Checkout availability can be considered when ranking merchants selling the same product. openai

The product recommendation and the merchant recommendation operate at different levels.

That distinction changes what we need to measure.

The previous article, From Answers to Orders, mapped the execution layer of the AI Recommendation Economy. This article moves from architecture to audit.

Its central question is not simply whether a recommended product has a purchase link.

It is whether the buyer can act on the recommendation without losing the conditions that made it relevant.

The missing concept is continuity: continuity between the buyer’s requirements, the selected product, the merchant’s offer, and the observable purchase path.

1. The Product Is Not the Offer

“Buy this laptop” is a product recommendation.

“Buy this configuration from this merchant at this price” identifies an offer.

The difference matters because the same product can be sold by several merchants under different conditions.

A product recommendation might correctly identify a suitable model while leaving unresolved:

• The required configuration.
• The seller.
• The condition of the item.
• The price applicable to the buyer.
• Delivery costs and eligibility.
• The purchase route.

Conversely, a technically valid offer may correspond to the wrong configuration or fail an essential buyer requirement.

An audit should therefore preserve a linked sequence:

[
\text{Buyer requirements}
\rightarrow
\text{Product and variant}
\rightarrow
\text{Merchant offer}
\rightarrow
\text{Purchase route}
\rightarrow
\text{Observed endpoint}
]

The sequence is an analytical model proposed here.

It is not a claim that every platform implements these decisions as separate internal stages.

Its purpose is to prevent distinct commercial claims from being treated as one.

2. Product Ranking Is Not Merchant Ranking

OpenAI states that Instant Checkout does not give products preferential placement in product results. It separately explains that, when several merchants sell the same product, merchant ranking considers factors including availability, price, quality, whether the merchant is the primary seller, and whether Instant Checkout is enabled. openai

This is a provider’s description of its system—not an independent verification of ranking behavior.

Nevertheless, it establishes an important boundary for research.

A study asking whether transaction integration affects recommendations must specify which recommendation it means:

1. Selection of a product.
2. Selection of a merchant for that product.
3. Selection or presentation of a purchase route.

An observed change at the second level does not automatically demonstrate a change at the first.

Google’s UCP documentation introduces another relevant boundary. Its FAQ states that Native integration does not affect offer ranking in product listings, while enabling the direct-purchase experience. developers.google

These statements should not be flattened into a simple cross-platform comparison. “Product results,” “merchant ranking,” and “product listings” may describe different surfaces and ranking tasks.

The audit must identify the surface before interpreting the behavior.

A checkout button is observable.

The internal reason for a ranking position usually is not.

3. The First Price Is Not Necessarily the Final Price

Price introduces another layer of ambiguity.

OpenAI’s shopping guidance states that the price shown in an initial response is typically the price from the first listed merchant and may not be the lowest available price. help.openai

That does not establish that the displayed price is incorrect.

It establishes that the number has a particular scope.

A purchase-path audit should distinguish:

Price observation	What it establishes
Price in the AI response	The amount presented at recommendation time
Price on the matched merchant offer	The amount displayed for that offer and variant
Observable checkout total	The amount calculated at the inspected checkout stage
Final charged amount	A transaction outcome requiring separate evidence

If shipping, taxes, or mandatory fees remain unresolved, the audit cannot assume that the visible product price satisfies a total-budget constraint.

Equally, it should not assume that the constraint has been violated.

The correct status may be unknown.

Precision requires preserving uncertainty rather than replacing it with a convenient verdict.

4. Checkout Eligibility Is Not Purchase Readiness

Google’s Merchant Center documentation includes an explicit product attribute:

native_commerce(checkout_eligibility)

The documentation explains that a product is not eligible for the relevant checkout experience when this value is false or absent. It also emphasizes pricing freshness, inventory freshness, and correct variant handling. developers.google

This creates a useful distinction:

A product can be represented in the commerce environment without being eligible for a particular checkout path.

Eligibility is also not the same as readiness.

A product may support checkout in principle while a particular purchase still lacks a valid address, current inventory confirmation, a delivery option, or a completed total.

Google’s Native Checkout documentation separates states including incomplete, ready_for_payment, ready_for_complete, and completed. These states distinguish missing information, payment preparation, final validation, and completed order placement. developers.google

The existence of a checkout entry point therefore cannot establish that the transaction is ready to finish.

It establishes access to a process.

5. The Agent Does Not Necessarily Execute Every Step

“Agentic purchase” can suggest a fully autonomous process.

That description is not always accurate.

Google’s Native Checkout documentation describes a flow in which control passes to Google’s interface for sensitive information and order submission after the checkout session is created. The agent does not remain the actor at every stage. developers.google

This matters for both research and terminology.

A purchase path may combine:

• AI-generated recommendations.
• Structured merchant data.
• User-entered information.
• Conventional checkout interfaces.
• Payment authorization.
• Merchant-side validation.

The audit should record who acts at each observable stage.

It should not label the entire journey autonomous merely because an AI assistant initiated it.

User authorization is a separate event from recommendation.

Execution is a separate event from authorization.

6. What Research Benchmarks Add

Commercial documentation explains intended interfaces and responsibilities.

It does not establish how reliably agents satisfy shopping tasks.

Research benchmarks provide a different kind of evidence.

ShoppingBench: satisfying several constraints at once

ShoppingBench: A Real-World Intent-Grounded Shopping Benchmark for LLM-based Agents introduces a shopping environment containing more than 2.5 million real products. Its tasks extend beyond single-product recommendation to requirements involving budgets, vouchers, and other shopping constraints. The authors report success rates below 50% for the evaluated models, including GPT-4.1, under their benchmark conditions. arxiv

The project also provides a public repository. github

The relevant lesson is not that commercial AI shopping systems fail at a particular universal rate.

That would be an invalid extrapolation.

The lesson is narrower:

Producing a plausible recommendation and completing a multi-constraint shopping task are different capabilities.

WebMall: the merchant comparison is part of the task

WebMall: A Multi-Shop Benchmark for Evaluating Web Agents uses four simulated shops populated with product data extracted from Common Crawl. Its tasks include finding products, comparing prices, identifying alternatives or complementary products, and proceeding through checkout. The conference version appeared at SIGIR 2026. dl.acm

This supports treating cross-merchant comparison as part of evaluation rather than an incidental click after recommendation.

But an offline environment does not reproduce every condition of a live commercial ecosystem.

Live prices, stock, location-dependent offers, account requirements, and changing interfaces remain separate challenges.

The two approaches are complementary:

• Controlled benchmarks support repeatable task evaluation.
• Live audits examine the conditions encountered in an actual purchase path.

Neither substitutes completely for the other.

7. A Proposed Live Audit

The first study should remain narrow enough to interpret.

A proposed pilot would examine:

• One product category.
• One delivery market.
• A fixed observation period.
• A declared set of accessible AI shopping environments.
• Prespecified buyer scenarios.
• A stopping point before any financial commitment.

Platform access should be verified before the study begins.

An announced feature that researchers cannot access is not an observable purchase environment.

Nor should lack of researcher access be counted as a failure for eligible consumers.

Define the buyer before collecting the response

Each scenario should specify:

Requirement	What the protocol must settle
Use case	What the buyer needs the product to do
Essential specifications	Which properties are mandatory
Variant	Required configuration, size, capacity, or edition
Budget	Whether the limit includes delivery and taxes
Location	Delivery country and relevant regional information
Deadline	Whether timing is a requirement or preference
Purchase mode	Whether an external merchant checkout is acceptable

An audit cannot test requirement preservation if the requirements are decided after the response appears.

8. Follow the Recommendation Without Rewriting the Task

A standardized interaction sequence can separate recommendation evidence from execution evidence.

Stage A: Capture the recommendation

Present the buyer scenario.

Preserve the complete answer before any follow-up.

Record:

• Products receiving qualified recommendations.
• Any leading preference.
• Stated reasons.
• Uncertainty or missing information.
• Displayed merchants, offers, and prices.

Stage B: Resolve the offer

Use a fixed follow-up requesting the exact variant, merchant, price conditions, delivery information, and purchase route.

Apply the same rule to every recommendation selected for inspection.

Do not ask extra clarifying questions only when a preferred brand encounters difficulty.

If the study inspects only the top recommendation, declare that restriction.

If it inspects all qualified recommendations, preserve their shared response context.

Stage C: Inspect the purchase path

Follow the route the assistant actually provides.

Record redirects, substitutions, missing information, and the furthest permitted checkpoint reached.

If the researcher abandons that route and independently finds another seller, the new offer can be recorded as a separate observation.

It does not validate the original route.

The buyer’s ability to rescue the task and the system’s ability to preserve the task are different findings.

9. What Counts as a Valid Path?

The audit should test several links.

Identity

Does the destination match the recommended product?

A related model is not an exact match.

Variant

Does it preserve the required configuration?

A suitable product family does not guarantee a suitable variant.

Commercial terms

Do the observable price and conditions match what was represented?

Conditional discounts, memberships, financing, and subscriptions should remain explicit.

Delivery

Can the merchant serve the declared location?

Does the observable delivery information satisfy any mandatory deadline?

Route

Can the buyer proceed through the provided path to the declared checkpoint?

A working product page and a complete order-review screen represent different depths of inspection.

They should not receive identical descriptions.

10. Use Technical Contracts Without Pretending to Observe the Backend

Google’s UCP FAQ specifies that merchants must validate inventory and address constraints. It identifies errors such as:

out_of_stock
address_undeliverable
address_unverifiable

These are defined API outcomes for particular execution problems. developers.google

They are useful when designing an audit taxonomy.

But an external researcher may only see a user-facing message.

If the interface says, “We cannot deliver to this address,” the researcher can record a delivery contradiction.

The researcher cannot claim to have observed address_undeliverable unless the corresponding technical evidence is available.

The same rule applies to checkout states.

Seeing a final review screen does not automatically establish a particular internal status.

An audit must distinguish:

• What the interface showed.
• What an authorized technical trace established.
• What the researcher inferred.

These categories should never be silently merged.

11. Preserve Unknowns

A binary pass/fail system is insufficient.

The proposed coding scheme includes:

Status	Meaning
Confirmed to checkpoint	All required conditions observable within scope were satisfied
Contradicted	Evidence conflicted with a mandatory requirement
Unresolved	Evidence needed for a determination was unavailable
Not applicable	The requirement did not belong to the scenario
Research access limitation	The team could not inspect the relevant experience

Examples clarify the distinction.

A merchant explicitly refusing delivery to the buyer’s location is a contradiction.

Delivery cost hidden behind an inaccessible step is unresolved.

A shopping feature unavailable to the research account is an access limitation.

None of these should be converted into another merely to simplify a chart.

Unknown is not success.

Unknown is not failure.

It is a limit on the conclusion.

12. Time Is Part of the Observation

A recommendation and its offer can change between inspections.

The study should record:

• Recommendation time.
• Offer-inspection time.
• Platform and access conditions.
• Product and variant identifiers.
• Merchant identity.
• Displayed amounts and qualifications.
• Stock and delivery evidence.
• The inspected endpoint.
• Redacted evidence where permitted.

Google’s documentation explicitly places importance on fresh price and inventory data, while requiring merchant-side validation during checkout. developers.google

The audit should therefore describe findings as time-bound observations.

“Available at inspection” is defensible.

“Available” without a timestamp or market scope is often too broad.

If the study measures change over time, it needs a declared revisit schedule.

Repeated observations should not consist only of returning to cases that produced interesting failures.

13. Stop Before the Audit Becomes a Purchase

For an initial study, the stopping rule should prohibit actions that:

• Place an order.
• Authorize a charge.
• Create a subscription.
• Reserve inventory.
• Establish another commercial commitment.

The last inspectable checkpoint may differ between platforms.

That difference should be reported rather than hidden.

A path reaching a product page has weaker transaction evidence than one reaching a calculated order summary.

Neither proves a successful purchase.

Google’s checkout states make the boundary concrete: preparation and final validation precede the completed state. developers.google

Post-purchase evidence extends further still. Google’s order-lifecycle documentation separately models events involving shipment, delivery, cancellation, returns, and refunds. developers.google

Order placement is not fulfilment.

Fulfilment is not retained revenue.

A pre-purchase audit establishes none of these downstream outcomes.

14. Report the Funnel Before Inventing a Score

The initial report should show counts at each stage:

1. Recommendation opportunities.
2. Qualified product recommendations.
3. Identified product variants.
4. Matched merchant offers.
5. Offers satisfying observable mandatory conditions.
6. Purchase checkpoints reached.
7. Unresolved cases and access limitations.

Every percentage needs a visible denominator.

Let (R) be the number of audited qualified recommendations, (C) the number confirmed to the declared checkpoint, and (U) the unresolved cases.

Then report:

[
\text{Confirmed proportion}=\frac{C}{R}
]

and:

[
\text{Unresolved proportion}=\frac{U}{R}
]

These are descriptive audit quantities, not proposed universal market standards.

Do not remove unresolved observations without disclosure.

Do not treat several recommendations from one response as independent buyer journeys.

And do not let a large number of repeated inspections disguise a small number of distinct scenarios.

15. What the Audit Cannot Explain

Suppose products with integrated checkout appear frequently.

The observation does not identify the cause.

Possible explanations include:

• Better fit to the scenario.
• Broader merchant coverage.
• More complete product information.
• More current availability.
• Differences in retrieved candidates.
• The surface’s presentation rules.
• Preference for a lower-friction purchase route.

An observational audit cannot isolate these explanations.

Official ranking statements provide context, but they are not substitutes for independent testing. OpenAI’s distinction between product results and merchant ranking shows why the level of analysis matters. openai

A causal study would require a credible intervention or comparison that changes execution eligibility while sufficiently controlling other relevant factors.

Where that design is unavailable, the conclusion must remain descriptive.

An audit should reveal uncertainty, not turn uncertainty into an accusation.

16. What This Adds to AI Recommendation Share

ARS should retain its declared recommendation definition.

Purchase-path evidence adds another dimension.

A brand can receive frequent recommendations while its offers repeatedly fail buyer constraints.

Another brand can have valid offers but receive few recommendations.

A third can perform well on both dimensions.

These combinations require different investigations.

The first suggests examining offer identity, availability, and execution.

The second suggests examining discovery and recommendation conditions.

Neither diagnosis is complete without checking whether the buyer requirements explain the pattern.

The objective is not to compress the journey into one impressive number.

It is to make different commercial states distinguishable.

17. The Evidence Package Is Part of the Contribution

A publishable audit should provide, where lawful and permitted:

• A versioned protocol.
• Buyer scenarios.
• Standardized interaction sequences.
• Platform and access conditions.
• Raw responses.
• Product-to-offer mappings.
• Redacted inspection evidence.
• Coding rules.
• Reviewer disagreements and resolutions.
• Analysis code.
• Missing-data and access reports.

A second reviewer should assess a declared subset where resources permit.

The report should distinguish exact agreement from agreement reached after discussion.

Re-running a live shopping task later may encounter a different market.

Reconstructing the original analysis should not require guessing what the researchers observed.

That is the minimum promise of the evidence package.

Conclusion: Audit the Transition, Not Just the Answer

AI shopping combines several decisions that an interface can make look like one.

A suitable product is selected.

A merchant offer is presented.

Commercial conditions are checked.

A purchase route is opened.

A user authorizes an action.

An order may eventually be placed and fulfilled.

Provider documentation shows that these boundaries matter operationally. OpenAI distinguishes product selection from merchant ranking. Google separates checkout eligibility, readiness, completion, and post-purchase events. Research benchmarks show why satisfying a complete shopping task requires more than generating a plausible recommendation. openai

The next measurement task is therefore not to declare that recommendations have become transactions.

It is to audit the transitions between them.

Did the selected offer preserve the product?

Did the commercial terms preserve the buyer’s constraints?

How far could the path be verified?

And where did the evidence stop?

An answer can be persuasive before any of these questions is resolved.

A credible audit begins by refusing to confuse them.

---

Research status: This article proposes an audit framework, not findings from a completed field study. Platform descriptions reflect the cited documentation and announcements; availability varies by market, account, merchant, and implementation. Benchmark results apply to their respective experimental environments. A pre-purchase audit cannot establish successful payment, fulfilment, customer satisfaction, incremental revenue, or the internal cause of a ranking decision.
Author: Seyed Alireza Alhosseini Almodarresieh
my site :https://almodarresieh.github.io/