Configuring Events Setup

Objective

After completing this lesson, you will be able to configure the Source Application to accept events sent to SAP Customer Data Platform for ingestion.

Introduction

Application Events are used to configure how SAP Customer Data Platform ingests customer data from external systems. These events include data provided voluntarily by a customer, aka first-party data, and data provided by others, which may be second-party, third-party, visitor, or offline data.

Examples include a customer’s wish list data, order data, or product browsing data, and so on.

In the following image, we see an Event Settings page (step 1) showing basic info, such as Name, Data Type, Description, as well as other information, for instance:

  • Required Processing Purposes: for the customer data merge cases, the incoming information (Event data) will need to be granted for all Processing Purposes configured in this setting, otherwise it will be discarded.
  • Granted Processing Purposes: during ingestion, the customer will be granted the Processing Purposes configured on this field.
  • Read File Path: because the Source Application is cloud storage, you can point out which folder SAP CDP should look at for customer data to be ingested.
  • Filename Regex: only file names matching the regular expression configured on this field will be considered for ingestion.
  • File Format to Read: here you set whether the format of the text input files to be ingested is JSON or CSV.
  • Move After Ingest: do you want the input files moved to another folder after their contents get ingested?
Event configuration showing Name, Data Type, Required and Granted Processing Purposes, Description, and additional settings such as the Read File Path, Filename Regex, File Format to Read and Move After Ingest.

Event Schema

Each attribute of the event schema has data preparation rules, applied before the event data is ingested. Data Preparation means customer data is validated, normalized, and transformed during the ingestion phase.

In the image below, we see an Event Model page (step 2). Here we can see the types and names of the fields. New fields can be created using the Create New Node button. The Event Model can be either defined using the UI or JSON Schema. There’s also an option for dropping a file containing sample data from a single customer profile, and the system defines the schema based on its contents. The attribute masterDataId will be used on step 3 as an Event Matching Rule. The attributes when and eventId will be used in the Metadata configuration.

Event configuration Model page containing the schema definition that matches the structure of the data to be ingested by the Event.

Event Schemas support multiple data types for the event attributes or fields, such as String, Number, Boolean, and even Object and Array. With the Object field type, you can nest fields to ingest complex data types. Event data or event attribute values can be validated using built-in patterns, for instance e-mail address, date and time, and URL, mimicking the Customer Schemas attribute editor features.

Common properties of one of the Event Model attributes containing Type, As Array toggle, Name, Display Name, Description fields.

For more complex validation logic, you can manually specify a Regular Expression pattern to test against field values or provide a list of allowed enumeration values.

Validation of an Event Model attribute. Validation toggle is on, Validation Type is By Format, Format is Regex, the Pattern looks for a lowercase word starting with an uppercase letter, and the string Brandson is used as Test Text (for testing the pattern).

The event attribute values can also be normalized to remove Punctuation and spaces within the data field. You can find and replace specific parts of the data field with Regular Expressions. This means you can perform quality checks on the event data by using your own data cleansing rules before ingesting it into the SAP Customer Data Platform.

Normalization of an Event Model attribute. Normalization toggle is on, Punctuation and Spaces removal are checked.

Event Metadata

The Event Metadata configuration is responsible for two important settings:

Deduplication ID
Used to identify the input payload record. This is usually a generated UUID, or sometimes even a checksum. It is used in the case the source payload has multiple occurrences of the same customer data record; if so, then the system can safely discard subsequent ones.
Timestamp Field
Used to inform SAP CDP of the last time this information was created or updated. SAP CDP will use this value to plot this piece of customer data in a timeline when processing time-sensitive insights, graphics, or to perform cut-date delta ingestions.
Metadata screen having eventId and when fields linked to Deduplication ID and Timestamp Field, respectively. The Timestamp Field format can be customized using Timestamp Format.

Matching Rules Mapping

This is the step where you will map the Application Identifier attributes you want to use based on which customer data identifier information you have available in the Event Model Schema.

In the image, we see an Event Model page (step 3). On the left side, you can pick any attribute available in the Event Model (input payload schema) that can be linked to the existing Matching Rules listed on the right side. As you can see, masterDataId was dragged from the left side and dropped into the corresponding masterDataId Matching Rule on the right side, creating an Application Identifier link between the Event Model attribute masterDataId and its Profile counterpart.

