Analytics

Meridian measures its own sites. Page views are recorded on the server as each page renders; outbound clicks, phone reveals and card impressions are recorded through first-party links and a small script the engine serves. Everything is stored in your own database, aggregated into hourly, daily and monthly rollups, and read on the admin’s Insight screens, in exports and in reports.

This is how an event travels from a visitor to a figure:

flowchart LR
  subgraph collect["Collection"]
    render["Page render<br/>(server)"]
    beacon["/_e beacon<br/>(analytics script)"]
    tracked["/r/v1 tracked link"]
    api["Content API events<br/>(headless)"]
  end
  collect --> filter{"bots, exclude_ips,<br/>DNT"}
  filter --> raw[("Raw events<br/>monthly partitions")]
  raw --> rollup["Hourly, daily and<br/>monthly rollups"]
  rollup --> insight["Insight dashboards"]
  rollup --> export["Exports"]
  rollup --> reports["Member and<br/>organisation reports"]

The design is privacy first: no cookies, no IP address stored, no user id, no fingerprint. Because no personal data is processed and no cookie is set, the analytics needs no consent banner.

What you get with no workCopy Anchor Link

Analytics is on by default (analytics.enabled: true). With nothing in your templates, every page render records a page_view, every search records its query, and index pages and search filters record what was filtered. Staff with analytics.view see the Insight overview for the site.

To record interactions as well, print the client in your layout:

  {{ analytics() }}
</body>

It writes one deferred script tag (/_e.js) and nothing in a preview. The script records card impressions and marked interactions, batched into one request to /_e. Without JavaScript nothing it measures is recorded; server-side views and tracked links still work.

What is collectedCopy Anchor Link

Every event carries: the time, the site, the locale, the source channel (organic, social, referral, campaign, internal or direct), the medium (the referring host or the campaign), the campaign (utm_campaign, normalised), the device class, the country when a trusted proxy supplies it, and two keys. The keys are an HMAC of the address, user agent and site under a salt that changes every UTC day; the previous day’s salt is deleted when the next is made, so nothing links across days and nothing can be reversed. A visit is one visitor key’s day. Each event of a visit is attributed to the source of the visit’s first event, so no cookie is needed to carry it.

Not collected: the IP address, any cookie, any user or member id, any free text a visitor typed (search queries are kept in the separate search log, without identity), cross-day identity. So there is no returning-visitor metric, no multi-session funnel and no cohort retention.

FilteringCopy Anchor Link

• Bots. bot_filtering: standard drops requests whose user agent is on the built-in crawler list; strict (the default) also drops requests claiming to be a browser without an Accept header; off keeps everything.
• Your own office. exclude_ips lists addresses and CIDR ranges that record nothing. They are compared in memory and never stored.
• Do Not Track. With respect_dnt: true, a request with DNT: 1 or Sec-GPC: 1 records nothing.
• Repeat views. Repeat views of the same subject by the same visitor key within dedupe_window (30 minutes) count once when events are rolled up.
• Previews and tooling. Previews, engine-dmo render and the warm job record nothing.

Template helpersCopy Anchor Link

Tracked outbound linksCopy Anchor Link

track(entry, kind, url) returns a first-party, signed /r/v1/ address that records the click and redirects to the target. It works without JavaScript, cannot be spoofed and cannot be used as an open redirect. An empty target returns an empty string, so a template can pass a field that may be absent. Like every address in an href, print it through the url filter; engine-dmo check refuses one that is not. The target may be a string or a link value (its url).

{% if entry.website %}<a href="{{ track(entry, 'website', entry.website)|url }}">Visit the website</a>{% endif %}
{% if entry.bookingUrl.url %}<a href="{{ track(entry, 'booking', entry.bookingUrl.url)|url }}">Book</a>{% endif %}

reveal(entry, kind, value) does the same for a telephone number (kind phone, making a tel: link) or an email address (email, a mailto: link):

