AI 产品经理03 Evaluation & Metrics
Chapter 04
4 / 10

AI Product Metrics: Measurement & Optimization

⏱️ 50 min

Build a North Star metric framework for AI products and master the unique DAU/retention/LTV calculations and optimization strategies for AI products

CHAPTER DECISION GOAL
01Product question

Build a North Star metric framework for AI products and master the unique DAU/retention/LTV calculations and optimization strategies for AI products

02Reviewable evidence

A reviewable product artefact: an assumption, prototype, evaluation result or launch decision.

03Definition of done

State the decision, the supporting evidence and the gate for moving to the next stage.

The most dangerous state for an AI product is when the team is busy every day but nobody can accurately answer "is this feature actually getting better." Usage alone isn't enough. Thumbs-up alone isn't enough. Model benchmarks definitely aren't enough. AI PMs need to manage a complete metrics chain from value to quality to cost.

So this page isn't just about dashboards. It's about building a metrics system that actually drives decisions.

AI Product Metrics Board


Bottom Line: AI Metrics Can't Just Track Growth -- Track the Price Too

Traditional products make a common mistake: if engagement is up, the product must be better. AI products need follow-up questions:

  1. Did users actually complete the task
  2. What was the completion quality
  3. How much did this result cost

Miss any one of these and your metrics will mislead you.


AI Metrics Look More Like a Three-Layer Structure

LayerWhat to track
BusinessRevenue, conversion, retention, ROI
Product / QualityTask success, satisfaction, accuracy, regenerate rate
Efficiency / CostLatency, token usage, cost per task, margin

If your dashboard only has the first and third layers without quality in the middle, you won't know why users are churning. If you only have quality without cost, you won't know why the business math doesn't work.


North Star Metric: Don't Make It Too Vague

Many AI products use "AI usage count" as their North Star. That metric is usually too shallow.

A more reasonable approach:

North Star = successful task completion x quality factor

Examples:

Product typeMore credible North Star
AI writing toolWeekly adopted output
AI support copilotResolved tickets assisted by AI
AI searchSuccessful answer sessions
AI coding assistantAccepted AI-generated code changes

The key is "the user actually used the result," not "AI just said something."


First Define What Success Means

AI PMs very easily skip this step and jump straight to event tracking.

But you must first define:

ScenarioWhat counts as success
AI summaryUser doesn't need to heavily rewrite to keep using it
AI draftingOutput is adopted, not just generated
AI supportProblem gets solved, not just more chat turns
AI searchUser gets a trustworthy answer and stops searching

Without a success definition, all downstream metrics are half-empty.


A Sufficient Core Metrics Set

1. Value metrics

MetricWhat it tells you
Task success rateDid the task get done
Adoption rateDo users keep using it
Assisted conversionDid AI actually drive business results

2. Quality metrics

MetricWhat it tells you
Satisfaction / thumbs upUser's subjective feeling
Regenerate rateIndirect signal of first-answer dissatisfaction
Hallucination rateIs high-risk content making things up
Edit distance / acceptance rateHow much generated content actually got changed

3. Efficiency metrics

MetricWhat it tells you
Avg latencyWhether users are willing to wait
Tokens per requestWhether prompts are growing out of control
Cost per successful taskThis is the real business metric
Model routing ratioWhether small/large model split is reasonable

Most Commonly Misread Metrics

MetricWhy it misleads
Session lengthLonger isn't necessarily better -- model might not be solving the problem
Total promptsMore doesn't mean value -- users might be retrying
Thumbs up ratePeople who don't give feedback aren't necessarily satisfied
Avg cost per requestWithout combining with success rate, insufficient information

AI PMs need to build a habit: any single metric needs a counter-metric alongside it.


How to Build a More Practical Dashboard

A more credible metrics board has at least 4 sections:

SectionCore question
Acquisition / activationAre users actually entering the AI scenario
Task qualityFirst-answer, re-answer, adoption quality
Cost / performanceResponse speed, cost level
Risk / trustBad answers, safety issues, complaints

This is way more useful than staring at a single "DAU curve."


Quality Metrics Must Mix Automated and Manual

Many AI products don't have good automated evaluation early on, so human review can't be skipped.

A more stable approach:

online metrics
  + sampled human review
  + labeled bad cases
  + weekly trend review

Automated metrics tell you "where problems might exist." Human review tells you "what the problem actually is."


Cost Metrics Must Connect to Business

