How We Research

This page describes exactly how an article on ecomtoolshed is produced, and — just as importantly — what our method cannot tell you.

Last updated: September 21, 2026

The starting point: what we do not do

We do not hold accounts with, or personally operate, every product we write about, and we do not claim that we do. We are not a testing lab for software, and we will not write as though we had run a full evaluation of every tool we compare.

That admission matters, because it is the difference between a source you can calibrate and one you cannot. Everything below explains what we rely on instead, so you can judge how much weight to put on any claim on this site.

Step 1 — The vendor’s own documentation first

For every tool we cover, we start with what the vendor publishes.

  • Pricing pages and plan comparison tables for tier structure, per-seat and per-volume rates, overage charges, and what each plan gates.
  • Help-centre and documentation articles for hard limits, API quotas, export formats, and documented behaviour under load.
  • Terms of service and acceptable-use policies for contract length, cancellation, data ownership, and what the vendor reserves the right to change.
  • Changelogs and release notes for what has recently changed, especially where it affects pricing or limits.
  • Status pages and incident history for reliability, as published rather than as claimed.

When a figure is not published, we say so rather than estimating it. “The vendor does not publish this limit on the pricing page” is a legitimate and useful sentence. A guessed number presented as a fact is not.

Step 2 — Aggregate user reporting

Marketing pages describe a product at its best. User reports describe it at renewal.

We read reviews and discussion across review platforms, forums, and vendor communities, and we look for patterns rather than anecdotes:

  • Which complaints recur across many independent users, and which appear once;
  • Whether a problem is about the product or about billing and support;
  • Whether a limitation is a plan gate or a technical ceiling;
  • What users report about cancellation, refunds, data exports, and price increases.

One angry review is noise. The same billing complaint described by dozens of users is a signal. We report the pattern and its strength, and we do not fabricate individual quotes or invent reviewer identities.

Step 3 — Cost modelling at a stated volume

List price is the least useful number in this category, because every tool prices differently — by seats, by contacts, by orders, by page views, by email volume, or by a mixture.

We model, and disclose the assumptions behind:

Component What we model
Plan cost The tier you would actually need at the stated volume, not the entry tier
Unit pricing Per-seat, per-contact, or per-order charges, and how they step
Overage behaviour What happens when you exceed the allowance: hard block, automatic upgrade, or per-unit charge
Transaction fees Payment processing and platform percentage fees, where applicable
Add-ons Anything required to make the tool do the job, including features sold separately
Annual vs monthly The real discount for paying annually, and the lock-in it creates
Exit cost What it takes to leave — export limits, contract notice, migration effort

Assumptions are printed in the article, not hidden. If a cost model depends on a variable we cannot know, such as your order volume or your list size, we say which figure we assumed and let you substitute your own.

Step 4 — Cross-checking and conflict reporting

Published sources contradict each other constantly. A marketing page advertises a limit that a help-centre article qualifies. A review site repeats a price that changed two years ago.

When that happens we do not silently pick the flattering number. We state the conflict and explain which figure we consider better supported and why. Where we cannot resolve it, both figures appear, labelled.

What we label, and why it matters

We use a small set of explicit labels so you can see the evidentiary status of a claim rather than having to infer it:

Label Meaning
Published by vendor Taken directly from the vendor’s pricing page or documentation, with the source listed
Reported by users A pattern in aggregated user reporting, with the strength of the pattern described
Calculated Our own arithmetic from stated inputs, with the inputs printed
Unverified A claim we could not confirm against a primary source. It appears in the article only with this label
Not published The vendor does not disclose the figure, and we will not guess it

Our sources

Every article ends with a Sources list containing the URLs we actually consulted, with the date we checked them. Pricing pages are dated, because the date is the only thing that makes a price claim meaningful.

If a claim in the article cannot be traced to that list or to a label above, treat it as an error worth reporting — and tell us.

What our method cannot do

Being clear about the limits is part of the method:

  • We cannot tell you what your bill will be. We can show the arithmetic at a stated volume and name the assumptions. Your usage is the missing variable.
  • We cannot assess your compliance. Whether a tool’s data handling satisfies your obligations depends on your jurisdiction, your customers, and your contracts. That is a question for a professional.
  • We cannot verify every pricing page continuously. Vendors change pricing without notice and without a blog post. Always confirm at the vendor before you commit.
  • We cannot test your migration. What exports cleanly in theory often needs manual repair in practice. Back up and test before cutting over.
  • We cannot assess a tool we have no credible information about. In that case, we say so rather than filling the gap.

Corrections

If you find an error, email editor@ecomtoolshed.com with the article and the source you are relying on. We verify against primary sources, correct what is wrong, and record what changed under our Editorial Policy.