What is raw data? Definition, examples and what aggregation loses

What raw data is

Raw data is the record a system writes when something happens. A web analytics tag writes an event. A store writes an order line. An ad platform’s API returns one row per campaign per day.

Three properties define it:

• Grain. Each row is one thing that happened, with its own timestamp and keys (user, session, order, campaign).
• No decisions applied yet. Nobody has chosen which statuses count as revenue, which visits count as a session, or which duplicates to drop.
• Not clean. Raw data carries duplicates, missing keys and test records. “Raw” describes the stage, not the quality.

“Raw” is also relative. The daily campaign rows an ad platform returns are already a summary of its click logs, but they are the rawest data you can get from that platform, so for your warehouse they are raw.

Raw data vs aggregated data

What aggregation loses: users that do not add up

Most pages describe raw data as “more detailed”. The concrete loss is sharper than that: some numbers cannot be rebuilt from totals at all. We ran the numbers on Google’s public GA4 sample, the obfuscated event export of the Google Merchandise Store for November 2020 to January 2021 (bigquery-public-data.ga4_obfuscated_sample_ecommerce, 4.3 million events).

A common shortcut is to export a daily users report and sum the days to get users for the quarter. On this sample:

Summing daily counts overstates users by 18.1%, because everyone who came back on a second day is counted again. Summing monthly counts is closer (3.1% high) and still wrong. Only the raw event rows give the real figure, because only they still carry user_pseudo_id:

WITH events AS (
  SELECT event_date, user_pseudo_id
  FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20210131'
),
daily AS (
  SELECT event_date,
    COUNT(DISTINCT user_pseudo_id) AS users
  FROM events
  GROUP BY event_date
)
SELECT
  (SELECT SUM(users) FROM daily) AS sum_of_daily_users,
  (SELECT COUNT(DISTINCT user_pseudo_id) FROM events)
    AS actual_users

How far off the shortcut lands depends on how often the same people come back on another day:

Sessions barely move, because a session rarely spans two days (only the ones that cross midnight count twice). Users and buyers move a lot, because they return. The rule: the more a thing recurs across days, the less its daily counts add up.

It is not a quirk of one dataset. On the [Demo] E-commerce shop data (owox-demo.ecommerce.sessions) for July to September 2026, summing daily visitors gives 78,528 against 65,191 distinct visitors, 20.5% high. If all you kept was the daily report, the quarterly number is gone.

Raw data is not clean data

The opposite mistake is to treat raw rows as correct. In the same GA4 sample, 5,692 purchase events carry only 4,451 distinct transaction IDs, and 906 have none. Counting events as orders would overstate orders by 28%. Duplicate transactions in Google Analytics walks through the query and the fix.

The lesson runs in both directions. You need raw data to get distinct counts right. And raw data needs written rules (deduplicate on transaction ID, decide what to do with rows that have none) before any number built on it is safe to share.

Examples of raw data in analytics

The textbook examples are survey answers and sensor readings. In a marketing or analytics team, raw data usually means these tables:

1. Web and app events. The GA4 export to BigQuery writes one row per event with nested parameters. See the GA4 export schema for how its tables and dates work.
2. Ad platform rows. Spend, clicks and impressions per campaign, ad group or ad per day, pulled from each platform’s API.
3. Order lines. One row per product per order from the store or ERP, with price, quantity, cost and status.
4. CRM records. Leads, deals and their stage changes, each with a timestamp.
5. Server logs. One line per request: IP, time, path, status code.
6. Survey and form answers. One row per respondent per question, before anyone tallies them.

Each of these comes with its own keys and its own grain. Most analytics work is making two of them meet at the same grain, which is where raw data stops being optional.

Why analysts keep raw data

An aggregated report answers the questions it was built for. Raw data is what you need for the next question. Keep it when you will ever need to:

• Count distinct things over a new period. Users and buyers do not add up across days (see above).
• Re-define a metric. “Revenue” with or without returns, “new customer” by first order or by registration. A new definition needs the rows.
• Re-slice. A segment nobody thought of when the report was built.
• Reconcile two numbers. When two dashboards disagree, only the rows show which one is right. That is data lineage in practice.
• Check quality. Duplicates, missing keys and late rows are visible only at row level. See data quality checks for the tests.
• Train a model. Forecasts and propensity scores learn from rows, not totals.

A simple rule: if a number will be defended in front of someone, keep the rows it was made from. The aggregate is a cache; the rows are the evidence.

Where to store raw data

Raw data belongs in a warehouse you control, not in the tool that collected it and not in a spreadsheet. A spreadsheet has a hard cell limit, a quarter of web events is already millions of rows, and a sheet keeps no record of what changed.

Layers: raw, cleaned, published

Most teams keep three layers in the warehouse:

The raw layer is what lets you replay history when a definition changes. The published layer is what keeps two people from computing “orders” two different ways from the same raw rows.

Practical rules

• Partition by date so queries read only the days they need, and cost follows.
• Set a retention policy. Decide how long raw rows are kept and say it in writing.
• Restrict access to personal data. Raw tables often hold emails, IPs and user IDs that the published layer does not need.
• Keep the load time. A column that records when each row arrived tells you how fresh a number is. See data freshness.

Any of the major warehouses works for this: Google BigQuery, Snowflake, AWS Redshift, AWS Athena, Databricks. The choice matters less than keeping raw and published data separate.

From raw data to a number people can use

Both examples above end the same way: someone writes a rule once (count distinct users over the whole period, count distinct transaction IDs), and every report should use that rule instead of reinventing it.

In OWOX Data Marts that rule is a Data Mart. The analyst writes the SQL over the raw or cleaned tables in your warehouse, for example a deduplicated orders query, and publishes it with a description and an owner. Related Data Marts join through relationships the analyst defines, which together form the data model. The raw data never leaves your warehouse.

Business users then get reports on the Data Mart in Google Sheets, Microsoft Excel or Data Studio, refreshed on a schedule. They see “orders” with one definition, and the analyst can show the SQL behind it when the number is questioned. The raw rows stay the source of truth, and nobody has to touch them to get an answer.

You can start with OWOX Data Marts on your own warehouse.

Data ModelingData Aggregation: Techniques, Examples and ToolsJuly 22, 2023→Data AnalyticsAn Analyst’s Guide to Handling Ad-Hoc RequestsMarch 23, 2026→Data AnalyticsAugmented Analytics: What It is, Use Cases and Examples, and Where It FailsOctober 14, 2026→

See all articles →