Engage Studio is a powerful feature designed to help marketers create and manage effective email campaigns within the Treasure Data CDP. A key aspect of successful email marketing is the ability to track performance. Engage Studio provides Email Delivery Performance Insights by automatically collecting detailed email metrics.
These valuable email metrics are stored automatically for each email domain you use in your dedicated Treasure Data table. This table allows you to analyze the outcomes of your email sends at a granular level.

Your email performance data is stored in your Treasure account in the following location:

• Database: delivery_email_<your email domain>

• Table: events

Schema of the Email Performance (events) Table

The events table contains various columns that capture detailed information about each event that occurs during your email campaigns. The schema of this table includes the following fields:

• time (int): Equivalent to delivery_timestamp, representing the time.

• email_sender_id (string): The ID of the sender.

• email_domain_id (string): The ID of the email domain.

• email_domain (string): The email domain used for sending.

• message_id (string): A unique ID assigned to the message by Amazon SES upon a successful send request. This is the ID Amazon SES returned when the message was sent. Note that Amazon SES also includes this ID in the commonHeaders of the mail object.

• email_template_id (string): The Email Template ID used for the message. You can find this ID in the URL path when editing an email template in Engage Studio.

• from (string): The FROM email address.

• to (string): The TO email address of the recipient. This is one of the email addresses listed as recipients of the original mail.

• to_plain_address (string): The recipient's email address in a simple format, even if a display name was originally included.

• subject (string): The subject line of the email. This can be found in the commonHeaders of the mail object.

• timestamp (string): The date and time at which the original message was sent (in ISO8601 format).

• event_type (string): A crucial field indicating the type of event that occurred. This field describes different outcomes for each email sent.

• delivery_reporting_mta (string): The Mail Transfer Agent (MTA) address for deliveries. In Amazon SES, this is the hostname of the SES mail server that sent the mail.

• delivery_smtp_response (string): The MTA log for deliveries. This is the SMTP response message from the remote ISP that accepted the email from Amazon SES.

• delivery_processing_time_millis (long): Time taken for delivery processing in milliseconds. This is the time between Amazon SES accepting the request and passing the message to the recipient's server.

• delivery_timestamp (string): The time when the email was delivered.

• open_user_agent (string): The Email Client User Agent used when the email was opened.

• open_timestamp (string): The time when the email was opened.

• open_ip_address (string): The IP address where the receiver opened the email.

• click_user_agent (string): The Email Client User Agent used when the email was clicked.

• click_timestamp (string): The time when the email was clicked.

• click_ip_address (string): The IP address where the receiver clicked the email.

• click_link (string): The full URL of the link that was clicked by the recipient. This field provides valuable analytics data to understand which content drives engagement.

• bounce_reporting_mta (string): The IP address of the MTA that attempted delivery before a bounce occurred.

• bounce_feedback_id (string): A unique ID associated with the bounce.

• bounce_timestamp (string): Time when it is marked as Bounce.

• bounce_subtype (string): The subtype of the bounce.

• bounce_type (string): The type of bounce (Undetermined, Permanent, or Transient).

• bounce_recipient_status (string): The value of the Status field from the DSN. This is the per-recipient transport-independent status code that indicates the delivery status of the message.

• bounce_recipient_action (string): The value of the Action field from the DSN. This indicates the action performed by the Reporting-MTA as a result of its attempt to deliver the message to this recipient.

• bounce_recipient_address (string): A list that contains information about the recipients of the original mail that bounced

• bounce_recipient_diagnostic_code (string): The status code issued by the reporting MTA. This is the value of the Diagnostic-Code field from the DSN. This field may be absent in the DSN (and therefore also absent in the JSON).

• delayed_timestamp (string): The date and time when the delivery delay occurred, in ISO8601 format.

• delayed_type (string): The type of delay (e.g., MailboxFull, MessageTooLarge, TransientCommunicationFailure).

• delayed_recipient_address (string): The email address that resulted in the delivery of the message being delayed.

• delayed_recipient_status (string): The SMTP status code associated with the delivery delay. This is the per-recipient transport-independent status code.

• delayed_recipient_diagnostic_code (string): The diagnostic code provided by the receiving MTA. This provides additional information about the delay.

• delayed_expiration_time (string): The date and time when Amazon SES will stop trying to deliver the message, shown in ISO8601 format.

• complaint_timestamp (string): The date and time, in ISO8601 format (YYYY-MM-DDThh:mm:ss.sZ), when the ISP sent the complaint notification.

• complaint_feedback_id (string): A unique ID for the complaint.

• complaint_user_agent (string): The value of the User-Agent field from the feedback report. This indicates the name and version of the system that generated the report.

