BeginnerAction GuideUpdated regularly5 min read

Format Contact CSV for Klaviyo Profile Import

Klaviyo's profile import parser is case-sensitive and reserves all properties prefixed with '$' as built-in profile attributes. Columns named 'Email Address', 'email', or 'E-mail' will not auto-map to the $email reserved property — Klaviyo requires the exact column header '$email' to recognize and populate the primary identifier. Similarly, $first_name and $last_name must use the dollar-sign prefix; without it, Klaviyo creates custom properties instead of populating the profile fields that personalization tags like {% person 'first_name' %} reference, causing emails to render with blank greetings. For SMS marketing imports, Klaviyo enforces strict E.164 international phone number formatting — the number must include a leading '+', country code, and subscriber number with no spaces, dashes, or parentheses. A value like '(415) 555-0123' triggers 'Invalid Phone Format' and the row is rejected. This workflow renames your columns to match Klaviyo's reserved property schema exactly, strips and reformats phone numbers to E.164 (e.g., +14155550123), and validates email syntax before upload — all processed locally in your browser so subscriber PII never leaves your machine.

Why this matters?

A DTC skincare brand migrating 340,000 subscribers from a legacy CRM uploaded their CSV to Klaviyo with columns named 'Email', 'First Name', 'Phone'. Klaviyo's import wizard flagged 'Missing Required Columns' because it could not find $email, halting the entire migration. After manually renaming columns in Excel and re-uploading, 28,400 phone numbers were rejected with 'Invalid Phone Format' because they contained parentheses and dashes from the legacy system's display formatting. The 3-day migration delay pushed their Black Friday campaign launch past the optimal send window, and the first campaign — sent without properly mapped $first_name fields — rendered 'Hi ,' in 340,000 emails, resulting in a 0.34% click-through rate versus their historical 2.1% average, costing an estimated $89,000 in lost revenue.

The 3-Step Solution

Follow this streamlined workflow to transform your raw data export into a clean, analysis-ready dataset. Each step leverages our browser-based tools to ensure your sensitive data never leaves your device.

By following these three steps, you eliminate manual data wrangling, reduce human error, and maintain full GDPR compliance throughout the process.

Ready to clean your data?

100% local processing. Zero uploads. Blazing fast.

Recommended Tools

Related Workflows

How to Anonymize Customer Data Before Sharing with ChatGPT or Developers

A step-by-step SOP for stripping PII (names, emails, phone numbers, physical addresses) from production datasets while preserving the statistical shape of the data. Includes guidance on which columns to mask, which to drop, and how to verify the output is truly de-identified.

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

Apollo.io exports contain duplicate contacts, generic role-based emails (info@, support@), invalid domains, and inconsistent company name formatting. This workflow shows how to clean all of these issues in one pass to keep your sender reputation above 95% deliverability.

How to Convert Stripe Payout Reports into QuickBooks Import Format

Stripe's payout CSV has 15+ columns that don't map to QuickBooks' expected schema. This guide shows how to separate gross revenue from processing fees, reformat dates to MM/DD/YYYY, and produce a clean CSV that QuickBooks accepts without manual reconciliation.

Clean WooCommerce Exports for Financial System Import

WooCommerce's native CSV export is notoriously hostile to accounting workflows. Product descriptions in the post_content column arrive wrapped in raw HTML tags and shortcodes like [woocommerce_reviews]. Custom meta fields (e.g., _regular_price, _sku) frequently shift columns when plugins inject hidden postmeta, and the post_date column alternates between Y-m-d H:i:s and Unix timestamps depending on your WordPress version. This SOP strips HTML remnants via regex, realigns displaced meta columns, and standardizes all date fields to ISO 8601 so QuickBooks and Xero accept the import without throwing schema validation errors.

Sample Datasets

Amazon Settlement Report Sample Data

A representative Amazon Seller Central settlement report with 150 transactions covering FBA fees, commissions, reimbursements, and refunds across multiple marketplaces. Use this to test the Amazon Settlement Cleaner and see how 40+ raw columns collapse into a clean profit summary.

Facebook Ads Campaign Report Sample

A Facebook Ads Manager export with 100 rows spanning 3 campaigns, 12 ad sets, and key metrics (impressions, clicks, spend, conversions, ROAS). Includes intentionally messy rows with zero-spend days and broken attribution windows for testing the Ads ROAS Pivot tool.

Stripe Payout Export Sample

A Stripe payout CSV with 80 transactions including charges, refunds, disputes, and fee breakdowns across USD and EUR. Timestamps are in raw UTC format. Use this to test the Stripe Payout Formatter and validate QuickBooks-compatible output.

Zendesk Tickets Export Sample Dataset

This dataset contains 5,000 synthetic Zendesk support tickets exported in standard CSV format, featuring exact production columns: Ticket ID, Subject, Description, Status, Priority, Requester, Assignee, and Created. It simulates a realistic helpdesk environment with a mix of open, pending, and resolved tickets across multiple support queues. The critical Zendesk export quirk is that Description and Comments fields contain embedded CRLF (\r\n) line breaks from customer emails and multi-paragraph replies. Naive CSV parsers that don't respect RFC 4180 quoting rules will split a single ticket row into multiple invalid records at every newline, corrupting the dataset structure. The intentionally injected dirty data inventory includes: embedded CRLF newlines in 1,200 Description cells, 340 rows with Assignee set to null (unassigned tickets), and UTF-8 characters (é, ñ, ü) in Requester names without a BOM header to test encoding fallbacks. After cleaning and proper quote-handling, this yields exactly 5,000 valid ticket records. Ideal for: ETL pipeline testing, CSV parser validation, DuckDB text-loading demos, and NLP preprocessing on support logs. Load this file into the format-cleaner tool to strip CRLF artifacts and normalize the text fields.