Agent-Led Growth Metrics: What to Track and Why

Direct answer

Track mention, recommendation, and citation rates to understand visibility; verified task success and completion time to understand usability; and detected agent traffic to understand site activity. Use attributed activation and repeat use to assess customer adoption. Start with the metric that answers your current question, and keep separately collected responses, test runs, and customer records separate.

---

An agent can mention your product, recommend it, and still fail to use it. A successful test can also produce no new customers. Each result answers a different question.

The eight metrics below are ordered from visibility to continued use, rather than ranked by importance.

These are practical measurement definitions, not a claim that every platform uses the same counting rules. The numerical examples are hypothetical.

1. Mention rate: does your product enter the conversation?

Mention rate is the share of monitored responses that name your product. If 40 out of 100 eligible responses mention it, the rate is 40%. Count each response once, even if the product appears several times.

Use a consistent set of relevant prompts. A question that already names your product tests something different from an open-ended request such as “Which email API should I use for this application?” Keep those results separate, and define how you recognize product aliases.

This metric helps you identify use cases where your product is absent. It does not establish that the agent endorses the product: “Avoid this service for your requirements” still contains a mention. When mentions are low, inspect which alternatives and sources appear before deciding what content to change. Lightsage's Agent Discoverability brings prompt responses, mentions, and cited pages into that investigation.

2. Recommendation rate: does the agent endorse your product?

Recommendation rate is the share of eligible responses that recommend your product for the task. If 25 of the same 100 responses recommend it, the rate is 25%, even though its mention rate is 40%.

Define what counts as a recommendation and review sample classifications. A passing reference, an explicit rejection, and a recommendation should produce different labels. When an answer recommends several products, each can receive credit; the rates across products can therefore total more than 100%.

Use this metric to investigate fit and positioning. If mentions are common but recommendations are rare, read the reasons agents give. A recommendation is still distinct from an agent selecting and integrating the product during an actual task. Our guide to tracking recommendations across APIs, SDKs, CLIs, and MCP covers the different product interfaces you may need to test.

3. Citation rate: does the agent use your content as a source?

Owned-source citation rate is the share of eligible responses that cite at least one URL on your defined domains. Eighteen citing responses out of 100 gives a rate of 18%. Count each response once for the rate; inspect individual URLs separately.

Use citations to see which documentation or explanations appear in sourced answers. A frequently cited page may help answer a category question without generating a recommendation for your product.

Where a platform does not expose citation information, mark the metric unavailable. Treating missing citation data as zero would make platforms look comparable when they are measuring different things. Review the cited passages before deciding that a page is helping your positioning.

4. Verified task success: can the agent produce a working result?

Divide task attempts that pass your success checks by all eligible attempts. If 14 of 20 attempts pass, task success is 70%. Define the outcome before testing: a test email arrives, a deployed service responds, or a query returns the expected record.

Record what the agent receives at the start. A supplied API key removes a different obstacle than an onboarding flow that includes obtaining credentials. Also record human assistance and whether the product was named in the task.

Include product failures and timeouts. Set a rule for excluding invalid test infrastructure in advance and disclose those exclusions. Use the failing traces to choose a product or documentation fix. The agent's own “success” message is not enough to establish a pass. Anthropic's agent evaluation guide makes the same distinction between what an agent says and the outcome recorded in the environment.

Lightsage's Agent Usability runs product tasks in sandboxes and exposes execution traces to help locate those failures.

5. Time to verified success: how long does the task take?

Measure elapsed time from a defined starting point to the first verified outcome. Report the median for successful runs, together with the number of successes, failed attempts, and timeouts. State whether setup is included.

For example, “median four minutes across 14 successful runs; six of 20 attempts failed or timed out” is more informative than “four-minute integration.”

Use this metric to locate delays in setup, retries, or verification. Read it alongside task success: if the harder attempts start failing, the remaining successful runs may look faster even though the experience has deteriorated. Tool-call counts can help diagnose a delay, but they do not measure customer value on their own.

6. Detected agent traffic: where do agents interact with your site?

Count requests identified as agent traffic, grouped by page, agent classification, and period. If you report sessions or visits, define how requests are grouped. Three hundred requests do not necessarily represent 300 agents, people, or buying decisions.

Server-side observation can capture requests that do not execute browser analytics scripts. Lightsage's Agent Analytics describes its middleware approach; our explanation of AI traffic gaps in GA4 covers why browser tracking can miss those requests. Detection still has limits: some traffic cannot be identified reliably, and background crawling differs from a customer's agent attempting an integration.

For a concrete example of request-level reporting, Cloudflare's AI traffic documentation separates crawler requests, response codes, and referral traffic. Keep those categories separate in your own reporting too.

Use traffic to decide which pages deserve closer investigation. If agents repeatedly access an outdated quickstart, that is a reason to inspect and correct it. Traffic volume alone does not establish successful use or acquisition.

7. Attributed activation: do those journeys lead to customer value?

First define activation for your product. Creating an API key might be a setup milestone; completing a useful customer operation may be the stronger value event.

For an observable cohort of agent-referred accounts, divide activated accounts by eligible accounts in that cohort. If 12 of 30 accounts activate within the defined window, the rate is 40%. Document how the referral was linked to the account, the observation window, and how multiple sources are handled.

Use this measure to investigate the path from referral to first value. Keep unlinked accounts unattributed. Better tracking can increase attributed activations without increasing actual adoption, so report how much activity your attribution method can cover.

8. Repeat use: does that first success lead to continued use?

Choose a meaningful follow-up action and a window that fits the product. Then measure the share of activated accounts that repeat that action within the window. Include only accounts old enough to have completed the observation period.

If eight of the 12 activated accounts use the product again, and all 12 have completed the window, repeat use is approximately 67%. A daily workflow and an occasional reporting tool may need different observation periods.

Use this measure to investigate whether the first outcome leads to lasting value. Continued customer use does not necessarily mean an agent initiated every later operation. Describe the result as repeat customer use unless the records support a more specific claim.

Use the metrics to answer a question

If you want to know whether agents recommend your product, begin with recommendation rate and inspect the answers. If you want to know whether agents can use it, begin with verified task success and inspect the failures. If the question is whether this activity produces customers, you need linked account-level evidence.

Keep independently collected samples separate. The 25% recommendation rate and 70% task success rate above come from different tests. Multiplying them would not give you an observed customer conversion rate.

For every rate, keep the underlying counts, period, prompt or task set, and relevant agent setup. That makes changes interpretable and keeps a shift in the test mix from looking like a product improvement.

Our guide to getting recommended by coding agents explains how to turn discovery and execution findings into a focused change, then test it again.

Frequently asked questions

Which agent-led growth metrics should I start with?

Start with the question you need to answer. Recommendation rate measures whether agents endorse your product; verified task success measures whether they can use it. Track activation and repeat use when you have customer records that connect agent activity to those outcomes.

What is the difference between mention rate and recommendation rate?

Mention rate counts responses that name a product. Recommendation rate counts responses that endorse it for the task. An agent can mention a product while advising against it.

What is a good agent task success rate?

There is no universal target independent of the task and test setup. Establish a baseline, report the number of attempts and failure reasons, and compare the same tasks under comparable conditions.

Does more agent traffic mean more customers?

Agent requests show activity. To count customers acquired through agents, you need evidence linking that activity to customer accounts and a defined attribution rule.