# Product Usage Health

### Product usage health

<figure><img src="/files/gQcFhp1AcfroxYkj4hlj" alt=""><figcaption></figcaption></figure>

**Where to find it:** Settings → Products **Who can access it:** Admins only to configure. All team members see the results on customer profiles.

***

#### What it is

Product usage health measures how well your customers are actually using your product. It is not a single number — it is a per-product signal, calculated continuously, that tells your team whether each customer is engaging with your product in a meaningful way.

The result shows on the customer profile as a color-coded health indicator per product (Good / Fair / Poor), and feeds into the overall AI Health Assessment alongside experience and support signals.

***

#### How it works: the model

You define what "good" usage looks like for each product. Startdeliver then measures every customer against that definition, continuously, and produces a health status.

The model has three components you configure per product: the goal type, the goal targets, and the usage types attached to it.

***

#### Step 1 — Create a product

Go to Settings → Products and click Create new product.

Every product in Startdeliver represents something you want to measure usage for. This could be your core product, a module, an add-on, a feature area, or any discrete thing where usage matters. The demo account shows examples like Core Features, Analytics, Add-on 1, Add-on 2, and Logged in — each tracked independently.

**Product settings:**

**Name** — what the product is called across the platform.

**Abbreviation** — 1 to 3 characters shown on the customer profile header tile (e.g. COR for Core Features).

**Number of days to look for usage** — the rolling window Startdeliver uses when calculating health. Default is 35 days. Adjust this to match how often your customers naturally use the product — a daily-use tool might use 30 days, a quarterly-review tool might use 90.

**Exclude from average health** — tick this to track the product's health without it contributing to the customer's overall usage health score. Useful for optional add-ons, nice-to-have features, or products in beta where poor usage shouldn't penalise the overall health.

**Product weight in average health** — optionally weight this product more or less than others in the average. Set 2 to count it twice, 0.5 to count it half as much. Leave as Auto for equal weighting.

***

#### Step 2 — Set the goal type

The goal type defines what "usage" means for this product. Choose the one that best reflects how your product should actually be used.

**Unique days** The product should be used on a certain number of distinct days in a rolling month. Frequency matters more than volume — a customer who logs in 10 days is healthier than one who does everything in one session then disappears.

Use this for: core products where consistent daily or weekly engagement is the definition of good adoption.

**Usage count** The product should accumulate a total number of usage events in a rolling month. Individual session patterns don't matter — it's the total that counts.

Use this for: products with flexible usage patterns where the event volume is what's meaningful, not the spread across days.

**Depended count** The product's health goal scales with the volume of another usage event. The target is not a fixed number — it's proportional to how much of something else is happening. For example: the number of reports exported should be at least 20% of the number of dashboards created.

Use this for: features that should be used in proportion to other activity, where a fixed target would be misleading.

**Unique quota** A certain percentage of users should be performing specific usage events within a time period. Tracks breadth of adoption across the user base, not just volume.

Use this for: products where seat utilisation matters — you want to know that enough of the customer's users are active, not just that some power users are doing everything.

**Field value** Health is calculated based on a value stored in a custom field on the customer or user record, rather than live usage events. Use this when health data comes from an external system or calculation that you import into Startdeliver as a field value.

Use this for: products where the source of truth for usage lives outside the event tracking system.

***

#### Step 3 — Set goal targets

Goal targets define the thresholds for Good, Fair, and Poor. Anything below Fair is automatically Poor — you only need to set where Fair starts and where Good starts.

**Customer or user usage** — choose whether health is calculated per user or for the customer as a whole.

* **User** — each user is measured individually against the goal. Then the percentage of users achieving the goal determines the customer's overall product health.
* **Customer** — usage is measured in aggregate across all users. One large power user can compensate for inactive others.

**Goal count** — the number of times (or days, or events, depending on goal type) that constitutes Fair and Good usage for a single user or the customer total.

**Number of users** — when using User-based calculation, you set what percentage of users need to achieve Fair or Good for the customer's health to reflect that. For example: if 50% of users are achieving fair usage, the customer is Fair. If 80% are, they're Good.

The sliders in the UI let you set these thresholds visually. The platform shows you in plain language what the rule means as you configure it: "For one user to achieve fair usage, how many times in a rolling month should a usage event occur?"

**Advanced goal options** (visible depending on goal type):

* **Only count users with this product** — limits health tracking to users who have the product assigned, ignoring others. Useful for products with distinct user subsets.
* **User goal from a field value** — instead of a fixed goal count, the target is pulled from a custom field value per user or customer. Enables dynamic, account-specific targets.
* **No news is good news** — inverts the logic: a lower count is healthier. Use for things like support tickets opened, errors triggered, or downtime events, where fewer is better.
* **No fair** — removes the Fair band entirely. Customers are either Good or Poor. Use when there's no meaningful middle state.
* **Adjust for recent activity** — softens health targets for new customers who have recently been activated, accounting for the fact that they haven't had time to build up usage history.

***

#### Step 4 — Attach usage types

Usage types are the individual events that feed this product's health calculation. They are the raw signals — things like "Logged in", "Created dashboard", "Exported report", "Added page as favorite" — that your product sends to Startdeliver via the API.

Go to the Usage Types tab on the product. You'll see all available usage events in your account. Click any row to attach or detach it from this product.

One usage event can be attached to multiple products. A "Logged in" event might feed both your Core Features health and a Logged in product you track separately.

If you have not yet set up usage event tracking, refer to the API reference to get started. Usage events are sent to Startdeliver programmatically from your product.

***

#### Viewing product health

Once products are configured and usage data is flowing, health appears in three places:

**Customer profile header** — a tile per product showing Good / Fair / Poor with a colour indicator. The tile also shows a breakdown by product as coloured tags.

**Customer profile → AI Health Assessment** — product usage is one of the three inputs (alongside experience and support) that the AI reads when producing the overall assessment and recommended actions.

**Lists and filters** — you can filter your customer portfolio by product health. For example: all customers where Core Features health is Poor, sorted by ARR.

***

#### Common setups

**Core product — daily engagement tool** Goal type: Unique days. Target: Fair = 10 days in a rolling month, Good = 20 days. User-based calculation with 60% of users needed for the customer to be Fair.

**Add-on feature — usage volume tool** Goal type: Usage count. Target: Fair = 5 events, Good = 20 events. Customer-based calculation. Excluded from average health so it doesn't drag down the core score while adoption is still ramping.

**Support ticket tracker — no news is good news** Goal type: Usage count with No news is good news enabled. Zero tickets = Good. One or more = Fair or Poor depending on volume.

**Seat utilization — breadth matters** Goal type: Unique quota. Track that a meaningful percentage of licensed users are actually active each month. Fair = 50% of users seen, Good = 80%.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.startdeliver.io/health-and-metrics/product-usage-health.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.