Customer Breakdown

A single impact score tells you whether a feature moved the metric. The Customer Breakdown on a dev item’s detail page tells you who it moved — which customers adopted the feature, how heavily they use it, and how the impact is distributed across them. A feature that looks flat overall can be a big win for a handful of power users; a feature that looks like a win can be riding on one outlier. The breakdown shows you which.

Where to find it

Open a dev item that has been released — one in Measuring, Complete or Archived. Below the overall impact, you’ll see a Customer Breakdown section. It leads with a headline — “18 of 40 customers adopted (45%)” — then a distribution bar, then a table of individual customers.

Items still in Planning or Development don’t show the section at all, however many events have arrived.

If the section shows “Customer data is being calculated,” no per-customer results have been produced yet. If it shows “Insufficient data (N customers): too few events to score yet,” results exist but nobody could be scored — see What the breakdown needs, because that one does not always resolve on its own. And if it shows “Customer data is temporarily unavailable,” the results couldn’t be loaded just then — reload the page.

The breakdown is available for dev items measured by Count occurrences or Time to complete. Conversion rate and Overall activity describe your whole customer base at once, and Revenue (manual) is a number you enter yourself, so none of the three can be split customer by customer — on those items the section says so directly instead of leaving you waiting. The feature’s overall impact score is unaffected either way.

What the breakdown needs

Scoring a customer means comparing them against themselves before the release, so it takes both sides of that comparison:

1. Activity in the period before the release date — the customer’s own baseline. For a Count occurrences item that means qualifying events; for Time to complete it means completed start-to-end pairs, not raw events.
2. Enough of it to be a baseline rather than a coincidence — a handful, not one.
3. Use of the feature since the release. A customer who hasn’t picked it up yet has no “after” to compare.

Anyone missing one of the three is held in insufficient data rather than scored against zero — a low-traffic or not-yet-adopting customer never drags the picture down unfairly.

Point 3 resolves on its own as customers adopt. Points 1 and 2 do not: a customer who first appears after release has nothing to be compared against, ever.

Burn-in does not fill this in

Burn-in lets a feature with no pre-release data earn an overall impact score from its first post-release weeks. The Customer Breakdown does not work that way — it always compares against the pre-release window.

So a feature that was instrumented at release will get an overall score in time while its breakdown keeps saying insufficient data, and waiting will not change that. If you want the per-customer view, instrument the feature before you release it.

The distribution bar

Before the per-customer table, one bar — Frequency — how often they use it — gives you the shape at a glance, grouping adopters into the usage cohorts below. It answers “is this a feature a few people lean on, or one everybody touches lightly?”

Impact isn’t shown as a bar here. The feature’s overall impact is the headline at the top of the dev item, and each customer’s own impact is a column in the table below. The two are measured against different things — a customer’s impact is measured against their own activity before the release, while their cohort is a rank against your other customers — so they don’t belong on a shared scale.

Usage cohorts

A cohort is a rank, not a rating. VEKTIS measures how many days a week each adopter uses the feature, sorts every adopter of this dev item by that number, and cuts the list into bands:

Cohort	Where they sit
Power	The top tenth — the heaviest users of this feature
Active	The next fifth
Standard	The broad middle, around four in ten adopters
Low-touch	The bottom third
Non-adopters	Haven’t picked the feature up at all — a band on the Frequency bar only, never a value in the table’s Cohort column

Because the bands are cut from your own list, they always fill. If every adopter uses the feature daily, someone is still ranked Low-touch — it means “lowest of a heavy-using group,” not “barely uses it.” Hover the cohort to see the number it was ranked on, e.g. 6.96 active days/week, which is usually what explains a surprising label.

The band sizes are provisional and may be retuned as real usage distributions come in.

Tip

Cohorts are about frequency, not impact. A Low-touch customer can still show significant impact, and a Power user can show none. That combination — heavy use, little measured impact — is often the most interesting thing on the page.

The customer table

Each row is one customer who adopted the feature and has enough data to be scored. Everyone else is accounted for in the footer line below the table.

Column	What it shows
Customer	The customer’s name, if your product has sent one — hover to see their identifier. Names come from the optional name on identify(); without it this column shows the raw customer ID.
Cohort	Where they rank among this feature’s adopters — Power, Active, Standard, or Low-touch. Blank if VEKTIS has no usable frequency to rank them on.
Uses	How often they use it — daily, weekly, monthly, or rarely — plus whether they now rely on it more, less, or about the same as before. Blank alongside a blank Cohort, for the same reason.
Seats	How many people at that customer used the feature, out of everyone there VEKTIS has seen using the product — for example 14 of 30 (47%). This is not a count of licences they bought — hover the column heading and it says so. A dash means VEKTIS can’t tell who used it at that customer; the whole column is hidden when that’s true for everyone.
Impact	The impact for that customer — Significant, Confirmed, or Signal. A dash on both this and Score means the customer qualified for a row but no score came through.
Score	That customer’s impact score.

The table shows the top 8 customers by default. Above that, a Show all button appears with the full count — Show all 23 — and Show less collapses it again.

A footer line accounts for everyone not in the table — for example “12 not adopted · 5 insufficient data (too few events to score yet).” Either half appears on its own when the other is zero. Customers with too little activity are held out of the scored view rather than counted as zero impact, so a low-traffic customer never drags the picture down unfairly.

How to read it

You see	What it’s telling you
Significant impact on your Power and Active rows	Your heaviest users are getting the most out of it — a strong signal the feature earns its keep.
High adoption, but most rows read Signal	People are trying it, but it isn’t changing behavior much. Worth asking whether it solves the problem you thought it did.
A few Significant rows and a large not adopted count in the footer	The impact is real but narrow. Decide whether to drive broader adoption or accept it as a power-user feature.
Almost everyone in insufficient data	If adoption is still ramping, this resolves as customers pick the feature up. If the feature had no pre-release activity to compare against, it will not — see What the breakdown needs.

Note

The per-customer view answers a different question than the overall score. The overall score asks “did this feature work?” The breakdown asks “who did it work for?” — the input you need when deciding whether to double down, broaden, or move on.

Related

• Impact Scores — how the score for each customer (and overall) is measured
• Acting on Impact Results — turning a result into a decision
• Initiative Health — rolling many dev items up to the initiative level, including customer reach