Publishing open data that citizens, journalists, and oversight bodies actually use

The default mode for government open data is performative compliance: a portal gets stood up, CSVs get dumped quarterly, and the dataset page records 47 downloads, half of which were the agency's own staff checking that the upload worked. The data exists. Nobody uses it. Meanwhile, a journalist files a FOIA request for the same information because they didn't know the portal existed, or because what's there doesn't match what they actually need.

This gap matters more in 2026 than it did five years ago, because the accountability infrastructure around government data has grown faster than most agencies' publishing practices. Investigative desks at outlets like ProPublica, The Texas Tribune, and The Marshall Project now run dedicated data teams that will pull from a well-structured portal daily if the data warrants it. State and federal oversight bodies increasingly expect machine-readable data as part of routine reporting, not just audits. If your agency's open data isn't usable, someone will eventually go around it, and what they find through FOIA or whistleblower channels tends to be less flattering than what a well-maintained portal would have shown.

A sequence of concrete steps

Start with the user before the dataset

Before publishing anything, mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → who actually uses government data in your jurisdiction. Call three journalists who cover your agency's beat. Ask a local open-government nonprofit, like the Sunlight Foundation's successor networks or state-level equivalents, what they've tried and failed to get from your portal. Talk to the oversight staff at your inspector general's office. What you'll find is consistent: users want longitudinal data they can track over time, clear variable definitions, and a reliable update schedule. They do not care about your internal system architecture.

That intelligence shapes every decision downstream.

Define the release schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → before the first export

One of the most common failures in government data publishing is letting the schema drift across releases. A journalist building a two-year analysis of your agency's contract awards breaks their pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → every time you rename a column or change how a vendor ID is formatted. Fix the schema before release one and document it formally, with a data dictionary that lives on the same page as the download link.

For financial and procurement data, align your field names to recognized standards. The Open Contracting Data Standard (OCDS) is the reference for procurement; USASpending.gov's field definitions are a reasonable model for federal agencies. Alignment to a known standard means journalists and oversight staff can apply tools they already have.

Section 508 of the Rehabilitation Act requires that electronic information published by federal agencies meets accessibility standards. For data, this means the portal interface must be screen-reader compatible and the documentation must be accessible, not just the raw file. Treat this as a publishing requirement, not a checkbox.

Choose formats that match actual workflows

CSV with a UTF-8 encoding and no merged cells is still the workhorse. Journalists open it in Excel or feed it into Python. Offer JSON alongside for developers building applications. If you're publishing geospatial data, GeoJSON or a Shapefile with a documented coordinate reference system is standard. Avoid publishing data only as PDF tables or as Excel files with formatting-dependent logic baked in; both formats break automated ingestion and will cost you repeat users.

For larger or frequently updated datasets, consider an APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → endpoint with stable versioning. The City of Chicago's Data Portal and New York City's Open Data program have both demonstrated that a reliable API drives substantially more developer and media use than static downloads alone. If your technology stack can't support a public API today, a predictable flat-file release cadence (weekly, on a named day, at a named URL) is the credible alternative.

Build the update process into operations, not project plans

Data that was published once and never updated is worse than data that was never published, because it misleads. Make the data pipelinedata pipelineETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.View full definition → an operational responsibility with a named owner, documented in your agency's data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → policy. If you're using a transformation layer, tools like dbt (from dbt Labs, a commercial vendor) can help automate and test SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.View full definition → transformations that feed your public releases. The testing capability matters: a failing test that catches a broken join before publication is the difference between accurate public data and a front-page correction.

Commit to a public changelog. When a field definition changes, or historical data is revised, publish a note. Oversight bodies rely on this. Auditors, particularly those operating under FAR-adjacent processes, treat undocumented data revisions as a red flag.

Make discoverability a first-class concern

A dataset that exists but can't be found is not open data. Register your datasets with Data.gov (for federal agencies) and your state's open data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition →. Write dataset descriptions in plain language that a journalist searching for "city contractor payments" will recognize, not in the internal language of your data warehousedata warehouseA central repository that consolidates data from many source systems into a structured, query-optimized store designed for analytics, reporting, and business intelligence.View full definition →. Include the time period covered, the update frequency, the source system, and a contact for data questions. That contact should be a real inbox that someone monitors.

Pitfalls that kill adoption

Releasing data without suppressing personal identifiers is the fastest way to create both a privacy violation and a legal incident. Before publishing any dataset that touches individuals, run it through a formal de-identification review aligned to whatever framework governs your data: HIPAA Safe Harbor for health-adjacent data, FERPA for education records. Get that review documented and retained, because FOIA requests on your own publication process happen.

Publishing data that contradicts figures in your official reports, without explanation, invites False Claims Act scrutiny if federal funding is involved. Reconcile public data to official reporting before release, and note any legitimate differences in methodology.

Procurement data is particularly sensitive. Releasing contract award data that inadvertently reveals a contractor's proprietary pricing can expose the agency to protest. Work with your contracting officer to identify fields that need redaction before any procurement dataset goes live.

Start this week

• Call one journalist who covers your agency and ask what data they've requested through FOIA in the past year. That list is your publishing backlog.
• Audit your existing portal: check when each dataset was last updated and whether the download URLs have been stable for 12 months.
• Pull your agency's current Section 508 compliance status for the portal interface. If it hasn't been reviewed since 2023, schedule one.
• Write a one-page data dictionary for your single highest-traffic dataset and publish it alongside the download link.
• Identify the internal owner of each published dataset and confirm they know they own it.

Open data publishing fails when it's treated as a communications exercise. It works when it's treated as an operational commitment with named owners, tested pipelines, documented schemas, and a direct line to the people who actually need the information. A portal that a ProPublica data reporter bookmarks is not an accident; it's the result of someone in your agency making specific decisions correctly.

The full course on this sector:Data in Public Sector & Nonprofit.