85 / ADOPTION RATE / ACTIVATION · WAU · MAU · STICKINESS · COHORTS
85 / METRIC / EVALS · ANALYTICS · MANAGEMENT

ADOPTION
RATE.

Adoption Rate — метрика реального использования AI целевой аудиторией. Она отвечает не на вопрос «сколько лицензий выдали?» и не «сколько запросов прошло через модель?», а какая доля людей, которым AI действительно релевантен и доступен, регулярно использует его в своей работе.

Главный принцип: adoption начинается с правильного denominator. Если считать всех сотрудников компании, метрика будет занижена; если считать только уже активных пользователей — завышена. Нужна eligible population: те, у кого есть доступ, релевантный use case и реальная возможность применять AI.
00. ARCHITECTURAL STATUS

PRODUCT / USAGE METRIC

№85 = METRIC / DEFAULT N/A / SEPARATE COMPONENT N/A / Evals / Analytics / Management. Это первая конкретная метрика после №84 AI Metrics Framework: реальное использование AI целевой аудиторией.
TYPEMETRICProduct usage / adoption.
DEFAULTN/AObserved, not toggled.
USE WHENAI IS AVAILABLE TO USERSRollout, launch, cohort, product health.
SEPARATE COMPONENTN/AAnalytics implementation may exist separately.
LIVES INEVALS / ANALYTICS / MANAGEMENTProduct analytics + management.
VALUEREAL BEHAVIORDistinguish access from adoption.
01A. BOUNDARIES

WHAT ADOPTION RATE DOES — AND DOES NOT — MEASURE

BOUNDARY WITH NEIGHBORS

№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.

PREREQUISITES

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 / DATA / OFFLINE

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 CONTRACT

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.

DOES NOT OWN

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.

01. ADOPTION FUNNEL

LICENSED → ELIGIBLE → ACTIVATED → ACTIVE → HABITUAL

01 / ACCESS

Licensed / enabled

User technically has access to AI capability.

This is not adoption.

02 / ELIGIBLE

Relevant user

Role/use case allows and benefits from AI.

This is the preferred denominator.

03 / ACTIVATED

First meaningful use

Completed first real AI task, not just opened page.

04 / ACTIVE

Uses in period

Meaningful AI usage in week/month.

05 / HABITUAL

Repeated retained use

Recurring use across periods or meaningful task frequency.

Самая частая ошибка — прыгнуть из “licensed” сразу в “adoption”. Реальная воронка должна отделять доступ от релевантности, activation и устойчивого поведения.
02. PRIMARY FORMULA

WAU / ELIGIBLE USERS

Weekly Adoption Rate =

weekly_active_eligible_users
--------------------------------
eligible_users
× 100%

Example:

eligible users = 1,000
weekly active eligible users = 420

Weekly Adoption Rate = 42%
“Active” должен означать meaningful AI usage, а не dashboard view, page open или authentication event.
03. ACTIVE USER DEFINITION

WHAT COUNTS AS MEANINGFUL USE?

GOOD

Completed AI task

User completed a real eligible workflow/use case through AI.

GOOD

Meaningful interaction

Example: generated output, analysis, code patch, research result or successful tool action.

WEAK

Prompt sent

Can count exploratory/failed/test usage; useful as diagnostic, not primary adoption event.

BAD

Login / page view

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
04. ACTIVATION

FIRST VALUE MOMENT

ACTIVATION EVENT

First successful relevant task

Use a product-specific first-value event.

TIME TO ACTIVATE

Access → first value

Shows onboarding friction.

ACTIVATION RATE

Who reaches first value?

Activated eligible users / newly eligible users.

Activation Rate = activated eligible users / newly eligible users
Activation не равна long-term adoption, но часто является самым полезным leading indicator after rollout.
05. DAU / WAU / MAU

CHOOSE WINDOW FROM NATURAL USAGE CADENCE

