comparedge-data.github.io/methodology.html at main · comparedge-data/comparedge-data.github.io · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Methodology: how ComparEdge verifies SaaS pricing data</title>
<meta name="description" content="How the ComparEdge open dataset collects and verifies pricing: vendor-page sourcing, verification dates, confidence decay, aggregated ratings, and the CC BY 4.0 license.">
<link rel="canonical" href="https://comparedge-data.github.io/methodology.html">
<meta name="robots" content="index, follow">
<meta property="og:type" content="website">
<meta property="og:site_name" content="ComparEdge open dataset">
<meta property="og:title" content="Methodology: how ComparEdge verifies SaaS pricing data">
<meta property="og:description" content="How the ComparEdge open dataset collects and verifies pricing: vendor-page sourcing, verification dates, confidence decay, aggregated ratings, and the CC BY 4.0 license.">
<meta property="og:url" content="https://comparedge-data.github.io/methodology.html">
<meta property="og:image" content="https://comparedge-data.github.io/og.svg">
<meta property="og:image:type" content="image/svg+xml">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Methodology: how ComparEdge verifies SaaS pricing data">
<meta name="twitter:description" content="How the ComparEdge open dataset collects and verifies pricing: vendor-page sourcing, verification dates, confidence decay, aggregated ratings, and the CC BY 4.0 license.">
<meta name="twitter:image" content="https://comparedge-data.github.io/og.svg">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="stylesheet" href="/style.css">
</head>
<body>
<header class="site-header">
  <div class="wrap">
    <a class="brand" href="https://comparedge-data.github.io/">
      <span class="mark"><svg width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="#fff" stroke-width="2.4" stroke-linecap="round"><path d="M4 18V9M10 18V5M16 18v-6M20 18h-18"/></svg></span>
      ComparEdge open dataset
    </a>
    <nav class="main">
      <a href="https://comparedge-data.github.io/">Overview</a>
      <a href="https://comparedge-data.github.io/index.html#categories">Categories</a>
      <a href="https://comparedge-data.github.io/methodology.html">Methodology</a>
      <a class="ext" href="https://comparedge.com">Main site</a>
    </nav>
  </div>
</header>
<main>
  <div class="wrap">
    <h1>How the pricing data is collected and verified</h1>
    <p class="lede">Every price comes from one place: the vendor's own current pricing page, read from the live page and stamped with the date it was checked.</p>

    <p>Nothing in the dataset is estimated, averaged from third parties, or carried over from an old press release. When a plan lists a seat price, that seat price is what goes in the record, along with the billing period and what the plan actually includes. If a vendor shows monthly and annual rates, both are kept, because the annual discount is often the number that decides a purchase.</p>

    <h2>The verification date</h2>
    <p>The part that matters most is the date. Each product carries a verification date, the day its pricing was last read and confirmed against the live page. A price without a date is a rumor. Keeping the date attached to the record lets anyone using the data apply their own staleness rule. If a figure was last confirmed two months ago and you are about to sign a contract on it, check it again. The dataset tells you when to worry instead of pretending every number is current.</p>

    <p>Records also carry a confidence signal that decays as they age. A price checked yesterday is treated as more reliable than one checked in spring, and the score reflects that automatically. When a vendor changes a price, the change is written to a changelog feed so the history stays visible rather than being silently overwritten.</p>

    <h2>Ratings are built separately</h2>
    <p>Ratings sit apart from pricing and are built differently. Instead of running our own review program, the rating on each product aggregates scores from independent review platforms, weighted and normalized so a product with a handful of reviews does not outrank one with thousands on a rounding artifact. The rating is a summary signal, not a verdict. The plan data is there for the actual decision.</p>

    <h2>What the data will not pretend to know</h2>
    <p>There are limits worth stating plainly. Enterprise pricing that only exists behind a sales call is recorded as contact-sales, not invented. Usage-based products, where the real bill depends on your volume, are marked as such and carry the published unit rates rather than a made-up monthly figure. Free plans are flagged only when they are a genuine standing plan, not a time-boxed trial dressed up as one. Those last two get confused constantly, so the dataset keeps a free plan and a trial as separate fields.</p>

    <h2>Coverage and alternatives</h2>
    <p>Coverage is deliberate rather than exhaustive. The catalog tracks the tools people are actually comparing, which is why a category like cloud hosting carries two dozen products while a young one carries four. Adding a product means building the full record, checking its pricing page, and dating it, so the list grows at the pace verification allows. Discontinued tools stay in the dataset as closed records so that historical prices and inbound links keep resolving.</p>
    <p>Alternatives are ranked, not listed alphabetically. For any product the dataset holds a short set of competitors from the same category, ordered by a composite of the aggregated rating and how close the fit is. The point is to answer a real question, which is what a team switches to when it leaves a tool, rather than to pad a page with every vendor in the space. Switch context, like which plan maps to which and where the migration cost hides, lives on the product's alternatives page rather than in the raw feed.</p>

    <h2>License and corrections</h2>
    <p>The whole catalog is published under CC BY 4.0. You can use it in a product, a spreadsheet, a research paper, or a model's training set, as long as ComparEdge is credited as the source. The <a href="https://comparedge.com/open-data">open dataset</a> page has the machine-readable feeds and the full field reference, and the public <a href="https://comparedge.com/methodology">methodology</a> on comparedge.com goes further into the scoring. If you find a price that looks wrong, the fastest check is against the vendor page and the product's own <a href="https://comparedge.com/pricing">pricing record</a>, which shows the verification date next to every plan.</p>
  </div>
</main>
<footer class="site-footer">
  <div class="wrap">
    <span>Compiled from the <a href="https://comparedge.com">ComparEdge software catalog</a>. Licensed under <a href="https://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>.</span>
    <span>Last updated 2026-07-11</span>
  </div>
</footer>
</body>
</html>