ÃÛ¶¹ÊÓƵ

Transcript

Hi, this is Daniel and in this video I’m going to show you how to set up the ÃÛ¶¹ÊÓƵ target destination in Realtime Customer Data Platform so you can begin sharing both segments and profile attributes from real-time CDP to target to personalize your websites, mobile apps, and other connected devices. These are mostly administrative tasks needed to get the integration up and running. In other videos we’ll cover how to actually share and use the segments and profile attributes. The setup is easy and you’ll see it’s just a matter of checking various boxes and pressing buttons, but they’re spread over a few product features and depending on how your company manages user permissions it might require a few people at your company to complete these steps. So the features we need to configure are data streams, merge policies, and destinations. First let’s enable a data stream. To get the most functionality out of the integration you should implement the ÃÛ¶¹ÊÓƵ Experience Platform web and or mobile SDKs which use platform edge network and data streams to send data to target. You can still share segments to target if you’re still on an older SDK like ATJS, but the segment qualification won’t happen on the edge and will be a little slower. Of course ATJS doesn’t use data stream so if you’re still using that library you can skip this step. Okay so I’m in the platform interface but you can also do this in the data collection interface too. You need to have permissions to view and manage data streams to complete this step. Okay so first both target and experience platform need to be included as services in the data stream. Second in the experience platform service you need to check these two boxes for edge segmentation and personalization destinations. Now I’m doing this in a dev sandbox and you would need to repeat this for any other sandboxes or data streams in which you’re going to use the integration. That’s it for this step. Next let’s make a small change to a merge policy. To complete this step you need to have permissions to view and manage merge policies. In experience platform I’ll navigate to profiles in the left navigation and select the merge policies tab. A merge policy creates a view of a profile specifying which data sets are included and how to prioritize overlapping fields. You can create multiple merge policies that create different views of a single profile but only one merge policy can be selected as the default and only one can be used with edge segments. To keep things simple for your marketers I suggest just activating your default merge policy for edge which you can easily do by enabling this active on edge merge policy toggle and then clicking through the workflow to save the policy. When marketers create segments that evaluate on the edge the segment definition needs to use this active on edge merge policy. Let me just show you quickly in this segment builder. You see here under the gear icon you can see the merge policy used by this segment. So if you hear from a marketer that they’re unable to save an edge segment it’s probably because they’re using the wrong merge policy and that’s why it’s easiest to just enable the default merge policy for edge. Again another simple but important configuration. So finally I’ll set up the ÃÛ¶¹ÊÓƵ Target connection and a destination. For this I need permission to view and manage destinations. All you have to do is select the connect to destination button and it’s going to connect to the ÃÛ¶¹ÊÓƵ Target account that’s in your experience cloud organization. This checkbox will subscribe you to alert notifications if a certain threshold of profiles aren’t getting sent to target due to missing attributes or consent violations. You can subscribe to them later as well. On the next screen it’s going to ask me for a name and description as well as the data stream id. For the data stream id I’m going to select the one that I just enabled with those two check boxes. Then I’m asked for the marketing actions used by target. This is a configuration setting for every destination and it helps to automate enforcement of your organization’s data governance policies and your customers consent preferences. It’s basically asking how do you use target which might be slightly different for each one of you. I’ll check a few options and that’s it for the destination and remember you can set up additional destinations for your other data streams and sandboxes. In other videos I’ll show you how you can activate segments and profile attributes to target and use them to personalize your digital properties. So thanks for listening.

Transcript

