Find it before it reaches the report
Bad data is rarely discovered by a quality tool. It is discovered by an executive whose number looks wrong, three weeks after the fact. Catching it earlier is a question of where the checking happens.
How DataLens approaches it
Checking starts at ingest
Profiling runs when data lands, with no configuration. The first quality report exists before anyone has decided to write one.
Findings, not dashboards
Problems are reported as specific findings against specific columns — this column is 40% null, these twelve rows share a key — rather than as a score.
Rules become gates
An expectation you care about becomes a gate in the flow. Data that fails it stops the run instead of arriving quietly.
The history answers “when did this break”
Every rule keeps a record of when it last passed, so a regression has a date rather than a suspicion.
The fix is in the same tool
A finding leads to a proposed transform you can apply immediately, rather than to a ticket for a different team.
The stages this leans on
The rest of the lifecycle is there when you need it.
Questions
How is this different from a data observability tool?
An observability tool watches a pipeline from outside and tells you something changed. DataLens is the pipeline, so a finding comes with the transform that fixes it and the gate that stops it recurring.
Do I have to write the quality rules myself?
The first pass is generated from the profile — nullability, types, uniqueness and ranges that the data itself implies. You edit those and add the business rules only you know.
What happens when a gate fails?
The run stops at that gate and reports which rule failed and on how many rows. Nothing downstream consumes the failed data.
See it on your own data
DataLens is in private beta. Bring a file, a database or an API and work through the whole lifecycle in one sitting.
Request beta access