{% if entry.phone %}<a href="{{ reveal(entry, 'phone', entry.phone)|url }}">Call {{ entry.phone }}</a>{% endif %}

The target must be an ordinary web, mail or telephone address. The entry’s organisation is stamped on the event (DMO bundle), so a business’s figures survive a listing moving between organisations.

Marked elementsCopy Anchor Link

With {{ analytics() }} on the page:

The beacon accepts only interaction events (impressions, clicks, reveals, shares, downloads, filters and search events); page views cannot be reported through it. Cards patched into the page later are watched too.

Insight and dashboardsCopy Anchor Link

The admin’s Insight screen shows a site’s dashboard over a date range with a comparison. Without a dashboards file, the overview shows visits, page views, listing views, member referrals, page views over time, the top listings and the top zero-result searches.

Declare your own dashboards, and the figures staff enter by hand, in config/analytics/dashboards.yaml:

# config/analytics/dashboards.yaml
metrics:
  - { key: box_office_visits, kind: entered, label: { en: Box office visitors }, period: month, unit: people }

dashboards:
  - key: default
    name: { en: Overview }
    default_range: 30d
    compare: previous_year
    widgets:
      - { type: metric, metric: visits, size: 1 }
      - { type: metric, metric: page_views, size: 1 }
      - { type: metric, metric: box_office_visits, size: 1 }
      - { type: timeseries, metric: page_views, breakdown: source, interval: day, size: 4 }
      - { type: table, metric: page_views, dimension: page, limit: 10, size: 2 }
      - { type: table, metric: search_zero, dimension: query, limit: 10, size: 2, highlight: true }
      - { type: funnel, steps: [page_views, downloads], size: 2 }

Run engine-dmo check --fix to write the entered metric’s id.

Dashboard keysCopy Anchor Link

Widget keysCopy Anchor Link

MetricsCopy Anchor Link

The DMO bundle’s memberships module adds these:

That is the whole catalogue: these keys are what a dashboard widget, an organisation report’s KPI and a funnel step may name, besides your entered metrics. A funnel’s steps must be counted events: the metrics from page_views to enquiries in the first table. No command prints the catalogue; this table is it for this version. A widget naming a metric the bundle does not compile is refused. engine-dmo check reports every mistake at its line: an unknown metric (with a suggestion), a dimension the metric does not have, a funnel with one step, a size or limit out of range.

Entered metricsCopy Anchor Link

A figure no website measures, such as visitor numbers from a survey, is declared under metrics: with kind: entered:

Staff with analytics.enter record a value per period on the Insight screen’s entered figures page. An entered figure is always shown as entered, never as measured.

ExportsCopy Anchor Link

The Insight screen exports the dashboard on screen as CSV or JSON (analytics.export). The command line does the same:

engine-dmo analytics export --site main --range 30d --format csv --out overview.csv
engine-dmo analytics export --site main --metric page_views --from 2026-09-01 --to 2026-09-30 --format json
engine-dmo analytics export --dashboard board --range this_financial_year --compare previous_year --as analyst@example.org

Every export is audited.

Retention and rollupsCopy Anchor Link

Raw events are kept for raw_retention_days (90) in monthly partitions, dropped a whole month at a time once every row in it is past the window. Hourly rollups and the search log are kept for 400 days. Daily and monthly rollups are aggregated, identify nobody and are kept. Rollups and retention run on the engine’s scheduler; the commands run them by hand:

The DMO bundle adds member reports, the monthly digest and scheduled organisation reports (Member reports).

Headless sitesCopy Anchor Link

A headless frontend has no server-rendered views, so the content API hands it a signed view token with each document it resolves. The frontend reports the view through the beacon (proxied under its own domain) or from its server through the content API’s events operation, and the engine records exactly the events a rendered page would. See the content API.

PermissionsCopy Anchor Link

Configuration referenceCopy Anchor Link

Every key is under analytics: in config/engine.yaml.