Hi, it’s Daniel. And in this video, I’m going to show you how to share segments and profile attributes from ÃÛ¶¹ÊÓƵ Realtime Customer Data Platform to ÃÛ¶¹ÊÓƵ Target and custom personalization destinations. Let’s start by creating a segment and experience platform. I’ll go to the Segment Builder and select Create Segment. Segments default to batch evaluation, which is the slowest method. So let’s start our segment definition by selecting Edge Evaluation. When someone visits your website or mobile app with platform web or mobile SDKs implemented, their event data is sent to the platform edge network, where their profile can be evaluated for qualification into these edge segments for same page and next page personalization. OK, so I’ve defined my segment, and I’ll save it. When saving a segment, there are a few messages you might encounter. You might see this message if you’re not using the correct merge policy. You can see the merge policy a segment uses by selecting the gear icon. And this merge policy must be set to active on edge. That’s covered in a configuration video. Segment definitions that are too complex for edge evaluation might result in an error like this. There’s a great piece of documentation that spells out all the types of segments that qualify for edge evaluation, which you might want to review if you encounter this message. I’ll close this segment and activate to my target destination. This workflow is the same for custom personalization destinations. Next is the mapping step. Here’s where you can select profile attributes to send to the destination. So this is sending actual info from the profile, like first name is Daniel, individual attributes like that. So you can select any attribute by either typing it in or selecting the icon to open a dialogue, and then you can select the field. These attributes will be sent to the destination only for people who qualify for one of the segments shared to it. So in my example, only for people who have more than 100,000 loyalty points. So what you might want to do if you want to share these attributes for as many visitors to your site as possible, create a very basic segment that almost everybody is going to qualify for, and then you’ll get the attributes. So once I’m done, I click Finish to complete my segment and profile sharing. One screen you might run into at this point is for a data governance policy violation, which looks something like this. It means your segment or profile attributes contain fields which aren’t allowed for use with this destination according to the governance defined by your privacy stewards. It’s there to help you use your company’s data appropriately, and you’ll need to work with your colleagues to figure out if there’s a path forward to share that segment to your destination. The last thing I want to share with you is how to update the destination. It’s easy enough to add or remove segments. You’ll figure that out on your own, but it’s not as obvious to add or remove attributes that you’re sharing. If you add a new segment, you’ll go to that mapping step again. But what if you want to modify the attributes without adding a new segment? So to do that, open the destination and select View Data Flow. Then under the three dots, select Activate Segment. So you’ll see your segment list, and then just click Next, and that will take you to the mapping step. And you can add or remove attributes and complete the workflow. All right, so have fun sharing segments and profile attributes to ÃÛ¶¹ÊÓƵ Target and your custom personalization destinations.

Transcript

Hi, it’s Daniel. In this video, I’m going to show you how you can use ÃÛ¶¹ÊÓƵ Realtime Customer Data Platform segments in ÃÛ¶¹ÊÓƵ Target. This video is geared to target users and assumes that the segments have already been created and shared to the target destination in real-time CDP. That’s covered in a separate video. I’m also going to assume that you’re a target power user. You know what segments or audiences can do in Target and how to use them in your activities. Also, ideally, you have Target implemented with Web SDK. That’s going to get you the fastest segment qualification. If you’re still on ATJS, you can still use the segments, but the user won’t be able to qualify for the fastest edge segments. If you’re on mobile SDK, you should implement Target with the ÃÛ¶¹ÊÓƵ Journey Optimizer decisioning extension for the fastest results. So let’s start on the audiences list. Segments shared from real-time CDP will show as ÃÛ¶¹ÊÓƵ Experience Platform audiences. And by opening the info icon, you can see details like the segment ID, which is useful for debugging, the description, which sandbox it was shared from, and the activities in which it’s being used. All segments are shared to the default workspace, but you can easily move these to other workspaces in Target. Then, of course, you can use them like any other Target audience. You can target an experience or an activity to the audience. You can combine them with other audiences. You can use them as reporting audiences. And they’ll factor into automated personalization and auto-target models. The audience qualification details will also show up in Target traces. Let’s quickly look at a common debugging scenario. I’ve launched my activity, which is targeted to my real-time CDP segment, but I don’t seem to be qualifying for it. I’ll open the Experience Platform debugger, log into my Experience Cloud org, and start an Edge Logs session so I can see the details of what’s going on. I’ll look for the Target traces and dig into the unmatched activities list. I conveniently named my activity unmatched activity. I can see that I’m not in the activity because I haven’t qualified for the audience. So to debug this further, I would need to go into the platform interface. And I can look up my profile by taking the ECID out of the network response of my interact call. And then I’ll go into Platform. I’ll go to Profiles in the left nav and then click on the Browse tab, select ECID as my namespace, and paste in my ECID. So now I’ve looked up my profile, and I can confirm that I’m not in the audience as far as real-time CDP is concerned. And if I look at my profile attributes, I can see that this profile doesn’t have any loyalty points associated with it at all. So of course, I’m not qualifying for the audience. So I guess I’ll have to spend $100,000 on yoga equipment on the Luma website and then test again. Namaste, everyone.

Transcript

