In addition to being able to automatically associate offer responses with specific journey steps, it is possible to harness events to trigger movement on the customer journey. This document will go through an example of how a user might hook up web event processing and capture to customer journey processing, specifically to capture an event when a user views a certain web page.
Note that there a few ways event capture could be integrated; this document goes through one such way and one such use case.
This process, end-to-end, does not provide much value unless you already know of at least one event that you would like to track as part of a customer journey. You can build the infrastructure entirely within Pega before determining relevant events.
The streaming data set
To start, build a streaming Data Set to capture your web events. First, create a class under Data-Event. In this case, we will go with Data-Event-PageView.
In this class, create a new Data set. Under the Type dropdown, ensure that the type is set to Stream. Configure a name (such as PageViewStream) and other relevant information as fitting for your system. Save the data set. Take note of the Integration box at the bottom of the Stream tab. Here, you will see that a REST service endpoint has been outlined with relation to the data set. Invoking this REST service will populate the data set. There is also an example payload available in this box that will give an example REST POST for that service.
The data flow, and connecting the customer journey
The example below represents how a user may want to configure a data flow to capture journey interactions.
The source for this data flow is the streaming data set created in an earlier step, PageViewStream.
The branch in red brackets represents steps that you might want to take if you are planning on passing your events to the event store. This doc will not be covering that process, as it is not relevant to the Customer Journey.
The branch in blue brackets is a minimum configuration for processing the event for Customer Journeys. The Convert shape has the responsibility of converting the incoming event data to an instance of Data-pxStrategyResult so that it can be processed for journeys. That shape might be configured something like below, though users should be aware of what their event data looks like and adjust accordingly. Also, users should consider any other data that may be important. The data does not need to be limited to the values below.
The most important properties for Journey processing are the customer id, the event and reason, and the channel.
The other key component is the output to the DF_JourneyManager data flow. There is nothing complicated to configure with this shape. It just needs to be configured to reference the DF_JourneyManager data flow.
Configuring your journey to react to events
There are two ways to track data within the Journey:
- Content (offers)
- Entry Criteria (proposition filters)
To track event-based behavior, proposition filters should be utilized. As an example, to help illustrate the concept, imagine that the entry point for a given Journey is that a customer visits a page on the company website for one of any 3 new products. Each of those pages has an event that fires upon a customer accessing the page, and those events stream to a data flow like the one earlier in this doc, which feeds the events to Journey processing. If a customer visits one of those pages, we want them to be eligible for the Discovery stage on the Visited Product Page step. That entry criteria might look like the following configuration:
These are the default criteria of the proposition filter. Based on the Logic string, if at least one of the When rules returns true, the event will be considered eligible for the Visited Product Page step. Each of those When rules might look as shown in the following example:
This checks the identifier of the event (.JourneyPayload.pyReason) for a specific event. If the event matches, the When rule returns true. Note that it is of course possible to have a standard When rule that checks that the value of .JourneyPayload.pyReason matches a passed in String parameter. This is a matter of preference based on the organization. In some cases, having explicit When rules might make things easier to read and understand.