If you need to configure a composite Application Identifier, multiple Event Model attributes can be combined if you drag and drop them into the same target attribute.

Matching Rules Mapping page containing the Event Model schema on the left-hand side and the Matching Rules on the right side. The attribute masterDataId is linked as Event Matching Rule.

Schema Mapping

In this step you will link the remaining Event Model attributes to their Customer Data counterpoints, be that Profile, Group, or Activity customer data. You can choose to:

  • map only the ones you need
  • map the same Event Model attribute to multiple targets
  • map multiple Event Model attributes into a single target
  • configure transformations for each attribute value during the ingestion pipeline

In the image below, we see a Schema Mapping page (step 4). We can see first and last name, as well as the gender attribute mapped from the Event Model on the left-hand side into the Profile attributes on the right-hand side, akin to the way it happened during the previous step (Matching Rules Mapping).

Schema Mapping page containing the Event Model schema on the left-hand side and the Profile attributes on the right side. The attributes firstName, lastName, and gender are linked to their customer data Profile attributes counterparts.

Scheduled Polling

In the last step, you can optionally turn on scheduling to pull new Event data from the source at a given interval starting on a specific date and time. Please note that some Source Application connectors may have this option, while others may provide a REST HTTP Endpoint Source Applications can use to push customer data into the SAP Customer Data Platform.

Scheduled Polling page showing settings commonly found in scheduling systems, such as start date and time, and repeat interval.

Ingest Now Feature

Some Source Applications will allow you to fire ingestion of customer data manually whenever there’s a need for that. Check if that is available in the Event card’s context menu (three dots at the top right of the Event card) by using the Ingest Now option. You need to select a cut date and time using the Since field. For each record of customer data fetched from the source, the system will only consider ingesting it when its Event Metadata Timestamp attribute is greater or equal to what you set in the Since field. You can also optionally place an upper limit the number of customer data records applied to the ingestion pipeline when setting the Limit field.

Ingest Now pop-up displaying the Since and Limit fields.

Event Status

The status of the ingestions processed for each Event will be kept for 7 days in the system, and can be quickly analyzed using the View Status option from the Event card’s contextual menu. For every ingestion, this option will display the number of records ingested and the completion status. For a deeper analysis of issues with customer data ingestions, please consider using the Monitoring feature. You can find out more about that by consulting Monitoring Customer Data Ingestion in SAP Customer Data Platform.

The Event Status showing two batches of past ingestions: one that succeeded, taking 5 seconds and ingesting 100 records, and another that failed.

Event Playground

The Event Playground allows you to ingest a single record of customer data inside the SAP Customer Data Platform Console, including Profile, Group, and Activity data. It does so by creating a UI form that matches the Event Model attribute fields. Sample data is generated randomly for each field based on its type and format. After submitting the form, the system shows the ingestion results on a screen displaying each of the ingestion pipeline steps, including any possible failures.

Event Playground screen showing some sample customer profile data.Results from an Event Playground ingestion showing some of the pipeline steps.

Configuring Incoming Events – Demo

Summary

In this lesson, you've learned how to configure the SAP Customer Data Platform to efficiently ingest customer data from external sources by setting up application events. You explored various components of the event setup, from specifying the source and file format to mapping schemas and setting event metadata. Essential tasks include configuring the event settings, where you define required processing purposes, filename patterns, and ingestion protocols like moving files post-ingestion. The event schema plays a crucial role by allowing data validation and transformation, ensuring data integrity before ingestion.

Furthermore, you examined the importance of event metadata in deduplication and timestamp tracking, helping manage data efficiently using identifiers. You practiced mapping matching rules and schema attributes to align event data with customer profiles, groups, and activities, thereby ensuring seamless data integration. With options like scheduled polling and manual ingestion, you can effectively control how and when data is pulled into the platform. The lesson also introduced features like the Event Playground and Event Status, allowing for real-time data testing and ingestion monitoring. By mastering these configurations, you're equipped to maximize SAP CDP's capabilities in handling diverse and complex customer data sets to create actionable insights.