Skip to content

Excel (.xlsx) download format for download packages — evidence and recommendation #6781

Description

@Marigold

Summary

Should our download packages (chart / data page / mdim) offer an Excel .xlsx file alongside the CSV+metadata+README zip?

Proposed in the mdim download-package review (#6668) as an xlsx with 4 tabs — Data / Metadata / Sources / Readme — and deferred in #6769 with "the Excel variant is on hold until we know whether anyone would use it".

Current recommendation: don't build it yet. Filing this so the evidence is written down and it can be triaged rather than re-litigated.

What we know about demand (checked Sept 2026)

Short version: there is no demand signal, in either direction.

  • No external user has ever asked. An org-wide sweep of issues and comments for excel / xlsx / spreadsheet finds zero external requests. Every mention is internal:
  • Google search demand is negligible and mostly aimed elsewhere. Over 12 months, queries reaching ourworldindata.org mentioning Excel/XLSX/spreadsheet total 39,315 impressions and 2 clicks. The top ones are maddison project database 2023 download excel, sipri military expenditure database excel download, "ghe2021_deaths_bycountry_2020.xlsx" — people hunting the producer's spreadsheet, not an OWID export. An Excel-native audience exists; nothing shows it wants Excel from us.
  • Nobody is guessing at an xlsx endpoint. /grapher/<slug>.xlsx doesn't exist and gets ~470 requests/month, all 404, overwhelmingly vulnerability scanners.

Important caveat: every instrument above measures behaviour on formats we already serve. You cannot measure revealed preference for an option that was never on screen, so the absence of a signal is not evidence that demand is absent. This question is not answerable from analytics — only by shipping something and measuring.

Why not now: the cost is the format, not the file

Generating an xlsx is nearly free — Table.to_excel(with_metadata=True) already exists in owid-catalog (lib/catalog/owid/catalog/core/tables.py) and writes a data sheet plus a metadata/codebook sheet. And the download modal already ships an Excel/Google-Sheets affordance today (=IMPORTDATA(csvUrl)).

The expensive part is getting the presentation right. The 4-tab shape means porting the README/citation/sources formatting into a spreadsheet layout and then keeping it in sync. etl/collection/download_package_format.py is already a hand-maintained Python port of grapher's own formatting logic; adding a second presentation surface doubles that sync burden for a format nobody has asked for.

Context on who actually reads downloads

Worth weighing: ~98% of requests to chart data-file endpoints are machines. Even on life-expectancy — the most-downloaded chart on the site — a realistic human data-download count is a few hundred per month (measured as in-browser clicks). Excel is a human-only format, so it competes for a small, though real, slice of the audience.

If we decide to do it

Ship the simplest version first: data sheet + metadata sheet from the existing writer, as a second button next to the zip. Then read the split after a month. Don't build the 4-tab format up front — that's the part with the maintenance cost, and we'd be building it on intuition.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions