Acquisition test
Intent-specific landing page
Measure qualified launch rate from one comparison, guide, or answer cluster.
Product analytics guide
Measure the email workflow, not the package download.
Downloads and page views are useful distribution signals, but they do not show whether an agent received a message, completed the task, or returned with an authorized use case.
Direct answer
Measure agent email conversion as a sequence of distinct, privacy-preserving events: qualified content visit, tool install or launch, provisional mailbox bootstrap, address used in an external workflow, first expected inbound message, successful extraction or retrieval, completed external outcome, permanent identity approval, and retained authorized activity. Keep npm downloads, mailbox creation, provider acceptance, and active users separate. Diagnose the largest transition loss by acquisition source and workflow cohort before changing onboarding or authority policy.
The agent email activation ladder
Each step proves more product value than the step before it.
- 01Discover and launch
A qualified visitor reaches a workflow page and starts a tool path.
- 02Bootstrap and receive
A scoped inbox is created and receives the expected current message.
- 03Complete the task
The code, link, or reply produces the intended external result.
- 04Return with authority
The user approves durable identity or repeats an authorized workflow.
Metric boundaries
Name what each event proves and what it does not
An npm download can be a first install, upgrade, CI restore, cache miss, automated scan, or repeated activity from the same machine. It measures package retrieval, not unique people and not product value. A created mailbox proves that bootstrap ran, but the address may never be used. A received message proves routing, not that the agent selected the right message or completed the external task.
Write the evidence boundary beside every dashboard metric. This prevents an improving top-of-funnel number from being reported as retained users and prevents a transport event from being reported as customer success. It also makes a decline diagnosable instead of emotionally interpreted.
| Event | It proves | It does not prove |
|---|---|---|
| Package download | An artifact was requested | A unique user installed or used it |
| Mailbox bootstrap | A scoped identity was created | The address received anything useful |
| Inbound stored | Routing and ingestion worked | The caller extracted the right value |
| Code returned | A parser selected a candidate | The external service accepted it |
| Workflow completed | Email contributed to a product outcome | The user will return |
| Durable claim | A human approved continuity | The mailbox remains active later |
Event model
Connect the funnel with privacy-preserving cohort identifiers
Assign a random analytics cohort when a user intentionally starts the tool path. Carry it through local bootstrap and API events only with clear disclosure and without storing the mailbox key, raw address, message body, subject, OTP, attachment, or external account name. Rotate or expire the identifier according to a documented period.
Record timestamps, broad acquisition source, interface type, runtime version, result state, and latency bucket. For the workflow event, record a declared category such as verification, invitation, notification, or reply rather than free-form content. If the system cannot link events safely, report stage totals separately and avoid pretending they form one user funnel.
- Hash or randomize identifiers before analytics storage.
- Keep operational message access separate from product analytics.
- Use coarse error categories that still identify the failing layer.
- Document consent, retention, and deletion behavior for telemetry.
Activation funnel
Use completed external state as the first-value event
The strongest early activation definition is not message receipt alone. It is a known message received after a trigger, a bounded value retrieved, and the external workflow confirmed. For an OTP flow, the user account reaches verified state. For an invitation, membership appears. For a notification, the agent records the expected status in its own workflow.
Track the time between stages and the failure reason. A visitor who installs but never bootstraps has a different problem from a mailbox that receives nothing. A code returned but rejected points to stale-message selection, duplicate requests, parsing, or an external service rule. A completed first task with no return suggests the use case is occasional or the durable path is unclear.
-
01
Qualified entry
The visitor lands on content matching a real implementation intent.
-
02
Scoped bootstrap
The CLI, SDK, MCP, or playground creates the first bounded identity.
-
03
Message and extraction
The current expected inbound event produces a typed result.
-
04
External completion
The surrounding application confirms the intended outcome.
-
05
Return or promotion
The user repeats value or approves a durable operating path.
Diagnosis
Match each conversion loss to the layer that can fix it
Low qualified traffic calls for distribution, search coverage, comparison pages, examples, community placement, and partner integrations. Low launch from high-intent pages suggests unclear category positioning, trust concerns, or a CTA that does not match the reader's job. Low bootstrap suggests installation, runtime, or interface friction.
Low first inbound after bootstrap may mean users do not know where to put the address, the hosted boundary is unclear, the sender rejects the domain, or routing is failing. Low completion after inbound points to search, extraction, tool output, browser orchestration, or security policy. Low retention after completion may be normal for one-time tests, so segment by workflow before treating it as churn.
| Largest drop | Likely layer | First experiment |
|---|---|---|
| Content visit to launch | Positioning and CTA | Use one runnable action matched to page intent |
| Launch to bootstrap | Install and first-run product | Remove configuration before receive-only trial |
| Bootstrap to inbound | Address use and routing | Show one exact trigger example and routing evidence |
| Inbound to completion | Retrieval and orchestration | Return bounded typed values with better failure states |
| Completion to return | Use-case frequency and durable path | Segment one-time tests from recurring identities |
Experiment design
Change one conversion boundary at a time
A content release, new automatic mailbox path, revised claim policy, and analytics rewrite launched together make attribution weak. Prefer bounded experiments that alter one stage and keep upstream and downstream definitions stable. Compare cohorts by page intent, interface, version, and use-case category rather than only calendar week.
Protect risk controls during conversion work. Removing human approval for permanent hosted names might increase claims while also increasing abuse, abandoned identities, and support load. A better experiment can preserve the gate while making the reason, timing, and handoff clear after the user completes first value.
Activation test
Runnable first workflow
Measure expected message receipt and external completion, not only command copy.
Promotion test
Contextual durable-identity handoff
Offer claim or self-hosting after repeated value while retaining approval.
Implementation judgment
A useful metric should point to a product decision
Keep the funnel honest enough that each loss maps to content, setup, transport, retrieval, orchestration, lifecycle, or product frequency. When a number cannot distinguish those layers, treat it as a distribution signal rather than evidence of users or value.
Evidence
Sources and product scope
Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.
- mails0 source repositoryImplementation, license, and deployment source
- mails0 hosted API implementationMailbox, message, and hosted lifecycle events available for implementation review
Questions and answers
Questions that come up in practice
Are npm downloads active users?
No. Downloads include installs, upgrades, CI, caches, bots, and repeated activity. Use them as distribution evidence and connect product usage with separate privacy-preserving events.
What is activation for an agent email product?
A strong activation event is receiving the expected current message, retrieving the required value, and confirming the external email-dependent workflow completed.
Should a permanent mailbox claim count as activation?
Treat it as a later commitment event. A claim should follow demonstrated value and human approval; it does not prove retained use by itself.
Start with a bounded inbox
Prove the smallest useful email loop.
Start with one scoped inbox and one expected message. Add durable identity, sending, and operational complexity only when the first loop works.