Intelligently re-engage your customers: Luma examples

So how can you execute the intelligent re-engagement use case at your company? I’m Daniel Wright, technical marketing engineer. And then a series of videos. We’ll walk you through an example of implementation and execution using our fictional brand Luma. This video is for the developers doing the implementation work, and the other videos will show marketers how to do their part in real time customer data platform and Journey Optimizer. So let’s dive in. The Adobe Experience platform components that we’ll use in our implementation are schemas, identities, data sets, data ingestion and profiles. Let’s make sure we understand the business requirements and then transition into our data model and schemas. So we have three scenarios abandoned Browse in which a customer browses a piece of content but doesn’t take the next step and you want to reengage them. We’re going to showcase this in a retail scenario, but you can apply this to almost any industry. Maybe you’re a financial institution and somebody reads about your auto loans but doesn’t apply for one. Next is abandoned cart. In this one, a customer adds a product to their shopping cart but doesn’t complete the purchase. Finally, we have an order confirmation scenario which is sending a message after a purchase or other conversion event. So what data do we need to pull this off? I’m going to break this problem down into three themes ID, qualification and messaging. Okay. So let’s start with ID. Who is this user so we can message them? They need to be what we call a known user. We need to be able to connect online behavior to an email address or mobile phone number. Typically, you would get this information by having an account creation process, and they occasionally log in to your website or mobile app for in-store purchases. It’s a good idea to have an incentive to self identify, say, by entering loyalty program details at checkout. Qualification is about what makes them eligible. In our use case, there are different events used in this scenarios like viewing a product, adding it to their shopping cart or purchasing something accompanying these events. You need things like timestamps because the passage of time is another important element of qualification. Finally, we have messaging. What message do you want to show them? If you want to show them the actual products they browsed, abandoned or purchased, then you need to collect SKUs, product names, images or things like that. Also, what channel will you use to message them? What are their communication preferences? So now that we know the scenarios and the data points they require, we can build an entity relationship diagram of our data model.

Here are the three main schemas mentioned in the use case. Customer attributes which uses the axiom individual profile class. Since these are attributes of the customer or customer digital transactions which uses the EKM Experience event class. Since this captures actions that a customer’s taken on the website or mobile app over a period of time, and customer offline transactions which also uses the ZM experience event class again, because these are actions that customers have taken. So here’s the thing you don’t need to use these exact schemas, you just need to collect the right data for the use case. For example, here’s our data model for LUMA. Now I like to have separate schemas for each data source. It might look more complex, but I find it more intuitive. Your data model is probably going to be even more elaborate because you’re going to onboard data from additional sources and need additional fields for additional use cases. The important thing is that you’re collecting the right data in the right format. By the right format, I mean use the experience event class for event data like the product use and purchases and use the Axiom individual profile class for attribute data like email addresses and consent preferences. Use the right data types and field properties to help ensure data integrity. For the most part, I’m using the same field groups that were outlined in the use case document.

Now let’s talk about identities and profiles. We want to use data from our website or mobile App store purchases and then systems with attribute data about our customers like CRM or loyalty. We’re going to stitch the data from these sources together to build real time customer profiles. Identity fields and the identity graph are What do this? Let’s take a look at how we collect these with Luma. Starting with this CRM system, Our CRM system uses a CRM idea as the primary identity and you can see how it’s labeled as such in the schema. Note that my email and phone number fields are also in this schema and I don’t have to use them as identities. Our loyalty system uses a loyalty ID as its primary ID, but it also uses the CRM ID as a secondary identity. This allows us to connect profiles between the CRM and loyalty systems and note that these identity fields are custom fields added through a custom field group. I’ve also created custom identity namespaces for them. Our offline purchases schema, which captures those in-store orders, also uses the loyalty ID as the primary.

Anonymous in-store purchases, which wouldn’t have a loyalty ID. They’re not helpful in the use case. In our use case, we use the in-store purchases to send or suppress messages. So if we can’t tie the in-store purchase back to a known user, we don’t need that data for our scenarios anyway. Our consent and test profile schemas also use the CRM idea as the primary.

Now let’s look at the web and mobile schema. Note that I’m not using any fields labeled as identities. Instead, I’m using the identity map, which is automatically part of every experience events schema. When you use identity map, you specify the identity namespace and whether or not the identity is primary. When you send the data to platform, I’ll explain this more. When we get to the data ingestion portion.

