How to read Cledara research
Research methodology
Our research measures recorded software payments and spend in the Cledara customer population. Payment activity is a useful signal of purchasing, but it does not measure product usage, quality or the whole market.
Methodology revised · research-methodology-v2
Sources and population
Cledara research describes software purchasing and payment activity observed through the Cledara platform. The customer population and its software mix can change over time. It is not a representative survey of all businesses or the entire software market.
Public benchmarks use aggregated purchasing signals. Customer identities and absolute buyer counts are withheld. Anonymous individual purchases in the activity ticker are transaction activity, rather than aggregate benchmarks; the ticker does not identify the buyer.
Product, team, category, investor and headquarters classifications are enriched from recorded source information and can be incomplete or corrected. Missing observations remain unavailable; a missing payment or classification is not proof of zero activity. Products with different names or shared domains are not necessarily the same product.
What the metrics mean
- Payment activity and popularity rank
- Recorded software purchase and renewal transactions determine the activity ranking. A lower numerical rank indicates a higher position. “Popularity” is a payment-activity label, not measured active users or distinct customers.
- Activity share
- The comparison metric is the product's percentage of trailing 12-month software purchase and renewal transactions across tracked software. Each page states its own scope; category and team metrics may use narrower groups.
- Spend rank and spend share
- These describe the product's relative position or share within the stated recorded software-spend population. They do not measure price per seat, vendor revenue or value for money. A percentage-point share change is different from percentage growth.
- Rank movement
- A change in rank positions over the named window. It is not a percentage growth rate. A calendar-month comparison requires both observations; missing history does not become a zero change.
- Payment overlap
- Comparison overlap describes buyers with recorded payments to both products across available transaction history, as separate percentages of each product's recorded buyers. It does not prove current co-use, compatibility or a shared workflow.
- Investor rankings
- Recorded portfolio holdings are grouped by their positions in software-spend ranking tiers. This is a portfolio exposure measure, not investment returns or verified investor performance.
Read the denominator and observation period beside the finding and in its public data download. Different scopes are not interchangeable. A changing customer cohort, billing schedule or product classification can affect a time series without establishing a causal market trend.
Observation dates and updates
The observation period describes the payments or monthly metrics included. The page's updated date describes a change in published content. A cache refresh does not establish new payments or a later observation period. A retained publication can remain available when its next refresh is delayed.
The batch research pipeline is configured to run hourly by default; deployment settings, source availability and job failures can change that cadence. Monthly metrics describe their stated observation months. The Spend Index uses complete eligible months, and its warm-up scheduler runs every six hours by default with a 24-hour live cache. These schedules do not promise hourly changes in every dataset.
The transaction tail normally covers about 48 hours. A successful current sync cannot establish that an earlier missed window was captured. Operators retain durable source checkpoints and unresolved gap warnings, and use bounded platform exports to reconcile missed history. Historical completeness is not inferred from a recent payment or a successful refresh.
Quarterly Spend editions use their original publication date and stored data. If an edition is absent, it is unavailable; current data must not be substituted under an older edition URL. Use an edition link when one is offered, and keep the downloaded data with your citation.
Spend, currencies and publication floors
Spend Index monetary benchmarks show the median and the 25th and 75th percentiles, separately for GBP, EUR and USD. These currency slices are inferred from buyer geography (UK, EEA and US); they are not a blended foreign-exchange-converted total. Unknown currency in the transaction ticker is shown as unknown.
The overall annual spend band is an observed trailing 12-month per-company distribution. Category “annualized monthly” bands multiply the eligible month's per-company band by 12; they are estimates based on that month, rather than observed annual category spend. Annual invoices and seasonal purchases can affect these measures.
Spend Index cells require at least 20 eligible companies internally before publication. Payments without a recorded, nonblank buyer identity are excluded from per-company spend distributions and their calendar coverage. Monetary sample floors count companies with at least one finite recorded amount in the selected window; missing amounts do not become observed zero spend. Absolute customer counts are not published. Coverage gates can omit incomplete months, and the headline index uses a trailing three-month rolling median relative to its eligible baseline. Gaps remain visible rather than being interpolated into invented values. Older editions may use earlier documented methodology; their own metadata governs interpretation.
Read the Spend Index's specific methodology and available editions.
Inferred usage-based billing
Current definition: calendar-cadence-v2
Conservative payment-cadence proxy, not confirmed usage billing. Positive software-subscription payment days are grouped by subscription, buyer, vendor, currency geography and declared periodicity. Same-day charges collapse; repeated equal amounts within three days are treated as possible retries. Credits reset the evidence window. At least three clean payment days and two unusually short gaps are required, with short gaps a strict majority of the latest six gaps. A gap must be at least two days and shorter than the calendar interval by more than the greater of two days or 20%. Each observation uses only payments recorded on or before that day. Proration, timing changes and unidentified retries can still affect the inference.
The public share uses clean positive software-subscription payment days, not the percentage of companies or vendors with verified usage-based pricing. The upstream feed's cleaned amount can hide refund signs or omit status information, so not every retry, credit or proration can be removed. The inference should not be treated as confirmed contract terms.
Departures and possible switching
Current definition: departing-calendar-cohort-v1
Inferred new adoption among prior monthly/weekly software-subscription payers with no positive payment to that vendor in the following calendar window. Declared billing coverage plus seven days of renewal grace excludes still-covered buyers. A destination must have no earlier observed positive payment by that buyer and share a recorded team or unambiguous category. The denominator is the actual departing cohort, including departures masked by new buyers. At least five departed buyers and two destination adopters are required internally; counts are not published. Multiple destinations are allowed, so percentages may sum above 100. Payment gaps do not prove cancellation or replacement; source history and classification coverage limit the inference.
Comparison switching uses a three-calendar-month window by default, anchored to the latest eligible source payment. Explicit product aliases connect known name variants without merging distinct products that share a corporate parent or domain. Declared annual, quarterly, monthly and weekly payment coverage plus seven days of renewal grace protect continuing buyers. The calculation uses the actual departing cohort even when new buyers increase the vendor's total.
Available history cannot establish that a customer never used another product outside Cledara. A latest-payment watermark does not prove complete feed coverage. Neither a missed renewal nor a new payment proves cancellation, replacement, product usage or the reason for a decision.
Vendor geography is different from buyer geography
Country and city directories group vendors by recorded headquarters. They describe software vendors based in that location and their measured spend position in the Cledara dataset. They do not describe all buyers in that country, national software market share or place of incorporation. Enrichment may be missing, stale or revised. Spend currency slices and buyer-geography filters describe different populations.
Citation, downloads and reuse
Use each research page's citation and CSV/JSON controls. Include the page title, source URL, observation window, selected metric and currency, and the edition or methodology version when supplied. Chart-download time is not the data date. Downloads are available without an email signup.
Attribution example: Cledara, “[page title]”, [page or edition URL], observations [period], [selected scope], accessed [date]. State any changes you make to the data or chart.
Site data is licensed under Creative Commons Attribution–NonCommercial 4.0. Follow the licence's attribution and noncommercial terms; public access does not grant unrestricted commercial reuse. For commercial reports or uncertainty about a proposed use, contact Cledara about permission.
Methodology revisions and corrections
- — research-methodology-v2: per-company spend and calendar coverage exclude missing or blank buyer identities; monetary publication floors exclude companies with no finite recorded amount, and missing percentiles cannot become zero.
- — research-methodology-v1: consolidated source, metric, inference, date and reuse definitions. Calendar billing and departing-cohort definitions are identified above; this revision date is not a new data observation.
Page-level metadata and downloads record the methodology available for that publication. A methodology revision does not retroactively create missing historical data. Report a possible error with its source URL, observation period and downloaded values via the research correction contact.