A map of everything your project has built, and a score for how well it hangs together. Vitals reads your events, audiences, insights and actions as one graph, scores how much of it is described, mapped to a lifecycle stage and actually used, and lists the gaps worth closing.
What Vitals is
A Countly project accumulates things. Events arrive from the SDK, somebody builds a cohort on them, somebody else builds a funnel, a journey targets the cohort, a dashboard shows the funnel. Each of those lives on its own page, and no page shows how they fit together or whether they do.
Vitals reads all of it as one graph. Every event, segment and profile property; every cohort, funnel, formula, dashboard and saved query; every journey, push, survey, experiment, alert, hook and report. Each becomes a node, and the references between them become edges: this cohort consumes those events, this journey uses that cohort.
From that graph it answers one question. Not "how is the product performing", which every other page in Countly already answers, but "how well is this project set up". Is the data described well enough for a new colleague to understand it? Is it organized against the customer lifecycle? Are the audiences you built actually being used by anything?
The answer comes back as a score out of a hundred, a set of scores broken down by layer and by lifecycle stage, and a list of specific gaps, each one naming an entity and what to do about it.
Nothing here changes your data or your setup. Vitals reads and scores; the fixing happens on the pages that own each entity.
Vitals is a prototype. It is available in demo builds rather than on a live deployment, the graph it reads is generated rather than projected from your real project, and the scoring formula is deliberately simple because the point of the prototype is to test whether these are the right questions, not to settle the arithmetic. Read what follows as a description of how it works, not as a promise about a shipped feature.
The two axes
Everything in the graph is placed on two axes, and almost every view in Vitals is one of them, or both crossed against each other.
The layer is what kind of thing an entity is, and there are exactly three.
Schema is what your data means: custom and native events, event segments, profile properties. It is the raw vocabulary, and on its own it says nothing.
Insight is what you have made the data show: cohorts, funnels, formulas, dashboards, saved drill queries. It reads from schema and produces an understanding.
Action is what you do about it: journeys, pushes, surveys, in-app messages, experiments, adaptive variables, alerts, hooks, email reports. It reads from insight and changes something outside Countly.
The three are a chain, and the chain is the point. Schema without insight is data nobody has interpreted. Insight without action is an understanding nobody acted on. A project heavy at one end and thin at the other is the shape Vitals is built to make visible, and the usual version of it is schema heavy: many events, a handful of cohorts, few actions.
The lifecycle stage is which part of the customer relationship an entity is about: Acquisition, Activation, Engagement, Retention, Win-back. Unlike the layer, this is not derived from what the entity is. Somebody has to say so, which is why a large share of any real project starts out untagged.
Crossing the two gives a grid of five stages against three columns of layers, and that grid is the Lifecycle blueprint. Reading down a column tells you which stages you have neglected. Reading across a row tells you whether a stage has data but no insight, or insight but no action. Empty cells are the finding.
Use Cases
See where your setup is thin
You have inherited a Countly project, or you are reviewing one before a push of new work, and you want to know where the weak parts are before anyone asks.
- Open Vitals from the Manage menu. The Overview tab opens on the maturity score and the four checks beside it.
- Read the four supporting checks rather than the headline number. The headline is a blend, so it tells you there is a problem but not which one. Has description, has lifecycle, insights actioned and orphan events each name a specific failure.
- Read the score by layer. A low schema score means your data is not described or organized. A low insight score means the cohorts and funnels you have built are not being used. A low action score is usually a project that analyzes and does not act.
- Read the score by lifecycle stage. A stage sitting at zero has nothing tagged to it at all, which is a different problem from a stage with a low score.
- Switch to the Lifecycle tab and look at the grid. The empty cells are the finding, and they are far more concrete than any number: this stage has events and no audience, that one has an audience and nothing acting on it.
- Note the Untagged row at the bottom. Everything there is invisible to the whole blueprint, so a large untagged row means the grid above it is showing you less than the whole picture.
Do not read the score as a grade. It measures how well the project is described and connected, not whether the analysis it produces is any good. A small, deliberate setup that answers one question well will score below a sprawling one that answers nothing.
Find what nobody uses
The project has grown for years and you suspect a good part of it is dead weight, but you do not want to guess which part.
- Open the Gaps tab and filter Type to orphan events. An orphan is a schema entity, an event, a segment or a property, that nothing else in the graph references.
- Read them with a question in mind: is this something to build on, or something to retire? An orphan is not automatically waste. A new event nobody has built a cohort on yet is an opportunity; an event from a feature removed two years ago is not.
- Open the ones you cannot place. Clicking a row opens that entity in the catalog, where the lineage panel shows exactly what feeds it and what reads it, and the vital signs show whether it is still receiving traffic.
- Switch the filter to audiences without an action. These are cohorts and funnels that exist and are not used by any journey, push, survey, experiment or other action. Each is either a piece of analysis waiting to be acted on, or an artifact of a campaign that has ended.
- Work down by severity. The inbox sorts worst first, and a broken dependency, something pointing at an entity that no longer exists, outranks everything else because it is a thing that is already failing rather than a thing that is merely unused.
Vitals will not delete anything. The decision to retire an entity, and the deletion itself, happen on the page that owns it. Vitals is how you find them; it is not where you act.
Make your setup legible
Nobody can tell what your events mean without asking the person who added them, and that person has left.
- Open the Gaps tab and filter to missing descriptions. This is usually the largest single category in any real project, and it is the cheapest to fix.
- Start with the schema layer. A described event is worth more than a described dashboard, because everything downstream inherits the confusion of an undescribed event.
- Write one sentence per entity, on the page that owns it. What it means, when it fires, and anything surprising about it. A description that only restates the name adds nothing, and Vitals will not count a description that is too short to be real.
- Move on to lifecycle tags. Filter to unmapped lifecycle and assign each entity a stage. This is what puts an entity on the blueprint; until it has a stage it sits in the Untagged row and contributes nothing to any stage score.
- Come back to the Overview and watch the has description and has lifecycle checks move. They are the two dimensions that carry most of the score, so this work shows up quickly.
There is a second reason to do this beyond human readability. Descriptions and lifecycle tags are what an assistant reading your setup has to work with. An undescribed event is a name and nothing else, and no amount of intelligence recovers the intent behind it.
Compare your setup against a pack
You are not sure what a well set up project in your industry is supposed to contain, and you want a reference rather than an opinion.
- Open the Pack tab. A pack is a blueprint for an industry: the events, audiences and programs a project of that kind usually needs, laid out on the same grid of stages and layers.
- Pick your industry. The e-commerce pack is the one that ships; the others are listed and marked as still to come.
- Read the conformance figure at the top. It is the share of what the pack expects that your project actually has, with the matched and missing counts beside it.
- Read the grid rather than the number. Every cell holds the entities the pack expects at that stage and layer, with the ones you already have marked as matched. The unmatched entries are the concrete suggestion.
- Read the worked examples underneath. Each one is a pattern written out end to end, from the event through the audience to the action, which is more useful than the entity list because it shows how the pieces connect.
- Treat the pack as a menu, not a checklist. A missing entry you have a reason not to want is not a gap, and conformance is not a target to maximize.
A pack is a starting point for a conversation about what to build next, and it will always suggest more than any one project needs.
FAQs
Is this measuring my product or my Countly setup?
Your setup. Vitals says nothing about how the product is doing. It measures how well the things you have built in Countly are described, organized and connected to each other.
Why can I not find Vitals on our deployment?
Because it is a prototype and is hidden outside demo builds. What it shows is a generated graph illustrating the idea rather than a reading of a real project.
What is a good score?
Eighty and above reads as healthy and fifty as needing attention, but the headline is a blend of three coverage measures and is not really a grade. The four checks beside it are what you can act on.
Why did my score barely move after a lot of work?
Because the headline is an average of the three layer scores, and each layer counts equally regardless of how many entities it holds. Fixing forty schema entities moves the schema score and then contributes only a third of that to the headline.
What counts as a description?
Anything long enough to be a real sentence. A very short field is treated as missing, so restating the name does not count.
What is an orphan?
A schema entity, an event, a segment or a property, that nothing else in the graph references. It is not automatically waste: a new event nobody has built on yet looks identical to one left over from a removed feature.
Why is a cohort I use every day flagged as having no action?
Because that check looks for a journey, push, survey, in-app message, experiment, adaptive variable, alert, hook or email report that references it inside the graph. Using a cohort by opening it, or by filtering a report with it, is not a reference and does not count.
Why is so much of my project in the Untagged row?
Because a lifecycle stage has to be assigned by a person and nothing infers it. Until an entity has one it sits in Untagged and contributes to no stage score.
Can I dismiss a gap I have decided to live with?
No. Gaps are recomputed from the graph on every load, and there is nowhere to record a decision, so the same rows come back.
Can I fix anything from here?
No. Vitals is read only throughout. Clicking a row or a card takes you to the entity in the catalog, and the catalog links out to the entity's own page, which is where descriptions, tags and deletions happen.
What is the difference between the Lifecycle tab and the Pack tab?
Same grid, different contents. Lifecycle fills it with what you have. Pack fills it with what an industry blueprint expects and marks the parts you already have.
Should I aim for a hundred percent pack conformance?
No. A pack describes a pattern common in an industry and will always suggest more than any one project needs. The worked examples are the useful part, because they show why each piece is there.
Is the Assistant really answering my questions?
It is a deterministic stand-in, labeled as a demo on the tab. It draws on the graph, the score and the active pack with prepared responses, and it shows what the interface would be rather than doing the reasoning.
Why does an entity say it is not part of the Vitals graph?
Because nothing has registered it. The design is for each feature to project its entities into Vitals automatically; in the prototype that projection is simulated, so parts of a real project are missing by construction.