So by having a considerate data model with good identity selection, identity graphs can form.

Let’s take a look at one. I’ll go to the identities screen and search for one of my CRM IDs. I can turn on the visualizations so we can see how the loyalty ID, CRM, ID and device IDs called experience Cloud IDs or ECI IDs are all graph together for this user.

So we review the schemas and identities. Now let’s take a look at our data sets. Data sets are no big deal. They just take a few seconds to create and I use one for each schema mentioned earlier. And I do like to use separate data sets for my web and mobile data.

To build profiles, you need to take one minor step and enable both schemas and data sets for profile, which is done through these toggles. You need to have identity fields to enable profile and with a schema using the identity map, there will be an additional dialog you go through to confirm that you’ll be passing your identities that way.

Once you have schemas and data sets enabled for a profile and ingest data, you can see profiles in the interface. So let’s click through to the profile viewer where we can see that this profile contains attributes from CRM, loyalty, consent and event data from the website and mobile app. Now let’s pivot to data ingestion and we’ll start with the website and mobile app. So we’ve implemented with the Experience Platform, web and mobile SDK, which can send data to platform as well as other Adobe applications and third parties. But this isn’t actually a requirement if you use app measurement for your web analytics data, you can use the Adobe Analytics Source Connector to pull that data into platform. And if you use a non Adobe analytics vendor on your website and mobile app, you can ingest that data into platform two using source connectors or APIs.

When someone logs into the Luma website, they become a known user and we can pass their authentic data or customer ID to Adobe. If I inspect a network car, you can see I’m passing this Luma CRM ID as the primary identity in the hit. I use tags to implement the web SDK and there is a special identity map data element type that you can use to set these authenticated IDs.

There’s another identity, a device ID called the Experience Cloud ID or ECI ID, and that gets added to the identity map on the platform Edge network. Before that data is sent to the platform. So I won’t see it in the call, but it will be there when the data gets into platform and the idea is used as the primary identity. When the user is not logged in and the mobile app does the same thing, we also collect our events through the case. So the product for use adds to cart purchases. There are two common ways of doing this. First is to use the event type field. Note here I have event type set to commerce product views. I also have a commerce stop product used values set to one. That’s another way of signaling that a product view has occurred. I can only send one event type per call, but with that dot value approach, you can indicate that multiple events have occurred within a single call. It’s just important that your marketing team knows which approach you’re using in order to build their journeys and audiences correctly.

The SDK will automatically add timestamps and IDs to every event, so you don’t need to worry about those or other events coming from in-store purchases. Those can be streamed or batched into platform using the available source connectors in our catalog or by using the API. I use the API to ingest my sample data. This data should map to the same extreme fields as your web and mobile data so that you can easily identify purchases across all sales channels.

What about our messaging requirements? How do we collect the product details in case we want to display things like product names and images in our re-engagement messages? I’m collecting the product SKUs and names here in the Web SDK implementation. You can see them in this product list items array. The image URLs. I don’t collect client side. If we go back to my ERP. Note that I have a separate product catalog schema that uses a custom product catalog class. I use what’s called a schema relationship to map the SKUs from my events to this schema. So it’s basically a lookup table and all I really need to collect in my events is the SKU.

Now let’s move on to our customer attribute data. CRM data can be onboarded from our CRM source connectors available in the catalog or through cloud storage connectors or via API. I’m using the API to batch ingest sample data.

Consent preferences can also be onboarded from the consent and preferences source connectors in the catalog through cloud storage, connectors or API. Again, I’m just using the API to batch my sample data.

Loyalty system data can be onboarded using cloud storage connectors or API. Again, I’m using the API and the test profiles since this is more of an internal configuration for the marketer. These are usually just dragged into the UI on the data set screen, so that should cover data ingestion and our messaging requirements. And that concludes our implementation video showing how we built our schemas, chose and populated our identities, built data sets, ingested data and constructed real time customer profiles. As you can see, we took that design pattern from the use case document. Broke down the problem into the areas of identification, qualification and messaging requirements and used an entity relationship diagram to help focus on the use case. Make sure we were capturing everything we needed to accomplish the use case. I hope you’re are able to use this example to implement the use case at your business.