A technology survey lists several ecommerce platforms and their percentages add up to more than 100%. That result is not automatically an arithmetic mistake. The dataset may allow the same website to appear under several technologies, especially when a storefront combines systems or retains visible traces of an earlier implementation.
EcomToolkit’s position is that platform usage and exclusive market share should be labeled differently. This guide shows how to inspect overlapping counts and calculate what the data can actually establish. All platform names in the worked examples are fictional, and the numbers do not claim to describe today’s market.
Table of Contents
- Establish whether categories are exclusive
- Calculate unique reach with an overlap count
- Do not normalise away the question
- Show bounds when overlap is unknown
- Distinguish coexistence from a migration
- Build an auditable comparison for platform selection
- The EcomToolkit view
Establish whether categories are exclusive
Start with the counting rule. If every site receives exactly one primary platform label, the categories can form a partition of the population. If every detected technology is counted, one site can contribute to several categories. The percentages then measure usage prevalence, not mutually exclusive slices of a pie.
W3Techs explains in its FAQ that technology percentages can exceed 100% when websites use more than one technology. Its survey methodology also describes website-level counting. Those definitions are useful reading before transferring a figure from a detection report into a platform-selection presentation.
Do not assume every provider uses the same rules. One may count domains, another stores, another merchant organisations. A company operating three regional storefronts can occupy several rows in one dataset and one row in another. Overlap and entity duplication are related but separate problems.
Record the observation date, eligible population and unknown category. A result covering detected technologies on accessible sites is not automatically a census of active businesses. Keep that scope beside the number rather than expanding the claim to all merchants in later copy.
Calculate unique reach with an overlap count
Imagine 100 observed sites. Platform A appears on 60 sites, Platform B on 50, and both appear on 20. Adding the platform counts gives 110 detections. The number of unique sites using at least one of the two is 60 + 50 − 20 = 90.
The subtraction corrects the double counting of sites in both groups. It does not remove valid technology detections. Both the 110 detections and the 90 unique sites can be useful, provided they are described as different measures.
| Hypothetical site group | Unique sites | Share of all 100 sites |
|---|---|---|
| A only | 40 | 40% |
| B only | 30 | 30% |
| Both A and B | 20 | 20% |
| Neither A nor B | 10 | 10% |
| At least one of A or B | 90 | 90% |
The first four rows form an exclusive partition and sum to 100 sites. The final row is a summary of the first three, so it should not be added to them. Clear table labels prevent a reader from treating every displayed row as another category.
Do not normalise away the question
A tempting response to the 60% and 50% usage figures is to divide each by their sum. This produces approximately 54.5% and 45.5%. The numbers now sum to 100%, but they describe shares of the 110 detections, not shares of the 100 sites.
That transformation changes the denominator and therefore the meaning. It does not reveal which platform owns the checkout, processes the revenue or serves as the primary commerce backend. Calling the result platform market share would conceal those unresolved questions.
The denominator should follow the intended decision. A developer evaluating integration coverage may care about any detectable use. A merchant assessing a primary commerce platform may care about the active transaction system. A vendor estimating its commercial footprint may need merchant or revenue data unavailable from detection alone.
Avoid presenting a pie chart for overlapping usage categories. A labeled bar chart can show prevalence without implying that each site belongs to one category. When exclusive groups are available, a separate chart can show A only, B only, both and neither.
Show bounds when overlap is unknown
Suppose the report gives only 60 sites using A and 50 using B out of the same 100-site population. The overlap cannot be below 10 because there are not enough sites to keep both groups completely separate. It cannot exceed 50 because the smaller group has only 50 sites.
Consequently, unique reach for A or B lies between 60 and 100 sites. The exact answer is unavailable without joint information. Reporting that interval is more honest than assuming no overlap or inventing a primary-platform assignment.
| Known marginal counts | Possible overlap | Possible unique reach |
|---|---|---|
| A: 60, B: 50, population: 100 | 10 to 50 | 60 to 100 |
| A: 20, B: 30, population: 100 | 0 to 20 | 30 to 50 |
| A: 80, B: 80, population: 100 | 60 to 80 | 80 to 100 |
These are arithmetic bounds for two sets in a shared population, not statistical confidence intervals. They express missing joint information. Adding more observations to a report that still withholds overlap will not by itself identify the exact union.
For three or more technologies, pairwise overlaps are not always sufficient because some sites can belong to three groups simultaneously. Use record-level technology flags or properly defined joint groups when available. Avoid extending the two-platform subtraction casually to a larger stack.
Distinguish coexistence from a migration
Seeing A and B on the same site does not prove a migration. One technology may power a subscription flow, another a regional checkout, or an old script may remain after a completed change. Detection establishes a signal under the provider’s rules; interpretation requires additional evidence.
If migration analysis is the objective, track the same entity over time and inspect the relevant transaction journey. Define when a change becomes confirmed, how long conflicting signals remain unresolved and how domain changes are handled. Do not count every temporary overlap as a new merchant win for both vendors.
The platform detection precision and recall guide explains uncertainty in the detector itself. Overlap analysis assumes the recorded labels are the data being analysed; it does not guarantee that those labels accurately describe the site’s current commerce architecture.
Keep an unknown or ambiguous group where necessary. Excluding hard-to-classify sites can make a chart cleaner while changing the represented population. Report the excluded count and assess whether complex or large merchants are disproportionately removed.
Build an auditable comparison for platform selection
Ask the data provider for a stable entity identifier, the technology flags, the capture date and the primary-platform rule if one exists. If only aggregate counts are supplied, write down which joint questions cannot be answered. Do not manufacture record-level certainty from a summary table.
Separate the adoption signal from the merchant decision. Broad usage can indicate an ecosystem worth investigating, but it does not prove that a platform supports your product model, workflow or performance requirements. Confirm those capabilities through representative tasks and a realistic operating-cost assessment.
If you create an exclusive classification, publish the rule and its limitations. For example, selecting the backend that handles the main checkout may suit one research purpose but miss secondary regional operations. Apply the rule consistently and preserve original detection flags for later review.
The platform concentration guide requires particular care here. A concentration calculation based on exclusive shares should not silently ingest overlapping usage percentages. Resolve the population and category design before calculating a more sophisticated index.
Before publication, reproduce the totals from a small extract. Check unique identifiers, duplicate rows, unknown labels and overlap groups. Have another reader explain what each percentage means without help. If their interpretation differs from yours, improve the labels before using the chart in a procurement decision.
The EcomToolkit view
A percentage above 100% in a summed column may reveal overlapping technology use rather than broken arithmetic. The right response is to understand the entity and denominator, then choose an honest representation. If platform statistics are shaping a replatforming shortlist, request an EcomToolkit platform audit to connect adoption evidence with the architecture and operating model your team actually needs.