MetricMeaningBest when
DAUEligible active users in one dayAI is expected to be used daily: support desk, coding assistant, operations.
WAUEligible active users in one weekMost knowledge-work AI; good default for product adoption.
MAUEligible active users in one monthLower-frequency use cases: monthly reporting, legal review, finance cycles.
Rolling 28dActive in last 28 daysStable trend smoothing across calendar month boundaries.
A monthly process should not be penalized for low DAU. Measurement window must match expected natural behavior.
06. STICKINESS

HOW OFTEN ACTIVE USERS COME BACK

DAU / MAU

Daily stickiness

Among monthly active users, how many use AI on a typical day?

DAU / MAU
WAU / MAU

Weekly stickiness

More appropriate for many professional AI products.

WAU / MAU
ACTIVE DAYS

Frequency

Median active days per active user in the period.

median(unique active days / user)
Stickiness is useful only relative to expected task frequency. A monthly reporting assistant can be valuable with low DAU/MAU.
07. HABITUAL ADOPTION

ONE-TIME TRY ≠ ADOPTION

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
Thresholds should reflect product cadence and be versioned. Do not universally hard-code “5 tasks” as truth.
08. RETENTION

DO ACTIVATED USERS KEEP USING AI?

W1

Week-1 retention

Activated users who return in the next relevant period.

W4

Week-4 retention

Shows whether novelty becomes habit.

W8 / M3

Longer retention

Useful after product stabilizes.

RESURRECTION

Returning after inactivity

Track separately from continuous retention.

W4 retention =
  cohort users active in week 4
  / users activated in cohort week
09. COHORT ADOPTION

GLOBAL RATE CAN HIDE ROLLOUT FAILURE

CohortWhy slice
Role / teamDifferent tasks and AI relevance.
Use caseAdoption may be high for research but low for actions.
Rollout waveMeasure onboarding/process improvements over time.
Experience levelNew vs mature users often behave differently.
Region / languageModel/tool quality and policy availability may differ.
Manager / org unitUseful for rollout diagnosis, but avoid turning into individual surveillance.
10. COHORT RETENTION TABLE

THE CLASSIC ADOPTION VIEW

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.
11. ELIGIBLE POPULATION

THE DENOMINATOR MODEL

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
Eligibility can change over time. Store eligibility snapshots or effective-date rules so historical adoption remains reproducible.
12. LICENSED vs ELIGIBLE

WHY LICENSE COUNT IS A BAD DENOMINATOR

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?”
13. ADOPTION BY USE CASE

ONE USER CAN ADOPT AI UNEVENLY

RESEARCH

High adoption

User may rely on AI for information discovery.

WRITING

Medium adoption

Uses only for drafts, not final output.

ACTIONS

Low adoption

Trust/permissions/HITL may limit usage.

ANALYSIS

Variable

Quality/complexity can determine whether habit forms.

User-level adoption answers “who uses AI”; use-case adoption shows where AI is becoming part of work.
14. ADOPTION ≠ COVERAGE

USERS vs WORK

ScenarioAdoptionCoverageMeaning
Many users, one tiny use caseHighLowAI is popular but not deeply embedded.
Few specialists, huge task volumeLowHighBroad work impact concentrated in few users.
Many users, many tasksHighHighBroad and deep deployment.
Few users, few tasksLowLowEarly/failed rollout or intentionally niche use case.
15. ADOPTION ≠ VALUE

HIGH USAGE CAN STILL BE BAD

FORCED

Workflow mandates AI

Usage high because users cannot avoid it.

NOVELTY

Initial spike

Launch curiosity can inflate first-week adoption.

LOW QUALITY

Repeated retries

Many prompts may indicate poor first-pass usefulness.

SHADOW WORK

AI adds step

Users interact because process requires AI but total human time increases.

Always pair adoption with Acceptance, Time Savings, Coverage and qualitative user/review signals.
16. ACTIVATION FRICTION

WHERE USERS DROP BEFORE FIRST VALUE

ACCESS

Enabled

User can enter product.

DISCOVERY

Understands use

Knows AI exists and relevant scenario.

FIRST TASK

Attempts

Starts meaningful workflow.

SUCCESS

Gets usable output

First successful task completed.

RETURN

Comes back

Next-period retention.

Drop-off tells you whether the bottleneck is awareness, onboarding, capability, quality or recurring utility.
17. TIME TO VALUE

