Speaker 0: Hey, everyone. Thank you for attending today’s session, five essential data configurations for marketing cloud engagement. My name is Sarah Smith, and I’m a marketing automation strategist here at Sercante. I work primarily with clients who use marketing cloud engagement as their primary marketing automation platform. Before we begin today’s session, I would like to give a shout out to our wonderful, wonderful sponsors. Without them, we would not be able to host MarDreamin every year for all of you marketers out there. So today’s goals. I’m gonna talk about how the subscribers list works with any kind of sync subscriber data. I’ll then talk about how the data relationships functionality works within marketing cloud engagement. We’ll move on to talking about system data views. I would also like to tell you all about the SEM log within marketing cloud engagement. And then finally, we’ll wrap up today’s session talking about contact models. So let’s begin. Being able to keep your all subscribers list in sync with any updated subscriber data. What do I mean by this? Well, first, let me tell you about what the all subscribers list is if you are not already aware. The all subscribers list is within marketing cloud engagement. It acts as, like, like, a kind of master list or the gatekeeper of all the email subscribers in your account. So if contacts are added, um, to lists within the marketing cloud engagement, they’re gonna be automatically also added to this all subscribers list as well. If you are adding contacts to data extensions within your marketing cloud engagement account, then they’ll eventually be added to the all subscribers list when they’re emailed for the very first time. So there is a slight difference of when contacts end up on this all subscribers list, but if you email them, they will eventually get on there. So what is the issue here? Well, it’s standard practice these days to use data extensions over lists within marketing cloud engagement. However, if you have updates that you’re making to any records within data extension, especially as it pertains to subscriber attributes, um, those updates do not automatically get updated in the all subscriber list as well. And the problem is that because the all subscribers list is that gatekeeper for any subscriber data, then you can run into an issue where you have an email address on a data extension, You send to that email address for the first time. That email address then gets added to the all subscribers list, and that kind of sets the record. Right? But what if you were to then update that email address on that same standard data extension? Um, because the all subscribers list email is not updated, the email still goes to the old email address and not to the updated one. How do we solve for this? Well, you can do it the manual way, which is to always make sure you’re importing information into the all subscribers list in addition to whatever updates that are being made on the data extension itself, or you can automate it. And because we’re huge fans of automation here at Certante, I would recommend that latter option. So how do we do this? Um, it’s a five step process that you’re setting up an automation studio. I know it sounds like a lot, but once you set it, you can kind of forget it because it’s always gonna be self maintaining and just run-in the background. So the first step is you’re setting up a SQL query that should be querying the kind of master data extension that you have of all your contacts and where they’re coming in from whatever external data source. Whatever wherever the updates to that subscriber data is happening, whatever data extension that is, that’s gonna be the the data extension that you query. And you’re gonna match it against the all subscribers list and collect any results where the subscriber attribute data is not matching. Typically, this will be for, like, email address, but say you also use, uh, opt out status this way as well, then you’d want to kind of pull in that mismatch. The second step of this automation is going to be a verification activity step. Uh, the reason why we want to put a verification here is if you don’t get any records from step one and then you try to perform step five of this thing, your import’s gonna fail and the automation is gonna fail. So we create a verification step just to make sure we have records to use from step one. And if so, then we’ll continue on to step three. If not, we’re gonna stop the automation in its tracks. Uh, step three, the activity step here. Um, it’s a data extract step. And what it does is it’s just gonna take everything from the query, all those results from step one, and it’s gonna put them into a marketing cloud safe house is what it’s called. This technically sits outside of your marketing cloud account. So you have to then bring that data back into your marketing cloud account in step four in a file transfer activity. Finally, once you’ve brought in that data back from the safehouse, you’ll then create an import activity where you’re importing the results into your all subscribers list. And that’s how you keep your subscriber data updated. Keep in mind that when you’re importing into the all subscribers list, it does require, um, at least three fields within that file in order for it to successfully update. And that’s the subscriber key, email address, and subscriber status. So make sure your data that you’re importing back in, that you have a value for those fields. Let’s talk about how to leverage data relationships to really extend your filtering capabilities within marketing cloud engagement. So typically within marketing cloud, I mean, there are two automated ways to build out data extensions if you’re not just manually importing in a list, and that is through a SQL query or by using a data filter. So, a SQL query produces a standard data extension type, whereas a data filter will end up producing a filtered data extension. A SQL query can join data from multiple data extensions together, so it does offer you the kind of advantages of having a lot more sophistication in terms of your segmentation and filtering. However, the downside of this is that you do have to know SQL in order to take advantage of that. Whereas the data filter, even though it just filters results from one data extension, it’s a lot more accessible because it kind of follows the Salesforce philosophy of clicks, not code. So it’s just the UI where you’re dragging and dropping, and it’s pretty intuitive. Both the SQL query standard data extension and a filtered data extension can be run ad hoc or can be put into an automation and run it can run-in the background. So it’s not just an either or relationship here, though. You can kind of use, um, data relationships functionality to kind of get a semblance of middle ground between a standard data extension that’s populated by SQL query and a filtered data extension. So, a data relationship is functionality that will create a relationship between two data extensions. So, it’s extending your natural data filter ability to include additional attributes from whatever data extension that you’re linked to. It kind of operates very similar to a Salesforce cross filter, um, if you’re familiar with how Salesforce reports works. You can see in my screenshot here, on the left, I have a data extension called Salesforce contacts. And then on the right, I have a data extension that’s called email clicks. Within this UI, I am mapping the two data extensions together, and I’m using the mapped field. The ID on the Salesforce contacts data extension equals the subscriber key field on the email clicks data extension. Those two values are the same. We can map them together. We join these two data extensions together. Now when I go to create a filter data extension from Salesforce contacts, I not only have all the field attributes for my parents’ data extension to filter off of, but now I have all the fields’ attributes for my secondary data extension to filter off of that email clicks. Right? You can kind of see that in this screenshot how that works there. Just a few things to note about this functionality is that when you want to use data relationships between two data extensions, one field at least one field from either data extension that you’re mapping together does have to be a primary key field. So remember that. It doesn’t have to be both, but you do need to have at least one. And then finally, because the ultimate result of this functionality is still a filtered data extension, you’re only going to be able to see the fields that were from the parent data extension. Even though the the event the eventual filtered data extension from the data relationship will consider the fields from the second data extension that it was mapped to, you won’t actually be able to see any of those field attributes from the secondary data extension within your kind of filtered data extension child here. Let’s talk about using system data views and how they can be a really powerful tool for segmentation and contact management. If you’ve used Marketing Cloud engagement for any length of time, you may realize that this view can be very familiar to you. And this is basically a standard email tracking report view that you can see off of any email send. It gives you a lot of great, uh, information at a glance, you know, the delivery rate, engagement metrics. You can kind of drill in deeper to some of these numbers and get an actual list of maybe the links that were clicked and who clicked on them. It kind of pulls it all together for you and one of you. Pretty great. Um, only issue is that it only gives you this kind of level of insight off of one email at a time. Well, what if I were to tell you that there’s a way to kind of get broader insight into your marketing, uh, email activities? And the way to do that is through what we call data views here in marketing cloud engagement. So what are data views? They’re basically data tables that can store up to six months of subscriber engagement and journey information. Some examples of standard data views within marketing cloud engagement include data, you know, data tables for subscribers, for any email jobs, any emails that were sent, a list of, um, who opened which email, who clicked on which link in which email, etcetera, etcetera. There are many data views available. But I bring this up because the real power of these data views is that they you can collect the kind of that data from those data view tables, um, through SQL. So what are some use cases for this functionality? Well, you can quickly create filtered data extensions, um, to act as exclusion lists based off of, say, email or mobile saturation, or opens or clicks. Um, you can kind of see an example of this here. You can segment subscribers who maybe clicked on a very specific link to send targeted communications on similar categories. So, for example, if I have a group of subscribers who clicked on an article about dogs in one email, you can then collect all those people who clicked on that link and send them an even more targeted follow-up email specifically all about dogs because you know that they probably have some interest in that. Uh, track VIP subscriber engagement interests. So you can kind of use data views to really track specific people, especially if they’re of any kind of significance or importance to your company. Follow kind of their their engagement activity within any of your marketing communications to really see what is engaging them. And data views are not only for just marketing activities. You can also put them to use for any kind of administrative or operational purpose. You can monitor spam complaints, spouses, or subscriber statuses. You can even monitor automation and journey activities within your account as well. One of the greatest uses for data views is for contact management, and the reason why I will strongly recommend that you put this in place now is because during the course of your marketing cloud engagement use, you will undoubtedly start collecting unmailable or unsubscribed contacts. Uh, the problem is is that those unmailable and unsubscribed contacts do not automatically get removed from any data extensions or lists that you have in your account, and so this can end up skewing your eventual reporting metrics, And then, more importantly, this is also still counting towards your contact limit. So how do you solve for this? Well, use data views to query for subscriber statuses, pull them all into another data extension, and then you can delete them from your account that way. If you have a Salesforce integration with marketing cloud engagement, you can go one step further to ensure that you’re unsinking those contacts, you know, from Salesforce to make sure they do not return either. I wanna move on to talking about what the send log is within marketing cloud engagement and what you can do with it. This is one of my favorite things about marketing cloud engagement. So what is the send log? It is, like almost all things within marketing cloud engagement, a data extension. Um, but this data extension stores ongoing records of send time data and subscriber specific attribute data as well. So, it’s very similar to the sent data view, but there are some key differences. For example, you can only create one send log data extension within your business unit. That send log, though, allows you to record error codes that may happen during the course of the email job. The event date field, which the sent data view also has this event date field as well, but you may discover that the data between the two can be slightly different. And that’s because the send log records when an email job begins, and the sent data view records when the email is actually sent. So that’s why the timing can be maybe slightly different. The send log, once you set it up, it will populate automatically, so you don’t have to power it with a query and automation or anything like that. Just set it up in your account, and it should start collecting records. But, of course, the best thing about the send log, in my opinion, is that you can modify it. You can’t modify any data views as they exist within marketing cloud engagement. You have to kind of create a separate query and data extension to really begin those modifications. With the sunblock, though, um, it will record any personalization strings or AMPscript variables that are contained within any of the emails that you send out. So if that variable is within your email and you have it as a field attribute on your send log, it’s going to record the value of those variables. Uh, some use cases for the send log, uh, faster debugging. So because we are recording error codes, if something goes wrong with your email job, you can kind of query the send log and find out maybe what went wrong there. Error error messages are far and few between between within marketing cloud engagement, so this is valuable. You can track KPIs on dynamic content with AMPscript variables. And and similar to this, you can also kind of conduct multivariate testing with those kind of AMPscript variables or personalization strings. And then, of course, with the availability of variables, you can do even more nuanced tagging for reporting and segmentation. But my favorite thing about the send log is that you can create what I think has been called the ultimate view into your marketing cloud activities. And what this is is you’re combining your send log with your data view tables to create this ultimate view that is consolidated, comprehensive, um, can be sliced and diced with filter activities. And then you can also export this ultimate data extension as a flat file for any business intelligence or data vis tools. You can kinda see here in the screenshot how we’re using a query to join all those tables together to kind of create that one ultimate data extension. Finally, I’m gonna wrap up today by talking about setting up proper contact models for your journeys. What is a contact model? Well, it is an entity model that establishes the relationship between data extensions within marketing cloud, and it’s all hinged upon, you know, what we call the Marketing Cloud contact. The Marketing Cloud contact is your subscriber, is your contact from which all kind of marketing engagement data flows and to whom you are, you know, sending all of your marketing activity upon, I guess. So being able to build out this model within marketing cloud kinda lets you map out how all of your various data tables are connected to each other. It’s very similar if you’re familiar with Salesforce, the schema builder, and how all those objects within Salesforce are connected to each other. You can find the contact model within audience builder within Marketing Cloud Engagement. Uh, the cool thing if you have a Salesforce integration is that once you start syncing in those Salesforce objects, the contact model for Salesforce gets set up automatically within Marketing Cloud. And if you have more than one business unit in your account, we typically recommend that you’re syncing your Salesforce, um, to the parent business unit, so you’re only syncing it to one business unit, and then you’re sharing that, uh, access across your children business unit. So the sync only happens in one place and gets shared across the children. The only issue with this, however, is that while you’re setting up your sync within your parent business unit, the contact model gets built automatically. The same cannot be said, though, for your children business units because the sink is not directly being built out there. Therefore, you are going to have to set up that contact model manually with any children. Well, why go through all that work to even do that? And the answer is because of journeys. If you really want to leverage contact data within journeys, they have to be within the contact model. If you are sending tracking data back to Salesforce, those data extensions also need to be within the contact model. There are two different places where data extensions are stored within your Marketing Cloud engagement account. The standard data extensions folder, um, really houses all the data extensions that are accessible for journeys, and therefore journey contact data. The kind of drawback of this is that if you are doing single sends and just using the send flow process, you cannot, uh, have tracking data sent back to Salesforce from any data extensions that are still that are stored within the standard data extension folder. So that is the one drawback there. Conversely, any data extensions that are stored within the Salesforce data extension folder, You can have tracking data automatically be sent from marketing cloud engagement to Salesforce from any single sender ad hoc, like, email that you’re sending through the send flow process. Conversely, though, any data extension stored within a Salesforce data extension folder cannot be used for journeys. So Journey Builder will not be able to access any data extension within this folder. I’d like to end today’s session by just, uh, summing up everything we learned today. So, we talked about using automations to keep your data extensions in sync with the All Subscribers list. We talked about how to use data relationships to create a link between commonly associated data extensions, really to extend your data filtering capabilities. We discussed how data views can kind of give you granular insight into your email metrics, can kind of allow for greater filtering and segmentation, as well as even just plain old admin tasks. We’ve talked about the send log and how you can kind of enhance that send log to really create an ultimate view into your marketing activities. And then finally, we talked about how the contact model works, and especially as it relates to leveraging contact data within journeys, and how it’s useful for any kind of tracking data that needs to get sent back to Salesforce. If you want to learn a little bit more about any of the these things that I talked about today, I know we didn’t get to really delve too deeply into any of these topics. I do have some additional resources here, um, both the official documentation from Salesforce, but also from some really great Salesforce developers, um, who I always tend to consult whenever I have a question or issue within my own work. Thank you, everybody. I hope today’s session was really helpful and beneficial and that you’ve learned something new.