[Music] [Sal Daoud] Thank you for coming in today.
My name is Sal Daoud. I am in the Product Management Team in Adobe Experience Platform.
[Danny Miller] And my name is Danny Miller. I'm in Customer Engineering. I'm architect that basically guides a lot of our partners and consulting team in really complex, gnarly implementations. And he's my partner in crime when we help many customers like you navigate the complexity of representing your business, let's just say, in configuring Adobe Experience Platform. So how many of you today attended the keynote in the morning and saw the Marriott Global VP talk about how they represented or unified their profile across five brands globally? That wasn't a perfect use case for what you're going to hear about today. Today in our session, we're going to describe and show you how you could actually achieve the same. Plus we will discuss additional ways or options that we have as part of the features of Adobe Experience Platform that enables you to actually configure your platform to support multi brand or multi regions use cases and grow your business.
But the challenge is it gets really complex managing customer data across brands and across regions. You're constantly balancing multiple challenging dimensions as you evolve, as complexity increases, as you grow your business. And, today, we'll talk about some of these key challenges and how we will help you navigate those. So at the heart of it is potentially someone likely like you that's sitting here in the audience that's constantly thinking, "How do I do this? How do I manage my brand requirements, my regional demands, data governance? How do I create this unified profile and provide data insights in a world that only gets complex as you actually expand and onboard more use cases," because you got to think when you're first starting your implementation. You're probably thinking of seven use cases or so. But you know that you have many other use cases that you want to implement for potentially multiple business units. And then the efficiency here becomes something that you have to pay attention to. It becomes challenging to manage and balance the complexity of managing all these regions or brands that require certain either to operate autonomously, is that another way to think about this or uniquely? Maybe each brand has some unique requirements to that specific brand that you need to consider as you're implementing or deploying your Experience Platform. You'll also be facing some challenges related to consistent customer experience. And what I mean, what we mean here is not necessarily the intent to create one campaign or one messaging that fits one for all. This is not necessarily the case. The situation here is how do you still leverage consistently the data, the shared data that you have for brands or regions, at the same time, create this unique experience for a brand or an audience specific to a region. And on top of all of this, you're also thinking of governance. How do I govern my data that I have in the Experience Platform? Who should have access to the data? And if they have access, what parts and what pieces of this data that they should access for the purpose of their role or their persona? Let's just say and we'll talk about that in a minute. So it can get complex with scale. And we want to make sure we today provide you as much information that can help you navigate this complexity. And then we don't-- That's why I asked you about the Marriott today because we've been working with many enterprise customers that are global and some that are just local to a specific country. And as you can see, in our presentation today, we'll cover topics that's not just relevant to like the Marriotts of the world, which was the use case today, which actually it's more likely the one in the middle, which is a global company that we manage to unify their multiple brands across different countries while respecting governance. But we'll also-- It will apply to financial services company that we've helped as well, which their intent was, I just want my profiles globally to operate on one single profile because I want that complete understanding of my customer accessible available for my marketers, for my data analysts that are going to act on this data so they could derive either actionable insights or actionable activations to personalize experiences at scale. At the far right, you have a balance of both. It gets a little bit more complex as you start operating a brand and a region. You may have customers who want to operate on a country level, but within the country, you may also if you're a retailer, you have multiple brands that you still want to create some unique experiences for those brands within these countries. So as you could imagine, it could really get complex if we don't start or architect the implementation from the beginning to be set for success for the long term. And we're hoping today we'll help you understand more how to address and face these challenges.
How do you start? One of the questions that we get when we talk to customers is, where do we start? Do we start talking to our IT? Do we start talking about to our marketers? Or what key personas in our organization is going to help us decide or make these decisions? And we always advise customers to really start with just the business structure. Maybe don't look at your technical or IT convenience in this context. Here, you need to really think of your organization. You need to think of your business. Are you a type of organization that is centralized when it comes to marketing or decentralized? Centralized means you may have a marketing team that actually creates audiences for all brands and for all regions that marketing team has access to all the data. Decentralized types of marketing it could be-- You may have marketing teams that specialize in certain region or certain language. A group of German speaking countries, for example, may have a specialized marketing team that just focuses on that type of an audience. So thinking of your business structure helps influence how you architect the deployment. Remember, if you're familiar with Adobe Experience Platform, we have capabilities that allows you to isolate the data, like the sandboxes you saw up top that we will talk about multiple sandboxes versus a single sandbox. So such decisions or such discussions here will help determine which path do you follow, and within each path, also, what might you need to pay attention to really successfully deploy Experience Platform. Another key requirement is data. What level of data sharing? Not all customers-- Some customers do really want to isolate the data and not share it or they want to share it, they want to still have that unified profile, but they may want to keep a piece of this data not necessarily isolated but protected. Maybe it's PII. Maybe you're working with an agency and you want to only give them certain access or a brand and you want to isolate the brand's data in a certain place or only have certain people access that data. So understanding your data requirements and data sharing is key because it's going to also influence the compliance here, right? So in combination of thinking if compliance needs would help you decide on, in some instances, you may have regulatory reason where the data has to be isolated. I'll give you an example. If you go to a pharmacy and you buy a Snickers bar and you buy medication. You may not want to have this data in the same place. You may be via compliance reasons, you may have to separate this data and keep it isolated. So thinking about potentially the structure of your business, your data sharing levels, your compliance, and then the amount of autonomy that you want to have for your teams will help you make some decisions as you expand and build your Experience Platform.
People sometimes tend to forget also that growth trajectory.
Customers start small, but they grow their business. Customers evolve. You add brands or you may add regions or you may add additional BUs if you're operating in a multi-BU space. And if you don't really think two, three years down the line of where potentially you may be, or how many additional use cases, or BUs, or brands you want to onboard, you will face some challenges. So it's good to think through the overall big picture, start breaking it down, which will help influence such decisions. But with that, Danny, I mean, do you have any ideas, how can we structure or can you give an idea how can we structure Adobe Experience Platform for an efficient implementation? Sure. So one of the things that we see is part of what comes to the forefront is a centralized versus a decentralized structure. Sal touched on it a little bit there when he was referring to do we have an enterprise style team that is executing everything in one place? Do we have local, let's say, decentralized teams that need to execute within the context of their area and brand or region? And this plays a part of how we think about when we start to consider a multi-sandbox versus a single sandbox scenario. Along this front, we also have to start to consider from a data-sharing standpoint. Sal also touched on this. Do we want to encourage data reuse across these different groups of regions and/or brands, or do we need to do a more of an isolated approach? More isolated the data is, the less easy or harder it is to do data sharing across these different areas. But of course, compliance will always trump everything in terms of if compliance dictates in certain way that data must be isolated, then we have to take that in consideration in our design and see what does need to be isolated and what can be centralized. And do we have a capability to accomplish a little bit of a hybrid of both? So tell us a little bit, Sal, about the key personas that you've seen. That's important as Adobe applications are designed for more than one persona. They have features and functionality for specific personas, but not all personas are equal. Not all personas in terms equal, in terms of what access level they should have or what function they operate in. You need to think of your personas in context of your workflows, so you can successfully build roles, and we'll talk about those in a minute, and permissions around these personas which will dictate the experience of a persona when they log into the Experience Platform. If you're a marketer, for example, you may not need to look at schemas or you may not need to look at ingest the data. You have a data architect for creating schemas and ingesting data. Similarly, if you're a developer, you may never activate an audience or create an audience. So you need to think of the personas that you have within your business structure, within your organization, and then start, based on that, building their roles and decide the workflows that they should follow. With Adobe Experience Platform and applications, when you define a role and you say this role has permissions to or does not have permissions for schemas, for example, their experience within the Experience Platform itself, when you log in, you're not going to see schemas on the left. So you optimize the experience of your persona based on the permissions that you grant the persona. So more permissions, they'll see the whole set of functionality which can overwhelm individual users potentially, and with less features and functionality geared and planned towards the persona is much better, let's just say, for effective, productive team that works and focuses on marketing. So here, I'm giving just a couple of examples where if you have a marketing team that specializes in Germany versus France and you may have also-- We talked about the balanced approach, centralized and decentralized, you may have both in some certain situation. You may have a centralized team or a global, if you're a large enterprise that operate on multiple countries, you still have the global enterprise company that wants to still operate and see all the data across all the countries. And you also potentially will have a marketing team for Germany or for France, and for that, what we encourage you to do is build roles specific for these marketing teams, specialized and not specialized, and then decide what they can access, what they can see via the family of permissions that we have in place.
And now, I want to ask, Danny, what's the best strategy, a marketing department that is centralized, how can they take action on all our unified profiles worldwide, which was similar to the financial services company we've had up in the front? Great question, but it's always usually followed up with a separate question, which is this, but I still want to have each geo and/or brand have its own "area" where they can do their thing without being held up by necessarily a centralized enterprise kind of overload, if you will. And so what we see is a single sandbox versus a multi-sandbox. And we've thrown the term sandbox around a few times, so for those of you who aren't familiar with platform, it essentially, a sandbox, is you could think of as a container. This container contains all the objects that we might create, such as journeys and audiences. It also contains the data that can be accessed within and only within that sandbox, so when we use a single sandbox approach, what we're essentially saying is I'm going to centralize all my data and objects and workflows in one spot, so what does that give us? That allows for a more global operation across all my brands and geographies, and it allows me to bring together all that information into one single view of the customer across these brands or regions, and this enables a lot of things around, for example, a centralized place to do all my segmentation. I can cut across brands, I can cut across regions, I can mix and match. There's no need to move data around because it's already been centralized into one place.
But it also says how do I ensure that there's a data model that does not become chaos, can't allow everyone to just do whatever they want. There does need to be some kind of a core data model that we agree with our regions and brands how we're going to, what I like to call, do the city planning, so I might establish certain ways where I'm going to agree with these, how they will extend and implement and integrate their piece of this overall puzzle. But it does lead to various questions, which is, "Well, I may still want to allow some people to see the whole thing and some people to just see pieces," and so this is where some of the controls and governance that Sal just mentioned around the access control. And so all these you basically take into consideration as we bring this together into one sandbox. So from an implementation standpoint, your architecture would roughly look like this, where I have all my right sources, you've seen diagrams like this before on the left side here from Analytics to various enterprise sources and SDKs. I would load that into platform into one production sandbox. I might have other sandboxes for things like dev and stage and things like that, but one production one. And from here my native apps that are built on top natively in platform would access each of those sandboxes directly, and there's what we call sandbox-aware. Some of the other tools here we also would integrate with each of the sandboxes, and some of them do it a little differently than others, right? Target has their concept of workspaces, I believe it is, Audience Manager I believe puts things in folders for the sandboxes. Marketo has a connector, that it points to a specific instance, so each one of these things, you would work with what those are to make sure that those are being accessed appropriately, but since I have one production sandbox, it's a fairly straightforward implementation across these.
So what might it look like from an activation perspective? So from an activation perspective, I might have my enterprise core attributes. These are things that we would agree as an enterprise, they are shared and central across all the brands. Then I would allow each one of these different brands to have their piece of the puzzle. In this case, I might have membership tier as an attribute of brand A, whereas purchases for yesterday was an event that happened in brand B, and I could pull all that together in a new campaign that I execute for brand C. And so this again is encouraging reuse at a very low level, access to the attributes that somebody might be interested in executing a campaign in a different context without having to move data around because it's already been centralized. So this again encourages reuse, and cross-sell is a great example of this.
So how does this actually look like when we go into the schema? This is one example of how we might do this. Another example could be doing it slightly different, which I'll go through. Here, I'm using Adobe as an example. We're all familiar with the Experience Cloud. I might put a context node here for Adobe, and under that, I put another context of the Experience Cloud. And within that, I will have developed a whole schema of fields that are attributes that are relative and specific to people who are in the Experience Cloud. I might have a dataset there to capture all my data, and so you can see I'm allowing that one business unit to develop anything and extend it within the context of the Experience Cloud node, and therefore if I extend that out, I would add another one for the Document Cloud, I would add another one for the Creative Cloud, and then each one of them would have their own set of schemas or datasets. I could do this for those out there who know platform well. I could build all this in one uber schema or I could have multiple schemas depending on what my needs are. Usually this is set up in multiple schemas, each one having their own dataset, and then I would hand over to that appropriate group the ability to load just their dataset. And I would have a core set of attributes that I talked about before with its schema and its dataset, and the union view would bring all this together in profile so that I could execute against one unified profile. So this allows flexibility and autonomy while still allowing, what I call, city planning. So I'm laying out that one business unit. Over here it's going to have a hospital and a school, and this one over here is going to have some government buildings, and I don't really care per se what they do there when they actually build it. I just know it's going to go there. And as long as we agree to that in terms of at an enterprise level, I can provide some flexibility, autonomy, and speed without having to hold them up through enterprise level governance, but I would do that for those centralized enterprise level attributes, so flexibility and standardization come together.
So, Sal, while this is all great and everything, what if I only want the people in that one brand or geo to see the fields and audiences that are appropriate to them? I don't want to open up everything to everybody. Yeah, that's fair. That's a really good question. How do we do that? I mentioned earlier we have access controls. We have a family of access controls. The common one that you probably used first is the role-based access controls, and then not too long ago, recently, last year, we've added an additional attribute-based access controls for that purpose that Danny was just asking, which is I want to be able to restrict certain nodes for access, or even within a node, a certain field in that schema, which of course will apply on the data that is going to be based on the schema. We could actually restrict access on the individual field. So if you have social security or a medical condition, whatever that may be, you have the power, or a brand node or a region node, as Danny was expressing, not necessarily the entire region node. We're talking about the stuff that's not core common to the profile. Maybe the name is not necessarily brand specific, right? The name is a name, email potentially, but the idea is you have the power to use attribute-based access controls, and to be specific, field-level access controls, which is a subset of attribute-based access controls, to actually label these fields. And once you add a label, you could then apply a policy that says if my role has that same label on it, we match it. It's a match-based policy. And if you have the same label on the field or the node, it will allow you to see the field or the node. If you don't, you won't see it. So that's how we actually allow you to do this. And you could apply more than one label. You're not restricted to one label on a field. You could actually add multiple. So you have the agility, let's just say, to classify your data based on sensitivity and then action on it on a per role. And of course, users that belong to that role would not have access to these specific fields. Now, I said a family, because on fields, this is great, meaning it allows a use case that enables a customer to label the fields. The lights are flickering, so they're trying to put you to sleep.
For a different type of a use case, we have another family of access controls, which is OLAC, which is object-level access controls. For this specific use case, we enable the customer to actually label also segments. Remember, we talked about centralized and decentralized. So imagine you either have a combination of both or one centralized team that builds audiences. They can, at the time of creation, label the audience Germany, which means if you are a marketer with a role France, you're not going to see an audience that has a label Germany. So we yet also optimized what you see in the Experience Platform. We filtered the audiences that you're not supposed to see based on this labeling. What's also critical to understand here is activation. Here you're trying to also prevent potential user error of me activating an audience I'm not supposed to activate. So if you want to restrict access to specific audiences like this, maybe it's a paid media audience, not all marketers should activate the paid media. That's one way where you would restrict access to specific audiences. So notice we're layering the functionality. It's not one feature that's going to solve for the multi-brand, multi-region. You're layering it down for the purposes of different personas in order for them to get the job done and achieve a certain objective.
So now, what if I want to make it even more complex, Danny? What if I want only a specific geo or a brand? I want them to build only specific audiences for regions and only activate on a per brand or a per journey, even if the audience has profiles from multiple different brands. Good question.
So we have basically two tools or levers by which we can accomplish this. This one is fairly easy and simple to understand in that you can build audiences that basically filter down to say person must be in, for example, the United States. So now I have a United States audience, and then I just include that audience in all the subsequent audiences I build. It's easy to understand, it's easy to train on, and now I have a way, and I just build a whole bunch of those for however many regions I have or brands that I have. The downside to this or the trade-off really is now I have to ensure or remember that I'm doing this every single time. The upside of this, though, is that when I look at my audience size, I know that that audience size has already been filtered for the region that I'm going to activate against. And so I don't see any discrepancy between activation and audience size. Why do I bring that up? Well, the next lever that we really have is we can filter at the time of activation. What this is is utilizing consent policies in a slightly different way. So I can design consent policies for more than just consent. What I can do is essentially have a consent policy that says, whenever the marketing action is equal to, for example, the email and marketing for the United States, I can apply this by checking to make sure that that profile is actually from the United States.
So therefore, when something starts to go out the door, it's going to filter down just to those people. So if I start with a generic large audience of everyone who purchased yesterday and tried to send an email out to apply this consent policy, I'm going to have a huge discrepancy between the amount of profiles I thought I had and the amount that actually go out the door. So by including the filter in the segment, my segment size is equal to the activation. So they're just trade-offs. This one, I don't have to embed in every single audience, so that's nice. But again, if I don't have it in the audience definition, some people get confused as to why the audience is so big and so few people actually receive the email.
So, Danny, I'm going to make it a little bit more difficult for you. Lovely. This is nice. I mean, it's like a happy day scenario. But the real world is that there's some additional complexity. Complexity here in terms of what if you're really required to have isolation, 100% isolation? I don't want profiles, I don't want my audience to include data or audiences from two different brands or two different regions. And I don't have the need to share. I'm completely operating autonomously on my own in a certain country or a certain brand. How can we do this? Great question. And this is really where legal starts to step in. But for us, generically, we call this the multi sandbox approach. So what we have here is we basically have a need to compliance saying we need to separate this data. So at the sandbox or data layer, we need to have the data persisted in isolation of one another. So in order to achieve this, we use sandboxes and we separate the data. But what this also does is it asks us, once I have multiple sandboxes, how do I do my marketing? Do I have a centralized enterprise level sandbox that executes, let's say, brand-level, cross-global campaigns like we saw with Marriott, right? Or do we have multiple regional sandboxes or brand specific sandboxes where they execute campaigns within each one of those specific to that? I also have to keep in mind my data and my workflows now become isolated because, remember, all the objects in the sandbox are specific to that sandbox. So my ingestion may need to be duplicated across a centralized enterprise sandbox and a regional or brand sandbox. Same thing with my workflows, right? I have different journeys that I may want to do the same thing, just in multiple places because now my data is in multiple places. So I need to have the journey in multiple places. And of course, this leads to increased management complexity of making sure that all these things are being loaded into all these different sandboxes, synced where appropriate, and autonomous or separated where appropriate. This does provide a lot of brand and regional flexibility that you brought up that allows them to execute because essentially we have a full-blown sandbox now by which that team monitors controls and is able to do what they want.
And a lot of the access controls still apply here. They may be a little looser because we have already isolated things at a sandbox level, but they still apply. We would want to take into account whatever we were thinking and applying it at the sandbox level.
So when we think about it at a diagram level here, you almost have what looks like this, is where I have some enterprise data, okay? And I might load it into an enterprise level sandbox, and I just put the full thing there. But I have these regional or brand specific sandboxes, so I might take the core data, those enterprise attributes we talked about, and I would put them into those regional sandboxes. At the same time, I might have some enterprise level data where I need to slice up so that they just see their specific area of the data for that brand or for that region and put it into the appropriate sandbox. So now they have a piece.
Because we have independent sandboxes now, though, each of those brands or regions is able to load their own data, and it will just sit in that one sandbox. It doesn't get replicated to different sandboxes. As a result of this, we may find ourselves in a certain scenario where, though, we have our marketing campaigns that need to execute. So we'll dive more into that later, but at a high level, I may want to be able to take things and share audiences in such a way where I have some sensitive data maybe that's local-- Sorry, in the enterprise sandbox, and I need to get it to a local or regional sandbox. And so I can do some audience share there, so I'm not really sharing the data per se, just that somebody exists in an audience. And then, of course, if I want to do it in reverse, I can't, where maybe I build an audience in a regional sandbox that's specific to data that exists there, and I need to get it back into the centralized enterprise sandbox, but I don't want to move the sensitive data, so I could just share the audience in such a way so that it comes up to an enterprise shared area.
From a implementation approach, you'll see it looks similar here in that I still have all my sources, and I still have platform, but now I have all these different sandboxes that are also production sandboxes, so I might end up with a region sandbox for each one of these. And as a result, you could see and imagine all my data sources now possibly need to be replicated in multiple places depending on my needs, but also my integrations over here from the different perspectives, we have to make sure that those are connected to the right sandboxes for those appropriate different kinds of regional or brand sandboxes. So the integrations here start to get a little bit complex in that you have to consider ensuring that the right one is hooked up to the right thing. And some of these target audience manager, they specifically have one instance, and that's why the workspaces and the folders come into play here. So we have to consider and keep that in mind as these integrations are laid out, whereas some of the more native platform ones are sandbox-aware by default. So, Sal, once we put this multi sandbox thing together, though, how does that increase the operational workload? I talked about having objects in all these different places and journeys and audiences and things like that. How do we ensure that customers are operating efficiently in this kind of environment? I'm sensing some competition from your tone with these questions, Danny.
We've got an app for that. No, no, we have an application feature that actually enables you to exactly do what Danny was describing. The complexity or as you grow your business-- I don't want to call it complexity, but as you grow your business, the need to have multiple sandboxes or in your software development lifecycle, we also have these sandboxes for that purpose. You could develop and iterate and only allow developers in a development sandbox and once you're happy with your schema, for example, or with an audience that you're experimenting with, you, in many cases, want to have that schema available in your single production sandbox or if you operate multiple production sandboxes for brands or regions, you also want to replicate it because, for the most part, schemas, your data sources as an enterprise, most likely are the same. Your schema is going to likely be common. So the sandbox tooling is a feature that allows you to create what we call a package. Think of it as a zip file. I am working in my source sandbox. I'm able to add objects to a package. I didn't publish it yet. It's still not published, so I can keep adding objects to it, like a schema or two. I can add audiences. What's nice about the packaging as well is it pulls in any dependent objects. So a schema has a field group. If the field group is not in the target sandbox, for example, it needs to be created. So you don't want to go and also manually find the field group and add it to the package. There's intelligence in the tooling that when you add a schema, it's going to pull in all dependent objects. Same thing with a segment that you add to the package. It will bring in the right components, dependent objects with that. And then you publish it. When you're ready, you publish this package. And this package, once you publish it, it becomes available at the global level. Global level meaning I could be in any sandbox if I have the right permissions, again, this is also controlled by permissions. It's not like anyone can import and export. Let's just say we have permissions that enables admins to control who would do this activity. But the idea is you will have a repository of packages, and then you could import them into a target sandbox. So by this, we optimized and efficiently enhanced the software development lifecycle. We also enabled collaboration between potentially brands. You may publish or share schema-- Not schemas, audience definitions between the different sandboxes as well. So this is really helpful in terms of setting or optimizing the workflow as you grow your business.
Danny, now let me ask you a tough question. Okay. As an enterprise with multiple brands, multiple sandboxes, reporting becomes a challenge. How do you give visibility into the multiple different data that lives in different sandboxes? And how can you also potentially use this data for activation? Great question. And this one is a bit tricky, Sal, so I'll give you credit there. So let's go back to my simple diagram here of sandboxes. If we take our enterprise data, we know we're going to load it into an enterprise level sandbox, and we'll probably take a copy of that and we'll put pieces of it into each of the subsequent region or brand sandboxes. Now if we have an enterprise marketing team that's executing campaigns, they're going to have-- They'll be executing their campaigns out of the centralized enterprise sandbox. From there, let's say they're using something like AJO, and that will create data saying this person got to this node, they activated in this way, we sent this push notification. All that lands also in that same sandbox. And we can use then CJA to do reporting based on the data we loaded plus the data and campaigns that generate data and merge all that within CJA to do reporting on these one area enterprise style campaigns. At the flip side, remember we said we would allow each of the region sandboxes to also load their own data. They can then take that data. Using a decentralized marketing team, they may execute campaigns out of that specific sandbox. With that sandbox, again, we'll generate data in that sandbox for those localized campaigns or brand specific campaigns. And we can layer in CJA to do analysis on data, again, that exists in just that one sandbox.
So we have these two areas that are kind of reporting and activating data off just those areas. But some teams we've seen have a centralized marketing team that wants to also execute inside these local or regional sandboxes or brand sandboxes. So how do you allow this? Well, a simple way to do this is really to allow a login. I can take my centralized team, give them a login to this brand specific sandbox, and then they can run campaigns out of that. So that's a simple way for us to just allow access and without having to move the data back to the centralized area in order to execute any kind of campaigns.
Another way to do this is, as I said earlier, we can share audiences. And this can go in both directions. So I can take a regional or brand specific audience, and I can share it back to a centralized area and utilize that in combination with other pieces of data to execute out of an enterprise level sandbox, again. So that allows me to still keep the data isolation in the forefront.
Now for some customers, though, they feel that this isn't quite enough, and what they want to be able to see is some kind of reporting. So after the activation's done, I want to look at things from an enterprise level. So one way is I can do what's called a panel share. So it's like a dashboard inside of CJA that I can create, and inside there I can have multiple panels. One panel pointing to the data that's sitting in my enterprise sandbox and another panel that's pointing to the other sandbox in my regional or brand specific area. Now the data doesn't technically get merged together. It's kind of sitting side by side, if you want to think of it, or top and bottom, and I can have a whole bunch of these. So it's not really bringing it into one area. It's bringing it into one kind of project or dashboard, if you want to think of it that way. So pseudo brings it together. If that isn't good enough or you want more of a merged approach, what we can always do is do a dataset export, and then the other sandbox can do an import. And so now I can take the data and merge it back into some kind of an enterprise conglomerated, right, something that I can drill down and cut across each one of these. So it solves that problem. But you have to ask yourself a question now. Did I just create a problem? The whole point of having isolated sandboxes is because I want isolated data. So we have to ask ourselves and/or legal to say, can we do this? If I bring back this data, does it create a problem if I don't bring any attributes along with it? Maybe yes, maybe no. They'll give you some feedback. If they say no, then we say, okay, if I were to anonymize the data, can I bring it back? They'll let you know, yes or no, right? You may have to roll it up to a campaign level even to say, okay, I'm going to bring data over at that level.
Maybe it works, maybe it doesn't. Part of that will be dictated by your legal teams and your compliance teams, but it can be done just by using this approach. But I would double check with them, and maybe panel sharing is the best way we can go about bringing this together in one view.
So with that-- Thank you, Danny. But one last thing on probably many people's minds, which is we're talking about data moving sandbox to another or compliance, GDPR. What are your thoughts on privacy? How do we actually ensure that privacy is honored within our Adobe Experience Platform? Is it complex, the functionality that we're giving? Does that complicate GDPR or doesn't impact it? It would be helpful to understand. Sure, sure. The nice thing is this. So just a quick primer on how it happens. A customer will provide an access or delete request into the company, you guys. From there, you'll submit a job into the privacy service for Adobe saying, "Please delete this person's data or access this data." From there, the privacy service will federate out to all the different Experience Cloud, whatever you specify, whatever applications you specify for us to access and/or delete. So if you say analytics, target audience manager, it'll go to those. At the same time, if you specify platform and you can specify the different data stores inside platform, like the lake and or profile store or identity graph, each one of those, it will issue that same request across every single sandbox you have. So single, multi sandbox, doesn't matter. Privacy service will get them all. So you don't have to worry about which strategy and how it affects privacy service.
So with that, I want to wrap this up, wrap this up with a side by side, because we've thrown a lot of information at you. So for me, this is how I have my mental model. I have my single and my multi sandbox approach.
Compliance, legal will always trump this decision. Always. And so that's the first thing we need to consider is what are they telling us. And get specific and discreet with them on what exactly we can and cannot do before just saying, they say we have to keep the data separate. Because as you can see, if I provide a context node, I'm keeping the data separate. I'm landing it in different datasets. The question is, is that okay? So we then need to go in and talk with legal about specifically, what does isolation mean if they're saying it needs to be isolated? Now, Sal talked about that package tooling and putting it together. And sandbox would move this thing around. Standardization becomes easier when I have a single sandbox. It's much easier to control. Because once I create schemas in other sandboxes, technically, they can just go in and edit the piece in that sandbox. And I'm not controlling things. Now, if I have really good controls from a governance level, like you talked about, I might be able to isolate and keep some of that down. But it is easier, definitely, from a single sandbox approach.
Autonomy, we showcase that I can somewhat control it really well and provide the flexibility really well within a single sandbox. But you definitely have more autonomy in a multi sandbox approach. But also think of autonomy partially as your business readiness. What is your culture? Are you a very highly sharing, cross-collaboration culture across these regions and/or business units or brands? Or is it very much we're very isolated and we don't want to work together, only you will know that? But part of that may lean you more towards a multi sandbox approach. But I don't think it's a really good reason, per se, to do that. I think there's ways to do that in a single sandbox. But reusability, these objects, these journeys, these audiences, having everything in one area is definitely going to make it easier from a reusability standpoint. Data, it really boils down to this. Data and workflows become more shareable in a single sandbox because it's all there. I don't have to move data around. There's no latency. There's no worrying about synchronization of things. Whereas in a multi sandbox, I definitely end up with some data duplication, but I achieve isolation. So it's a trade-off, really, that it boils down to here. For me, last thing I'll leave you with is I always strive for a single sandbox in every single implementation because all the work that I'm going to do there, if I decide at some point I need a multi sandbox, I can take all that work and repurpose it exactly as is in a multi sandbox environment without any problems. All that sandbox tooling you talked about, the schema design, if it's kept consistent, I can use the package without worrying about things. And therefore, my audiences and my workflows, they're all referring to a common schema that's highly reusable. But, Sal, I gave them my thoughts. What are yours? Let's talk the key takeaways, and we'll take questions, but we want to leave you, if we leave you with this successfully and you successfully really consume this material and use it, it will make your life easier as you implement the Experience Platform because it helps you streamline your approach and think about, in general, your architecture because I think it's one of the most important things is to architect your deployment, look at your business structure. Don't get stuck in the technical convenience, for example, even if it was a little bit more to do, but think of your architecture up front and think of your business structure up front is key. Think of growth. Plan for growth because we know companies grow. That's what we like to see, of course, and that's everybody's wish. So thinking of growth will help you make those decisions. As Danny mentioned, you could start with a single sandbox, but at least knowing that there is the option, the convenience, the ability to grow, whether within the same sandbox, like what we showed you today with some options or multiple sandboxes, this is available for you. And the multiple sandboxes in here is a feature that really gives you that flexibility that actually helps you set yourself for success. And governance, I can't stress enough how important it is for you to really understand the data, understand who should have access to it, and labeling it early on so you could be successful and not fall into pitfalls related to privacy or noncompliance use cases. And with that, we really appreciate your time, but we're happy to take questions. If you have any questions, come up to the front.
There is a microphone, and we're happy to hang after the session as well. There's no other sessions after this. Maybe we can also chat a little bit more.
[Music]
