Feature IDs

A feature_id is the short string identifier that connects a tracked event from your application to a Dev Item in VEKTIS. It’s the glue between “an event happened in my app” and “VEKTIS knows which feature this counts toward.”

When your app calls vektis.track('feature.used', { feature_id: 'checkout-completed' }), the value 'checkout-completed' is the feature_id. VEKTIS uses it to find a Dev Item whose Impact Tracking is configured for checkout-completed and routes the event there.

Where feature_ids come from

Source	What happens
Set by you in code	When you call vektis.track(), you choose the feature_id value as part of the event payload.
Set by the dashboard	When you create a Dev Item with Impact Tracking enabled, you pick the feature_id it should listen for.

Both paths converge on the same string. The dashboard, the SDK, and the Dev Item all need to agree on the value.

Naming rules

A feature_id must be:

• Lowercase — checkout-completed, not Checkout-Completed.
• Hyphenated — words separated by -, not _ or spaces.
• Alphanumeric + hyphens only — no underscores, no spaces, no special characters.
• No leading or trailing hyphens — -checkout- becomes checkout.
• Up to 200 characters — keep them descriptive but reasonable.

Examples of valid feature_ids: checkout-completed, dashboard-viewed, subscription-upgraded, password-reset-requested.

When you adapt an existing analytics event name, the same rules apply — 'Checkout Completed' becomes checkout-completed, 'view item' becomes view-item, 'User_Signed-Up' becomes user-signed-up.

How VEKTIS routes an event

When an event arrives carrying a feature_id:

1. VEKTIS looks for a non-deleted Dev Item in your organization whose Impact Tracking is configured for that feature_id.
2. If a match exists, the event is counted toward that Dev Item’s metrics.
3. If no match exists, the event is recorded as an unmapped feature — the value was reported by your SDK but no Dev Item is listening for it yet.

A feature_id only connects events to Dev Items in your organization. Two organizations can use the same string checkout-completed independently — events stay isolated to their own organization.

Unmapped features

When your SDK reports a feature_id that doesn’t have a matching Dev Item, the dashboard shows it in two places:

• Unmapped features banner on the Dev Items list — surfaces the most-frequent unmapped feature_ids so you can map them quickly.
• New dev item form — opens with the feature_id pre-filled when you click Link on a feature in the banner’s list.

Mapping an unmapped feature_id takes one of two shapes:

Goal	What to do
Track this feature in VEKTIS	Click the unmapped feature in the banner. The Create Dev Item dialog opens with the feature_id pre-filled. Fill in the title, target metric, and value type.
Stop reporting this feature_id from your app	Edit your code to remove the vektis.track() call (or change the feature_id). The unmapped entry will stop appearing as soon as no events for that ID arrive.

Tip

Unmapped features are not errors — they’re a normal state during instrumentation. If your team adds tracking calls before creating Dev Items, you’ll see them appear in the unmapped banner and can map them on your own schedule.

Choosing feature_ids

When picking feature_ids, a few practical rules:

• One feature_id per measurable surface. A “checkout flow” might be one feature_id (counted by feature.engagement events), or it might be three feature_ids (checkout-started, checkout-completed, checkout-abandoned) depending on what you want to measure.
• Use the same feature_id everywhere it applies. If two pages both show the same checkout button, they should both call vektis.track('feature.used', { feature_id: 'checkout-completed' }) — one Dev Item, events from both pages.
• Don’t encode environment or version in the feature_id. checkout-completed-v2 and checkout-completed-staging create separate Dev Items that fragment your data. Keep the feature_id stable across versions and environments.
• Match the user-visible feature, not the implementation. If you reorganize the code behind a feature, keep the feature_id the same — VEKTIS measures user impact, not code structure.

When the same feature_id appears multiple times

This is common and intentional:

• Multiple call sites in your app — a single feature_id can be reported from several places. VEKTIS counts every event.
• Multiple value_type configurations on the same Dev Item — for duration and percentage value types, the Dev Item’s Impact Tracking config defines which action name counts as the start vs end (or numerator vs denominator). The same feature_id covers both. Matching is on the action name, never on the event type — see Which event type to send for the event type to pair with each.

If two different Dev Items try to listen for the same feature_id, only one will receive events. The dashboard prevents you from creating a duplicate during Dev Item creation.

Where feature_id appears in the dashboard

Surface	What you’ll see
Creating or editing a dev item	Under “How should VEKTIS measure this?”, choosing VEKTIS measures it for me shows the Feature ID with format hints — pre-filled when you came from the unmapped features banner, editable any time after.
Unmapped features banner (on /dev)	A list of feature_ids your SDK has reported recently that don’t yet match a Dev Item.
Dev Item detail page	A tracking status badge if the Dev Item’s data source is automated (driven by a feature_id rather than by manual entries).

Common questions

What if I change a feature_id after Dev Items already exist? Your old events will still be associated with the old feature_id (and may show up as unmapped if no Dev Item matches). The new feature_id starts collecting events immediately. To preserve continuity, prefer keeping feature_ids stable.

Can I have a Dev Item with no feature_id? Yes — Dev Items are useful for manual baseline-and-post-release tracking even without automated event ingestion. Leave the Impact Tracking section empty when creating the Dev Item; you can add a feature_id later.

Do I need to register the feature_id somewhere before my app calls vektis.track()? No. Your SDK can call vektis.track() with any feature_id value at any time. If no Dev Item exists for it yet, the event becomes an “unmapped feature” — visible in the dashboard, ready to map when you’re ready.

Related

• Choosing how VEKTIS measures it — where you set the feature_id in the dashboard
• Measurement Types — the five ways VEKTIS can work a metric out for you
• Metric Value Types — how a metric’s value is displayed and formatted