NAFYIVerified outcomes
Find servicesResourcesProvide servicesOrders
Find servicesResourcesProvide servicesOrders

Resources

COMPETITIVE INTELLIGENCE

How to Run a Competitor Pricing Analysis You Can Verify

The value of competitor pricing analysis is not copying a set of prices. It is enabling a team to see who was compared, when the pages were accessed, which billing definitions were used, and which conclusions return to original evidence.

Competitor pricing9 minPublished August 4, 2026

Who this is for

Product and growth teams designing packages, preparing a price change, or bringing external evidence into a pricing review.

Key takeaways

  • Freeze the decision question and comparison rules before opening pricing pages.
  • Capture price, billing period, unit, feature boundary, and access time together.
  • Keep page facts, analytical inferences, and unresolved unknowns distinct in the delivery.

On this page

  1. 1. Start with the decision
  2. 2. Freeze a comparable field contract
  3. 3. Capture evidence context, not just numbers
  4. 4. Normalize without flattening meaningful differences
  5. 5. Deliver facts, inferences, and unknowns separately
  6. 6. Check these eight items before delivery

1. Start with the decision

“Review competitor pricing” is not an acceptable scope. An executable question names the decision, subjects, and time boundary: Should we keep a free tier? Which plan should include team permissions? Is our annual discount outside the market range?

A precise question keeps collection stable. Without one, a five-competitor review can expand into twenty companies and move from public prices into private sales quotes—producing a long document that still cannot support a decision.

  • Decision: what should this analysis change or confirm?
  • Subjects: which products are direct competitors, substitutes, or reference brands?
  • Time: which access date or observation window applies?
  • Boundary: are regional prices, taxes, promotions, and sales quotes included?
Freeze the scope

Confirm competitor count, region, currency, billing period, team size, and decision questions before execution. Record scope changes instead of silently mixing them into the result.

2. Freeze a comparable field contract

Prices are comparable only when their billing units align. Per-seat monthly pricing, annual contracts expressed as a monthly average, workspace pricing, and usage pricing cannot share one column without context. Plan names are not equivalents either: one product’s Pro may map more closely to another product’s Business tier.

Define the field table before collecting pages. Give every field allowed values, a missing-value convention, and a normalization rule. That limits ad hoc judgment during execution and lets reviewers inspect why a value changed.

A minimum comparison contract
DimensionFrozen ruleFailure signal
PriceKeep original currency, period, and tax contextA number survives but its billing context disappears
UnitLabel seats, workspaces, and usage separatelyDifferent units are ranked directly
PlanMap by target user and key capabilitiesPlans align only by name
SourceStore original URL, access time, and page locationA screenshot exists without a visitable link
UnknownMark unpublished, quote-only, or unconfirmed valuesGuesses fill every blank

3. Capture evidence context, not just numbers

Each price record should include the original URL, access time, original page wording, and a necessary screenshot. If a regional redirect, login wall, dynamic toggle, or promotion affects the page, capture that access condition too.

A screenshot shows what was visible at the time; a URL lets a reviewer return to the source. Neither replaces the other. Pages change, so the delivery must keep access dates and avoid presenting an older screenshot as a current price.

  • Prefer the company’s pricing page, help center, or public contract documentation.
  • Use secondary aggregators to discover leads, not to override a primary source.
  • When several pages support one claim, state the role of each source.
  • Record access failures and conflicting statements as exceptions.

4. Normalize without flattening meaningful differences

Normalization should make comparison possible, not force every product into the same business model. You may calculate a monthly equivalent for an annual plan, but retain the original annual total and formula. You may map plans to small-team or enterprise tiers, but show the mapping criteria.

Treat usage tiers and custom quotes as business-model differences rather than empty cells. For the decision, that structural difference may matter more than whether one visible price is higher than another.

Recalculation rule

Every transformed value should be reproducible from the original value, formula, and assumption. A normalized price that cannot be recalculated does not belong in the conclusion.

5. Deliver facts, inferences, and unknowns separately

“The Business plan displays this annual price” can be a page fact. “The company uses permission controls to drive upgrades” is an inference from packaging differences. “The final Enterprise contract price” may remain unknown. Writing all three in the same voice hides their reliability.

A recommendation should cite the facts that support it and name its assumptions. If you recommend placing team permissions in a higher plan, show which competitors use a similar boundary, whether the sample is sufficient, and whether your own customer evidence supports the move. Competitor evidence reduces uncertainty; it does not replace customer evidence.

6. Check these eight items before delivery

A review-ready pricing brief lets someone who did not collect the data verify key figures and understand how the recommendation was formed.

  • The competitor set and selection rationale are confirmed.
  • Region, currency, tax, billing period, and team size are explicit.
  • Every key number has an original URL and access time.
  • Original wording and normalized values both remain visible.
  • Plan mapping has explicit criteria.
  • Conflicts, missing data, quote-only fields, and access failures are separate.
  • Facts, inferences, and unknowns use distinct labels.
  • Recommendations return to evidence and state the remaining internal validation.

NEED THE EVIDENCE, NOT THE BUSYWORK?

Need a pricing brief your team can review immediately?

The NAFYI competitor pricing evidence snapshot covers five competitors under a frozen scope, with original sources, access times, exceptions, and key conclusions.

View the pricing evidence snapshot

Continue reading

Complete the evidence chain with adjacent workflows.

Web data

Public Web Data Collection Checklist: Freeze the Schema First

An acceptance-ready public web data workflow covering field schemas, source boundaries, missing-value rules, provenance, and quality receipts.

Read
Web QA

Web App Smoke Test Checklist: Cover Critical Paths Before Release

A risk-driven Web App smoke testing method covering scope freeze, environment matrices, critical paths, evidence bundles, and release decisions.

Read
Proof Package

What Is a Proof Package? Making Agent Deliveries Verifiable

Learn how a Proof Package organizes outcomes, sources, execution records, validation states, exceptions, and acceptance rules into a reviewable Agent delivery.

Read