Response event feed layout overview

Overview

This document provides additional details related to the response event feed layout, including the use of the Feed Layout, how the data is reflected in the database, and how to use the data from RPI.

This section provides the following detailed information:

Response event feed layout definition

Response event feed layout sample

Response event extension feed layout definition

Response event extension feed layout sample

Feed layout intent

Communication, like an email send, can have a response, such as an open or a click, that is associated with the outbound campaign event record. These records are imported using the response event feed layout and are associated to the outbound campaign event ID (campaign event record).

The primary reasons for loading campaign history are to use in selection rules, to generate aggregates, and for reporting purposes. For example:

Use the data for a selection rule: to identify records that have previously opened or clicked on an email in general or for a specific campaign.
Use the data to generate an aggregate: to support calculating the last date an email address opened (last open date) or clicked (last click date) on an email message.
Use the data for reporting: to show various metrics related to a campaign response, such as…
- The number of opens for a given campaign
- How many of the emails were opened or clicked
- The number of unsubscribes generated from the campaign

Extension table

This feed has an associated extension table.

For general information about extension tables, refer to: extension tables.

Feed layout areas of consideration

Below are a couple areas of consideration when providing response event data to the CDP.

You need to have a client_campaign_event_id value to load the response data. This is because the response data links to a specific campaign event so that you know what outbound event generated the response. You need to consider how to correlate the response events to the campaign event when generating this feed for the data to load. This will vary depending on the source (vendor) of the campaign and response event data.

Currently, there are only a handful of disposition codes that can be provided as a part of the response event record. The disposition codes are listed in the table below (EVENT_DISPOSITION_LOOKUP table).

These codes are at the product-level and cannot be modified. A majority of common values are available; if there are additional dispositions that you need, discuss this with the onboarding team.

Disposition_Code	Disposition_Desc
`bounced`	Bounced email
`clicked`	Email was clicked on
`undeliverable`	Email or mail is undeliverable
`opened`	Email was opened
`processed`	Email or mail was processed
`reported_as_spam`	Email was reported as spam
`unsubscribed`	Email was unsubscribed
`sent`	Email was sent
`delivered`	Email was delivered
`forward`	Email was forwarded
`group_unsubscribes`	Group unsubscribes
`group_resubscribes`	Group resubscribes
`dropped`	Dropped email
`not_provided`	Not provided

Identity matching

Response event records are tied to campaign event records and do not have any PII associated to them, so there is no identity matching for this feed layout.

Use in RPI

This table will be used to define selection rules based on response event data for use within audiences. It can be used to select or segment data, for example if individual_id/individual_bu or email address opened or clicked a link for a specific campaign. It also could be used for suppressions based on click or open or if the email has unsubscribed or bounced, for example.

Use in reporting

This data will be used by the out-of-the-box PowerBI reports to show the stats related to a given campaign/campaign code among other stats.

Use in aggregates

The joins from the summary tables to response event table is through the Campaign_Event_Customer_Map to campaign event to the response event table.

The response data is used to calculate some of the aggregates in the email summary table.