Information for: DEVELOPERS   PARTNERS   SUPPORT

Event Feed

Important

This is an advanced functionality that typically applies only to specific tenants. Do not implement anything related to this if you have doubts. In any case, prior to implementing or developing any feed/API solution based on this article, please review your use case with your Customer Data Platform (CDP) team to ensure that your full use case can be supported, and that the platform is properly configured before you start pushing this data.

Note that this article lists the main attributes that you will want to send to CDP, but there are other attributes (not documented here) that could be leveraged depending on your use cases.

Feed description

Individual, atomic events linked to each customer. Examples include email events (emailSend, emailOpen, emailClick, etc.), web events (productBrowsed, checkout, login, etc.), direct mail events (directmailSend) or custom events that are specific to your brand (storeVisit, yogaEvent, warrantySignup, etc.).

Feed structure

Field Name Required ? Data type Referential integrity Description
Cookie Required/Optional (depending on the use case) String   Only used for web/app-related events, this is the visitor’s cookie ID, ie a unique identifier of the person triggering this event. For web/ app-related events : use an actual cookieID/mobiledeviceID of the visitor, prefixed with some indication of source system so that it does not collide with the other cookieIDs maintained by CDP (e.g. “ssid_web1_[insertCookieIDHere]”). For other events (email, SMS, etc…) : do not populate this column.
Type Required String  

The type of event. Please use standard event types as much as possible. Standard email events values for this attribute: emailSend, emailOpen, emailClick, emailBounce, emailSubscribe, emailUnsubscribe. Standard web events values for this attribute: productBrowsed, categoryBrowsed, onsiteSearch, cartUpdated, checkout. Custom event types are supported, but: you need to consult your CDP team prior to implementing them to make sure they can be loaded (ie the right configuration is in place) and your precise use case can be supported.

The value should always respect the camelCasing convention. Examples of custom events types created so far for certain customers (not available to all, please check with your CDP team) include: smsSubscribe, smsOpen, smsClick, smsUnsubscribe, smsSend, smsDeliver…

Subtype Optional String   For Email Bounce events, this attribute should store the type of Bounce event (hard/soft).
EventTimeStamp Required Datetime   The date and time at which the event occured. Be as precise as possible. This column is stored as an epoch timestamp in milliseconds in the backend to maintain the best precision.
SourceCustomerNumber Required (see description) String Customer: SourceCustomerNumber The unique identifier of the customer/visitor that triggered this event. Note that you need to provide one of the following 2 identifiers for CDP to load the events in the platform : Email, SourceCustomerNumber. Those should additionally tie to actual records in the Customer feed(s) you send to CDP, otherwise the events will not be loaded.
Email Required (see description) String Customer: Email The email address of the customer/visitor that triggered this event. Note that you need to provide one of the following 2 identifiers for CDP to load the events in the platform : Email, SourceCustomerNumber. Those should additionally tie to actual records in the Customer feed(s) you send to CDP, otherwise the events will not be loaded.
Referer Optional String   Only applicable for web events, this attributes stores the URL of the page that lead the visitor to the current page on which this event was triggered.
URL Optional String   Only applicable for web events, this attributes stores the URL of the current page on which this event was triggered.
SourceMessageNumber Recommended String Message: SourceMessageNumber The message which triggered this event for the visitor/customer. For email events : this is the message that was sent/open/clicked/bounced or that lead to the subscription/unsubscription of the customer/visitor. For other marketing campaigns (Direct Mail, SMS, etc…) : this is the message that was sent, or that was viewed by the customer/visitor and on which this event was triggered. This is important for reporting and tying events back to the marketing effort(s) that triggered them.
SourceProductNumber Recommended String Product:SourceProductNumber The identifier of the product tied to the event. Mostly applicable to web events : the identifier of the product targeted by any of the events productBrowsed/cartUpdated/checkout.
SourceProductCategoryNumber Optional String Product: SourceProductCategoryNumber Category: SourceCategoryNumber The identifier of the category tied to the event. Mostly applicable to web events: the identifier of the category targeted by categoryBrowsed events.
SourceTransactionNumber Recommended String Transaction: SourceTransactionNumber The identifier of the transaction tied to the event. Mostly applicable to web events: the identifier of the transaction created by a checkout event.
SourceOrganizationNumber Optional String Organization: SourceOrganizationNumber The identifier of the organization tied to the event. Mostly applicable to custom physical, in-store events (e.g. loyaltySignUp), and clients who have multiple websites that they would like to differentiate. Not applicable to email events.
SearchTerm Optional (use only with Type = “onsiteSearch”) String   The term(s) that was used during an onsite search event.
UserClient Recommended String   This is the client being used when this event was triggered. Use “A” for applications (e.g. mobile applications), “B” for browser, or “U” for unknown (you can leave it NULL if not applicable). This is interesting for web-like events where differentiating between the website and a mobile application is relevant for marketing campaigns down the line. This is automatically populated when you are using the CDP JS SDK on your website, but you should populate it when using the Tracker API.
Domain Optional String   The name of the domain on which the event was triggered (applicable to web event only). This is automatically populated when using the JS SDK but you should populate it when using the Tracker API (if you need to use it later for marketing campaigns).
DeviceType Recommended String   The type of device used to trigger the event (mostly applicable to web/ application events). This is automatically populated by the JS SDK when you implement it on your website, but you should populate it when using the Tracker API. The list of standard values supported by CDP is : COMPUTER (for laptops/desktops), MOBILE (for mobile phones, e.g. iPhone, Galaxy Note…), TABLET (“Tablet”, e.g. iPad, Kindle Fire…), GAME_CONSOLE (“Game console”, e.g. Playstation 4), DMR (“Digital media receiver”, e.g. Roku, Google TV, etc…), WEARABLE (for wearable devices) , and UNKNOWN for the rest. Please check with your Implementation team if you think you need to add other types.
OperatingSystem Optional String   The operating system of the device on which the event was triggered (applicable mostly to web events). This is automatically populated when using the JS SDK but you should populate it when using the Tracker API (if you need to use it later for marketing campaigns).
Browser Optional String   The browser on which the event was triggered (applicable to web events). This is automatically populated when using the JS SDK but you should populate it when using the Tracker API (if you need to use it later for marketing campaigns).
Custom attributes Optional Any (float, datetime, string, boolean)   Custom attributes that you want to use inside the CDP application. Note that this customization is not self-service, requires you to engage with your CDP CSM, and involves some deployment effort.