• complaint_feedback_type (string): The value of the Feedback-Type field from the feedback report received from the ISP. This contains the type of feedback.

• complaint_arrival_date (string): The value of the Arrival-Date or Received-Date field from the feedback report in ISO8601 format (YYYY-MM-DDThh:mm:ss.sZ). This field may be absent in the report (and therefore also absent in the JSON).

• reject_reason (string): The reason the email was rejected. The only possible value is Bad content, which means that Amazon SES detected that the email contained a virus. When a message is rejected, Amazon SES stops processing it, and doesn't attempt to deliver it to the recipient's mail server.

• failure_error_message (string): A message that provides more information about the rendering failure.

• custom_event_id (string): Any Campaign ID that is used for performance calculation. Using this identifier helps track email campaigns properly, for example, within a Customer Journey Orchestration (CJO) scenario. This ID is set when configuring an email activation.

• test_mode (boolean): True indicates that the email is sent by SendTest feature

• campaign_id (string): The campaign ID when sending an email using the campaign function.

• campaign_name (string): The campaign name when sending an email using the campaign function.

Understanding Email Event Types

The event_type column is essential for monitoring your sending activity and understanding campaign performance. It categorizes the outcome of each email sent. Here are the possible values you will find in this column and what they signify, along with related information captured in the table:

• Send : The request to send the email was successful, and Amazon SES will attempt delivery. Even if delivery is suppressed by a suppression, it is still counted as a send.

• Delivery : Amazon SES successfully delivered the email to the recipient's mail server. The delivery object includes the timestamp of delivery (delivery_timestamp), processingTimeMillis (delivery_processing_time_millis), recipients, smtpResponse (delivery_smtp_response), reportingMTA (delivery_reporting_mta), and remoteMtaIp.

• Bounce : Indicates a permanent or transient bounce where the recipient's mail server rejected the email. Permanent bounces mean you should remove the recipient from your list as future sends are unlikely to succeed and can negatively impact your sender reputation. Transient bounces might be successfully delivered later if the temporary issue is resolved.

• Complaint : The email was delivered, but the recipient marked it as spam. The complaint object includes complainedRecipients, timestamp, feedbackId, complaintSubType, and optionally userAgent, complaintFeedbackType, and arrivalDate from a feedback report. Note that most ISPs redact the specific email address that complained, so the complainedRecipients list includes recipients on the domain that issued the complaint. complaintFeedbackType can indicate the reason for the complaint (e.g., abuse, fraud, virus).

• DeliveryDelay : The email delivery was temporarily delayed due to an issue, such as a full inbox or a transient server issue. The delivery delay object includes the delayType (e.g., MailboxFull, MessageTooLarge), delayedRecipients, expirationTime (when SES stops trying to deliver), reportingMTA, and timestamp.

• Open : The recipient opened the message in their email client. This relies on open pixel tracking for HTML emails. The open object includes the recipient's ipAddress (open_ip_address), timestamp (open_timestamp), and userAgent (open_user_agent). Note that open tracking only works with HTML emails; text-only email clients do not provide this metric.

• Click : The recipient clicked one or more links in the email. This relies on click tracking, which supports HTTPS + custom domain. The click object includes the recipient's ipAddress (click_ip_address), timestamp (click_timestamp), userAgent (click_user_agent), and link (click_link) containing the full URL that was clicked.

The custom_event_id column is specifically designed to help you track the performance of individual email campaigns or journeys. When you configure an email activation, you can input a unique identifier for your campaign into the Custom Event ID parameter. This ID is then logged in the events table, allowing you to easily filter and calculate performance metrics (like sends, deliveries, opens, clicks, bounces, etc.) specifically for that campaign. This is particularly useful when running campaigns via Customer Journey Orchestration (CJO).

While custom_event_id provides basic campaign tracking, you can capture additional metadata about your activations and journeys using the Output Column Mapping feature.

Output Column Mapping allows you to add journey and activation metadata as additional columns in your email delivery events table. This feature is essential for ROI Dashboard reporting and advanced campaign analytics.

You can add the following metadata columns to your delivery events:

1. Go to Audience Studio and select your segment
2. Navigate to Activation
3. Create or edit a Treasure Engage activation

1. Scroll to the Output Mapping section
2. For each metadata field you want to include, click Add string
3. Configure the mapping:
   • For activation_id: Use String Builder to select the automatically generated value
   • For activation_name: Enter a custom value manually
   • For journey_id: Use String Builder to select the journey ID (automatically available in Journey Orchestration activations), or enter a custom value manually for other activation types
   • For journey_stage_id: Enter a custom value manually (String Builder is not available for this field)
