Dashboards and metrics

The built-in Analytics dashboard answers the questions CyberGuard already knows how to ask. Metrology is where you add your own: define a metric, instantiate it on a domain, feed it values over time, then compose those values — together with numbers the platform computes automatically — into dashboards you can hand to a steering committee.

Where to find it

Dashboards are reached from Overview → Analytics → Custom, which links to the dashboard list and to the dashboard you have made the default. The metric catalog sits alongside it: Metric definitions hold the templates, Metric instances hold what you actually track.

The three layers

Metric definition — the template. It says what is being measured, not for whom. A definition is either Quantitative (Number), with a Unit such as count, users, percentage or score, or Qualitative (Level), with an ordered list of named options. Higher is better tells the platform which direction is good — set it off for metrics like open vulnerabilities, where down is up. A Default target can be carried here and overridden later. Definitions can be imported from a library or created directly.
Metric instance — the definition projected onto one domain, and the object you actually track. It inherits the definition’s settings and adds the operational fields: an Owner, a Target value for this domain specifically, a Status, and a Collection frequency.
Sample — one timestamped value on an instance. Enter samples by hand, or push them through the API from whatever system already knows the number. Samples cannot be dated in the future.

Because the target lives on the instance rather than the definition, the same metric — “phishing simulation click rate”, say — can be held to a stricter target in one business unit than another without duplicating the definition.

Instance status and staleness

An instance moves through Draft, Active, Stale and Deprecated. Stale is the interesting one: you do not set it, the platform does. Each instance declares a Collection frequency — real-time, hourly, daily, weekly, monthly, quarterly or yearly — and when the newest sample is older than that cadence plus a grace period, the instance flips to Stale on its own. A dashboard full of confident numbers that nobody has refreshed in six months is worse than no dashboard, and the status is what exposes that.

Dashboards and widgets

A dashboard is a container with a name, an optional reference ID, a Domain that governs who can open it, and a grid layout. It holds no data of its own — every widget reads from somewhere else.

Each widget renders exactly one source:

A custom metric — one of your metric instances.
A built-in metric — a value the platform computes for a known object, such as an audit’s progress or its result breakdown. These refresh themselves as the underlying object changes, with no collection effort from you.
A text block — Markdown for a heading, a divider or a paragraph of narrative between the charts.

Available chart types are KPI Card, Donut Chart, Pie Chart, Bar Chart, Line Chart, Area Chart, Gauge, Sparkline, Table and Text. Each widget can carry its own title, an Aggregation (average, sum, minimum, maximum, count, last value, or raw data) and a Time range — last hour through last year, all time, or a custom range.

Building one

Create the dashboard, then open its Widgets layout view to add, drag and resize. Layout changes save in place. A dashboard with no widgets shows No widgets configured for this dashboard yet wherever it is displayed, with a shortcut back to the editor.

Putting a dashboard on the Analytics page

The Custom tab of Analytics embeds one dashboard for the whole instance. Administrators pick it from the dashboard name at the top of the tab and can Clear default to empty the tab again.

Analytics — the built-in dashboard and the tab that embeds yours.
Libraries — import off-the-shelf metric definitions instead of writing them.
Assignments — metric instances you own appear in your personal queue.