Marketers are facing quite a conundrum today. On one hand, they're being tasked with finding creative ways to capture first-party customer data as a response to the pending depreciation of cookies. This means getting smart about collecting data from across the organization and activating it within their marketing automation platforms. On the other hand, they need to be extremely diligent about protecting their customers' data and using it responsibly.

Of course, this means investing in security to prevent things like data leaks — but it also means being conscientious of how your customers' data can be accessed and viewed internally.

In this video, Stephen Rosenfeld (VP, Architecture at Stitch) demonstrates how to best mask PII (Personally Identifiable Information) data within the Braze platform to protect your customers, while still being able to use customer data to deliver personalized messaging. This includes:

• Setting up a test environment
• Defining PII definitions in your security settings
• Testing permissions to verify masked PII data

‍

Transcript:

Hi, everyone. I'm Stephen Rosenfeld with Stitch. We're a marketing consultancy focused on enabling marketers to get the most out of their Braze platform. This video is a Braze the Bar video where we provide digestible insight into Braze functionality. And while Braze has a comprehensive list of marketer-friendly functionality, today I'm going to be focused on masking PII data within the platform to protect consumers. It's not an uncommon need for an organization to have to protect that PII data, even for those accessing the system. 

And so let's walk through that now. I'll go ahead and start sharing my screen. The first thing I wanted to talk through is just the environment that I've set up. So I have a PII test app group that I put together so that I can send in some test data and mock things up in the security settings of my company. I've set up all the PII definitions available, and then I've also created a test user navigate there. So I've created a test user, and this user has every permission except for viewing PII. So I want them to be able to do anything else except to view that PII-specific data. And so with that, all my custom attributes are marked as PII, and the standard attributes are marked as PII. And so let's see what the end user experience is within Braze. So I'm logged in under another window here that I'm going to switch to. And so you'll find here I'm logged in under my test user. And so let's start with as I went through and started identifying the specific pieces I wanted to talk about here, searching was the very first topic that came up. 

So when you are now searching for a user, I want to search for Stephen at Stitch.cx. I can't use email addresses to search any longer. If email address was not defined as one of the PII definitions, if I uncheck that checkbox, then I would be able to search by email address. But if a phone number was still selected, then I could not search by phone number. So it's specific to the field itself. Also, under user import, I am able to continue to import files. However, even if I'm the owner of the file, I cannot download any of the file imports, no matter what the PII definition is. This is based on my permission to view PII data. It is not dependent on what attributes are selected as being defined as PII. All right, so let's pull up another profile, though, so I can still search for users, I just can't use their PII field. So I have orange meerkat here, and you can see all of the PII data is masked here at the top. And then any custom attributes I have are knolled out as well, dashed out, or hidden. I can still see some city and language data, but nothing is identifiable. Really limited here as to what I can see and it actually does a great job telling me throughout the application that I'm viewing a profile with mass PII data. And so my perspective is limited by that. 

So the next piece I want to talk about is Segments. Segments functionality is highly impacted by the ability to view PII or not. Specifically, in the upper right-hand corner here where we discuss user data. So when I click on that, you'll see I have the ability to export a CSV containing user data. However, that export excludes any of the PII-defined fields, and there would typically be a second option here to download to CSV export email addresses. Because my user does not have the ability to view PII data, that extract is disabled. It is not driven by the fact that the email address is labeled as PII. It is simply that my user cannot view PII data which prevents that export from being available. You'll notice below this. However, I do have the ability to filter on PII attributes. So I can still narrow in on my audience and define that audience using PII data, but I cannot view the results of that set. And I can also look up users based on their user ID and say whether or not they meet the criteria of my segment. But obviously, here I can't view any of the PII data either. I'm simply saying whether or not an example user qualifies for the filters that were previously defined in the segment. 

Okay, let's move on to campaigns. So the campaign was an interesting one as well. If we look at all campaigns, I'm going to jump into my PII test. One of the key takeaways is that a user that is not allowed to view PII can still view PII through the lens of rendering a message if they have that permission. So remember, my user has all the permissions except for viewing PII within the app, so they can view PII if they are rendering a message. So here I've created a webhook, and you can see I've got two fields that are defined as PII in my definitions. And if I go to test, I can get a random user and see the email address and phone number for that user with intent. A user that has the ability to create campaigns can go in and view these things, and I could select an existing user or a custom user as well, or generate my own. But it's important to understand that someone with the ability to go in and create campaigns and generate previews is able to view any of the PII attributes exposed through that liquid, right? And similarly to segment, if we look at the target audience here, I can still filter on PII attributes here from the target audience of my campaign, and then we're going to find similar behavior in the canvas section. PII attributes can still be used for things like decision splits or messaging. And here's another example. So here I'm only printing out email addresses, but if I go into the test, I can get random users and view some random users email addresses over here on the left-hand pane. So all this leads to what considerations should be made when marking someone as not viewable for PII data. And there are some things that are certainly best practices around permissions, but if you have individuals that don't have need to be able to render content or see PII data, you'll want to make sure you've disabled both of those things. It's not uncommon at all for someone that is composing messages to need to be able to see that PII data to ensure that the message context is appropriately displayed. So I think that the approach here is correct in that liquid is going to show those attributes and that the user should only have permission to perform those previews if their job function requires it. 

Thanks for your time today. I hope you enjoyed this Braze the Bar session. Look forward to seeing you again.

‍