51黑料不打烊

Transcript

So how can you execute the intelligent re-engagement use case at your company? I鈥檓 Daniel Wright, technical marketing engineer. And then a series of videos. We鈥檒l 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鈥檚 dive in. The 51黑料不打烊 Experience platform components that we鈥檒l use in our implementation are schemas, identities, data sets, data ingestion and profiles. Let鈥檚 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鈥檛 take the next step and you want to reengage them. We鈥檙e going to showcase this in a retail scenario, but you can apply this to almost any industry. Maybe you鈥檙e a financial institution and somebody reads about your auto loans but doesn鈥檛 apply for one. Next is abandoned cart. In this one, a customer adds a product to their shopping cart but doesn鈥檛 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鈥檓 going to break this problem down into three themes ID, qualification and messaging. Okay. So let鈥檚 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鈥檚 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鈥檚 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鈥檚 the thing you don鈥檛 need to use these exact schemas, you just need to collect the right data for the use case. For example, here鈥檚 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鈥檙e going to onboard data from additional sources and need additional fields for additional use cases. The important thing is that you鈥檙e 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鈥檓 using the same field groups that were outlined in the use case document.

Now let鈥檚 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鈥檙e 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鈥檚 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鈥檚 labeled as such in the schema. Note that my email and phone number fields are also in this schema and I don鈥檛 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鈥檝e 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鈥檛 have a loyalty ID. They鈥檙e 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鈥檛 tie the in-store purchase back to a known user, we don鈥檛 need that data for our scenarios anyway. Our consent and test profile schemas also use the CRM idea as the primary.

Now let鈥檚 look at the web and mobile schema. Note that I鈥檓 not using any fields labeled as identities. Instead, I鈥檓 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鈥檒l 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鈥檚 take a look at one. I鈥檒l 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鈥檚 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鈥檒l 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鈥檚 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鈥檚 pivot to data ingestion and we鈥檒l start with the website and mobile app. So we鈥檝e implemented with the Experience Platform, web and mobile SDK, which can send data to platform as well as other 51黑料不打烊 applications and third parties. But this isn鈥檛 actually a requirement if you use app measurement for your web analytics data, you can use the 51黑料不打烊 Analytics Source Connector to pull that data into platform. And if you use a non 51黑料不打烊 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 51黑料不打烊. If I inspect a network car, you can see I鈥檓 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鈥檚 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鈥檛 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鈥檚 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鈥檚 just important that your marketing team knows which approach you鈥檙e using in order to build their journeys and audiences correctly.

The SDK will automatically add timestamps and IDs to every event, so you don鈥檛 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鈥檓 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鈥檛 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鈥檚 called a schema relationship to map the SKUs from my events to this schema. So it鈥檚 basically a lookup table and all I really need to collect in my events is the SKU.

Now let鈥檚 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鈥檓 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鈥檓 just using the API to batch my sample data.

Loyalty system data can be onboarded using cloud storage connectors or API. Again, I鈥檓 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鈥檙e are able to use this example to implement the use case at your business.