How to prove a tool computes correctly: reconcile cells, not totals

"We calculate accurately" is a sentence anyone can say. It means something only when your number sits next to someone else's and survives a row-by-row comparison. At Tilsim we treat trust in a calculation as a procedure: the buyer repeats it on their own data and lands on the same result.

What exactly did we reconcile?

We took an official audience table and rebuilt it from raw Nielsen delivery files (binary EVS/RDS/RSP), not from a text export. That difference matters. A text export is already someone else's computed result; reproduce it and you have copied their numbers. A raw delivery is source records, so the whole path from record to finished table sits on our side, and any mistake along it has to surface.

We compared cells, not totals: 60,858 cells, of which 21,548 were non-zero. All 21,548 matched within 0.5 of a person. That tolerance comes from the data itself — Nielsen publishes whole numbers, so half a person is the floor, and below it you are comparing rounding decisions instead of calculations. All 17 of 17 demographic breaks matched.

Why cells instead of totals?

Sums are forgiving. Two errors of opposite sign cancel each other, and the total comes out immaculate. At cell level there is nowhere to hide: every discrepancy stays visible, in the row and column where it happened.

Where does this kind of reconciliation usually fall apart?

The match itself is less interesting than the three places calculations usually diverge.

Multi-day aggregation. Almost any calculation agrees on a single day; there is nothing to break. The gap opens over a week, when daily percentages get averaged arithmetically. The universe differs by day, so each percentage is a share of a different base, and shares do not add like ordinary numbers. Aggregation has to be weighted by universe — ours is 2,295,613 people. This error is nasty because it looks innocent: shorter formula, plausible result, and a discrepancy that grows with the length of the period.

Repeat and corrected deliveries. Ingest the same file twice, let the rows quietly stack, and the table drifts without a single broken formula. No amount of checking the arithmetic catches it — the arithmetic is fine, the composition of the data is what moved. We ingest files idempotently by SHA-256: a repeat is skipped, a corrected day deletes and replaces the earlier rows. Re-run ingestion and you get the dataset you had the first time.

Reach and frequency. Reach has to be computed at the individual level, or nothing else you do carefully will make the numbers agree. Someone who saw the spot three times is one reach and three contacts. Aggregate shortcuts for that logic produce systematic error, not random noise.

What we check, in order

• Source — raw delivery files, not a text export of someone's result.
• Granularity — every cell, including the empty ones (60,858 total, 21,548 non-zero).
• Tolerance — 0.5 of a person, set by the publisher's own rounding.
• Coverage — all 17 demographic breaks, not a convenient sample.
• Aggregation — weighted by universe, never an arithmetic mean of daily shares.
• Ingestion — idempotent by file hash, so a re-run reproduces the dataset.
• Reach — individual-level, so one viewer with three exposures stays one reach.

The same discipline runs through the rest of a buying stack: discount ladders, prime splits, affinity, spot durations, post-buy. We work through those in the TV media buying software checklist

What this means, and what it does not

Our claim is narrow and literal: we reproduce Nielsen's numbers. Nothing about accreditation, endorsement or any formal status — only arithmetic that matches, which you can check yourself: bring your own table and compare. In TV Planner that means reconciliation against an official audience table. TV Budgeting follows the same logic — parity with an agency's reference Excel below 0.01%, held in place by almost three thousand tests. The tests matter more than the number. They stop parity from drifting with the next code change, which is what regression testing does in any engineering discipline: a result you cannot re-verify automatically is a result you will lose.

Asking for trust is the weak version of this. Put the two tables side by side. A tool that computes correctly loses nothing to a line-by-line comparison; that is where it wins. A vendor who will not reconcile at cell level has already answered the question about accuracy.