Dashboard Metric State Automation: Zero Answered Three Different Questions At Once

A summary tile reading "R$ 0,00" carries an implicit claim: that a real measurement was taken, and the true result of that measurement happens to be zero. That claim is only true for one of several genuinely different underlying situations a dashboard can actually be in — a program that is running normally and genuinely has zero of a specific thing right now, a program that has never existed at all for this organization, and a query that failed to run and produced no real answer whatsoever. Collapsing all three into the identical visual output removes exactly the distinction a person looking at the dashboard needs, at the exact moment they need it most: deciding whether a program that shows no activity is healthy and simply new, or not actually running at all.

A running total or a count is a genuinely useful thing to compute and display, and the most direct way to display it is simply to show the number. The gap opens specifically at the boundary where that number CAN legitimately be zero for entirely different reasons — a healthy program with no current activity, versus no program existing at all — and where a derived figure, like a percentage change, depends on a baseline that can itself legitimately be zero or entirely absent. A display built to show only the resulting number, with no accompanying signal for WHY that number is what it is, cannot express the difference between "measured, and it's genuinely zero" and "there was nothing to measure" — and a growth calculation with no explicit guard for a zero or missing baseline will, by the ordinary rules of arithmetic, either fail outright or, if a developer patches around the failure with a placeholder value instead of an honest state, quietly start reporting a number that was never actually measured.

Centriu Loop's own program-summary dashboard previously computed each of its tiles — available cashback, used cashback, total generated, customers with a balance, and a month-over-month growth percentage — by fetching the relevant rows directly and summing them as plain numbers, with the resulting figure displayed exactly as computed. This collapsed at least three genuinely different underlying situations into the identical visible zero: a program that is running with real historical activity but where the SPECIFIC total requested happens to be zero right now; an organization that has never had a single cashback movement recorded, ever; and a query that failed silently and returned nothing at all, treated by the display logic as indistinguishable from a genuine zero.

Separately, and independently, the growth-percentage tile computed `((recent - previous) / previous) * 100` whenever the prior 30-day period had any recorded activity — and, confirmed directly from the prior code's own logic, fell back to a hardcoded literal value of `100` whenever the prior period had zero activity but the current period had any activity at all. A percentage change computed against a genuinely zero baseline has no real mathematical answer — it is undefined, not one hundred — and presenting that placeholder with the identical visual styling and framing as a real, measured growth rate told a business owner their program had grown by exactly 100%, a figure with no actual basis in any real prior-period comparison.

The fix introduces an explicit, typed model with five distinct states for every metric the dashboard displays: genuinely measured (a real number, including a legitimate zero); no data, meaning the organization has never had any relevant activity at all; insufficient data, meaning some activity exists but not enough to support the SPECIFIC calculation being requested (the exact situation a zero-baseline growth calculation is now recognized to fall into); unavailable, meaning the measurement does not exist as a capability in the system today; and error, meaning a measurement was genuinely attempted and failed. Each state renders as its own honest, distinct piece of display text — a genuine zero shows as a real currency value, an organization with no program at all shows a dedicated "nothing launched yet" message instead of a grid of zeroed tiles, and the growth tile specifically now shows "no comparison baseline for the prior period" rather than any percentage figure whenever the prior period lacks real activity to compare against.

A related, smaller correction folded into the same fix: the underlying summary computation previously fetched every matching ledger row for a 30-day window with no limit applied, summing them in JavaScript on the application server — workable for a small dataset, but a genuine cost (the entire relevant transaction history pulled into server memory on every dashboard load) that grows directly with an organization's real activity. The aggregation itself was moved into a single dedicated database function, computing every summary figure directly inside PostgreSQL and returning only the already-summarized result to the application.

A store that joined Centriu Loop yesterday and a store that has run a healthy cashback program for a year but genuinely had zero redemptions today would, before the fix, see the identical dashboard: four tiles, all reading R$ 0,00. After the fix, the brand-new store instead sees a dedicated message explaining that numbers will appear after its first cashback transaction, while the established store sees its real, measured zero displayed as exactly that — a genuine, current result, not an absence mistaken for one.

Centriu Loop's program dashboard now distinguishes a genuinely measured zero from an organization that has never had any cashback activity and from a query that failed — and its growth-percentage figure reports an honest "no comparison baseline" rather than a fabricated "+100%" whenever no real prior-period activity exists to compare against.

This automation covers specifically how Centriu Loop's own program dashboard represents the state of a metric and computes a growth comparison. It is a distinct mechanism from this pillar's separate pages on Loop's cashback rounding calculation and its balance-update logic — related in that all three come from the same broader hardening effort, but each addressing a genuinely different, independent part of the system.

Computing a total and displaying it directly is the simplest possible design, and it is entirely adequate for as long as every possible result the calculation can produce means the same thing to whoever is reading it. It breaks down specifically when a bare number — most commonly zero — can legitimately mean several genuinely different things depending on context the number itself cannot carry. An explicit, typed state attached to every metric — distinguishing a real measurement from an absence of data, from insufficient data for one specific calculation, from a failure — costs more to build than displaying a raw number, but is the only version of the two that lets a person reading the dashboard trust that what they see reflects reality rather than a placeholder standing in for it.