HOW FAST DOES A NEW ELIGIBLE USER REACH FIRST SUCCESS?

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.
18. FREQUENCY DISTRIBUTION

AVERAGE TASKS/USER CAN BE MISLEADING

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
19. CONCENTRATION

IS ADOPTION BROAD OR DRIVEN BY A FEW POWER USERS?

TOP 10% SHARE

Usage concentration

Share of meaningful tasks produced by top 10% users.

tasks(top 10%) / all meaningful tasks
MEDIAN TASKS/WAU

Typical depth

More robust than mean usage.

median(tasks per weekly active user)
ACTIVE TEAM SHARE

Organizational breadth

Share of eligible teams with meaningful weekly usage.

active eligible teams / eligible teams
20. BOT / AUTOMATION TRAFFIC

SEPARATE HUMAN ADOPTION FROM MACHINE USAGE

HUMAN

User adoption

Interactive human use; denominator = eligible humans.

AUTOMATION

Workflow adoption

Scheduled/system-triggered AI; measure Coverage/Autonomy separately.

HYBRID

Human-triggered automation

User initiates but downstream AI runs autonomously; classify both user adoption and workflow outcome.

A bot generating 100,000 requests/day should not make DAU/WAU look healthy.
21. SHADOW AI

OFFICIAL ADOPTION CAN LOOK LOW WHILE REAL AI USE IS HIGH

OFFICIAL PRODUCT

Instrumented

Known adoption behavior.

EXTERNAL AI

Unobserved

Users may use consumer AI/tools outside company instrumentation.

SURVEY / RESEARCH

Complement analytics

Use periodic survey/interview for shadow usage; do not infer it from product logs.

22. ADOPTION SURVEY

BEHAVIORAL LOGS + SELF-REPORT

QuestionWhy
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.
Survey enriches behavioral data; it should not replace instrumented usage measurement.
23. CAUSAL ADOPTION EXPERIMENTS

WHAT ACTUALLY IMPROVES ADOPTION?

ONBOARDING

Guided first task

Measure activation and W4 retention, not clicks.

INTEGRATION

AI inside workflow

Compare usage/coverage before vs embedded experience.

QUALITY UPLIFT

Better output

Does improved acceptance lead to higher retained usage?

TRAINING

Enablement

Use staggered cohort or A/B where practical.

24. ADOPTION + ACCEPTANCE

TRUST / UTILITY MATRIX

Acceptance HighAcceptance Low
Adoption HighStrong product fit. Investigate coverage/time savings next.Users are trying it but outputs disappoint / forced workflow / retries.
Adoption LowQuality may be good but awareness, access, workflow integration or habit is weak.Weak fit or early product; fix quality before pushing adoption.
25. ADOPTION + COVERAGE

BREADTH vs DEPTH

BREADTH

How many users?

Adoption Rate.

DEPTH

How much work?

Coverage.

Both are needed for deployment maturity. High breadth with low depth often means shallow experimentation.
26. ADOPTION + TIME SAVINGS

REALIZED VALUE

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.
Adoption scales value already proven elsewhere. It does not create the per-task value estimate by itself.
27. ADOPTION TARGETS

SET BY USE CASE, NOT BY ABSTRACT “80%”

MANDATORY HIGH-FREQUENCY

Target can be high

If AI is embedded in core daily workflow and validated useful.

OPTIONAL KNOWLEDGE TOOL

Moderate target

Not every eligible user needs daily use.

SPECIALIST TOOL

Small denominator

High adoption among niche eligible cohort may be success.

LOW-FREQUENCY PROCESS

Use monthly/quarterly

DAU targets are meaningless.

28. ADOPTION ALERTS

MONITOR CHANGE, NOT ONLY LEVEL

ΔWAU

Weekly Active Change

Drop after release may signal quality/UX/access issue.

ACT

Activation Rate

New-user onboarding health.

W4

Retention

Does novelty become habit?

TTF

Time to First Value

Friction in discovery/onboarding.

CONC

Concentration

Is usage dominated by a few power users?

USE

