What Customers Actually Said

Every rating is delivered twice: once on a common scale so platforms can be compared, and once exactly as the source recorded it. Keeping the original matters, because a five-point scale and a ten-point scale do not carry the same distribution and a conversion that discards the source value cannot be audited later. Which normalisation you want is a scoping decision, since the right one depends on whether you are comparing across platforms or tracking within one.

Yes, and it is usually the most valuable part of the engagement. You supply your catalogue with whatever identifiers you hold, and reviews are matched to your SKUs across platforms — which is what turns a pile of review text into something a product team can act on per line item. Matching accuracy is validated against a sample before rollout rather than asserted.

Where the platform exposes it, yes, and it is one of the more important fields in the set. Unverified reviews are not worthless, but they behave differently enough that most analysis should either weight or segment on this flag. Where a platform provides no such signal, the field is explicitly null rather than defaulted to false.

We deliver the raw signals that detection depends on — reviewer history, posting-time clusters, verified-purchase ratios, rating distribution shape, and text duplication — rather than a single verdict field. We are deliberate about that: a proprietary fake-review score you cannot inspect is not something you should be making competitive decisions on. Customers apply their own thresholds to signals they can see.

For most platforms, the complete public review history on a listing, which for established products can run to years. Historical backfill is scoped and quoted separately from ongoing monitoring, and depth is confirmed per platform during scoping since some paginate their archives far more shallowly than others.

We treat them as though they do. Reviews are user-generated content that frequently contains identifying detail, so they are handled under a DPA with a documented lawful basis, deletion at source propagates to subsequent deliveries, and reviewer identifiers can be pseudonymised or dropped entirely at delivery if your use case does not require them.

Into the systems you already run. Records land as JSON, CSV, or Parquet in S3, GCS, or Azure Blob, or straight into Snowflake or BigQuery, on whatever cadence you set. Webhooks push new records to your endpoints as they are detected, which is how most customers wire alerting. A solutions engineer sets the schema, cadence, and destination with you during onboarding rather than handing you a docs page and wishing you luck.

Keeping the collectors working is our responsibility, not yours. Extractors are monitored continuously, and when a site changes we patch upstream while the schema we deliver to you stays fixed — so nothing downstream needs to be touched. If a change causes a genuine coverage gap we tell you which window was affected rather than quietly returning fewer records.

Yes, and we would rather you did. Every engagement starts with a free sample run against your own targets — your competitors, your catalogue, your keywords — and we hand back the actual dataset. Judging real output against your real requirements is the only useful evaluation, and it is a much better use of a first conversation than a slide deck.