Start with the last shopping milestone your merchant systems can confirm. Then check the next expected event, the response at that boundary and the coverage of the systems that should have recorded it.
A missing next event does not identify why a path stopped. The records may show a failure, a handoff or a changed offer; they may also be incomplete, or simply show no further activity. Start by establishing what is observable before calling the gap a lost sale.
The merchant guide covers broad checkout readiness. This workflow is for an ecommerce or engineering team investigating one specific path through its existing systems.
1. Define the path you are investigating
Write down the hostnames, APIs, platform and checkout mode involved. A storefront browser flow, a cart transfer and a native checkout integration can have different milestones. Use the documentation for the actual integration and version.
For example, Google’s UCP Cart API documents a cart response that includes a continuation URL back to the merchant. Google’s native checkout documentation describes a separate flow with checkout-session states. Do not treat those as the same event sequence. Google UCP Cart API, version 2026-04-08, Google UCP native checkout overview
Choose a bounded observation window and record which logs are available. Before comparing two systems, confirm their time zones, timestamp precision and collection delays.
2. Find the last confirmed state
Distinguish an attempted action from its application result:
- A product request is not a confirmed cart change
- A cart-update request needs the recorded cart result
- A checkout page response is not an accepted order
- A redirect or continuation URL is not proof that the destination was reached
Capture the event time, system, request identifier, permitted cart or checkout reference, response and resulting state. Where supported, note the integration version and retry or idempotency behavior. Keep restricted identifiers within authorized systems and redact exports.
Use existing relationships to connect the records. A shared IP address, user-agent or nearby timestamp is not sufficient on its own to establish that two requests belong to the same shopping journey.
3. Read the application outcome, not just the HTTP status
A successful HTTP exchange can carry a failed business operation. Google’s UCP documentation, for example, places business errors and warnings in the response body with HTTP 200 OK. The documented message includes fields such as type, code and severity; protocol and server failures are handled separately. Google UCP error guidance
For an affected attempt, check the fields your integration actually returns:
- Was a cart or checkout object created?
- Did the response contain an error or warning?
- Did the item, quantity or total change?
- Was further information or buyer action required?
- Was the response produced by the application, the edge or an intermediary?
Keep the error category and the precise milestone. “Cart creation returned an out-of-stock error” gives the team somewhere to investigate. “AI checkout failed” hides too much.
4. Check for a recorded challenge or block
Ask the security team whether the affected request received a challenge, rate limit or block, and which rule produced it. Correlate that result with the application record; the application may never have received the request.
For Cloudflare Challenge Pages, the documented cf-mitigated: challenge response header is an explicit signal that a challenge was returned, and the response content type is HTML. Preserve the signal if your authorized collection captures it. Cloudflare challenge-response documentation
That finding is a reason to review the rule and the intended access policy with its owner. Verification of a service’s identity does not authorize bypassing checkout, authentication, fraud or payment controls.
5. Follow a handoff only as far as you can observe it
A cart transfer may be intended to continue in the merchant’s checkout. Look for the recorded continuation, the destination request and the same merchant cart state, where the implementation supports that connection.
Google’s native checkout flow also explicitly describes a point where the user supplies sensitive fulfillment and payment details through a Google interface. The absence of further agent activity at that point does not establish abandonment. Google UCP native checkout flow
If the destination is outside your available logs, mark that boundary. If your order system later records a connected outcome, add that evidence. If the relationship cannot be established, leave the outcome unresolved. Do not manufacture a connection from timing alone.
6. Separate a changed offer from a technical failure
Compare only the terms your own systems recorded: selected variant, quantity, price, promotion, delivery estimate and other relevant conditions. Note the time and source of each version.
An item becoming unavailable can be a valid business outcome. An unexplained application error is a different problem. A delivery change and a session ending together do not prove the change caused the customer to leave.
The companion article, A cart can transfer perfectly and still fail the customer, explains how to test changed terms without assuming access to the shopper’s earlier AI conversation.
7. Write a diagnosis that another team can act on
Use this short review template:
- Observed: the last confirmed milestone, time and source record
- Identity: what was verified, what was only claimed, and the supporting evidence
- Next expected event: the event appropriate to this integration
- Recorded response: the exact error, warning, challenge or state, if available
- Coverage: the hosts, systems and time periods available, plus any gaps
- Conclusion: what the records establish and what they leave unresolved
- Next check: a specific record or configuration for the responsible team to inspect
For example, “Cart creation succeeded; the continuation URL was returned; destination activity is unavailable in this export” is an observation gap to investigate. It is not evidence of checkout failure or economic loss.
If a reproduction is needed, have the merchant’s team run a separately authorized test in its approved environment, preferably staging. Keep that synthetic result separate from observed customer traffic. A controlled test can establish that a condition reproduces; it cannot prove why a previous shopper stopped.
Synthetic worked example: where the evidence stops
Illustrative data only. Every event below is invented. These are not customer records, a Cartograph product screenshot or evidence of an available integration. The addresses and domains are reserved for examples. No real bot verification was performed.
Imagine a fictional merchant at shop.example.com. Its team has selected edge records and application events, but no events from the separate checkout host, checkout.example.net.
All times are illustrative UTC times on October 15, 2026. User-agent tokens are shortened for readability.
| Time | Recorded evidence | Supported conclusion |
|---|---|---|
14:00:00 | Edge: GET /robots.txt, HTTP 200, OAI-SearchBot/1.4, sample IP 192.0.2.10 | A request claimed that identity. Verification was not run. |
14:00:01 | Edge: GET /products/trail-pack, HTTP 200, same claimed token and sample IP; cache hit | A response was served on the product path. Its use by an AI service is unobserved. |
14:00:05 | Edge: GET /collections/day-hike, HTTP 200, Googlebot/2.1; original client IP unavailable | A Googlebot claim was recorded. Verification is unavailable; the operator is unresolved. |
14:03:00 | Edge: a browser-like request to /products/trail-pack, reported referral https://assistant.example/, merchant session s_demo_27 | A separate session arrived with a fictional assistant-domain referral. It is not linked to the earlier crawler requests. |
14:03:09 | Access and application records: POST /cart/items, HTTP 201, matching cart.updated, session s_demo_27, cart c_demo_42 | The merchant application recorded a cart update in that session. |
14:03:20 | Access and application records: POST /checkout, HTTP 303, matching checkout.redirect_issued, session s_demo_27, cart c_demo_42, checkout co_demo_42, destination checkout.example.net | The merchant issued a redirect intended to continue checkout. Destination activity is not recorded here. |
14:20:00 | Review checkpoint: checkout-provider and order events are outside the dataset’s coverage | The checkout outcome is unknown. This is not a zero-order count or proof of failure. |
The merchant session connects the later cart and redirect events. It does not connect them to the earlier crawler fetch. A browser-like user-agent does not prove a human operated it, and the fictional referral does not expose an off-site conversation.
The useful next check is whether authorized destination and order records can establish what happened after the redirect. Waiting longer does not fix a missing source on its own. If those records remain unavailable, the conclusion remains “checkout outcome not observed.” This selected example has no population denominator and should not produce a conversion or abandonment rate.
The sample IP is from a documentation-only range described in RFC 5737. The example hosts use reserved names described by IANA and RFC 2606. None is presented as a real provider address.
Cartograph is being built to organize merchant-side evidence for this kind of review. We are preparing for pilots. Contact us to register your interest; an inquiry registers interest only. Any product access, data connection, diagnostic scope and pilot terms would be agreed separately.
Sources checked October 16, 2026. Protocol and platform behavior can change; use the documentation for the version you operate.