What's New

VEKTIS is actively evolving. This page tracks what’s changed with each release — what we shipped, why we built it, and how it helps you get more from your metrics. If something sparks an idea or you’d like to see us take a different approach, we’d love to hear from you.

August 31, 2026 — Say what the data actually shows

Summary

Every number on a dev item page is a claim, and a few of them had stopped being true. A feature taking forty events a day was told no events had arrived. A metric that could never score was promised a scoring date. A breakdown that was never coming said it was still calculating. None of these were wrong by much — they were wrong in the one way that matters, which is that the page contradicted the data behind it.

This release goes through those claims one at a time and makes each one answer to what is actually arriving. Where VEKTIS can see the problem, it now names it — and, in the most common case, offers the fix as a button rather than an instruction. Alongside that, tracking is no longer a browser-only story: features that live in an API or MCP server can be instrumented too.

We think a product that says “here is exactly what is wrong” earns more trust than one that stays vague and optimistic, even when the honest answer is less comfortable. If a message still doesn’t match what you’re seeing, we’d love to hear about it.

In This Release

When the page and your data disagree, the page should say which

The problem: The most common tracking failure is a name mismatch — your code sends submitted, the dev item is looking for create-group, and nothing lines up. From the outside it looks identical to having no tracking at all, so the product said the wrong thing: no events received, check your installation. The installation was fine. A single string was wrong, and nothing on the page pointed at it.

What we’re doing about it: Event presence is now read from the events themselves rather than inferred from whether a measurement came out the other end — so VEKTIS can tell “nothing is arriving” apart from “plenty is arriving under a different name”, and say so.

A diagnosis instead of a guess

The Baseline and Post-Release cards now distinguish four states: nothing arriving, arriving under an action name the dev item isn’t looking for, arriving but marked as automated traffic, or fine
The mismatch message names the action name your dev item expects and lists what is arriving instead, up to five
Events sent with no action name at all appear in that list too, rather than vanishing
One diagnosis per page — before release it sits on the Baseline card, after release on the Post-Release card

Fix a mismatched name in one click

When the arriving names include one you can use, they render as a pick-list — choose the right one and the dev item is updated
For a two-part metric each name can be assigned as the numerator or the denominator
VEKTIS deliberately doesn’t pick for you: with more than one name arriving, guessing would quietly measure the wrong thing

Unavailable, not pending

Conversion rate, Overall activity and Revenue (manual) never produce a per-customer breakdown — the section now says so outright instead of showing a calculating state forever
The limitation is named in the value-type help text too, so it surfaces before you save rather than weeks later

Don’t promise a scoring date you can’t keep

The problem: The Impact tile at the top of a dev item named the date scoring would begin. That date was release day plus six weeks — a calendar fact, not a prediction. So a dev item whose instrumentation could never produce a score was still promised one, and a healthy dev item that simply hadn’t accumulated enough data went on displaying a date that had already passed.

What we’re doing about it: The tile only names a date when it’s one VEKTIS can stand behind.

An honest Impact tile

No date is shown when nothing arriving can feed the metric — the tile points you down to the card carrying the explanation instead
A date that has come and gone is dropped rather than left on the page
A visibly wrong number at the top of a page invites doubt about every other number on it, which is why this one is subtractive

Impact belongs in one place

The problem: The Customer Breakdown showed an “Impact” bar beside its frequency bar. It grouped every customer VEKTIS could score into a single “significant impact” band, whatever their actual result — so on most dev items it rendered as one solid bar claiming the release moved everybody. The table directly beneath it said otherwise.

What we’re doing about it: Removed the bar. Nothing else changes.

Where impact lives now

The feature’s overall impact stays where it always was — the headline at the top of the dev item
Each customer’s own impact stays in the Impact and Score columns of the breakdown table
The Frequency bar is unchanged, and now runs the full width of the section
See Customer Breakdown

Why it wasn’t just relabelled: a customer’s impact is measured against their own activity before the release; their cohort is a rank against your other customers. Two different comparisons — putting them side by side as matching bars invited a reading that was never sound.