Hi, it’s Daniel. In this video, I’m going to show you how you can use profile attributes shared from ÃÛ¶¹ÊÓƵ Realtime Customer Data Platform and ÃÛ¶¹ÊÓƵ Target. This video is geared to target users and assumes that the attributes have already been shared to the target destination in real-time CDP, and that’s covered in a separate video. Also, you must have target implemented with the Web SDK or Mobile SDK with the ÃÛ¶¹ÊÓƵ Journey Optimizer Decisioning extension in order to use profile attributes. ATJS or Mobile SDK with the ÃÛ¶¹ÊÓƵ Target extension do not support sharing of profile attributes. The capability this feature unlocks is online personalization with known customer data. Here’s an example of what I mean on the Luma site. So I am authenticated as Bartlett Leckie. All of these values here, Bartlett, Leckie, Gold, my join date, and loyalty points are all being shared from real-time CDP to Target. I logged in and Experience Platform’s identity service graphed my CRM ID to my EC ID. But wait, these are all loyalty system values, not CRM system. Well, I’m able to share these because my loyalty ID was already graphed to my CRM ID from separate data ingestion processes into platform. So I can output these loyalty system fields and create personalized messages on my website or mobile app using ÃÛ¶¹ÊÓƵ Target. So I hope this gives you a sense of how powerful this integration is, how you can use all types of data that you’ve ingested into Experience Platform and real-time CDP. So the first thing you should know since you’re target users is that the profiles shared from real-time CDP, they’re not stored in Target’s profile system. They’re stored on the platform edge network and Target has access to them. So they’re a little bit different. This slide shows the context in which you can and cannot use these profile attributes in Target. So this might change in the future, but this is the state of things at the time of this recording. Okay, let’s take a look in more detail at how the profile attributes can be used. Let’s start with HTML and JSON offers. I’ll go to offers and create a new offer. First, select your target workspace if you use those and name your offer. Okay, now there’s a nice helpful UI here to help you format the token replacement syntax correctly. So select ÃÛ¶¹ÊÓƵ Experience Platform as the source and the platform sandbox name it’s coming from. If you don’t know the sandbox name and you don’t have access to real-time CDP, you’ll need to ask your colleague who configured the target destination for this info. Then select the attribute you want to use and you can optionally specify a default value. And I’ll hit add and you’ll probably want to put some other content around that profile attribute and then hit save. So my offer is going to output something like hi gold customer or hi bronze customer. And if they haven’t joined the loyalty program yet, it would say hi valued customer. JSON offers work basically the same way. You’ll see that it throws in some escape characters. You can also use the attributes and redirect offers, although the default value for those does not work. Now let’s look at the VEC. Of course, I can pull in the HTML offer I just created, but I can also create freeform offers. Now there isn’t a little UI helper here, but if I know the syntax, I can just enter it in. And if you forget, just go back to the HTML offer screen and grab it. One other cool thing to be aware of too, if you’re a JavaScript developer, is that you can assign these attribute values to a JavaScript variable and then use them in conditional logic to do all kinds of fancy things. You can also output the attribute in a recommendations design with this syntax note the forward slash before the dollar sign. Okay, so those are the various ways you can use real-time CDP attributes in ÃÛ¶¹ÊÓƵ Target. I have one final point. This capability is great because it supports online personalization with known customer data, but with that power comes responsibility. So ideally your company’s privacy stewards have already configured the data governance framework in real-time CDP. So only profile attributes that can be used for on-site personalization will ever actually be shared for you to use in Target. But even with the attributes that have been deemed fine to use in Target offers, be sensitive to your customers’ expectations. For example, you know that once a user has logged in and sent an authenticated identity to experience platform, then known customer data can be sent to Target. But what you need to be mindful of is that these attributes will persist and continue to be available to Target even after the user has logged out. So see here now I’m logged out on my Luma home page, but I’m still seeing information like my first name, last name, all those same profile attributes. Is that weird? Kind of. Will your customers be turned off if you display attributes like this even after they have logged out? If so, here is a way you can handle that. So what I suggest is to first capture in an XDM field in your Web SDK implementation a field representing their authentication status. While I’m logged in, I’m passing a field userAccount.loginStatus equals authenticated. I use that to build a target audience and then I can apply this as a targeting condition to my activity. So only authenticated users will qualify for this target activity that is outputting these profile attributes. So when I log out, I’ll stop seeing those profile attributes on the home page. So I hope that makes sense. And wow, I think that is the longest video I have ever made for Experience League. There’s just a lot to cover with this integration and I hope you enjoy using it and I hope this video has been helpful. Thanks, bye.