Events

A product event records that something meaningful happened in your application: a feature was used, a flow was completed, a document was exported. The same SDK that reports your errors reports these, so there is no second installation, no second sampling configuration and no second bill.

More practically: no arguments about why two tools disagree on how many users you have.

Events are defined in code

Events are declared where the behaviour lives, versioned with your releases, and reviewed in the same pull request as the feature they describe. In React that looks like this:

import { trackFeature } from "@errordock/browser";

trackFeature("recipe-generator");

The exact signature differs per platform — see the .NET, JavaScript, React and React Native guides — but the model does not. An event belongs to a named feature, and that name is the unit everything downstream aggregates on.

Defining events in code rather than in a dashboard has one consequence worth stating plainly: an event cannot exist until it is deployed, and it cannot silently change meaning without a commit.

Naming

The feature name is the part you will live with, because renaming it splits your history.

• Name the feature, not the widget. recipe-generator, not sidebar-button-3.
• Keep it stable across redesigns. The feature is the capability, not its current UI.
• Keep cardinality low. A feature name that includes a user id, a document id or a timestamp is not a feature name; it is a log line. Put those in event properties instead.

A useful test: if you would not put the name on a roadmap, it is probably too specific to be a feature.

Distinct users, not event count

Every report built on events counts distinct users first and events second. A feature one power user triggers four hundred times a day is not a widely adopted feature, and a metric that says otherwise will get you to invest in the wrong thing.

How events reach Product Health

A feature is created automatically the first time an event names it. From then on, Feature health shows its adoption beside its error rate and P95 latency, and Priorities can flag it when almost nobody uses it. An error rate means one thing in a feature 72 percent of your customers depend on and something else entirely in one that two people have ever opened.

That link is the reason product events live in the same system as errors rather than beside it. See Product Health for what Feature health and Priorities show.

Funnels and retention

Beyond counting single events, there are funnels of two to six steps, over a window of up to 30 days, and a retention cohort grid. During the beta these are enabled per organisation; D1, D7 and D30 retention are always shown. See Users and identity.

Related

• Feature usage
• Users and identity
• Data and privacy