Just reporting monthly API bills has little management value. You should be looking at:

MetricMore useful question
Cost per requestHow much does each call cost
Cost per successful taskHow much to get one thing done
AI gross marginIs there room left after AI costs
Wasted generation ratioHow much generated content never gets used

If you see usage growing but cost per successful task growing with it, that's not necessarily good news.


A Simple But Sufficient Weekly Review

Each week, the AI PM should answer at least these 5 questions:

  1. Which use case had a success rate change
  2. Which type of bad answers increased
  3. Why are users regenerating
  4. Which model route is burning the most money
  5. Which metric change is worth putting on next week's roadmap

Lock in these 5 questions and team data discussions get much clearer.


Practice

Take an AI feature you're working on. Look at your current dashboard, then fill in 3 questions:

  1. Is there a clear success definition right now
  2. Is there a cost per successful task
  3. Is there a stable human review sampling mechanism

If all 3 are missing, this metrics system is basically still in the "spectator" stage.


Every Metric Needs a Metric Contract

Continue the “preview first, register second” release. A label such as “registration rate” allows product, data, and engineering to calculate three different numbers.

FieldExample
MetricPreview-to-registration completion
DenominatorEligible unique users who saw a result preview
NumeratorUsers who verify and create an account within the window
ExclusionsStaff, test accounts, bots, and existing accounts
Window24 hours after the first preview
SegmentsChannel, device, region, and verification result
SourcesEvent, account, and experiment-assignment tables
OwnerProduct defines, data implements, engineering validates instrumentation
DecisionContinue, hold, or roll back using baseline and guardrails

If the definition changes during an experiment, create a new version. Never silently overwrite the old calculation.

When the Metric Improves, Check Four Traps

  1. Denominator changed: Did failed users disappear from measurement?
  2. Traffic changed: Is a new channel naturally easier to convert?
  3. Value moved forward: Did sign-up rise while later retention fell?
  4. Averages hide harm: Did one region or device regress sharply?

A Decision-Ready Review Statement

Known: registration completion improved; verification success remained stable.
Limit: mobile sample is still small and seven-day retention is immature.
Bad cases: some users thought preview content had already been saved permanently.
Decision: hold at 5%, fix messaging, and wait for mobile and retention evidence.

Completion Criteria

  • Primary metric has numerator, denominator, exclusions, and time window
  • Quality, cost, and risk guardrails travel with the primary metric
  • Dashboard can reach key segments and failure samples
  • Data delay, missingness, and definition version are visible
  • Weekly review ends in continue, hold, correct, or stop

Chapter Deliverable

Leave a Metric Decision Pack containing metric contract, baseline, guardrails, segments, bad cases, and this week's decision. Continue to AI Ethics & Compliance and check whether metric improvement costs users safety, privacy, or fairness.

📚 Related resources

Common questions

Open a question to review the practical answer.

What are the three layers of an AI product metrics system?

Business (revenue, conversion, retention, ROI), Product/Quality (task success, satisfaction, accuracy, regenerate rate), and Efficiency/Cost (latency, token usage, cost per task, margin). With only layers 1 and 3, you cannot explain why users churn; with quality but no cost, the business math never closes.

Why is 'AI usage count' a weak North Star metric?

Too shallow—it measures 'the AI talked', not 'the user used the result'. Better: successful task completion × quality factor, per product: AI writing tracks weekly adopted output, support copilot tracks AI-assisted resolved tickets, AI search tracks successful answer sessions, coding assistant tracks accepted AI-generated code changes.

Which AI metrics look healthy but are actively misleading?

Four common traps: session length (long can mean unresolved, not engaged), total prompts (high count can be retry frustration), thumbs-up rate (silent users are not necessarily satisfied), and avg cost per request (meaningless without success rate). For every metric, pair it with a counter-metric before drawing conclusions.

How do you define success for an AI feature?

Write it per scenario: AI summary—user does not need to heavily rewrite; AI drafting—the output is adopted, not just generated; AI support—the issue is resolved, not the chat lengthened; AI search—the user gets a trustworthy answer and stops searching. Without a success definition, every downstream metric is half-empty.

How should AI cost metrics be reported so they actually serve the business?

A monthly API bill alone is useless for management. Track four: cost per request, cost per successful task, AI gross margin (margin after AI cost), and wasted generation ratio (share of outputs never used). If usage is climbing while cost per successful task is also climbing, that is not necessarily good news.