Skip to content
VEKTIS

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

Section titled “Where feature_ids come from”
SourceWhat happens
Set by you in codeWhen you call vektis.track(), you choose the feature_id value as part of the event payload.
Set by the discover skillThe discover skill normalizes existing analytics-SDK event names (e.g., 'Checkout Completed') into feature_ids ('checkout-completed') and writes them into a candidate list you approve.
Set by the dashboardWhen you create a Dev Item with Impact Tracking enabled, you pick the feature_id it should listen for.

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

Naming rules

Section titled “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.

If you use the discover skill, normalization happens automatically — 'Checkout Completed' becomes checkout-completed, 'view item' becomes view-item, 'User_Signed-Up' becomes user-signed-up.

How VEKTIS routes an event

Section titled “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

Section titled “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.
  • Configure Tracking dialog when editing a Dev Item — pre-populates the feature_id field if you’ve clicked through from the banner.

Mapping an unmapped feature_id takes one of two shapes:

GoalWhat to do
Track this feature in VEKTISClick 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 appEdit 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.

Choosing feature_ids

Section titled “Choosing feature_ids”

If you’re picking feature_ids by hand (rather than using the discover skill), 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

Section titled “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 feature.engagement events count as the start vs end (or numerator vs denominator). The same feature_id covers both.

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

Section titled “Where feature_id appears in the dashboard”
SurfaceWhat you’ll see
Configure Tracking dialog (on a Dev Item)The feature_id field with format hints. Edit-mode shows the current value; create-mode lets you set or paste one.
Edit Dev Item formAn expandable Impact Tracking section shows the feature_id when set.
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 pageA tracking status badge if the Dev Item’s data source is automated (driven by a feature_id rather than by manual entries).

Common questions

Section titled “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.

Section titled “Related”