Measure seller activation from profile to first sale

Run a verified three-step supply-side funnel and separate measured seller progression from unproven assumptions about listing friction or marketplace demand.

Updated July 10, 2026 · published May 16, 2026

difficulty intermediate · time to value 10 minutes · execution on demand

Measure seller-profile-completed → listing-published → first-sale for the last 60 days. Verify three distinct ordered events and seller identity, run funnel_3_step, calculate drop-offs, and keep listing-friction and demand explanations as hypotheses.

Why this matters

Marketplaces need sellers to publish usable supply and reach a first successful transaction. A seller-signup count hides whether the product loses supply at profile completion, listing publication, or the path to a first sale.

The ordered funnel locates measured loss. It cannot determine whether the cause is onboarding friction, inventory quality, price, moderation, or buyer demand.

What you get

Three verified seller lifecycle events
Ordered seller counts and conversion for the selected lookback
Clear distinction between published supply and draft activity
Follow-up questions for seller experience and marketplace demand

Walk through it

You

Where do sellers stop before their first successful sale?

Agent

I will map the actual seller events and confirm that first sale comes from the trusted transaction path.

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": "seller_profile_saved", "count": 5240, "last_seen": 1783651200 },
    { "event": "listing_published", "count": 1840, "last_seen": 1783651210 },
    { "event": "listing_first_sale", "count": 420, "last_seen": 1783651250 }
  ],
  "wildcards": []
}

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

Params:
  step1: seller_profile_saved
  step2: listing_published
  step3: listing_first_sale
  days: 60

{
  "rows": [
    { "step1_count": 5240, "step2_count": 1840, "step3_count": 420 }
  ]
}

The measured conversions are 35.1% profile-to-published-listing, 22.8% published-listing-to-first-sale, and 8.0% overall from the selected entry step. The query does not return seller signup counts or time-to-next-step.

The output

Seller activation funnel — last 60 days

seller_profile_saved   5,240  100.0%
listing_published      1,840   35.1%  drop: 64.9%
listing_first_sale       420    8.0%  step conversion: 22.8%

What the data establishes
- measured progression through the three verified events

What remains a hypothesis
- listing-creation friction
- moderation or inventory quality
- insufficient buyer demand or pricing mismatch

Setting it up

Emit profile and listing events from the trusted server path that confirms the state transition. Emit first sale only after the payment/order system confirms it. Carry a stable pseudonymous seller ID and avoid copying listing descriptions, addresses, payment details, or buyer identities into analytics.

Verify the real seller flow and transaction outcome during installation; do not use synthetic transport checks as proof that the funnel is answerable.

Variations

“Segment the funnel by a verified listing category or seller acquisition source.”
“Compare marketplace regions without exposing individual sellers.”
“Run a separate buyer-demand analysis for published listings with no sale.”
“Explain which missing signal prevents first-sale attribution.”

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.