Use-case Breadth

How many supported scenarios each cohort actually uses.

SEG

Cohort Gap

Difference between strongest and weakest eligible segments.

REV

Reactivation

Inactive users returning after product/change/training.

29. METRIC DEFINITION CARD

CANONICAL ADOPTION CONTRACT

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
30. EVENT MODEL

MEASURE ADOPTION FROM MEANINGFUL PRODUCT EVENTS

{
  "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"
}
Do not derive authoritative adoption from model provider request logs: one user task can generate many model calls, retries and subagents.
31. USER ELIGIBILITY SNAPSHOT

REPRODUCE HISTORICAL DENOMINATORS

eligible_user_daily(
  date
  tenant_id
  user_id
  account_active
  ai_access
  supported_role
  rollout_enabled
  policy_allowed
  relevant_use_case
  eligible
  eligibility_version
)
If roles/access change, current HR/account data cannot always reconstruct last quarter's denominator. Snapshot or effective-date model solves this.
32. SQL-STYLE CALCULATION

DETERMINISTIC COMPUTATION

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);
LLM не нужен для authoritative calculation. Это SQL/analytics code with governed definitions.
33. DATA QUALITY CHECKS

BEFORE PUBLISHING ADOPTION

IDENTITY

User mapping

No duplicate identity across SSO/workspaces.

TRAFFIC TYPE

Human vs bot

Automation traffic excluded from user adoption.

ELIGIBILITY

Coverage

% users with explicit eligibility decision.

EVENT QUALITY

Meaningful usage

Events fire only after actual qualifying interaction/task.

34. PRIVACY

ADOPTION ANALYTICS SHOULD NOT BECOME EMPLOYEE SURVEILLANCE

AGGREGATE

Default view

Team/use-case cohorts rather than individual leaderboard.

MIN SAMPLE

Suppress tiny cohorts

Avoid exposing individual behavior indirectly.

NO RAW CONTENT

Not needed

Adoption usually needs task event, not prompt/output text.

GOVERN

Access / retention

Align with №76 privacy/governance.

35. ANTI-PATTERNS

HOW ADOPTION NUMBERS GET GAMED

LICENSES = ADOPTION
Access is mistaken for behavior.
MEANINGFUL ACTIVE USERS
ALL EMPLOYEES DENOMINATOR
Irrelevant roles depress rate.
ELIGIBLE POPULATION
LOGIN = ACTIVE
Exposure inflates usage.
MEANINGFUL TASK EVENT
PROMPT COUNT
Retries and power users inflate broad adoption.
UNIQUE USERS + TASKS
ONE-WEEK SPIKE
Launch novelty presented as habit.
RETENTION / HABITUAL
FORCED USAGE
Workflow mandate produces artificial adoption.
PAIR WITH VALUE METRICS
GLOBAL AVERAGE
Strong teams hide weak cohorts.
COHORTS
BOT TRAFFIC
Automation inflates human activity.
TRAFFIC TYPE SEPARATION
36. GOODHART GUARDRAIL

DON'T REWARD USAGE FOR ITS OWN SAKE

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.
37. DIAGNOSTIC TREE

WHY IS ADOPTION LOW?

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
38. ADOPTION MATURITY

FROM ACCESS TO EMBEDDED HABIT

L0

Access

Users enabled; no behavioral evidence.

L1

Activation

Users reach first value.

L2

Repeat

Usage returns across weeks.

L3

Habit

AI becomes normal part of relevant workflows.

L4

Embedded

High adoption + high coverage + proven value.

39. MVP

THE MINIMUM TRUSTWORTHY ADOPTION SYSTEM

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
40. PRACTICAL CHECKLIST

BEFORE PUBLISHING “ADOPTION = X%”

QuestionStatus
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
41. AI PROMPT TEMPLATE

ADOPTION ANALYTICS ASSISTANT

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.
42. PRACTICAL DECISION

WHAT TO BUILD

QuestionAnswer
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.
43. FINAL MAP

FROM ACCESS TO HABIT

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.

ECC RETROFIT / PRACTICAL HARNESS INTEGRATION

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.