GA4 Raw Event Data Sample CSV (Dirty + Clean)
A production-realistic Google Analytics 4 event export (15,000 rows) mirroring the BigQuery export schema. The GA4 quirk: event_timestamp is stored in microseconds (16-digit integers), not milliseconds. Data engineers who treat these as Unix epoch milliseconds will shift all event dates to the year 53,000+, destroying time-series analysis. The 'dirty' version includes microsecond timestamps, null user_pseudo_id rows (bot traffic/consent denied), and event_params encoded as nested JSON strings that break flat-file parsers. Perfect for testing analytics engineering workflows, dbt model validation, and Looker Studio dashboards. Process everything locally — your analytics data never leaves your browser.
This Google dataset contains realistic, fully anonymized records. We purposely engineered it to include common messy data patterns—such as unmapped columns, dirty formatting, and duplicate IDs—so you can safely test your processing pipelines without exposing real PII.
💡 Pro Tip: GA4's nested event_params just broke your flat-file parser. Flatten it with JSON to CSV to extract keys like page_location into discrete columns. Zero data loss.
⚡ Next Step: Need to reconstruct sessions from raw events? Query this CSV directly with SQL in your browser — no BigQuery bills, zero cloud uploads.
Data Schema Definition
| Column Name | Data Type | Description |
|---|---|---|
| event_date | string | YYYYMMDD format string |
| event_timestamp | integer | 16-digit integer in microseconds (causes year 53000 bug) |
| event_name | string | e.g., page_view, session_start, purchase |
| event_params | json | Nested JSON string/array breaking flat CSV parsers |
| user_pseudo_id | string | Cookie ID (often null due to consent mode) |
| device.category | string | Inconsistent casing (desktop vs Desktop) |
| geo.country | string | User's country derived from IP |
Recommended Tools
Related Workflows
How to Query Nested JSON API Responses with SQL Directly in the Browser
Your Stripe API returns `line_items` nested 4 levels deep. Segment's tracking plan exports `event_properties` as objects inside arrays. Pasting this into Excel gives you a useless column of `[object Object]`. Writing a Python script with `json_normalize()` takes 20 minutes for a single ad-hoc query. This workflow loads raw JSON straight into DuckDB-Wasm, auto-detects the schema, and lets you run SQL with `UNNEST()` to flatten arrays and CTEs for multi-step logic—entirely inside your browser tab.
Isolate True Net Processing Fees from Stripe Balance Transactions
Stripe's Payouts export only shows the lump-sum deposit hitting your bank account — it tells you nothing about the per-transaction fee composition. To calculate your real effective processing rate, you need the Balance_Transactions.csv file, but this export dumps charges, refunds, adjustments, dispute reversals, and Stripe billing fees into a single flat table with no hierarchy. The Fee column contains negative values for processing fees, but refund-related fee reversals and dispute charges are interspersed without clear grouping, making a simple SUM() wildly inaccurate. This workflow filters the Type column to isolate charge, payment, refund, and dispute rows separately, recalculates the net fee per original transaction by grouping on Source ID, and produces a clean summary showing your true blended rate.
Reconcile Stripe Disputes and Refunds Against Original Charges
Annual Stripe exports for mid-volume merchants routinely exceed 500,000 rows, mixing successful charges, partial refunds, full refunds, dispute creations, dispute wins, and dispute losses in one monolithic CSV. The Type column uses cryptic values like dispute, dispute_reversal, and refund without linking back to the original charge amount in the same row. You must trace each dispute or refund back to its Source ID to find the original charge row and calculate net revenue impact. This workflow filters the export to only dispute and refund event types, joins them back to original charge rows using Source ID as the foreign key, and computes the net realized revenue per order after all adjustments.
Run Ad-Hoc SQL Queries on CSV Files Without Database Setup
When a stakeholder asks 'how many orders from California had a discount code in Q3?', the traditional workflow demands spinning up PostgreSQL, writing CREATE TABLE DDL statements, configuring COPY commands to import the CSV, and only then writing your SELECT query. For a one-off validation question, this environment setup takes 30-45 minutes of friction that discourages exploratory analysis. This tool registers your CSV file as a virtual table in DuckDB-Wasm running entirely in your browser. You write standard SQL — SELECT, WHERE, GROUP BY, JOIN, window functions — and get results in seconds. Schema inference handles type detection automatically, though you can override with explicit CAST operations when needed. The data never leaves your machine.
Sample Datasets
Zendesk Tickets Export Sample CSV (Dirty + Clean)
A production-realistic Zendesk support ticket export (5,000 rows) engineered to expose the exact edge cases that break naive CSV parsers and ETL pipelines. The critical Zendesk quirk: 'Description' and 'Comments' fields contain embedded CRLF (\r\n) line breaks from customer emails. Parsers that don't respect RFC 4180 quoting rules will split a single ticket into multiple invalid records. The 'dirty' version includes embedded newlines, null assignees, and UTF-8 characters without a BOM header. Perfect for testing ETL robustness (Fivetran, Python), RFC 4180 compliance, and helpdesk migrations (to Freshdesk/Intercom). Your support data is processed 100% locally — nothing uploaded.
Stripe Balance Transactions Sample CSV (Dirty + Clean)
A production-realistic Stripe Balance Transactions export (7,500 rows) covering the exact accounting edge cases that break financial reporting. The critical Stripe quirk: fee sign convention inverts depending on transaction type. For charges, the fee is negative, but for refunds/disputes, the fee becomes positive. Naive SUM aggregations double-count these reversals, silently inflating your P&L. The 'dirty' version includes UTC-forced timestamps, values stored in cents, unescaped commas in descriptions, and missing UTF-8 BOMs (causing €/£ mojibake). Perfect for testing SaaS P&L report accuracy, QuickBooks reconciliation, and building Net Revenue dashboards in Looker Studio. Your financial data is processed 100% locally — nothing uploaded.
Google Ads Keyword Report Sample CSV (Dirty + Clean)
A production-realistic Google Ads keyword performance export (4,800 rows) covering the structural issues that silently destroy automated CSV parsers. The Google Ads quirk: the CSV prepends two metadata rows before the actual header. Row 1 contains the report title and Row 2 the date range. When pandas reads this with pd.read_csv(), it treats the title as the header, causing every df['Clicks'] reference to throw a KeyError unless you use skiprows=2. The 'dirty' version includes this metadata header/footer, 1,120 zero-impression zombie keywords, Cost values formatted with $ symbols, and special characters (+, []) in keyword text. Perfect for testing ETL parser robustness (Supermetrics, Funnel.io) and account pruning workflows. Process everything locally — your PPC data never leaves your browser.