4. Enter the output column name (use the same name as the source for consistency)
5. Click Save

After the activation runs, the metadata columns will be available in your delivery_email_<your_domain>.events table alongside the standard delivery event columns.

The activation_id, journey_id, and journey_stage_id columns are stored as base32-encoded strings. To query these columns in a human-readable format, use the from_base32() and from_utf8() functions to decode them:

SELECT
  from_utf8(from_base32(activation_id)) AS activation_id_decoded,
  from_utf8(from_base32(journey_id)) AS journey_id_decoded,
  from_utf8(from_base32(journey_stage_id)) AS journey_stage_id_decoded,
  activation_name,
  email_template_id,
  event_type,
  to
FROM
  delivery_email_<your_domain>.events
WHERE
  TD_INTERVAL(time, '-1d', 'JST')

The activation_name column is stored in plain text and does not require decoding.

These metadata columns enable the Reporting Agent to generate ROI reports by linking email delivery events with journey performance and revenue data. For more information, see Report for Engage.

Some organizations operate under strict internal security policies that prohibit storing raw personally identifiable information (PII), such as email addresses, in analytics or operational tables. At the same time, these organizations still need to correlate delivery, bounce, error, and unsubscribe events back to customer records.

To support these use cases, Engage Studio provides a reserved field-name prefix — td_log_ — that you can use in activation output mapping. Any output mapping whose destination column name starts with td_log_ is:

• Automatically added as a column in the email event log tables.
• Populated per event row with the value mapped from the activation context (for example, a profile attribute such as member_id or crm_id).

This allows you to log non-PII identifiers of your choice (such as internal member IDs, CRM IDs, or hashed identifiers) alongside each event, without exposing raw email addresses in analytics tables.

When an activation defines one or more td_log_* output mappings, the configured columns appear and are populated across all three Engage Studio event tables, enabling end-to-end correlation:

• delivery_email_<your_domain>.events — send, delivery, bounce, complaint, delivery delay, open, click
• delivery_email_<your_domain>.error_events — runtime and rendering errors
• delivery_email_<your_domain>.subscription_events — unsubscribe events

The same td_log_* column name carries the same value for a given activation across these tables, so you can join across delivery, error, and subscription events on non-PII identifiers.

1. Go to Audience Studio and select your segment.
2. Navigate to Activation.
3. Create or edit a Treasure Engage activation.

1. Scroll to the Output Mapping section.
2. For the source, select the profile attribute that holds the non-PII identifier (for example, member_id).
3. For the destination column name, use a name that starts with td_log_ (for example, td_log_member_id).
4. Click Save.

After the activation runs, the configured td_log_* columns appear in the events, error_events, and subscription_events tables and are populated with the mapped identifier value for each event row.

Suppose you map member_id → td_log_member_id and crm_id → td_log_crm_id in your activation output mapping. You can then analyze deliveries, errors, and unsubscribes without referencing the raw to email address:

SELECT
  e.event_type,
  e.td_log_member_id,
  e.td_log_crm_id,
  COUNT(*) AS event_count
FROM
  delivery_email_<your_domain>.events e
WHERE
  TD_INTERVAL(e.time, '-7d', 'JST')
GROUP BY
  e.event_type, e.td_log_member_id, e.td_log_crm_id

• Maximum of 5 td_log_* fields per activation. This keeps the event schema stable and avoids excessive column growth. Any fields beyond the first five are silently dropped.
• Destination column names must use ASCII characters only (letters, digits, and underscores). Non-ASCII characters are ignored to avoid unexpected errors and incorrect column mapping.
• Column name length is limited to 256 characters, including the td_log_ prefix.
• Identifiers are logged only — never rendered in email content. The values mapped to td_log_* are used solely for event logging and analytics correlation; they are not substituted into the email message body or subject line.
• No backfill. Only events generated after you configure td_log_* mappings will include the new columns. Existing events are not retroactively updated.
• Backward compatible. If no td_log_* fields are configured, the schema and behavior of all event tables are unchanged.

For enterprise customers with strict PII-at-rest policies (for example, organizations that prohibit storing raw email addresses or other recipient PII in any analytics table), Treasure AI can enable an account-level option that suppresses PII columns across all three Engage Studio event tables. When this option is enabled, the following columns are written as NULL for every new event in the account:

• In events and error_events:
  • to
  • to_plain_address
  • subject
• In events only:
  • bounce_recipient_address
  • delayed_recipient_address
  • open_ip_address
  • open_user_agent
  • click_ip_address
  • click_user_agent
  • click_link
• In subscription_events only:
  • profile_identifier_value

With PII columns suppressed, use td_log_* non-PII identifiers (see above) to correlate events back to customer records.