Validator Analytics

What you get from Validator analytics

Validator analytics turn the compliance data your Validators collect into decisions you can act on. In one place you can:

  • See where non-compliant data is entering your applications, down to the individual form.
  • Prove the size of a data quality problem before you enforce anything, using Measure mode.
  • Confirm that an intervention is working after you move a Validator to Visible or Warning mode.
  • Show the business impact of cleaner data over time.

Together, these analytics let you measure the problem first, act on the evidence, and prove the result.

You'll find the analytics under Content Analytics, then Validators, in the Userlane Portal. For how Validators work (modes, Field Validations, Completion Buttons, and the Warning message), see the Validators help doc.

Two ideas that explain every number

Almost every metric here is a count of data entries, grouped by which of four outcomes each entry reached. Understanding those two ideas, the counted unit and the four outcomes, makes the rest of the page straightforward.

Sessions and data entries

A session is one attempt to submit a form: the user works through the fields and clicks a Completion Button (Save, Submit, or similar). Every Validator has a Completion Button in all three modes, so every mode produces sessions.

A data entry is one field the user actually filled in, counted within a submitted session. A form with ten fields, submitted once, is one session and up to ten data entries. A field the user never touched is not a data entry, so it doesn't affect these numbers.

Most metrics on this page count data entries. The Validators table at the bottom counts sessions instead, which is why the two compliance rates can differ (see Reading the numbers correctly).

The four outcomes

Every data entry ends as exactly one of these four outcomes:

Outcome Meaning
Correct from start Valid the whole time. The field never failed.
Corrected before submit Failed while the user was filling it in, then fixed before they tried to submit.
Corrected after warning Failed at submit, the Warning message appeared, and the user then fixed it.
Non-compliant Ended invalid.

The first three all count as compliant. Your compliance rate is the share of data entries that are not non-compliant.

Which outcomes are possible depends on the mode:

Mode Possible outcomes
Warning All four.
Visible Correct from start, Corrected before submit, Non-compliant. Visible mode doesn't intervene at submit, so there is no "corrected after warning".
Measure Correct, Non-compliant. Measure shows users nothing, so a field a user happens to fix is still counted as correct, not corrected.

The summary cards

Three cards summarize the whole property for the selected range.

Compliance rate

The share of all data entries that are compliant (Correct from start, Corrected before submit, or Corrected after warning), across every mode. This is the headline number, shown with its trend against the previous period.

Three supporting counts sit beneath it:

  • Sessions: distinct submitted form sessions in the range.
  • Total data entries: the fields users filled in across those sessions. This is the number the compliance rate is calculated from.
  • Users: distinct users who submitted a monitored Validator.

Only the compliance rate carries a previous-period comparison. The three counts are for the current period only.

Corrected data entries

Data entries that ended valid after at least one failure, broken down by mode:

  • Warning: fixed before submitting, or after the Warning message sent the user back.
  • Visible: the user saw the field marked invalid and fixed it before submitting.
  • Measure: shows N/A. Corrections aren't counted in Measure mode, because nothing was shown to prompt them (see the four outcomes).

The Warning and Visible figures add up exactly to the total.

Non-compliant data entries

Data entries that ended invalid, broken down by mode:

  • Warning: the user was warned and the field still ended invalid.
  • Visible: the field was marked invalid inline and ended invalid anyway.
  • Measure: the field ended invalid with nothing shown to the user, a silent observation.

Unlike corrections, every mode can produce a non-compliant entry, so all three figures add up exactly to the total.

Compliance by mode

This widget breaks performance down by mode, with a tab each for Warning, Visible, and Measure. Each tab shows that mode's compliance rate, corrected entries, and non-compliant entries, plus a stacked bar showing how that mode's data entries were composed.

The number of slices in the bar depends on the mode:

Tab Slices
Warning Correct from start, Corrected before submit, Corrected after warning, Non-compliant
Visible Correct from start, Corrected before submit, Non-compliant
Measure Correct, Non-compliant

Two things to keep in mind:

  • The percentages are shares of that mode's data entries, not the whole property. They add up to 100% within the tab.
  • A mode your property doesn't use shows N/A, not 0%, so "we don't use this mode" stays distinct from "this mode had entries and none fell here".

Performance over time

A stacked bar chart plots compliant against non-compliant data entries over the selected range, one bar per period. Use the mode dropdown to view all modes together or focus on a single one.

This is where you see the effect of a change. Line up a rise or fall in the non-compliant share with a product release, a process change, or the point where you switched a Validator's mode, and the before/after impact is visible.

The Validators table

The table lists one row per Validator that had submitted sessions in the selected range, with:

  • Status: Published or Unpublished.
  • Name, and any Segments it's scoped to.
  • Compliance rate: the share of the Validator's submitted sessions whose final submit did not fail.
  • Data entries: the fields users filled in across those sessions, shown as a volume signal alongside the rate.
  • Users: distinct users who submitted this Validator in the range.
  • Mode: the Validator's mode at its last activity in the range. If you changed the mode partway through the range, this shows the most recent one.

You can sort, filter, and search the table, and export it using the download button.

A Validator with no submitted sessions in the range doesn't appear in the table. A brand-new Validator, or one nobody has submitted yet, stays absent until it has activity.

Reading the numbers correctly

The compliance rate at the top and the rate in the table measure different things. The summary card counts one entry per field per session, so a ten-field form submitted once contributes up to ten entries. The table counts one per session, so the same submission is a single data point. The two rates answer different questions (how compliant is our data, field by field, versus how often a form gets submitted cleanly), so they won't always match, and neither is wrong.

N/A is not 0%. N/A means there was nothing to measure: no data entries in that mode, or a figure that isn't counted for that mode (such as corrections in Measure). 0% means there genuinely were entries and none fell into that slice. This matters most for a mode you don't use, where everything reads N/A rather than 0.

Measure mode never shows corrected entries. Because users see nothing in Measure, a field that ends up valid is counted as correct rather than corrected, even if the user changed it along the way. Corrected data entries are always N/A for Measure.

Getting value from the analytics

  • Start in Measure to size the problem. Deploy a Validator in Measure mode, watch the non-compliant data entries, and let the numbers make the case before you introduce any end-user UI.
  • Use the trend, not just the snapshot. The compliance rate's previous-period comparison and the Performance over time chart tell you whether things are improving. A single number in isolation doesn't.
  • Work the table from the bottom up. Sort by compliance rate to find the worst-performing forms, then decide whether the rule, the hint text, or the workflow is the problem.
  • Measure the impact of a mode switch. After moving a Validator from Measure to Visible or Warning, use Performance over time to show the before/after change in compliance.
  • Watch corrected entries as a sign of value. A high corrected count on Warning or Visible Validators means users are catching and fixing problems they would otherwise have submitted.

Frequently asked questions

Q: Why don't the compliance rate at the top and the rate in the Validators table match?
They count different things. The top rate counts each field check across all sessions; the table rate counts each form submission. On any form with more than one field they will usually differ, by design.

Q: Why does Corrected data entries show N/A for Measure mode?
Measure mode shows users nothing, so there is no prompt to correct against. A field that ends up valid is counted as correct, not corrected. Corrections are only counted for Warning and Visible modes.

Q: Why is a Validator I just created missing from the table?
The table only lists Validators with submitted sessions in the range. Until users have submitted a form the Validator runs on, it won't appear. Widen the date range if you expect activity that isn't showing.

Q: Can I export the data?
Yes. Use the download button on the Validators table to export the current view.

Q: Does switching a Validator's mode reset my analytics?
No. Historical compliance data is preserved across mode changes, and the switch is marked on the timeline so you can compare before and after.