Treasure Data CDP Integration

Treasure AI Voice can push your organization's recordings, transcripts, AI-generated summaries, and device inventory directly into your own Treasure Data CDP database. Once the data lands in your CDP, you can join it with the rest of your customer data, build segments, drive journeys, and run analytics over what was actually said in your meetings and calls.

The integration supports both manual and recurring exports. An export runs in the background and streams data to the tables you specify in your Treasure Data CDP database. The destination settings and a dedicated write-only API key can be saved for later manual or unattended scheduled runs. The full API key is never returned to the console, included in an export run payload, or written to the audit log.

Each export writes to four logical tables in your CDP database. The recordings, transcript_segments, and summaries tables reflect the recordings in scope for the run. The devices table is not filtered by recording date; an initial export may include the full device inventory, while an incremental export includes devices changed since the export checkpoint.

Recordings are included regardless of processing status. The status column reflects each recording's state, and transcription_text, summary_text, and the related fields are empty for recordings that have not finished transcribing or summarizing yet.

Exports can be incremental. The export uses the source record's updated_at value to identify records changed since the previous checkpoint. A date range limits recording candidates by recorded_at; it does not change the purpose of the incremental checkpoint.

Every row carries a stable unique_id derived from the source record. The same source record always maps to the same unique_id, but Treasure Data CDP appends incoming events rather than replacing existing rows. Use updated_at to identify the latest copy when repeated exports produce more than one row with the same unique_id.

Every row also carries an updated_at column containing the source record's last-updated time as Unix epoch seconds. If a source update time is unavailable for an older record, updated_at falls back to a table-specific timestamp (see each table's updated_at description below).

Every row also carries a time column (Unix epoch seconds) that Treasure Data CDP uses for native time partitioning, so analysts can efficiently filter by time. The time value is anchored to the most meaningful timestamp for each table — recorded_at for recordings and summaries, the recording timestamp plus the utterance offset for segments, and the last heartbeat (falling back to provisioning time) for devices. Use time for partition filtering and updated_at for freshness and deduplication.

The schema is owned by Treasure AI Voice. Columns are appended to your CDP tables on first write — you do not need to pre-declare them.

Before configuring an export, make sure you have:

• An Enterprise Administrator account on Treasure AI Voice.
• The integration enabled for your organization (see below).
• A Treasure Data CDP API key belonging to a user who has Import Only or General Access permission on the destination database.
• A destination database in the Japan (AP01) region of Treasure Data CDP. The export creates the destination tables on first write.

The integration is off by default. To turn it on:

1. Sign in to the AI Voice Console as an Enterprise Administrator.
2. Open the Export page.
3. Select the Treasure Data CDP destination.
4. Click Enable export.

If you do not see the option to enable it, contact your Treasure AI representative.

Save the destination and credential before running a manual or scheduled export:

1. Open the Settings tab on the Export page.
2. Enter the destination Database.
3. Enter a dedicated Write-only API Key.
4. Optionally expand Advanced and change the Recordings table and Transcript segments table names.
5. Click Save settings.

The database and table settings are restored when you return to the Export page. To replace the credential, click Replace and save a new key. To remove it, click Remove. Removing the saved key disables an enabled recurring schedule.

1. Confirm that the destination database and saved API key are shown on the Settings tab.
2. Optionally expand Advanced and set a From and To date range.
3. Optionally select Re-export previously exported recordings.
4. Click Run export now.
5. Open the History tab to monitor the run.

The date range filters recordings by their recorded date. The To date is inclusive through the end of that day. The range applies to recordings, transcript segments, and summaries; it does not filter devices by recording date.

The request creates a background run and returns before the export finishes. You can leave the page while the export continues.

Recurring exports use the saved destination, table settings, and write-only API key. The available intervals are:

• Every hour
• Every 6 hours
• Every 12 hours
• Every 24 hours
• Weekly

The shortest interval is one hour. Custom cron expressions are not supported. The first scheduled run can either start from the time the schedule is enabled or backfill the organization's existing exportable data before continuing incrementally.

A recurring export cannot start while another export is running for the same organization.

The History tab lists manual and scheduled runs. Each run has one of the following statuses:

The History list shows the start time, trigger type, status, accepted and rejected row counts, duration, and run ID. Run details include the destination database, table-level counts, failure information, and recordings rejected because their event was too large.

Invalid credentials and insufficient Treasure Data CDP database permissions can appear as a failed run because the export runs asynchronously. Grant the key's user Import Only or General Access permission on the destination database, then run the export again.

A recording whose serialized event exceeds the 1 MB per-event limit is listed in the run details. The recording row is rejected, but its transcript segments and summary may still be exported. The recording is retried by later runs for a limited number of attempts.

Every export run is recorded in the Audit Logs under the TD_CDP_EXPORT event type. Run status and row counts are available in History and the run details, not in Audit Logs. Settings and credential changes are also audited. The API key itself is never written to the audit log.

Scheduled and undated exports use an incremental checkpoint. Recordings and devices updated at or after that checkpoint are included in the next run. A date range narrows recording candidates by recorded_at while preserving the incremental check.

Selecting Re-export previously exported recordings removes the checkpoint for that run and sends all records in the selected scope again.

Treasure Data CDP appends incoming events instead of replacing existing rows. Repeated exports can therefore contain multiple rows with the same unique_id. Deduplicate downstream by unique_id, keeping the row with the greatest updated_at.

For older records without a maintained source update time, updated_at falls back to a table-specific timestamp (see each table's updated_at description below).

For operational procedures and administrator permissions, see the Administrator Guide.

For the exported table schemas, data relationships, and querying examples, see Querying the exported data.

Because each table shares recording_id (recordings.id), you can reconstruct any view of your meeting data in your CDP. For example:

• Join summaries to recordings on recording_id to get summaries alongside the full recording metadata.
• Join transcript_segments to recordings on recording_id, ordered by segment_index, to reconstruct or analyze the conversation utterance by utterance.
• Pivot transcript_segments on speaker_label (or speaker_id) to analyze talk time per participant.
• Join recordings to devices on device_serial_number = serial_number to attribute conversations to devices and assigned users.

WITH ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY unique_id
      ORDER BY updated_at DESC
    ) AS rn
  FROM your_table
)
SELECT *
FROM ranked
WHERE rn = 1

For older records without a maintained source update time, updated_at falls back to a table-specific timestamp (see each table's updated_at description below).

For the exported table schemas and query examples, see Schema reference.