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.

Transcript

Welcome! In this video you will learn how to implement the abandoned product browse scenario in 51黑料不打烊 Journey Optimizer. I鈥檓 Sandro Ausmann, Senior Technical Marketing Engineer at 51黑料不打烊. This video is for the marketer. I will walk you through two implementation options on an example of a fictional retail brand called Luma. This scenario can also be applied to other industries like financial services or pharma. I will explain the reasoning behind each implementation step and what you will need to implement. But I will not go into the depth of how to set up each element of the journey. You should therefore know how to create a journey, messages, audiences and events. If you are unfamiliar with any of these concepts, please review the tutorial section on Experience League for detailed guidance before starting this tutorial. Now let me go through the technical prerequisites. You will require the following permissions. Managed Journeys and Published Journeys. Managed Journey Events, Data Sources and Actions. Managed Messages. Published Messages. Published Messages. Managed Segments. You will also need to have the communication channels you would like to use configured. In this example we are using Email, SMS and Push. Let鈥檚 review the business requirements for the abandoned browse scenario. In this scenario we aim to re-engage a customer who viewed a product on either the website or the mobile app and did not continue to interact with the brand. We will show the customer personalized ads as well as send them re-engagement messages via Email, SMS or Push. The re-engagement through the messaging channels will be implemented with Journey Optimizer. The destination framework is used for paid media ads which is covered in another video. The scenario is triggered when a product has been viewed. When there is no brand engagement in the following three days, we will send the customer a message with a call to action to re-engage. Brand interaction would be online or offline purchase, a product was added to the cart, a site visit or any interaction with the app. After another three days, should the customer still not engage, we will send them another reminder message. Now let鈥檚 get started. Before you can start building your journey you will need to create two events. The journey is triggered by a Product View event which means a profile enters a journey when they view a product. Journey Optimizer will then listen for an hour after the product view if this customer added any product to the cart. If he did, we will end the journey for this specific profile. Let me show you how the events are configured. The Product View is a unitary, rule-based event. The Luma schema we are using is the web and mobile event schema. We have added the following fields in the event payload. The Identifier, Event Type which we will use for the condition, the Identity Map fields which link this event to the profile and the timestamp. The other fields are specific to Luma and depend on your specific data structure and which information you want to have in your payload to use to personalize the messaging. The event condition needs to be defined as Type is Product Views. And the namespace is ECID. The second event we need is the Add to Cart event. It is also a unitary, rule-based event. Again, the fields depend on what you require in the payload and how your data structure is set up. For this use case, we don鈥檛 require a lot of information as we just need to know if this event was triggered or not. Identifier ID, Event Type and Identity Map will be sufficient. However, if you are planning to implement the abandoned cart use case as well, you should add all information you require to personalize the communication with a customer. Like the cart ID, the ID and value for the product list ads, as well as the required product catalog data. Such as the image URL, the SKU, product name, price and so on. Once the events are available, you can add them to your journey. You can just work with a Product View event, but in this retail scenario, listening to an Add to Cart for an hour after a Product View allows you to exit profiles who have a buying intention from your journey earlier. Without this event, all profiles will stay in the journey for at least 3 days. Since the events are followed by a 3 day wait before we check if the customer has been inactive since the Product View. So how do we check if the profile engaged with the brand? Remember, engagement with the brand means browsing the website or interacting with the app, adding a product to a cart or an online or offline purchase. So the online and offline purchase is important. Depending on your data structure, you have two options to implement this use case. If your data structure has all event information in one schema, you can simply create a brand engagement event. And instead of listening to the Add to Cart after the Product View for an hour, you can listen for any brand engagement for 3 days. In that case, we won鈥檛 require a wait activity and the profile will exit the journey as soon as they engage with the brand. But if you have the event data in different schemas, one for each data source for example like Luma does, then you cannot use an event to listen for overall brand engagement as each event can only link to one schema and Journey Optimizer can only listen to one event at a time per journey. So if you have your online and offline purchases in two different schemas, we will need to work with audiences and a condition that checks if the profile is part of an audience. If they are, they will exit the journey. So we need a batch audience that a profile qualifies for if they view the product in the last 3 days and engage with a brand after the Product View. However, 51黑料不打烊 Experience Platform batch audiences are only calculated once a day, which for this scenario potentially means that profiles can be missed. So let鈥檚 take a look at the timeline to understand the implications. Our timeline starts when the profile views a product and enters the journey. After listening for an add to cart for an hour, we have a wait for 3 days before we check if the profile is part of the engaged audience or not. Since the audience batch generation only runs once a day, the first audience that will be relevant for us will be generated sometime within 24 hours after the Product View. So let鈥檚 assume this is when the audience is calculated. So a profile will qualify for the audience if they viewed a product in the last 3 days and after that engaged with a brand. So you can see the yellow block shows the timeframe when in our journey the profile can qualify for the audience. Now let鈥檚 take a look at the situation at the time of the condition check. As you can see here, the third batch generation run after the Product View is the relevant one for our condition check. You can also see that the audience will include all profiles that viewed a product, so entered our journey, and then had brand engagement since the initial Product View. So far so good. However, due to the timing of the batch run, we鈥檙e going to have a blind spot exactly between the last audience calculation and the condition check. This blind spot means that any profile that was engaged with a brand during this time will not be added to the audience, which ultimately means that they remain in the journey and we will be targeting them, and of course we don鈥檛 want to do that. Depending on when within the 24 hours after the Product View the first audience calculation runs, the timeframe of this blind spot can be longer or shorter, but it will never exceed 24 hours. So, to bridge the gap, we will define a second audience, which looks for profile engagement within the last 24 hours. This audience can be of type streaming or will be of type streaming, so a profile gets added in real time. Unfortunately, we do have yet another issue. Because we added an hour wait if our audience calculation runs within an hour of the condition check, then you can see here all profiles in the journey will disqualify from the batch, because the first rule of our batch audience, the Product View, falls out of the lookback timeframe. So, to solve for this issue, we simply expand the lookback period from 3 days to 4. That way we have a 24 hour buffer again and we are on the safe side and do not miss any profiles. In our first condition we will therefore check if the profile has not qualified for the two audiences. If it has, then the profile will exit the journey. If they were not engaged, we check what their preferred channel is and if we have consent to contact them via this channel. Now let鈥檚 talk about personalization of the messages. Let me navigate into the email. Now, if you would like to refer to the product the customer reviewed in your communication, you have two options. You can personalize the message either by using the contextual attributes coming from the Product View event. In this case it is the first product the user viewed, the product view that triggered the journey. If you expect that the customer might have viewed other products after they entered the journey and you would like to personalize on the last product viewed and not the first product viewed, then you can work with computed attributes. These will need to be set up before you can personalize your message. Please see the product documentation for a detailed description on how to set up computed attributes. The rest of the journey is straightforward. Journey Optimizer waits for 3 days after sending the message and then again checks the audience membership. In this case we only need to check for engagement in the last 3 days, so we require a third audience. This one also needs to be a batch audience. And to cover the potential blind spot we have due to the timing of the batch run, we also need to check for membership to the streaming audience of engagement in the last 24 hours. If the profile is not a member of either audience, the customer is not engaged with the brand since the last message was sent, so we will check the channel preferences and the consent once again and then send a second re-engagement message and end the journey. If your data structure allowed you to work with a brand engagement instead of the condition check on the audiences, then of course you again listen to the brand engagement event and set a timeout for 3 days and do not require the wait. Now you should know how to implement the Abandoned Product Browse Use Case in 51黑料不打烊 Journey Optimizer for your brand. Thank you for watching!