One account is not one user

The problem: A customer showing heavy usage might be a fifty-person team or a single enthusiast. Those are very different signals, and the breakdown couldn’t tell them apart.

What we’re doing about it: The Customer Breakdown now counts the people behind each account.

Seats

A new Seats column shows how many people at each customer used the feature, out of everyone there VEKTIS has seen — for example 14 of 30 (47%)
It is a measure of spread inside the account, not a count of licences bought
Seats come from the user_id your product sends when identifying a user. Without one, the cell shows a dash — and if no customer sends one, the column is hidden entirely
See Customer Breakdown

A cohort is a rank, not a rating

The problem: “Low-touch” read like “barely uses it”, so a customer opening the feature almost daily could be labelled in a way that looked wrong. The labels are ranks within a feature’s own adopters, and nothing on the page said so.

What we’re doing about it: The columns now explain themselves.

Column explainers

Hovering Cohort says the band is measured against other accounts that adopted this dev item, not against an absolute standard
Hovering an individual cohort shows the number it was ranked on, e.g. 6.96 active days/week — usually the thing that explains a surprising label
Hovering Seats spells out active-of-total, and that it isn’t a licence count

Not every product runs in a browser

The problem: Setting up tracking assumed the feature you wanted to measure was something a person clicked. Plenty aren’t — an API your customers call, a tool an agent invokes, a job that runs on your server. There was no path for those, and the browser instructions didn’t translate.

What we’re doing about it: Configure Tracking now asks where the feature lives before it generates anything, and there’s a full reference for sending events from anywhere that isn’t a browser.

Choose where the feature lives

The dialog asks whether the feature is in your app or in your API or MCP server, and generates the matching setup
The server path produces a direct recipe rather than browser tracking calls, covering the parts a server has to handle itself — retries, duplicate protection, and identifying the customer
It defaults to your app, so nothing changes if the question doesn’t apply to you
Because VEKTIS can’t read a Feature ID out of a change that sends events straight from a server, the dialog says so and points you at the dev item to set it manually

Server-side event reference

A complete guide to sending events from a backend service, a batch job, or any non-browser caller
Covers which fields make an event scoreable, the accepted timestamp window, and what to do about paths — health checks, polling, cron — that shouldn’t be tracked at all
Explains how to identify a customer and a user when the request carries no browser session
See Server-side event ingest

August 23, 2026 — The verdict comes first

Summary

VEKTIS had grown into a product that showed you your data and left the conclusion to you. Every page opened with fields, tables and charts; the one thing you came for — did this work? — was somewhere further down, assembled in your head. That’s backwards for a tool whose whole reason to exist is the answer.

This release rebuilds the app around that answer. Every major surface now leads with a verdict and puts the evidence underneath it, the navigation moved to a sidebar that scales as the product grows, and the whole interface picked up a new design treatment along the way — including a dark mode. Two smaller changes support the same goal: it’s now visible whether a number is ready to trust, and suggestions arrive already knowing which feature they belong to.

We believe that leading with a conclusion, and showing the working underneath it, is what turns a metrics dashboard into something a team acts on. If a verdict ever reads louder than the evidence behind it warrants, we’d love to hear about it.

In This Release

The answer should be the first thing on the page

The problem: Dev items and initiatives opened with their configuration and their raw measurements. Whether the work had actually paid off was a conclusion you had to assemble yourself, every time, from parts scattered down the page.

What we’re doing about it: Every major surface was rebuilt so the verdict leads and the evidence supports it.

Verdict-first dev items and initiatives

Dev Item Detail opens with the result — did this move the metric, and how confident is that — with the measurements beneath it
Initiative Detail leads with the initiative’s overall standing rather than its list of linked work
Initiative List rows carry their verdict inline, and initiatives can be dragged into the order you want to read them in

A Dev Item list that leads with what’s settled

The list groups by measurement maturity by default: results old enough to be confident come first, and early scores are labelled as early rather than presented as equals
Older releases collapse behind a “Show all” toggle so the top of the list stays about current work
Any other sort returns the familiar flat list

