Ingesting custom campaigns/events

Customer Data Platform (CDP) entities & concepts

CDP offers multiple entities to support loading marketing campaign information, as well as broader inbound and outbound events that happen between a customer and the brand. This is very useful to both track a customer’s activity with the brand, but also to do follow-up campaigns, and to report on campaign performances. Those entities are actually the ones CDP itself uses for all standard tracking/reporting/segmentation in Metrics, Actions, 360 Profiles, etc… This article gives you an overview of what those entities are, when and how to use them, and where those manifest in CDP applications.


CDP supports this type of data by using 4 main entities : campaign, dispatch, message, event. Those have a hierarchical relationship between them : a campaign can contain multiple dispatches (ie. campaign has a 1:n relationship with dispatch), a dispatch can contain multiple messages (ie. dispatch has a 1:n relationship with message), and messages can have multiple events tied to them or none, and events can be tied to no messages as well (ie. message has a 0:n relationship with event).

The concepts behind each of those entities are inspired by the structure of Email marketing campaigns, but are quite elastic and can be used for a lot more types of campaigns/events. More details :

  1. Campaign: This is the actual concept of a marketing campaign, e.g. “VIP customer reactivation”. It can have multiple executions with different dates (aka “Dispatch” explained below), and it can be executed on different channels (which is why “Dispatch” is the entity on which “Type and “Subtype” attributes are provided).
  2. Dispatch: A dispatch is the concept of a specific campaign executed on a specific date on a specific channel. For that reason, it has attributes like “Type”, “Subtype” and other details like “AttributionStartDate” (for Direct Mail campaigns) that are tied to a specific execution of the campaign.
  3. Message: A message is the concept of a “version” (as in “A/B testing variant” or “segment of customer”) of a dispatch. In a sense, it contains the details at the most granular level for a specific execution of a specific campaign, sent to a specific group of customers. It contains the most granular information about a marketing campaign (e.g. “Cost” for Direct Mail campaigns).
  4. Event : An event is a very generic concept. It can be anything that happens between the customer and the brand, regardless of who initiated the contact, e.g. : CDP uses Events to track visitor activity on the brand’s website, but it is also used to record email clicks and opens form the customer’s side. Events can be used by themselves to satisfy simple tracking use cases (details below), but they can also close the loop on marketing campaigns by recording every interaction a customer had with the campaign and what results it had (email clicks, products viewed on the web, products added to the cart, transactions…).

As is usually the case for all CDP entities, each level of the hierarchy also supports custom attributes. However, you need to be careful and think about how each attribute ties to each level : does it provide details about the overall campaign (and it should be added to the Campaign entity then), or does it provide information for one specific execution of that campaign and a specific group of recipients of the campaign (then it should be added to the Message entity instead) ? For any ingestion of marketing campaign and/or custom event data, it is imperative that you review your proposal with an CDP Product Manager, in order to make sure that your use cases are properly implemented and you get the value you were looking for.

Use case typology

There are typically 2 types of use cases for such data :

  1. Simple interaction tracking : the simplest one. This is to track simple inbound/outbound interactions with the customer and be able to surface those in CDP, like a log of all interactions the brand had with the customer. This manifests in two ways : as events in the 360 Profiles application under the Journey timeline (to support better clienteling, or to enable the marketing team to have the full picture), and as part of the filter Performed an event in a time period in Actions. This supports custom attributes as usual, but no hierarchy. Examples of this use case : ingestion of Eventbrite event data (e.g. “attended a yoga class”), surfacing of store visits for each customer, surfacing of support calls for each customer.
  2. Marketing campaigns tracking : the more complex one. This tracks not only the events that append (ie the use case above, with the same manifestation), but also considers the concept of marketing campaigns as a whole for reporting on performances & further filtering. On top of the manifestations described above, this also adds the following : hierarchical organization of different types of events/campaigns (which in turns makes it easier to navigate in Metrics), support for the filter Performed a campaign activity and its refinements (message name, etc…), campaign performance reporting (via query-based reports), more detailed information in the 360 Profiles application’s Journey timeline, etc… Examples of this use case : the standard ingestion of Google Analytics data, standard ingestion of Direct Mail data, the ingestion of email data from ESPs that are not supported by the standard connectors, the ingestion of marketing attribution provided by vendors other than Google Analytics (e.g. Adobe Analytics, IBM Coremetrics).

Each use case above requires a different set of data :

  1. Simple interaction tracking : you only have to ingest and map the data to the Event entity.
  2. Marketing campaigns tracking : you will need to ingest and map the data for the Campaign, Dispatch, Message, Event entities.