Measure cart-to-purchase drop-off

Map three verified ecommerce events, run the canonical ordered funnel, and separate measured checkout loss from hypotheses about payment, shipping, or UX.

Updated July 10, 2026 · published May 16, 2026

difficulty beginner · time to value 5 minutes · execution on demand

Measure add-to-cart → checkout-started → order-completed for the last 30 days. Verify the exact events and stable shopper identity, run funnel_3_step, calculate drop-offs from the returned counts, and label possible causes as hypotheses.

Why this matters

A cart funnel shows where measured progression stops; it does not explain why. Payment failures, shipping cost, inventory, slow pages, identity changes, and simple intent can all produce similar drop-off.

The funnel_3_step blueprint answers the narrow ordered question reliably. Use separate evidence to investigate causes after the largest measured loss is known.

What you get

Three approved, observed ecommerce events
Ordered shopper counts for the selected lookback
Step and overall conversion calculated from canonical counts
Identity and instrumentation caveats plus a ranked follow-up plan

Walk through it

You

Where do shoppers drop between cart and completed order?

Agent

I will verify the storefront’s exact event names and identity continuity before running the three-step funnel.

GET /v1/projects/:project_id/signal-map
GET /v1/projects/:project_id/onboarding
# Require status: "verified"; use live event/property reads for the selected signals.
GET /v1/projects/:project_id/event-names
GET /v1/query-blueprints/funnel_3_step

{
  "server_emitted": [],
  "analytics_events": [
    { "event": "cart_item_added", "count": 21400, "last_seen": 1783651200 },
    { "event": "checkout_started", "count": 8800, "last_seen": 1783651210 },
    { "event": "order_completed", "count": 4200, "last_seen": 1783651250 }
  ],
  "wildcards": []
}

POST /v1/projects/:project_id/query-blueprints/funnel_3_step/run

Params:
  step1: cart_item_added
  step2: checkout_started
  step3: order_completed
  days: 30

{
  "rows": [
    { "step1_count": 21400, "step2_count": 8800, "step3_count": 4200 }
  ]
}

The measured conversions are 41.1% from cart to checkout, 47.7% from checkout to order, and 19.6% overall. Those calculations do not include time-on-step, cart value, payment failure, or a benchmark.

The output

Cart-to-purchase funnel — last 30 days

cart_item_added       21,400  100.0%
checkout_started       8,800   41.1%  drop: 58.9%
order_completed        4,200   19.6%  step conversion: 47.7%

Evidence gaps
- <identity, sampling, delayed server confirmation, missing device property>

Follow-up hypotheses
- payment failures → inspect verified payment-failure signal
- slow checkout → inspect measured completion duration
- payment-method differences → run the dedicated comparison

Setting it up

Send browser actions with the public browser credential and server-confirmed orders with the trusted server credential. Use a stable first-party shopper ID and a verified transition when the shopper signs in. Never treat a client-side “purchase clicked” event as a completed order.

Include only necessary properties such as SKU or storefront. Keep payment data, addresses, tokens, and cart contents outside analytics.

Variations

“Segment the same funnel by an observed device property.”
“Compare two exact adjacent periods with the same frozen event mapping.”
“Measure product-view to add-to-cart separately using a suitable approved query.”
“Tell me which missing event prevents a trustworthy funnel.”

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access

5.5 Extra High

1. Open your repo in Codex, Claude Code, Cursor etc.
2. Paste the install prompt.
3. Your agent reads the install doc and shows you an implementation plan for approval.