What "export conversations to CSV" actually means (and why JSON is often better)
Before clicking any Export button, get clear on what you are actually trying to accomplish. The phrase "export conversations to CSV" covers at least four distinct workflows, and the right format is different for each one.
The first workflow is the CRM import. You want lead-capture data (name, email, phone, intent, source URL) flowing into Salesforce, HubSpot, or Pipedrive. CRMs prefer CSV because every CRM ships with a CSV import wizard that maps columns to fields. JSON support is uneven outside enterprise tiers.
The second workflow is the analytics or warehouse load. You want raw conversation logs in BigQuery, Snowflake, Redshift, or DuckDB so you can run cohort analysis, deflection rate calculations, or topic clustering. CSV is fine here too, but JSON or NDJSON usually preserves more of what you care about (the full message thread, the citations the bot returned, retrieval confidence scores, attached files).
The third workflow is the GDPR portability request. A European visitor has asked you for a copy of every conversation tied to their email address. Article 20 of the GDPR requires you to provide that data in a structured, commonly used, and machine-readable format. CSV qualifies; so does JSON and XML. The data subject picks the format; you provide what they ask for.
The fourth workflow is the vendor migration. You are leaving one chatbot platform and want the historical conversations imported into the new one. CSV is rarely the right choice here because the new vendor's import path almost always expects JSON with a documented schema. CSV migrations lose message-level metadata that the new vendor's analytics depend on.
The honest summary: CSV is the lowest common denominator. It works everywhere but it loses nesting. If your downstream tool accepts JSON, prefer JSON. If it does not, accept the CSV flattening and document what got lost.
CSV vs JSON: when to use each
CSV is a flat table. Every row is one record; every column is one field. The format is defined by RFC 4180. It compresses well, streams line by line (you can process a 50GB file with 10MB of memory), and every analytics tool on Earth has a fast CSV loader. For lead-capture data (name, email, phone, intent, timestamp) this format is ideal.
The problem comes when a single conversation contains multiple messages, each with its own metadata. A conversation row in CSV usually collapses the message thread into a single text column with newline separators, drops the citation links the bot returned, drops retrieval confidence scores, and drops any attached files. The shape of a CRM contact survives the flattening; the shape of a multi-turn conversation does not.
JSON keeps the nesting. A single conversation record can contain an array of messages, each message can contain an array of citations, each citation can have a URL, a confidence score, and a snippet. Nothing is lost. The cost is that JSON is heavier to parse and not every downstream tool accepts it cleanly.
The practical rule: use CSV for lead-capture data, CRM imports, and GDPR portability requests where the data subject asked for CSV specifically. Use JSON for analytics warehouse loads, vendor migrations, and any case where you need to preserve message-level structure. Most chatbot platforms in 2026 will export both; pick the right one for the job and document what each contains.
GDPR Article 20 and your right to portability
Article 20 of the GDPR gives EU data subjects the right to receive personal data concerning them in a structured, commonly used, and machine-readable format. The European Data Protection Board has consistently interpreted "machine-readable" to mean formats like JSON, XML, or CSV. Plain PDFs do not satisfy the requirement on their own because they are not structured enough to re-import elsewhere.
The clock matters. Under Article 12, you must respond to a portability request without undue delay and within one month of receipt. The window can be extended by another two months for complex requests, but you must notify the data subject of the extension within the original month. Ignoring the request is a regulatory violation that the CNIL flagged as an enforcement priority for the 2024 to 2026 cycle.
The scope is narrower than people expect. Article 20 covers data the subject provided to you, which includes everything they typed into the chatbot and any lead-capture form they completed. It does not automatically cover derived data (sentiment scores you computed, topic clusters you assigned, agent notes about the subject). The Working Party 29 guidance suggests including provided data plus directly observed data, but excluding inferred data.
For chatbot operators specifically, that means a portability export should include the message thread, lead-capture form fields, attached files, and metadata about when each conversation occurred. It does not need to include your retrieval confidence scores, internal routing tags, or any analyst notes added after the conversation.
If your vendor cannot produce a structured export within the one-month window, you (the data controller) are the one in breach, not the vendor. Verify the export path on every chatbot platform you sign up for before you start collecting EU traffic.
Vendor-by-vendor walkthrough
The remainder of this guide walks through the concrete export path on the five chatbot platforms that show up most often in 2026 audits: ChatRaj, Chatbase, Intercom, Tidio, and Drift (now sunset). The vocabulary varies, but the workflow is always the same: filter by date range, choose CSV or JSON, download or wait for an email link, then move the file to wherever it needs to go.
Path A: ChatRaj
ChatRaj exposes export from the Conversations page in the dashboard. Open Conversations, set the date range filter at the top of the table, then click the Export CSV button in the upper right. The download includes the conversation transcript, the lead-capture data captured during the chat (name, email, phone, any custom fields), the citation URLs the bot returned, the CSAT score if one was collected at the end of the chat, and a session ID you can use to join the export against other ChatRaj data.
For larger workspaces, the same button also offers JSON export, which preserves message-level structure and the full citation array per message. The JSON shape is documented in the ChatRaj developer docs and is the recommended format for any analytics pipeline.
If you need a scheduled export (for example, daily lead drops into a CRM), ChatRaj's Zapier and Make integrations push new conversations as they close, which is usually preferable to scheduled CSV exports for any pipeline that needs to be close to real time.
Path B: Chatbase
Chatbase exposes export from the Activity tab within each agent's dashboard. Open the agent, click Activity, then Chats. Click the Export button in the upper right and choose CSV, JSON, or PDF. CSV gives you a flat table of conversations with one row per conversation and the message thread collapsed into a column. JSON preserves message-level structure.
Lead-capture data flows through Chatbase's Leads section (Dashboard, then Leads), which has its own dedicated CSV export with one row per captured lead. This is the right export path if you only need the CRM-bound contact data and not the full transcript.
Chatbase does not currently expose scheduled exports through the UI; if you need a recurring drop, use the Chatbase API to pull conversations on a schedule and write the result wherever you want.
Path C: Intercom
Intercom's export story is more complicated than it looks. The Reports section of your workspace has a Data Export tab. Click that, choose the Conversations tab or the Tickets tab, set your timeframe, and download as CSV. The catch is that this CSV contains reporting metadata only (conversation IDs, timestamps, attributes, custom metrics). It does not include the full message content.
For full conversation content, you have three options. The first is the Inbox bulk export: open Inbox, select up to roughly 200 to 300 conversations using checkboxes, and choose Export as PDF or text. This includes message content but is capped by selection size. The second is the Conversations API, which is the supported path for bulk content export at scale. The third is third-party tools (IntercomExport.com is the best known) that wrap the API and produce CSV or JSON output.
Workspace-level data export is also limited to 10,000 rows for browser downloads; anything larger is emailed to you when ready, which can take up to an hour. For GDPR portability requests against Intercom, plan for the API path; the UI exports alone will not satisfy a typical Article 20 request that asks for full message content.
Path D: Tidio
Tidio's export path is per-conversation by default. Open any individual conversation, look at the right-hand panel showing visitor details, click the three-dot menu, and choose Export transcript to CSV. This downloads exactly one transcript per click. There is no built-in bulk transcript export from the Tidio UI in 2026; the per-conversation flow is the official documented path.
For aggregated data, the Analytics section has a separate export that emails you a data file covering the selected timeframe and channels. This is the route to use for monthly metrics, deflection rates, and conversation volume reporting. Contact-list data (the Contacts section) has its own CSV export with one row per contact, which is the right path for CRM-bound lead data.
If you need bulk transcript export from Tidio, the practical workaround is the API: pull conversations by date range, then transform to CSV with a small script. Tidio has flagged bulk transcript export as a roadmap item across several years of changelogs; verify whether it shipped before relying on the per-conversation flow at scale.
Path E: Drift archive (post-sunset)
Drift was sunset by Salesloft following the August 2025 security incident, with formal sunset announced in March 2026. If you still have data sitting in a Drift workspace, you have a closing window in which to extract it. Once the workspace is decommissioned, the export paths below will stop working.
From the Visitors section, export contacts and segments as CSV. This is the lead and contact data and is the highest-priority export for most teams. From the Chats section, export conversation metadata (conversation IDs, timestamps, owner agents, tags) as CSV. This metadata does not include full transcripts.
For full conversation transcripts, you need the Drift API. The deprecation announcement covered the workspace UI but the API has remained available through the wind-down period for export purposes. Any team with significant Drift history should script a pull against the Conversations endpoint, write the result as JSON or NDJSON to local storage, and then transform to CSV if a downstream tool requires it.
Playbooks and routing rules cannot be exported in any format. Take screenshots of the configurations you might want to recreate in your new chatbot. Anything Drift had synced to your CRM (Salesforce, HubSpot) is already in your CRM and does not need to be re-exported.
What to do once you have the CSV
The export is the easy half. The hard half is what you do with the file.
For most teams, the CSV becomes a Google Sheet or an Excel workbook first, where someone scans it, filters it, and decides what is real signal. This is fine for one-off exports but does not scale.
For recurring exports, the file should land in cloud storage (S3, GCS, Azure Blob) and feed an automated pipeline. The most common pattern is a daily export landing in a staging bucket, an ingestion job loading the staging bucket into a warehouse table, and downstream dashboards reading the warehouse. If the export is large or frequent, JSON or NDJSON is usually a better source format than CSV because it preserves the structure the warehouse can shred into typed columns.
For GDPR portability requests, the CSV is the deliverable. Send it to the data subject through whatever channel they requested (almost always email, sometimes a secure portal) and log the request and the response. Most organizations keep a portability-request log per the same retention policy as their consent log.
CRM imports, Snowflake/BigQuery, redaction for analytics
Three downstream destinations show up most often, each with its own quirks.
CRM imports (Salesforce, HubSpot). Both Salesforce and HubSpot have native CSV import wizards. Salesforce's Data Import Wizard handles up to 50,000 records per job; for more than that, use Data Loader. HubSpot's import tool handles up to one million rows per file on the Enterprise tier. The hardest part is field mapping: your CSV column names will not match your CRM field names, so plan time for the mapping step. Always import to a sandbox or test list first, then to production.
Snowflake and BigQuery. Both have COPY-style loaders that accept CSV from cloud storage. Snowflake's COPY INTO and BigQuery's bq load are the standard paths. Both prefer files compressed as gzip and split into chunks of a few hundred megabytes. For raw conversation data, consider loading JSON or NDJSON instead of CSV and using the warehouse's JSON shred functions (Snowflake's PARSE_JSON, BigQuery's JSON_QUERY) to keep message-level structure queryable.
Redaction for analytics. Before any conversation data lands in an analytics warehouse, redact personally identifying information. The standard rule is to drop email addresses, phone numbers, full names, and any free-text the visitor typed unless the analytics use case strictly requires it. Email patterns (regex), phone patterns (regex), and full names (named-entity recognition) can all be stripped in the pipeline before the warehouse load. ChatRaj and several other vendors expose a redaction option directly in the export step; turn it on for analytics exports and turn it off for CRM and GDPR exports, which need the raw data.
The end state for most operators is two parallel pipelines. A lead-capture pipeline pushes CSV or webhook events to the CRM with full contact data. An analytics pipeline pushes JSON or NDJSON to the warehouse with PII redacted. The export button you click in the chatbot UI is the start of both pipelines, not the end of either.