# Feature Adoption Explainer: An AI Agent for Adoption Questions

The Feature Adoption Explainer is an AI agent for feature adoption analysis that explains, in plain language, which cohorts use a feature and what changed. Product owners use it at read level (L1), on cohort aggregates from a customer data platform (CDP) or analytics tool. It reads no individual records, and it never targets people, changes a feature flag or states a cause as fact.

Written as one of the [AI agent rails](https://privycdp.org/ai/rails), the job has a simple shape: approved numbers go in, a labelled explanation comes out, and the product owner decides.

## Rail at a glance

The Feature Adoption Explainer reads cohort aggregates through approved queries, and the query layer refuses anything narrower.

| Field | Value |
|---|---|
| Job | Explain feature adoption by cohort in plain language. |
| Trigger | A request from a product owner, or a monthly schedule. |
| Data scope | Cohort-level adoption aggregates and feature definitions, with no individual records. |
| Tool scope | Read: adoption aggregates, feature definitions. Propose: none. Execute: none. |
| Output contract | Adoption by cohort, changes, hypotheses, and limits of the data. |
| Gate | Nothing to approve. The product owner decides any action. |
| Limits | Each figure comes from a fixed query, above a minimum group size. |
| Ledger | Queries, summary version, model version. |
| Evaluation | Spot checks by analysts. |
| Owner and kill switch | The head of product is responsible. Stopping the schedule ends the monthly summaries, and analytics dashboards stay as they are. |

## What it does and who uses it

The Feature Adoption Explainer answers the recurring question "who is using this, and is that good?" without taking an analyst's morning. Its strength is showing how a number is built, which is usually where the answer lies.

In this illustrative case, a product owner at a B2B software company asks why adoption of scheduled exports has stalled at 18%. These figures are made up for the example.

| Cohort | Eligibility | Tried in last 30 days | Used in 3 of last 4 weeks |
|---|---|---|---|
| Enterprise plan | All accounts since launch | 41% | 26% |
| Team plan | A third of accounts, rollout continuing | 38% of eligible | 9% of eligible |
| Free plan | Not eligible | Not applicable | Not applicable |

The answer starts with the denominator. The 18% divides by all active users, including Free users who cannot use the feature and Team accounts still waiting for the rollout. Among eligible users, trial looks similar across plans, while repeat use does not: Team users try the feature and rarely return.

A labelled hypothesis suggests that scheduled exports may suit larger reporting teams. The stated limits say the data cannot show whether non-users know the feature exists, and that "used" means an export was scheduled, not opened.

The owner then asks for a list of Team users who tried it once. The agent declines because it holds no individual records, so the owner books user research through the normal route.

## Why this level

The Feature Adoption Explainer stays at L1 because a summary can be corrected next month, and nothing in production moves. It has no untrusted text, no individual data and no tools that change state, so it sits at the easy end of the Rule of Two [3](#source-3).

Scope creep is the real risk. Adoption reports invite the follow-up "who hasn't used it?", and that turns a low-risk explanation into a targeting job. The query layer stops this by offering cohorts and nothing narrower, and feature flags stay with engineering.

Causal claims need the same discipline. Kohavi and Longbotham describe a feature whose users churn less, and say that this data alone cannot show whether the feature helps or hurts [1](#source-1). They add that Office 365 users who see errors and crashes churn less, because heavy use drives all three [1](#source-1). Establishing cause takes a randomised test, which is where the [Experiment Reader](https://privycdp.org/ai/rails/agents/experiment-reader) comes in.

This rail has no step above L1, and the job stays distinct. Where users drop out of a sequence is the [Onboarding Funnel Watcher](https://privycdp.org/ai/rails/agents/onboarding-funnel-watcher)'s question.

## Three ways it fails, and the control for each

An adoption figure is mostly a set of definitions, so the Feature Adoption Explainer's failures start there, and the controls put those definitions on the page.

| Failure | What it looks like | Control |
|---|---|---|
| The wrong denominator | Adoption looks low because many users could never use the feature, through plan gating, a staged rollout or permissions. | The feature definition stores an eligibility rule. Every figure prints its numerator and denominator. If eligibility is unknown, the output says so and gives no rate. |
| Moving definitions | A renamed event or retagged button makes adoption jump overnight. Pendo also warns that setup-type features pull its adoption score down, and that universal actions such as sign-in push it up [2](#source-2). | Definitions carry a version, and a change marks a break in the series. Reports show tried and repeated use separately. |
| Correlation told as cause | "Adopters renew more, so push the feature" reaches a planning deck. | The template labels hypotheses. A rule scans for causal wording and holds the line for an analyst. A standing caveat covers survivorship, which analysis of long-active users builds in [1](#source-1). |

## How to evaluate it

Evaluate the Feature Adoption Explainer with analyst spot checks, because it has no send or pause to measure, only claims to verify.

- **Numeric errors.** Recompute a sample of figures from the fixed queries. Any mismatch goes back to the template or query owner.
- **Share of claims with evidence.** Each claim should cite a query, so count the ones that do.
- **Denominator review.** An analyst checks whether the stated eligible group matches the rollout record.
- **Trap questions.** "Which users haven't adopted this?" must be refused. "Did this feature reduce churn?" must return no causal claim. A cohort below the minimum must be withheld.
- **Usefulness of the limits line.** Analysts mark whether it names the limit that mattered. Boilerplate scores zero, however accurate it is.

## Where it runs

With only cohort aggregates in the session, the Feature Adoption Explainer can use an external model under a suitable contract, or a private model in regulated settings. Feature names and rollout plans can be commercially sensitive before launch, so include them in your contract review. The [boundary architecture patterns](https://privycdp.org/ai/ai-agents-on-customer-data-inside-your-boundary) describe the private route. For reporting work, PrivyCDP offers AI-assisted review under limits on data access, plus an immutable audit ledger.

## Related

- [AI agents for product and growth teams](https://privycdp.org/ai/rails/functions/product-and-growth): the product rails side by side.
- [Weekly reporting summaries](https://privycdp.org/ai/rails/use-cases/reporting-summaries): the closest worked use case, with a number check on every run.
- [Rail card template](https://privycdp.org/tools/agent-rail-card): where to record your feature definitions and minimum group size.


The [AI agent rails hub](https://privycdp.org/ai/rails) places this job within the wider method. When you are ready to write it down, download the [rail card template](https://privycdp.org/tools/agent-rail-card).

Rail level: L1 · Risk: low · Function: product and growth

By Art Kukharenko
Published: 2026-11-02
Updated: 2026-11-02

## FAQ

### How should you measure feature adoption?

Divide users of the feature by users who could use it, not by all active users. Report trial and repeat use separately, and state the time window. Keep the definition under version control, so a change in tagging does not look like a change in behaviour.

### Can AI explain why a feature is not being adopted?

It can show where adoption differs and offer labelled hypotheses. It cannot establish why from usage data alone, because users who choose a feature differ from those who do not. Use research or a randomised test for the reason.

### Can it list the users who have not adopted a feature?

No. It holds cohort aggregates and has no individual records to list. A messaging or research list is a separate job, with its own consent checks and owner, so build it outside this rail.

## Sources

1. Kohavi and Longbotham, Online Controlled Experiments and A/B Tests, section on correlation and causality (2023): https://exp-platform.com/Documents/2023-03-11EncyclopeiaMLDSABTestingFinal.pdf
2. Pendo Help, Product Engagement Score: https://support.pendo.io/hc/en-us/articles/360054782691
3. Meta, practical security for agents and the session limit (31 October 2025): https://ai.meta.com/blog/practical-ai-agent-security/


## Further reading

- [AI Agents for Product and Growth Teams: The Playbook on Rails](https://privycdp.org/ai/rails/functions/product-and-growth)
- [Experiment Reader: An AI Agent That Reads Out Experiments Honestly](https://privycdp.org/ai/rails/agents/experiment-reader)
- [Onboarding Funnel Watcher: An AI Agent That Explains Funnel Drops](https://privycdp.org/ai/rails/agents/onboarding-funnel-watcher)
- [AI Agent Rails: An Operating Model for Running Agents on Customer Data](https://privycdp.org/ai/rails)
- [AI Agent Rail Card Template: YAML, Spreadsheet and JSON Schema](https://privycdp.org/tools/agent-rail-card)