We ask you to check our work and send us the errors. This is what that has produced so far: 9 corrections to three studies published in October 2026, all found by us before a reader reported them, none of them silently applied.
Six corrections across three studies, all published on 21 October 2026 and corrected on 25 October 2026. Three were arithmetic or counting errors that changed a number a reader could have quoted. Three were text defects where a value met a template that added the same word or noun again. Every fix is in the study specification history, and the affected pages carry the corrected arithmetic.
The distinction worth holding onto: this is a list of the errors we found, not a certificate that the rest is right. The method that found these was recomputation, and it only reaches figures that got restated in a second document.
Last verified 2026-10-25. Plans move and prices follow usage bands; confirm current rates before you quote this page.
Every DataDab research page ends with the same sentence: spot an error, send the URL, and corrections are published on the page. That sentence is easy to write and easy to leave untested, because most readers never check whether a page changed after they cited it.
This page is the test. It lists every correction we have made to a study, what the page said before, what it says now, and how we found it. If the list is empty in a future month, that will mean we found nothing, not that we stopped looking.
None of the study entries was reported by a reader. All of them surfaced on 25 October 2026, four days after the three comparison studies went live, while writing companion articles that had to repeat the same figures. Repeating a number in a second document is a better audit than reading it again in the first, which is the uncomfortable lesson.
Two entries below are corrections to this page itself, made before it was deployed. A ledger that only lists other people's mistakes is a brochure.
Reconstructed from the committed history of each study specification on 25 October 2026. Where the page prints a computed figure, the computation is on the study page so the correction can be re-checked rather than trusted.
| Study | Date | What the page said | What it says now | Class |
|---|---|---|---|---|
| Product analytics: Mixpanel vs Amplitude vs PostHog vs Heap | 25 Oct 2026 | Across nine event bands | Across six paid event bands | Count, contradicted by the page's own table |
| Product analytics: Mixpanel vs Amplitude vs PostHog vs Heap | 25 Oct 2026 | Ten times the events costs N times the price, for the 5M to 20M step | Four times the events costs N times the price | Multiplier, wrong factor |
| Product analytics: Mixpanel vs Amplitude vs PostHog vs Heap | 25 Oct 2026 | Annual billing saves 40 percent of twelve months at the monthly rate | 29 percent, computed against the monthly-billed total | Arithmetic, wrong denominator |
| Conversation intelligence: Gong vs Chorus vs Clari vs Fireflies vs Fathom | 25 Oct 2026 | Fireflies Pro for 20 seats at 380 dollars a month | 200 dollars, which is 20 seats at the Pro annual rate | Arithmetic, wrong tier applied |
| Conversation intelligence: Gong vs Chorus vs Clari vs Fireflies vs Fathom | 25 Oct 2026 | Fathom's cheapest published seat at 16 dollars (the Premium rate) | 15 dollars (the Team annual rate), with Premium kept at 16 | Arithmetic, wrong tier labelled cheapest |
| Conversation intelligence: Gong vs Chorus vs Clari vs Fireflies vs Fathom | 25 Oct 2026 | A vendor claim of up to 44 percent annual saving, stated as fact | The claim is retained and paired with the 34 percent its own Business figures produce | Attribution, vendor claim presented as our finding |
| Feedback and roadmapping: Canny vs Linear vs Productboard vs Sprig | 25 Oct 2026 | Credits of credits, bundle bundles, credits credits, tracked users tracked users | Each duplicated noun removed; the underlying values were correct | Text, a value that already ended in the noun the template added |
| Product analytics: Mixpanel vs Amplitude vs PostHog vs Heap | 25 Oct 2026 | The saving is printed to zero decimal places, so the corrected 28.5 percent renders as 29 | Still rounded to a whole percent; the page prints the computation beside it so the figure can be re-derived | Precision, found while writing this ledger |
| **Corrections ledger (this page) | 25 Oct 2026 | Two of the rows above were published here first as a wrong tier label and a wrong defect count | Both corrected before this page was deployed: the study count was 3 not 4, and the row count 7 not 6 | Our own error, caught by re-reading the source diff |
The pattern in all of them is the same: the page was internally inconsistent. The count of event bands disagreed with the table directly above it. The saving percentage used a base that the same sentence did not name. A twenty-seat total was multiplied by the wrong tier's rate, which the page's own per-seat column made checkable.
None of those needed a re-crawl of a vendor page or a second reviewer. They needed one reader to recompute a figure from the numbers printed on the same screen, which is exactly what writing the companion article forced.
That is the argument for keeping studies and articles tied together. A study read on its own invites trust. A study restated in different words for a different reader invites arithmetic.
A ledger that only lists what you fixed is a selection. These are the weaknesses we know about and have chosen not to fix yet, each with the reason.
Tier naming conflicts between two of our own studies. The pricing tier census and the AI pricing index normalise tier names slightly differently, so a tier counted as Enterprise in one is counted as Custom in the other. The honest fix is to re-code both against one schema, which is a re-run rather than an edit, and until then any count of tier names should name the study it came from.
Per-unit figures that are our arithmetic rather than a vendor statement. Where a page prints a cost per million events or a twenty-seat monthly total, that figure is our multiplication of two published numbers. It is labelled as our arithmetic in the methodology, but a reader skimming a chart will not see the label. We have kept them because they are the most useful numbers in the capture, and the risk is stated rather than removed.
One reviewer per study. Every census in this program was coded by one person and checked by the scripts, not by a second coder. Where a study reports a confidence interval, that interval is sampling error on the count, not inter-rater reliability. A double-coded sample is the next real improvement in method, and it has not been done.
Every study page prints a verification date in its methodology section, and this ledger is the reason to read it. If you quoted a figure from one of the four October comparison studies before 25 October 2026, check it against the page now.
The four arithmetic and counting corrections changed numbers a reader could have quoted. If your citation was a conclusion rather than a figure, nothing moved. If it was one of the figures in the table above, the current page carries the correct value and the computation behind it.
The durable fix on your side is to cite the study page and its verification date rather than the number alone, so a reader can check the current version. That is also why the cite box below offers the page link and not a snapshot.
Yes. This page is that publication. Each affected study also prints the corrected arithmetic in place, so a reader who arrives from one of our articles sees the current figure with its computation rather than a corrected number with no history.
Check the study page itself rather than this ledger. Every figure a correction touched is now computed from a published fact on the page, so a revert would show as a number that disagrees with the inputs printed beside it. You do not have to trust this ledger to check that.
Because the alternative is asking people to cite research while giving them no way to tell whether it has changed. A vendor that compares its own products is asking for a lot of trust. This is the cheapest way to make that trust checkable rather than requested.
Not yet. All of them were found internally on 25 October 2026. If a reader report produces a correction, it will appear here with that noted, because the distinction matters: a self-reported error rate measures how well you check, not how often you are wrong.
It cannot tell you how many errors remain. A list of corrections is evidence that the checking works, not that the checking is complete, and the study entries were found by one method. A different method would find a different set.
It cannot rank our studies by reliability. A study with no corrections is not more accurate than one with three; it has been read less carefully by someone forcing its numbers into a second document, which is the only reason these surfaced.
It cannot substitute for checking the study you are actually citing. This page records corrections to the comparison studies. The census pages covering 479 companies were coded separately and have not had the same recomputation pass, which is stated here so that absence is not read as cleanliness.
Each row in the ledger was reconstructed from the committed history of the study specification files in the DataDab repository, not from working notes, on 25 October 2026. The wrong value and the corrected value are both read from that history.
The three studies were published on 21 October 2026. The corrections were made on 25 October 2026 and the affected pages were rebuilt from their corrected specifications, deployed, and re-verified, including at the edge.
Where a corrected figure is a percentage, the study page now prints the computation that produces it, so the correction can be re-derived from the inputs rather than taken on trust. The specific example is the annual billing saving on the Mixpanel page, which is computed against the monthly-billed total and shows its own arithmetic.
One reviewer per study. The corrections were found by recomputation, not by a second coder. No vendor page was re-captured for any correction: every defect was in our reading of a document already held on the capture date.
| Vendor | Page captured | Retrieved | SHA-256 (first 12) |
|---|
This measures what earns citations in this category. Finding out where your own brand sits in the same query set takes two weeks and covers 20+ of your pages.
Book the 40-minute qualification call
No email required for the free tools. The diagnostic is a fixed scope and a published price.
Covering this research? Please link the primary source so readers can verify the data and methodology:
Markdown: [The Corrections Ledger: Every Fix We Made to a Published Study | DataDab Research](https://www.datadab.com/research/corrections-ledger)
Spot an error? Send the URL to amit@datadab.com; corrections are published on the page.
This page is re-verified quarterly. Check the methodology section for the current verification date before quoting figures.