A technical deep-dive into the OpenAI Signals data portal and how to use its workforce telemetry for research.
What OpenAI Signals Exposes
OpenAI Signals is a data portal built around workforce telemetry: structured observations of how people and systems interact with AI products at work. For researchers, the value is not a single dashboard metric but a consistent schema that turns usage into joinable, comparable records. Treat the portal as a catalog of measurement definitions first and a download surface second. Before you model anything, read the field dictionary, unit conventions, and entity relationships so you know whether a row describes a person, a role, a team, a product surface, or an aggregate over a time window.
Workforce telemetry typically spans three layers: identity and organization context (who and where), activity and outcome signals (what happened and with what result), and metadata about collection (when the observation was made, at what grain, and under which sampling or privacy rules). Your first technical task is to map those layers onto the schema you receive, not to assume every column is ready for causal inference. Many fields will be descriptive or censored; others will be derived. Document which is which in your project notes so later analysis does not treat a rollup as a raw event.
Reading the Workforce Data Schema
Start with primary keys and foreign keys. Identify the stable identifiers for workers, teams, and product surfaces, then list the time grain of each table (event, session, day, week). Align clocks and time zones before you join. Next, classify columns by type: categorical enums, continuous measures, counts, rates, and free-text or opaque tokens. Enums need a closed value list from the documentation; if the portal allows open values, plan for unknown categories and schema drift between pulls.
Pay special attention to nullability and suppression. Workforce data often omits cells to protect individuals or small groups. A missing value may mean “not observed,” “not applicable,” or “withheld.” Encode those cases separately in your pipeline rather than filling zeros. Also note whether rates are precomputed or must be rebuilt from numerators and denominators; recomputing rates from partial joins is a common source of silent bias. When the schema ships version tags or changelog notes, pin your pipeline to an explicit version and fail the job if the version changes without review.
Practical Ingestion and Analysis Workflow
A durable research workflow looks like this:
- Pull a schema snapshot and a small sample before full extract; validate types and key uniqueness.
- Land raw files immutable (content-addressed or append-only), then build typed tables in a warehouse or analysis notebook.
- Define entity resolution rules for worker and team IDs that may recycle or reorganize.
- Build feature tables at a declared grain (for example, worker-day) with documented filters and exclusion rules.
- Run sensitivity checks: how results change under different privacy cutoffs, incomplete teams, or alternative time windows.
For modeling, prefer designs that match the observational nature of the data. Difference-in-differences, interrupted series, and hierarchical models can be appropriate when assignment is not random; always state the identification assumptions. Separate exploratory work from confirmatory analysis with a pre-registered question list when the research stakes are high. Keep product-facing metrics distinct from research constructs: a product “engagement” field is not automatically a measure of skill, productivity, or learning unless you justify the mapping.
Governance, Privacy, and Reproducibility
Workforce telemetry sits at the intersection of research utility and employment privacy. Use least-privilege access, strip or hash direct identifiers unless the research design requires them, and avoid publishing cell-level outputs that re-identify small groups. Prefer aggregate tables with minimum cell sizes, and document any suppression rules you apply on top of the portal’s own. If you share derived datasets, include the schema version, extraction timestamp, filter logic, and a data dictionary for every derived column.
Reproducibility means more than saving a notebook. Version your extraction queries, record environment and package versions, and keep a changelog of schema adaptations when fields rename or split. When results will inform policy or product decisions, run a second independent replication path—even a simpler reimplementation of the joins and rate calculations—to catch pipeline bugs. Used this way, OpenAI Signals is less a finished answer set and more a disciplined measurement interface: schema-first, privacy-aware, and explicit about what each field can and cannot support.