A rebuilt Create Dev Item flow

Creating a dev item is now a writing surface rather than a form to fill in
The left sidebar replaces the old top navigation, so the app has room to grow without the nav getting more crowded

The product should be readable at any hour

The problem: VEKTIS had one look, built for a bright room, and a visual language that had drifted as the product grew.

What we’re doing about it: A full design pass, and a dark mode you can switch to.

Dark mode and a refreshed interface

Switch between light and dark from anywhere in the app; your choice is remembered and applied before the page paints, so there’s no flash
Typography, buttons and surfaces were reworked together, so pages read as one product rather than as layers added over time
Verdicts have their own colour treatment in both themes, so a result reads the same way at a glance whichever you use

You should know whether a number is ready before you act on it

The problem: A metric on the page gave no sense of its own age or completeness. A value collected an hour ago and one that had been stale for a fortnight looked identical, and a baseline still filling up looked like a baseline that was finished.

What we’re doing about it: Automated dev items now report the state of their own data.

Baseline status and data freshness

A status banner on automated dev items says which of four situations you’re in — no data yet, gathering, burn-in in progress, or ready
Baseline and Post-Release sections carry an “Updated” timestamp in your local time whenever the data came in automatically
Adding a measurement by hand to an automated dev item now warns you that it may not line up with what’s arriving

A promoted suggestion should arrive already wired up

The problem: When a merged change became a suggestion, VEKTIS knew the work had shipped but not which tracked feature it belonged to. Promoting it meant going back and mapping it by hand — the step most likely to be skipped, and the one that decides whether the dev item ever measures anything.

What we’re doing about it: VEKTIS reads the Feature ID out of the merged work.

Feature ID detection from merged work

When work merges to your release branch, VEKTIS looks for the Feature ID in the tracking calls it added
Finding exactly one, it attaches it to the suggestion and carries it onto the dev item you promote — which arrives ready to measure
Finding none or several, it leaves the field to you rather than guessing
See Feature IDs

July 7, 2026 — Impact you can see customer by customer

Summary

Until now, a feature’s impact was a single number: it worked, or it didn’t. But “it worked” almost always means “it worked for someone” — a handful of power users, one big account, or your whole base. This release opens that number up. You can now see a feature’s impact customer by customer, see how many of your customers an initiative actually reaches, and choose how each feature gets measured in the first place.

The theme is moving from whether something worked to who it worked for — the detail you need to decide whether to double down, broaden adoption, or move on. Alongside it, the Suggestions queue was rebuilt to tell you not just what shipped, but what to do about it next.

We believe that showing impact at the customer level — instead of collapsing it to one average — will help teams make sharper calls about where to invest. If a view raises more questions than it answers, we’d love to hear about it.

In This Release

“Did it work?” should really be “who did it work for?”

The problem: A single impact score hides as much as it reveals. A feature that looks flat overall can be a decisive win for your heaviest users; a feature that looks like a win can be riding on one outlier. Averages don’t tell you which.

What we’re doing about it: Dev items now break impact down customer by customer, and group customers by how often they actually use the feature.

Customer Breakdown

Every dev item collecting per-customer data now shows a Customer Breakdown — who adopted the feature, how heavily they use it, and where the impact landed
Two at-a-glance bars show the shape: impact (did the release move them?) and frequency (how often they use it)
A per-customer table shows each customer’s usage cadence, whether they now rely on the feature more or less, and their individual impact
See Customer Breakdown

Usage cohorts

Customers are grouped into Power, Active, Standard, and Low-touch cohorts based on how often they use the feature
Reading impact against cohort tells a fuller story — significant impact concentrated in your Power users is a different result than the same score spread thinly
Customers with too little activity to score are held out rather than counted as zero, so a quiet account never drags the picture down unfairly

Customer reach on initiatives

Every initiative now shows a Customer reach tile — how many of your active customers its features have reached, as a real percentage of your base
A momentum note shows whether reach is still growing
Health tells you whether the work is landing; reach tells you how many customers it’s landing for — see Initiative Health