Transcript

Hi, it鈥檚 Daniel. In this video, I鈥檓 going to show you how we set up the activation of our paid media campaign for the Intelligent Re-Engagement Abandoned Browse scenario. We set up this scenario on our retail demo brand, Luma. First, let鈥檚 review this scenario diagram. Eligibility for the paid media campaign begins when a customer views a product on either our website or mobile app. After the product view, we want to give the customer a little time. Maybe they鈥檙e going to make a purchase without a nudge. Maybe it鈥檚 a purchase decision, which takes a few days, and they鈥檙e still actively engaged with your brand. We don鈥檛 want to waste advertising budget on active customers. So we鈥檒l wait for three days, and if they haven鈥檛 engaged with our brand again, we鈥檒l enter them into our paid media campaign. We鈥檒l also send them a message from our 51黑料不打烊 Journey Optimizer Journey, which is covered in a separate video. So we show them the ad for three days, and then that鈥檚 it. If they engage or not, we want our paid media campaign to end. To execute this, we need an audience to detect the lack of brand engagement and a destination to which we鈥檙e going to send this audience. Let鈥檚 start with the audience. I鈥檓 going to show you the end result and then walk you through how we got there. We ultimately built three audiences, two which look for specific behaviors and a third which combines them. Let鈥檚 dive in. We started by tackling this portion of the diagram, looking for a product view, and then excluding people who engaged with the brand. Engagement with the brand being defined as anyone who bought something or even just came back to the mobile app or website. This is what our final definition looks like. If you鈥檙e new to building audiences, this plain language description is incredibly helpful to understand how the audience behaves. Now I鈥檒l show you how we actually built the audience. I鈥檒l start by dragging the product view event onto the canvas. Next, we add our exclusions, excluding people who made a purchase, excluding people who launched the mobile app, and finally, excluding anybody who visited the website. I鈥檒l explain why I didn鈥檛 just use the page views event in a minute. Also, very important note that I use the and condition in the exclusion to make sure none of these events occur. When choosing how to define these events in the audience builder, we need to know a little bit about how events are collected in the source systems gathering this data. And this might be different for your implementation. We pass event type commerce.product views on product pages on our website and mobile app, which is why I was able to drag that product view event into the audience builder. Those easy to grab events are dependent on the use of event type. In our web SDK implementation, we don鈥檛 pass event type web.webpage details.page views on every page load. On this product page, remember I鈥檓 passing the commerce.product views and there鈥檚 a limit of one event type per call. We do pass web.webpage details.page views.value equals one on every page, which is why I use that in my audience definition. OK, let鈥檚 resume building our audience. Now, looking at our diagram again, we see there are some time considerations. We don鈥檛 want the visitor to qualify for this audience unless they鈥檝e been disengaged for at least three days after the product view. Also, after six days, we want them to fall out of the audience and no longer be in the paid media campaign. There are a lot of places to add time constraints in the audience builder, and they each have a different impact. There鈥檚 one here, here and under here. For this use case, I added to the product view event. I add a rolling range of three to six days ago. The description down here is your friend to see in plain language if the time constraint makes sense. Now, one thing we realized is that we don鈥檛 want to be too strict about banning brand engagement immediately after the first product view. For example, if someone looked at one product and then right afterwards looked at some other products or went to the home page, really went anywhere else in the website or mobile app, we wouldn鈥檛 want to kick those types of people out. So this is where our other time consideration comes in. We only want to look for the absence of brand engagement beginning an hour after that initial product view, which gives a little buffer for the visitor to complete that visit or session. We add that buffer here before the exclusion. So that鈥檚 our first audience. We save it as a batch audience, which is entirely suitable because of the time horizon. Now, because of that one hour buffer, we need to be careful. We just created a blind spot and we don鈥檛 want people who make a purchase or add a product to their cart during that hour to qualify for our paid media campaign. We don鈥檛 want to spend ad dollars on people who just bought something from us and people who added something to their cart but didn鈥檛 purchase. We鈥檇 prefer to save them for our abandoned cart scenario. So we built out our next audience to look for product views in that same window of three to six days ago and then do not purchase or add anything to their cart within one hour. At first, we tried to build this logic into our original audience, but there is a restriction on sequencing exclusions. Now we can build out the third audience, which just looks for anyone who qualified for both of the other two audiences. Now that we have our audience, we can activate it to our advertising destination. The configuration is going to be different based on what destination you use. All advertising destinations require you to use something as an identifier. For people who鈥檝e never logged in to the website, a destination like Google DV360 might be useful. To do this successfully, you鈥檇 need to implement a sync container on your website and mobile app to synchronize identifiers. For people who have authenticated, you can use other destinations like Google Customer Match and then use a hashed email, phone number or mobile device ID as the identifier. If you haven鈥檛 yet configured a destination, here鈥檚 a quick overview of the process. You find the destination you want to use in the catalog and configure the destination. Now, many destinations require more authentication and account details than this one. Once the destination is configured, you can add audiences to it. Advertising destinations only share audience qualification. They don鈥檛 share profile attributes. So we can鈥檛 share the details of the last product the customer viewed. Now, I have a bunch of test scenarios I use to validate the behavior of this audience. But what you should see when you test on your own website and mobile app is immediately after browsing the website or mobile app, you should see the product view event captured in your profile. On the third or fourth day after the product view, you should see that you qualify for the audience and you should continue to qualify for the next few days. Remember, these are all batch audiences and will evaluate once a day. You can view the timestamp of the last audience evaluation by opening up the audience in edit mode. So if you viewed a product immediately after the last evaluation, it might take a little bit longer for you to qualify for the audience than somebody who viewed a product a couple hours before the audience evaluated. The audience qualification leads to the person鈥檚 qualification status being shared to the configured destination. And assuming you鈥檝e configured your paid media campaign, they will qualify for that. After six or seven days, the person should fall out of the audiences and then cease seeing the ad campaign. That鈥檚 it. I hope this helps you to implement the abandoned browse scenario at your company.