Methodology

1. Importance score

Every tour, restaurant and event is scored once per build. The score decides whether a page is substantial enough to publish on its own URL.

• entity_count — how many known venues, landmarks, clubs or neighbourhoods the item is linked to in our knowledge graph. Weighted highest because a page connected to real places carries more context than an isolated listing.
• tag_diversity — the number of distinct canonical tags, after alias normalisation. Repeating a tag earns nothing.
• rating and review_count — taken directly from the source API. Reviews use a natural logarithm so a venue with 10,000 reviews does not drown out one with 500.
• semantic_weight — the sum of per-tag weights, reflecting how much search and commercial intent a topic carries (football 10, nightlife 8, fine-dining 8, italian 5, travel-transport 2).

The result is rounded to one decimal place.

2. Freshness score

A step function on the item's last update, in days. Stale content loses visibility automatically rather than waiting for a manual review.

3. Premium page threshold

Scoring alone does not publish a page. An item must clear the threshold below to get its own indexable URL; everything else stays inside listing and hub pages.

Events bypass the threshold because they expire on their own; an event that has passed is removed rather than kept at a low score. Experiences bypass it because they are assembled by hand.

4. City quotas

Without a cap, one city's large inventory would crowd out the rest. Each city has a maximum number of premium pages across all content types:

The quota caps how many pages a city gets. The traffic weight affects only which ones are picked — it multiplies the sort score, so when a quota is full the higher-demand pages are the ones that survive.

5. Priority score

Ordering within a city is a separate calculation from publishing. It blends intrinsic quality, estimated demand, and how well a page is supported by related content.

search_volume_score is modelled, not measured. We do not buy keyword data, so it is derived as base × city_multiplier × category_multiplier, where the base is 30 for tours, 25 for restaurants and 15 for events, and the category multiplier is the highest-weighted tag on the item (tours-sightseeing 3.5, food-drink 3.0, football 3.0). It is an internal ranking signal and should not be read as a traffic estimate.

cluster_density measures how many other pages share the same city and topic cluster, normalised to 0–10. A page surrounded by related coverage ranks above an isolated one.

6. Published statistics

Every number we publish as a statistic — median tour prices, typical durations, restaurant ratings, event distribution — comes from the list below. Each one is recomputed on every build from our own normalised dataset, and each sentence on the site states the sample it was measured across. Nothing here is estimated or hand-entered.

Methodology version

1.0.0

Last computed

2026-10-17T16:45:55.683Z

Percentile method

linear interpolation between closest ranks (R-7 / PERCENTILE.INC)

Publication rule

HIGH requires at least 30 items and 60% coverage; MEDIUM at least 10 items and 30% coverage; anything weaker is LOW. Minimum published confidence: MEDIUM.

Facts published / withheld

88 / 0

A metric is withheld rather than published when its sample is too small to be meaningful. Withheld figures do not appear anywhere on the site — the field is left out instead of being filled with a weak number. Source: engine/facts/fact-definitions.cjs.

Limits of this method

• Search volume is simulated from city and category multipliers, not sourced from a keyword API. It is a relative ranking signal only.
• Ratings and review counts are reported by the source platform. We surface them as given and do not independently verify them.
• Entity linking is automated and confidence-scored; low-confidence matches are discarded rather than published. Coverage is strongest in Manchester and London and is still being extended to our other cities.
• Weights and thresholds on this page are configuration, not fixed truths. When we change them, this page changes in the same commit.
• Sections 1–5 are written and maintained by hand against the code in our build pipeline. Section 6 is generated directly from the registry the statistics engine emits, so it cannot drift from the formulas actually used; a build check fails if it ever does.