Not every feature should be measured the same way

The problem: Some metrics live in your product, where VEKTIS can read them automatically. Others live in a spreadsheet or an analytics tool VEKTIS can’t see. Forcing every dev item down one path meant friction for half of them.

What we’re doing about it: Creating or editing a dev item now asks how you want it measured, and adapts the form to your answer.

Choose how VEKTIS measures each dev item

VEKTIS measures it for me — reads results from your product automatically; you set it up once
I’ll enter results myself — type values into the dashboard after each release
The form only asks for what your choice needs, and you can switch a dev item between the two later
See Creating and Managing Dev Items

Your suggestions queue should tell you what to do next

The problem: A list of shipped work is only useful if it’s obvious which items you can act on immediately and which need a moment’s thought. A flat queue makes you re-triage every time you open it.

What we’re doing about it: The Suggestions queue now sorts itself by what each item needs from you.

A triage-first Suggestions queue

Suggestions are grouped into Ready to track (approve in one step) and Needs a few details (pick a metric and owner first)
The header shows what’s waiting, what’s ready, and what’s aging — so a weekly pass is quick
Approve to start measuring impact, or dismiss what you don’t need to track
See Reviewing Suggestions

May 7, 2026 — Native analytics, end to end

Summary

Tracking the impact of your features no longer requires manual measurement entry. If your application already records analytics events — through a tracker SDK or the discover skill that finds them for you — VEKTIS now picks those events up automatically and computes Dev Item metrics on your behalf.

This release closes the loop from “install VEKTIS in your codebase” to “see whether a feature actually moved a metric” without you ever copy-pasting a number into a form. The same loop also surfaces in the product itself: dev items that are not yet wired up are flagged, the dashboard shows the freshly-arriving measurements as they happen, and a setup card walks you through what’s left.

We believe that removing the manual measurement step — and making the gaps visible when something is not yet hooked up — will help teams act on real data sooner instead of putting off measurement work. If a step in the flow feels harder than it should be, we’d love to hear about it.

In This Release

Setting up tracking should be guided, not researched

The problem: Installing a tracking SDK in an unfamiliar codebase usually means reading installation guides, hunting for a credential, deciding where init code belongs, and figuring out how to keep that credential out of source control. That’s a lot of context to carry before you’ve measured anything.

What we’re doing about it: A set of customer-facing skills walks you through every install step with diff confirmations, and a browser-based sign-in flow means you never need to handle a raw credential.

Customer Claude Code skills

Install the full set with one command: npx @vektis-io/tracker install-skills
vektis-bootstrap runs the full first-time onboarding (install → discover → instrument) end-to-end
vektis-install detects your framework and writes the init code in the right place
vektis-discover sweeps your codebase for existing analytics calls and proposes which to track
vektis-instrument inserts vektis.track() calls at every approved point in one batch
vektis-update re-scans periodically to find features added since your last instrumentation pass
vektis-troubleshoot diagnoses SDK errors against the live error catalog

CLI authentication

Sign in to VEKTIS from your terminal through your browser — the CLI never asks you to paste a credential
A paste-token fallback is available for environments that cannot open a browser
Skills create the credential they need automatically and store it as an environment variable; you never see or copy it

Connecting your features to VEKTIS should not require manual mapping

The problem: For VEKTIS to compute impact, it needs to know which event in your code corresponds to which Dev Item. Doing that mapping by hand for every feature is tedious and error-prone, especially when you have an existing event taxonomy.

What we’re doing about it: Dev Items now expose a feature ID field that ties them to events in your code, and a bulk-create flow handles many features at once.

Dev Item to feature ID mapping

Every Dev Item can be tied to a feature ID — the identifier you (or the discover skill) put in your tracking calls
Once mapped, every event with that ID flows to that Dev Item without further configuration
The mapping is editable from the Dev Item detail page

Bulk feature instrumentation

The instrument skill creates Dev Items for every approved feature in your discover output in one pass
Dev Items come pre-populated with the feature ID, type, and a sensible title
You review one diff covering all insertions instead of approving each call site individually

Once events flow, you should see results without further configuration

The problem: Even with events flowing, the value of VEKTIS only shows up when those events become visible numbers you can act on. Waiting for the first measurement to arrive, knowing whether burn-in is complete, and seeing the trajectory over time all need to be obvious in the product.

What we’re doing about it: A timeline chart, automatic burn-in for new features, and explicit source labels on every measurement make the picture clear at a glance.

Native analytics ingestion

Events tracked from your application reach VEKTIS automatically when their feature ID matches a tracked Dev Item
The platform computes baseline and post-release values without you typing them in

Metric timeline chart

Every Dev Item detail page now shows a chart of measurements over time
Hover a point to see the date, value, and source of that measurement
Spot trends, regressions, and burn-in stabilization at a glance

Automated burn-in for new features

For features that didn’t exist before development, VEKTIS collects your first few automated measurements and uses them as the baseline
A clear indicator on the Dev Item shows when burn-in is in progress versus complete
See Burn-in baselines for the full rationale

Source and details on every measurement

Each measurement now carries a label showing whether it came from a tracking event, a manual entry, or burn-in
Hovering reveals additional details — useful when reconciling unexpected values
The same labels appear on the timeline chart so the provenance of each point is one click away

Knowing whether tracking is healthy should be visible in the product

The problem: “Did I wire this feature up correctly?” should not require leaving the product. If a Dev Item has no events flowing, or your application has feature IDs that don’t match any Dev Item, you should see that the moment it happens.

What we’re doing about it: Three new surfaces flag tracking gaps before they cost you a release worth of data.

Tracking Setup card on Dev Items

Every Dev Item with Impact Tracking enabled now shows a card summarizing whether events are flowing
A built-in “verify events” check polls for incoming measurements so you can confirm setup in real time
See Setting up Impact Tracking for the full first-time flow

“Not tracked” badge on the Dev Items list

Dev Items without Impact Tracking configured display a clear badge so you can spot them at a glance
Click through to configure tracking from the same row

Unmapped Features banner

If your application sends events whose feature IDs do not match any Dev Item, the Dev Items page surfaces them in a banner
Each unmapped feature ID can be promoted into a tracked Dev Item without leaving the page

May 7, 2026 — GitHub-driven Dev Item suggestions

Summary

Every PR you merge can now become a tracked Dev Item without you typing the title. Connect a code repository to VEKTIS, and the platform classifies merged work and proposes Dev Items for the changes worth measuring — leaving you to confirm or skip rather than create from scratch.

This is built for teams that already make decisions in the PR review flow and don’t want to maintain a parallel “what should we track?” workflow. The classification labels each suggestion as a feature, improvement, bug fix, infrastructure change, or documentation change so you can promote only the ones that warrant impact measurement.

We believe that meeting teams where their work already lives — instead of asking them to remember to log it elsewhere — will lift tracking coverage for the work that matters most. If your suggestion stream feels too noisy or too quiet, tell us what you’re seeing.

In This Release

Tracking what you ship should not require remembering to log it

The problem: Most teams know they should track the impact of every meaningful release, but the act of opening VEKTIS and creating a Dev Item for each one falls off the priority list when shipping is busy. Coverage suffers, and so does the picture of overall impact.

What we’re doing about it: A code-repository connection lets VEKTIS read merged PR titles, classify them, and propose Dev Items automatically — turning a manual logging step into a one-click confirmation.

Connect a code repository

Connect a repository through Settings → Integrations
Pick which repository and which branch counts as a release for classification purposes
Connection-status indicators in Settings show whether the integration is healthy

Automatic suggestions from merged work

Merged PRs are classified by type — feature, improvement, bug fix, infrastructure, or documentation
Suggested Dev Items appear in a dedicated Suggestions view in the dashboard
Each suggestion shows the original PR title, a classification, and a link back to the source PR

One-click promote to a tracked Dev Item

