Zendesk

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.

This Zendesk 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: Your CSV parser just exploded because a customer used a line break in their email. Run this file through Format Cleaner — it respects RFC 4180, fixes the CRLF nightmare, and outputs a perfectly flat CSV in seconds.

⚡ Next Step: Need to know which agent resolved the most 'billing' tickets last month? Query this CSV directly in your browser with SQL — zero database required.

Data Schema Definition

Column NameData TypeDescription
Ticket IDintegerUnique ticket identifier
SubjectstringEmail subject or ticket title
DescriptionstringContains embedded CRLF (\r\n) line breaks that break parsers
StatusstringOpen, Pending, Solved, or Closed
RequesterstringCustomer name (often contains UTF-8 chars like é, ñ)
AssigneestringAgent name (frequently null for unassigned tickets)
TagsstringSpace-separated string of tags

Recommended Tools

Related Workflows

How to Anonymize Customer Data Before Sharing with ChatGPT or Claude

Your raw customer CSV contains toxic PII. Pasting it into ChatGPT sends that data to OpenAI's servers—risking a Samsung-style corporate leak. This SOP local-masks names, emails, phones, and IPs using browser-based hashing. It preserves column types and statistical structures for LLM analysis, rendering the output completely untraceable to real users.

How to Clean Apollo Exported Leads Before Importing into Cold Email Software

Apollo exports include 'guessed' emails and hidden spam traps. Importing raw Apollo CSVs into Instantly guarantees an automatic campaign pause. This 4-step workflow filters out non-verified addresses, purges role-based targets (info@, admin@), flags catch-all domains, and formats the header row for zero-mapping imports into Smartlead or Lemlist.

How to Convert Stripe Payout Reports into QuickBooks Import Format

Stripe's balance detail export dumps charges, refunds, and fees into a flat CSV (gross, fee, net). None of this maps to QuickBooks Online's rigid 3-column schema (Date, Description, Amount). While Stripe admits IIF files only work for QBD, SaaS connectors like A2X charge $49/mo to bridge the gap. This workflow splits your transaction types into specific Chart of Accounts buckets (Revenue, Merchant Fees), converts ISO 8601 timestamps to MM/DD/YYYY, and generates a CSV that passes QuickBooks import validation with zero reconciliation errors.

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.

Sample Datasets

Amazon FBA Settlement Report Sample Data

A representative Amazon Seller Central settlement report (TSV format) with 150 transactions. It covers all critical row types: Orders, Refunds, FBA Fees, Adjustments, and Transfers. The 'dirty' version includes common beginner traps like Transfer rows (which cause double-counting) and TSV delimiter issues that break Excel. The 'clean' version shows a collapsed profit summary ready for QuickBooks import. Ideal for auditing FBA fees or testing automated profit calculation scripts without exposing your actual store revenue. All processing runs locally — your financial data never touches a server.

HubSpot Contacts Export Sample CSV (Dirty + Clean)

A realistic HubSpot contact export (8,500 rows) covering the data quality issues that break CRM migrations and warehouse schemas. The HubSpot-specific quirk: multi-select custom properties and system fields (like Lead Status) are exported as semicolon-separated strings (e.g., 'New;Qualified;SQL'). Data engineers unfamiliar with this will split fields incorrectly, destroying the taxonomy. The 'dirty' version includes semicolon strings, emails with trailing whitespace (causing duplicate re-imports), and inconsistent company casing. Ideal for testing CRM migrations (to Salesforce), Reverse-ETL dry runs, and building Dim_Contacts schemas. All cleaning happens locally — your contact database stays private.

Salesforce Leads Export Sample CSV (Dirty + Clean)

A production-realistic Salesforce lead export (6,200 rows) engineered to expose validation errors that crash Data Loader bulk imports. The Salesforce quirk: strict validation on fields like LeadSource means even a single invisible character triggers INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST errors. The 'dirty' version includes LeadSource values with zero-width spaces (U+200B) invisible in Excel, malformed 15-character Lead IDs missing the checksum suffix (causing upsert failures), and embedded commas in company names. Perfect for testing API integrations, Data Loader workflows, and Marketing Automation migrations. Process everything locally — your lead data never touches a server.

Mailchimp Audience Export Sample CSV (Dirty + Clean)

A realistic Mailchimp subscriber export (12,000 rows) covering data inconsistencies that break ESP migrations and cohort analytics. The Mailchimp quirk: OPTIN_TIME is frequently blank for API-imported contacts (bypassing native double opt-in). This causes pandas to_datetime() and SQL date-parsers to throw NaT or NULL errors. The 'dirty' version includes: 4,800 blank OPTIN_TIME values, mixed date formats (MM/DD/YYYY vs YYYY-MM-DD), and emails with trailing spaces that ruin engagement calculations. Ideal for ESP migration dry runs (to Klaviyo/ActiveCampaign) and deliverability audits. All processing happens locally — your subscriber list stays private.