Member reports

The member report shows one organisation its own numbers for a period: how often its listings were seen, what visitors did next, the enquiries it received, where its visitors came from, how it compares with similar businesses, what people searched for, and what it could do to its listing to do better. It is computed once and served in four places, so they never disagree:

The report needs analytics to be on (analytics.enabled: true in engine.yaml, see Analytics) and listings linked to their organisations.

What is in itCopy Anchor Link

Each figure carries its change on the same period a year earlier and a direction (up, down or level). The events are recorded by the public pages; see Counting what visitors do.

The monthly digestCopy Anchor Link

The digest is one email per organisation per site, sent to every current contact who may edit the listing and has not opted out (a link in the email stops it). It is declared as a member report:

reports:
  - key: member-monthly
    name: { en-GB: Your monthly performance }
    audience: member
    schedule: "0 8 2 * *"
    format: [email]
    range: previous_month
    compare: previous_year
    tiers: { min: bronze }

and switched on in the portal’s file:

portal:
  report:
    email_digest:
      enabled: true
      report: member-monthly
      skip_when_no_data: true

The digest uses the report’s schedule, range and tiers, and needs email among its formats. It sends to each organisation with an active membership in the report’s tiers. A period with no impressions and no interactions is skipped when skip_when_no_data is on. A run is recorded per site and per report, so a restart or a second scheduler tick never sends twice, and a contact whose address is suppressed leaves an entry on the organisation’s timeline instead.

engine-dmo analytics digest queues the digest for the current period now, whatever the schedule says; --run also works through the mail queue in the command rather than leaving it to the server.

Report definitionsCopy Anchor Link

config/analytics/reports.yaml holds every scheduled report. engine-dmo config schema --file reports prints its schema.

Organisation reportsCopy Anchor Link

An organisation report sends the destination’s own figures against targets to the recipients the environment names, for a board or a funder:

  - key: board-quarterly
    name: { en-GB: Quarterly board report }
    audience: organisation
    schedule: "0 9 5 1,4,7,10 *"
    format: [email, pdf]
    range: previous_quarter
    compare: previous_year
    to: ${BOARD_REPORT_RECIPIENTS}
    metrics:
      - { key: visits, target: 120000 }
      - { key: member_referrals_total, target: 9000 }

BOARD_REPORT_RECIPIENTS="board@example.org,chair@example.org"

A metric is one of the engine’s measured metrics (such as visits, page_views, listing_views, enquiries, member_referrals_total, searches, members_active) or a figure staff enter, declared in config/analytics/dashboards.yaml. The full list of metric keys is in Analytics; no command prints it. Staff see each run under the admin’s Reports screen in Insight, and engine-dmo analytics report-run --report board-quarterly [--site <site>] [--run] queues one for its current period now.

Report settingsCopy Anchor Link

config/portal/portal.yaml holds the comparison and prompt rules, install-wide.

Improvement promptsCopy Anchor Link

Each rule looks at the organisation’s listing and, where the site’s own data supports it, says how much a change is worth. A prompt for a field the member’s tier may not edit is not shown, and a rule with no field on the listing type is not shown.

portal:
  report:
    improvement_prompts:
      enabled: true
      max_shown: 4
      rules:
        accessibility: { fields: [accessibility, accessibilityNotes] }
        website: { field: website }
        booking_link: { field: bookingUrl, tiers: { min: silver } }

The fields named here (accessibility, accessibilityNotes, bookingUrl) must be fields of your listing type: check reports a named field the type does not have, and a tier the tier list does not declare. A rule you leave out of rules: keeps its default.

CommandsCopy Anchor Link

All three need the database. The PDF is printed by a browser the engine drives (analytics.pdf.renderer in engine.yaml); engine-dmo version --require pdf exits 1 when this build cannot produce one.

In the portal’s templatesCopy Anchor Link

The report screen renders report.html in the portal’s template directory, and a custom screen can read the report with a report data source (figures: { report: { range: last_month } }, see Portal screens and actions). Copy report.html with engine-dmo portal scaffold --site <site> to restyle it.