Promote any suggestion to a tracked Dev Item — the title, type, and link are pre-populated
Dismiss suggestions that don’t need impact measurement so they don’t reappear
Pre-populated Dev Items can still be edited before saving — the flow is a draft, not a commitment

March 11, 2026

Summary

Tracking development metrics is only useful if you can quickly tell whether things are going well — and trust the data behind that assessment. Until now, VEKTIS gave you the raw numbers, but left it to you to interpret whether a metric was trending in the right direction, whether your measurements were reliable, and how much overall impact your development work was having.

This release focuses on three things: giving you clear signals so you don’t have to interpret raw data yourself, protecting the integrity of the measurements those signals depend on, and making the platform easier to navigate as it grows.

We believe that making metric interpretation automatic and visible — rather than leaving it as a manual exercise — will help teams catch issues earlier and celebrate progress sooner. If you see opportunities to improve how we surface these insights, we’d love to hear from you.

In This Release

Knowing whether you’re on track shouldn’t require digging through data

The problem: Understanding whether your development work is delivering results means clicking into individual dev items, scanning multiple metrics, and mentally aggregating whether things are trending the right way. At the initiative level, there’s been no way to see the bigger picture without doing that work yourself for every dev item underneath it.

What we’re doing about it: Two new capabilities work together to surface clear signals at different levels of detail — so you can start with the big picture and drill down only when something needs attention.

Health Indicators

Show the overall health of each initiative based on how its dev items are performing against their metrics
Performance is weighted directionally — improvements and regressions are scored relative to what “better” means for each specific metric
Navigate to any initiative to see its current health status and quickly identify which ones need attention versus which are on track

VEKTIS Impact Score

Gives each dev item a single score representing the measurable impact of its post-release performance
Metrics are evaluated using a dual-track scoring system — one track for metrics that are improving and another for those that are regressing
Scores are grouped into zones so you can quickly understand the magnitude of impact
View the score on any dev item’s detail page

Your metrics are only as good as the measurements behind them

The problem: Baselines are the foundation of every health indicator and impact score. But early measurements can be volatile, measurement cadences can drift without anyone noticing, and not every metric fluctuation is meaningful. When the underlying data isn’t trustworthy, the signals built on top of it aren’t either.

What we’re doing about it: Three new safeguards work together to protect measurement quality — so you can trust the signals VEKTIS surfaces.

Burn-in baseline freeze

Built for situations where baseline measurements weren’t possible before development — such as entirely new functionality that didn’t exist before or features too complex to measure prior to release
When a dev item is released without baselines, VEKTIS collects your first few post-release measurements and uses them to establish a baseline automatically — so impact scoring can still work even without historical data
While we encourage teams to track baseline data wherever possible — even through indirect measures like time-to-complete-a-task before and after development — burn-in ensures you’re never stuck without a scoring foundation when that isn’t feasible

Measurement regularity warnings

Alerts you when your baseline measurements are being taken at irregular intervals
Prompts you to establish a more regular cadence if timing between measurements is inconsistent
Catching irregularities early helps you build habits that lead to more reliable data over time

Minimum meaningful change

Define the threshold of metric change that actually matters for each dev item
Set this value when creating or editing a dev item
Changes below the threshold won’t be flagged as significant improvements or regressions — filtering out noise so you can focus on real impact

Getting the most out of VEKTIS should be effortless

The problem: As the platform grows with new capabilities, it should be easy to find answers, understand what’s available, and feel oriented — whether you’re a new team member or exploring a feature for the first time.

What we’re doing about it: A combination of documentation, expanded access, and interface refinements designed to reduce friction across the board.

Documentation site

You’re already here — comprehensive guides and reference material are available throughout this site
Browse guides on getting started, managing dev items, working with metrics, and more

Team visibility for all roles

The users list in Settings is now accessible to everyone, not just administrators
See who else on your team is using VEKTIS to make collaboration and communication easier

Interface improvements

Notifications and prompts now use clearer, friendlier language throughout
Clickable elements consistently show a pointer cursor so it’s obvious what you can interact with
Background colors are uniform across all views for a more polished experience