Adoption Rate — метрика реального использования AI целевой аудиторией. Она отвечает не на вопрос «сколько лицензий выдали?» и не «сколько запросов прошло через модель?», а какая доля людей, которым AI действительно релевантен и доступен, регулярно использует его в своей работе.
№86 Coverage measures how much work AI handles; Adoption measures how many eligible people use it. One user can have high adoption but low coverage if they use AI for one tiny task. №88 Acceptance measures usefulness of outputs, not usage. №87 Time Savings measures realized labor benefit. №91 Autonomy measures eligible work completed without mandatory human.
Need: eligible user model, stable user identity, product access events, meaningful task/use-case taxonomy, activation definition and time window. №84 owns framework-level denominator/versioning discipline.
CONTROL: definitions of eligible, activation and active. DATA: user access, task/use-case events, sessions, outcomes. RUNTIME: emit events only. OFFLINE: WAU/MAU, cohorts, retention, stickiness and rollout analysis.
Failure = counting licenses as adoption, counting any login as meaningful use, denominator changes without versioning, test/bot accounts included, repeated prompts by one power user mistaken for broad adoption, or usage inflated by forced workflow.
Adoption says people use AI. It does not prove that AI is good, safe, economical, trusted or valuable. Those conclusions require acceptance, coverage, quality, time savings, cost and outcome metrics.
User technically has access to AI capability.
This is not adoption.
Role/use case allows and benefits from AI.
This is the preferred denominator.
Completed first real AI task, not just opened page.
Meaningful AI usage in week/month.
Recurring use across periods or meaningful task frequency.
Weekly Adoption Rate = weekly_active_eligible_users -------------------------------- eligible_users × 100% Example: eligible users = 1,000 weekly active eligible users = 420 Weekly Adoption Rate = 42%
User completed a real eligible workflow/use case through AI.
Example: generated output, analysis, code patch, research result or successful tool action.
Can count exploratory/failed/test usage; useful as diagnostic, not primary adoption event.
Measures exposure, not AI adoption.
active_user = has ≥ 1 meaningful_ai_task_completed within measurement window OPTIONAL stronger rule: has ≥ N meaningful tasks OR ≥ X active days depending on product usage cadence
Use a product-specific first-value event.
Shows onboarding friction.
Activated eligible users / newly eligible users.
| Metric | Meaning | Best when |
|---|---|---|
| DAU | Eligible active users in one day | AI is expected to be used daily: support desk, coding assistant, operations. |
| WAU | Eligible active users in one week | Most knowledge-work AI; good default for product adoption. |
| MAU | Eligible active users in one month | Lower-frequency use cases: monthly reporting, legal review, finance cycles. |
| Rolling 28d | Active in last 28 days | Stable trend smoothing across calendar month boundaries. |
Among monthly active users, how many use AI on a typical day?
More appropriate for many professional AI products.
Median active days per active user in the period.
Possible habitual user rule: user is habitual if: active in ≥ 3 of last 4 weeks AND completed ≥ 5 meaningful tasks AND at least 1 task accepted/successful Then: Habitual Adoption Rate = habitual eligible users ------------------------ eligible users
Activated users who return in the next relevant period.
Shows whether novelty becomes habit.
Useful after product stabilizes.
Track separately from continuous retention.
W4 retention = cohort users active in week 4 / users activated in cohort week
| Cohort | Why slice |
|---|---|
| Role / team | Different tasks and AI relevance. |
| Use case | Adoption may be high for research but low for actions. |
| Rollout wave | Measure onboarding/process improvements over time. |
| Experience level | New vs mature users often behave differently. |
| Region / language | Model/tool quality and policy availability may differ. |
| Manager / org unit | Useful for rollout diagnosis, but avoid turning into individual surveillance. |
Activation cohort W0 W1 W2 W3 W4 ---------------------------------------------------- 2026-07-06 100% 68% 57% 51% 48% 2026-07-13 100% 73% 64% 58% 55% 2026-07-20 100% 79% 72% 67% 63% 2026-07-27 100% 81% 75% 70% ... Interpretation: newer onboarding / product version may be producing better retention. Need: compare cohort composition, not only raw percentages.
eligible_user if: account_active = true AND AI_access = true AND role in supported_roles AND at least one relevant use case AND not test/service/bot account AND policy allows usage AND user is within rollout cohort optional: minimum work volume expected task frequency
Company: 10,000 employees AI licenses: 7,500 Eligible users: 3,200 WAU: 1,600 If denominator = employees: Adoption = 16% If denominator = licenses: Adoption = 21.3% If denominator = eligible users: Adoption = 50% All three are mathematically correct. Only one answers: “What share of people who can reasonably use this AI are actually using it weekly?”
User may rely on AI for information discovery.
Uses only for drafts, not final output.
Trust/permissions/HITL may limit usage.
Quality/complexity can determine whether habit forms.
| Scenario | Adoption | Coverage | Meaning |
|---|---|---|---|
| Many users, one tiny use case | High | Low | AI is popular but not deeply embedded. |
| Few specialists, huge task volume | Low | High | Broad work impact concentrated in few users. |
| Many users, many tasks | High | High | Broad and deep deployment. |
| Few users, few tasks | Low | Low | Early/failed rollout or intentionally niche use case. |
Usage high because users cannot avoid it.
Launch curiosity can inflate first-week adoption.
Many prompts may indicate poor first-pass usefulness.
Users interact because process requires AI but total human time increases.
User can enter product.
Knows AI exists and relevant scenario.
Starts meaningful workflow.
First successful task completed.
Next-period retention.
time_to_activation = first_successful_ai_task_at − eligibility_start_at Track: median p75 p90 Example: median = 1.2 days p90 = 12 days This suggests: most users activate quickly, but a significant tail struggles.
100 weekly active users 1 power user: 800 tasks 99 users: 2 tasks each Average: 9.98 tasks/user Median: 2 tasks/user Conclusion: average suggests heavy adoption, median shows most users barely use it. Always inspect: median p25/p75 power-user concentration
Share of meaningful tasks produced by top 10% users.
More robust than mean usage.
Share of eligible teams with meaningful weekly usage.
Interactive human use; denominator = eligible humans.
Scheduled/system-triggered AI; measure Coverage/Autonomy separately.
User initiates but downstream AI runs autonomously; classify both user adoption and workflow outcome.
Known adoption behavior.
Users may use consumer AI/tools outside company instrumentation.
Use periodic survey/interview for shadow usage; do not infer it from product logs.
| Question | Why |
|---|---|
| Which tasks do you use AI for? | Discover missing use-case taxonomy. |
| Which tasks would you like to use AI for but cannot? | Opportunity / product gaps. |
| Why do you avoid AI? | Trust, quality, policy, UX, awareness, access. |
| How often does AI output require rework? | Qualitative cross-check vs acceptance instrumentation. |
| Does AI reduce your active work time? | Hypothesis for №87, not authoritative measurement by itself. |
Measure activation and W4 retention, not clicks.
Compare usage/coverage before vs embedded experience.
Does improved acceptance lead to higher retained usage?
Use staggered cohort or A/B where practical.
| Acceptance High | Acceptance Low | |
|---|---|---|
| Adoption High | Strong product fit. Investigate coverage/time savings next. | Users are trying it but outputs disappoint / forced workflow / retries. |
| Adoption Low | Quality may be good but awareness, access, workflow integration or habit is weak. | Weak fit or early product; fix quality before pushing adoption. |
Adoption Rate.
Coverage.
Potential company time saved = eligible users × adoption rate × average eligible task frequency × average human active time saved per task Example: 1,000 eligible users × 40% weekly adoption × 8 tasks/week × 6 min saved/task = 19,200 human minutes/week = 320 hours/week But only if: task frequency, time savings, quality are empirically measured.
If AI is embedded in core daily workflow and validated useful.
Not every eligible user needs daily use.
High adoption among niche eligible cohort may be success.
DAU targets are meaningless.
Drop after release may signal quality/UX/access issue.
New-user onboarding health.
Does novelty become habit?
Friction in discovery/onboarding.
Is usage dominated by a few power users?
How many supported scenarios each cohort actually uses.
Difference between strongest and weakest eligible segments.
Inactive users returning after product/change/training.
Metric: Weekly Adoption Rate Purpose: measure broad weekly usage among users for whom AI is relevant and available. Numerator: unique eligible users with ≥1 meaningful AI task completed in week Denominator: eligible users active in organization during that week Exclusions: test accounts bots/service users disabled users roles without relevant AI use cases Window: ISO week / rolling 7d (choose one and version it) Mandatory slices: role/team use_case rollout cohort region/language product version Guardrails: acceptance_rate time_savings support/error rate Owner: AI Product Analytics Version: adoption_rate_v1
{
"event_id":"EVT-...",
"event_type":"meaningful_ai_task_completed",
"occurred_at":"...",
"user_id":"USR-...",
"task_id":"TASK-...",
"use_case":"draft_marketing_post",
"tenant_id":"...",
"eligibility":{
"ai_eligible":true,
"eligible_reason":"role_use_case"
},
"outcome":{
"success":true
},
"product_version":"2026.09.1",
"traffic_type":"human"
}
eligible_user_daily( date tenant_id user_id account_active ai_access supported_role rollout_enabled policy_allowed relevant_use_case eligible eligibility_version )
WITH eligible AS (
SELECT DISTINCT user_id
FROM eligible_user_daily
WHERE date BETWEEN :start AND :end
AND eligible = true
),
active AS (
SELECT DISTINCT user_id
FROM ai_events
WHERE occurred_at >= :start
AND occurred_at < :end
AND event_type = 'meaningful_ai_task_completed'
AND traffic_type = 'human'
)
SELECT
COUNT(active.user_id) AS active_users,
COUNT(eligible.user_id) AS eligible_users,
COUNT(active.user_id)::float
/ NULLIF(COUNT(eligible.user_id), 0)
AS adoption_rate
FROM eligible
LEFT JOIN active USING (user_id);
No duplicate identity across SSO/workspaces.
Automation traffic excluded from user adoption.
% users with explicit eligibility decision.
Events fire only after actual qualifying interaction/task.
Team/use-case cohorts rather than individual leaderboard.
Avoid exposing individual behavior indirectly.
Adoption usually needs task event, not prompt/output text.
Align with №76 privacy/governance.
BAD OBJECTIVE:
“Get adoption to 80%.”
BETTER:
“Increase weekly adoption
among eligible users
from 42% → 55%
while:
acceptance_rate ≥ baseline
time_savings > 0
support incidents do not increase
no risk-policy regression.”
Usage is a means.
Value is the outcome.
LOW ADOPTION ↓ Do users have access? no → rollout/access problem yes ↓ Are they eligible/relevant? no → denominator problem yes ↓ Do they know the use case? no → discovery/training yes ↓ Do they attempt first task? no → UX/integration/friction yes ↓ Do they reach first success? no → quality/tool failure yes ↓ Do they return? no → weak recurring value / habit / workflow fit yes ↓ Is usage concentrated in few users? yes → breadth problem no → adoption broadly healthy Then inspect: Acceptance Coverage Time Savings Support/Error Cohorts
Users enabled; no behavioral evidence.
Users reach first value.
Usage returns across weeks.
AI becomes normal part of relevant workflows.
High adoption + high coverage + proven value.
DATA 1. user_id 2. eligibility flag 3. eligibility version 4. meaningful_ai_task_completed 5. use_case 6. occurred_at 7. traffic_type 8. product version METRICS 1. eligible users 2. activated users 3. activation rate 4. weekly active eligible users 5. weekly adoption rate 6. W4 retention 7. median meaningful tasks / WAU 8. top-10% usage share SLICES 1. role/team 2. use_case 3. rollout cohort 4. product version GUARDRAILS 1. acceptance rate 2. time savings 3. support/error rate
| Question | Status |
|---|---|
| Who exactly is eligible? | Required |
| What event makes a user active? | Required |
| Is it meaningful AI use rather than login? | Required |
| Are bots/test/service accounts excluded? | Required |
| What is the natural usage window: day/week/month? | Required |
| Is activation tracked separately from retention? | Recommended |
| Do we show cohort adoption? | Recommended |
| Do we show sample size and denominator? | Required |
| Is definition versioned? | Required |
| Is adoption paired with quality/value guardrails? | Required for value claims |
You are designing Adoption Rate analytics for an AI product.
1. Define the target user population.
2. Separate:
access,
eligibility,
activation,
active usage,
habitual adoption,
retention.
3. Do not use licenses or logins as adoption.
4. Define one meaningful usage event.
5. Choose DAU/WAU/MAU based on natural task cadence.
6. Specify:
numerator,
denominator,
exclusions,
measurement window,
cohort dimensions,
definition version.
7. Exclude:
bots,
service accounts,
test traffic,
disabled users,
irrelevant roles.
8. Show:
activation rate,
adoption rate,
retention,
median task frequency,
usage concentration.
9. Segment by:
role/team,
use case,
rollout cohort,
product version,
region/language where relevant.
10. Pair adoption with:
Acceptance Rate,
Coverage,
Time Savings
and operational guardrails.
11. Treat survey data as complementary,
not as authoritative behavioral measurement.
12. Compute authoritative rates deterministically
in analytics SQL/code, not with an LLM.
| Question | Answer |
|---|---|
| Separate component? | N/A. Product analytics/events/warehouse are implementation pieces; Adoption Rate is a governed metric. |
| Minimum 80% value? | Eligible user model + meaningful usage event + WAU/eligible + activation + W4 retention + cohort slices. |
| When overkill? | Internal prototype with no real rollout/user population yet. |
| Trigger? | “Are people actually using this AI?”, “Did rollout stick?”, “Where does onboarding fail?”. |
| How to measure uplift? | Compare eligible cohorts before/after onboarding/product changes and monitor retention, not only first-week usage. |
| Can rules/code replace LLM? | Yes. Eligibility rules and metric calculation should be deterministic. LLM may explain cohorts/anomalies or help draft taxonomy. |
ALL ACCOUNTS ↓ AI ACCESS? ↓ LICENSED / ENABLED ↓ RELEVANT ROLE / USE CASE? POLICY ALLOWED? REAL WORK EXISTS? ↓ ELIGIBLE USERS ↓ FIRST MEANINGFUL TASK ATTEMPT ↓ FIRST SUCCESS ↓ ACTIVATED USERS ↓ RETURN IN PERIOD? ↓ DAU / WAU / MAU ↓ ADOPTION RATE active eligible users --------------------- eligible users ↓ RETURN ACROSS PERIODS? ↓ RETENTION W1 W4 W8 ↓ REPEATED MEANINGFUL USAGE? ↓ HABITUAL ADOPTION ↓ HOW BROAD? cohorts teams roles use cases regions ↓ HOW DEEP? median tasks / active user use-case breadth coverage ↓ IS IT ACTUALLY GOOD? Acceptance Rate Time Savings Coverage Support/Error Quality Evals ═══════════════════════════════════ DO NOT COUNT: LICENSE as ADOPTION LOGIN as ACTIVE USE PROMPTS as USERS BOT TRAFFIC as HUMAN ADOPTION ONE-TIME TRY as HABIT FORCED WORKFLOW as VALUE ═══════════════════════════════════ THE CENTRAL FORMULA: WEEKLY ADOPTION RATE = WEEKLY ACTIVE ELIGIBLE USERS ────────────── ELIGIBLE USERS BUT THE CENTRAL QUESTION IS: “ARE THE PEOPLE WHO COULD REALISTICALLY BENEFIT FROM THIS AI RETURNING TO USE IT IN REAL WORK — BECAUSE IT IS ACTUALLY USEFUL?” THAT IS ADOPTION.
A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №85 Adoption Rate.
B–E. Existing boundary and placement. The existing conceptual boundary, class METRIC, default N/A and owner Evals / Analytics / Management remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.
F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.
I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.
K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.