Configure streaming events

Transcript

In this video, we will demonstrate how to configure an event for Journey Orchestration. In particular, you’ll learn what’s required for XDM experience events that will be used by Journey Orchestration, how to define a Journey Orchestration event, and how to configure a source system to send instances of the event, to platform for Journey Orchestration.

Journey Orchestration events, are XDM Experience Events that are sent to the Adobe Experience Platform via Streaming Ingestion. As such, an important prerequisite for setting up events for Journey Orchestration is that you are familiar with the Platforms Experience Data Model or XDM and how to compose XDM experience event schemas as well as had a stream XDM format of data to the platform. A thorough explanation of these topics is beyond the scope of this video. We’ll show some examples as part of the overall process of setting up Journey Orchestration events. We’ll show a specific example of configuring a mobile app to send an event to the platform and for that it will be helpful but not required, to be familiar with launch and the mobile SDK as well as the place’s core service. To illustrate the process of setting up an event for Journey Orchestration. We’ll use the event from the example journey in the introduction video, which represents a mobile app user entering a geofence around their local LUMA Studio.

The first step in setting up an event for Journey Orchestration, is to ensure that you have an XDM schema or data model defined to represent your event. And a data set created to record instances of the event in the platform. Having a dataset for your events isn’t strictly necessary, but sending the events to a specific dataset. We’ll allow you to maintain users event history, for future reference and analysis, so it’s always a good idea. If you don’t already have a suitable schema and dataset for your event. Both of those tasks can be done in the platform web interface. As noted previously, the complete treatment of XDM and Platform Streaming Ingestion, are beyond the scope of this video, but we’ll point out a few details that are important for Journey Orchestration. In order for an XDM schema to be used for journey orchestration events. You’ll need the following. The schema must be of the XDM experience events class and you must include the Orchestration event ID mixin, as we’ll show later, Journey orchestration uses this field, to identify what type of event this is. When an event instance is sent to the platform, you should also include an identity field for identifying the individual to whom the event pertains. The schema, as well as any data set you create based on the schema, should be enabled for unified profile.

And you should include data fields to capture any other context data you want to include with the event, such as information about the user, the device from which the event was generated, location, or any other meaningful circumstances related to the event.

You’ve also created a dataset based on this schema for recording events. Note the data set ID which we’ll use later, and that the data set is enabled for unified profile. The second step, once we have a suitable XDM scheme and data set defined on the platform is to define the event of interest in the Journey Orchestration interface. To do this, I’ll go to the events Tab and click Add. This will bring up a configuration pane. Well first, enter a name for my event and also give it a description.

Next, I’ll select the schema we’re using to represent the event of a user arriving at the Luma Studio, Luma Mobile Geofence Events. From this schema, I can then select the specific payload fields that I want Journey Orchestration to cash. When an instance of this event gets sends to the platform, this will allow me to reference data from any of the fields I select here. When executing a journey based on this event. You’ll see that the required event ID field is pre-selected as well as the ECID, which is designated in the schema as the primary identity key. We’ll also include the other identification fields and the fields for location information. Because the ECID field was already designated in the scheme as the primary identity. You’ll see that Journey Orchestration, has pre-populated the ECID as the identity key for this event.

Finally, we will add a condition. These are optional and you won’t always use one, but for this example, we’ll include a simple condition that the geofence entered his Luma Studio.

And with our event all configured, we can now hit Save.

Now if I go back to the main Journey Orchestration page and start a new journey, you’ll see that our new event is available on the left rail, so that we can use it as the starting point for a journey or as a waypoint later in the journey. We’ll go into detail on building journeys in a separate video.

The final step, now that we’ve defined the event that we want Journey Orchestration to listen for and respond to, is to configure our mobile app, to send instances at the event to the platform as they occur. The details of this will vary depending on your mobile app website or other source system from which an event might originate, but the endpoint to which the event should be sent and the payload used to represent event data would be the same. Our example event is a Geofence Entry, so that would be coming from the mobile app on a user’s device. For illustration, we’ll assume that LUMA uses the launch interface, to manage the Adobe experience platform, mobile SDK and its mobile app. And the LUMA uses the experience Clouds Places Core Service to manage geofences around its studio locations and a monitor for geofence entries and exits. In that case, we can create a rule in launch, descend the XDM format at event payload to the platform. Whenever the place is serviced to text the geofence entry event at one of the LUMA Studio locations. To do this in the launch interface, we’ll go to rules, create a new rule, and give it a name. We will configure the mobile SDK event that triggers the rule, by specifying that it is generated by the places extension and that we’re looking for entry events in particular. Next we’ll specify the action as a postback. To configure the postback, we need to specify the platform Streaming Ingestion endpoint to which you will send the event. Creating streaming endpoints is beyond the scope of this tutorial, but you can learn more about streaming endpoints from the platform documentation and tutorials. For the post body, it’s easiest to start with a sample payload that you can get from the Journey Orchestration interface. For the event that we’ve defined. If we can preview our arrive Luma Studio event, we get a sample payload that we can copy and paste into the text box and launch.

From there we’ll need to edit the payload to replace the placeholder values with something meaningful. In the header section of the payload, we’ll change the data set ID value to the ID of the data set that we created in the platform.

And we’ll change the name of the source, to the actual source name of the streaming endpoint we’re using, which in this case is Luma Mobile App.

In the body section of the payload, we’ll add references to launch data elements to dynamically answered those values into the payload when are the sent by launch. It elements or objects you can create in lodge to reference certain values that are generated or captured by the SDK. You can learn more about data elements from the launch documentation and tutorials.

We’ll do this for email, ECID and mobile number under the identification section.

And under location, we’ll reference values for store name, location type and location city, and we’ll just leave the others blank.

ID just needs to be a unique character string, so we use the random data element for that, and we’ll also, use a data element reference to insert the timestamp. Once we’ve edited the payload with the right dynamic values, we just need to specify the content type as Application Jason, adjust the timeout as needed, and click on keep changes.

Once we’ve saved the rule, and added it to the SDK configuration, using the publishing workflow and launch. The mobile app will send the arrival Luma Studio event to the platform whenever it occurs.

To summarize what we’ve learned, listening for and responding to individual specific events, isn’t a central part of Journey Orchestration. Setting up an event of interest for Journey Orchestration involves the following steps.

First, you need to have an XDM experience events schema defined on the platform, that includes the Orchestration eventID mixin, is enabled for Unified Profile and includes data fields that can represent whatever contextual data you want to convey when the event occurs. Second, you need to define the event of interest in Journey Orchestration, by specifying the schema identity key for the event and generating an event ID value, that should be included in the payload, whenever an instance of that event is sent to the platform. And finally, you’ll need to configure the source system that generates the event, whether it’s your mobile app, your website, or some other system. To send an XDM formatted payload with the relevant event ID value. Do a Platform Streaming Ingestion endpoint. We showed one example using launch to send an event from a mobile app, which you can adapt as needed, depending on the nature of the event and its source. In other videos, we will demonstrate how to use the events that you’ve set up to build customer journeys, and had a test and validate the end to end experience starting with the event. -