[Music] [Clare Greenlow] Awesome. Good morning. Welcome everyone.
Exciting time to get started. We're your wranglers up here today.
[Matt Thomas] Yeah. Thank you, Clare. Hopefully, everyone's excited. We handed out some super fun belt buckles. We are going to be the wranglers. You are also our wranglers. Hopefully, the Bash was super fun last night. We really appreciate you coming to a morning session, so really excited to get started. We're going to be doing Identity Twisters: Becoming a Wrangler Across Devices and Channels. So we're going to get started with some quick introductions.
Yeah. Howdy, everyone. Matt Thomas here. I'm a wrangler on the stage with these fine folks. Yeah, I've been a practitioner. I've been a consultant. I now sit in the product org within analytics space. This is some pictures of the adventures. I have a couple of wranglers, myself up in that top right corner as you can see. And fun fact about me is one of my early first Summits was 2008, where Flight of the Conchords was the entertainment. Was anyone here for that one? Raise your hands. Okay, two, three. Okay, four. Cool. That's me.
I'm Clare-- Thank you. I am Clare Greenlow. I'm an Enterprise Architect at Adobe. I'm on the pre-sale side. I cover the digital experience. Some fun facts about me is I'm a big sports fan. I grew up in San Francisco area. So Go Niners. And I was an athlete at the University of Utah. So Go Utes. And there's some fun little things that I've been up to in the last year.
[Chris Popple] Awesome. Thanks, Clare. I'm Chris Popple. I have not yet earned my-- I know.
I've not earned my cowboy hat yet, yeah, but I do have my buckle.
I love a lot of things. These are things I can actually find pictures about. So oysters, pink drinks, yoga, and London. And I like little, when's your first Summit? My first Summit was back in 2011 or '12.
It wasn't actually called the Summit then it was called the Digital Marketing Conference. I think I like the most, though, is presenting with people that really know what they're talking about and are really fun.
It's me, sorry again. I screwed that up. So maybe to set up my-- Clare and Matt are going to talk a lot about Identity graph and why it's useful and I'm the use case. But they set up the use case I think it's important to know what Wells Fargo is.
And that should not be a mystery, hopefully, but we serve one in three households. And just a show of hands, who here is a Wells Fargo customer? Awesome. Awesome. Thank you for being a customer.
You can probably imagine that in serving one in three households and being a full-service bank, all sorts of retail, all sorts of commercial...
There's a lot of opportunity to talk to customers, to interact with customers through various different means. Digitally, for sure, 5,600 branches, a load of call centers to service people. So there's a lot of activity that needs managing.
Awesome. Time to get into the session. We're going to discuss what we're going to cover real fast. We're just going to be covering cross-channel analytics for you wranglers. We're going to go into what an identity is, identity strategies, assessing your current identity efforts, why these identities are so important in Customer Journey Analytics specifically, elevating this through stitching, as well as an example from Wells Fargo on those identities and how they had to wrangle them.
Just to level set, this is mainly a CJA session, so identities in CJA. However, it starts all the way back at the foundation of Adobe Experience Platform or AEP, as I'll probably call it with our acronyms. So you will be having to do your schema setup, this is where you're setting your primary identity, your namespace, everything around there, and that's going to flow through when you do your data creations, your data sources, your connections, and mapping. Matt's going to really touch specifically on the difference between field-based stitching and graph-based stitching for identifiers, and then Customer Journey Analytics is going to be leveraging all of that to allow you to do reporting, creation, and anything around reporting creations.
Well, we want to start off with what is the basics of an identity and why that's so important. Matt, we were playing around with what a definition was. We really struggled to come up and find the best definition, and Matt said this, and I said this hits perfectly for how Adobe sees an identity. "An identity represents that link between an individual and the channel through which they're trying to engage." So it is our job to personalize messages, and we want to provide that tailored experience for our users, so we have to do this by figuring out that singular view of a person, so that person-centric view is really leaning in on those identities.
So how are we getting identities? Where are we seeing identities pop up? We're going to see them, for example, at a bank branch. You're going to walk into the bank. You're going to already have an account. You're going to go up to a teller. You're going to ask them questions. I want to do a transaction today. When you're at that branch, you're collecting all of that information. You're getting customer ID, a transaction ID, all of that information, and that's where CJA is so powerful, by being able to get that cross-channel and be able to get branch information into the platform. Not only that, but web, we have an unknown user looking for loans. They're trying to determine what loan they want. They're a new homeowner. Maybe they need a mortgage loan. They're browsing the site. So an ECID, or an Adobe Experience Cloud ID is placed on the page. But we still don't know it's Cassidy in this situation. We just know that she's been browsing and looking for things. But that identifier was placed, so we have an anonymous way to target her, maybe do some A/B testing and figure out anything else about her. But that identity is important to get started.
And then we have McKay sitting, and he's a current bank member. He's struggling with something in his app, so he calls the call center. The call center is going to have all of that customer data. You're going to get that customer ID, you're going to get phone number, more information. But when we look at this, we can tell some are durable IDs and some are non-durable IDs. And this is really important to think about when you're thinking about your identity strategies. A durable ID or a non-durable ID is going to change over time. So we see Cassidy. She is a non-durable ID, that ECID. She could clear her cookies. She could going in incognito. She could switch devices. So it's important to try to motivate your customers and your users to try to give you those identifiers because you want to have that main goal to working towards that durable, stable identifier. The importance of that is going to be the device, the channel, and the session are going to remain the same once we know that user and we get that durable ID. So when they go into the bank, we have a very strong durable ID. Some great examples, and I've called them out here is that customer ID, CRM ID, account number, anything around those. I know a lot of banks create their own customer ID as well, so that's a really great durable identifier.
With that, we can get a full image of McKay. McKay is our cowboy who's been out there looking for loan, looking for information. We can get that full image. Every single identifier is slowly coming together to get us a better image of McKay. So you might start with just ECID, really unknown. You might get email. You get a little bit more of him. Then maybe you pull your CRM data. You're getting more of him. So the goal is to get more and more of that person-centric information.
So we've got to get thinking, how do you get your IDs today? You probably have a lot of IDs. You've got to figure out what IDs are really important, what IDs you want to push into the platform, which one's going to be the one identifier to rule them all, right? This is going to be really important. And how are these generated? Where are they coming from? Anything around that. So to do that, let's jump into identity strategy.
And this is where I feel like we get a little bit more fun with my Firefly-generated images. So we are all on our horses trying to wrangle in all of these IDs that we have out. You probably have many IDs that cover many different locations. So this is figuring out, roaming those pastures. Those cows are your identifiers. So think about your cows. You want to get them into a trailer. You want to make sure you can determine that primary identifier.
So in this example, the trailer is my primary ID, which is our customer ID. And we want to get the other identifiers to link to those. So we want to get all those cows inside of that primary identifier. Yes, I love the laughing. It's fun, right? You've got to think of it as fun. It can't always just be work. So with a good identity strategy, we can manage customer identifiers better, and we can get that relationship across those dataset systems and channels. This will ensure that we're capturing every touchpoint and can link them together. This strategy will really help with our cross-channel analytics and personalization.
But how do we get them from unknown to known? What's that first step? We got to start with some baby steps. You can't always get that amazing, perfect step of a login. We often see banks have an app. When you have an app, you immediately require them to log in. But that's a known customer, and that's a great, perfect use case for mobile. You know who they are on a mobile application because you force a login. But you might have them on a web page searching around. This may not be so bank-specific. However, it's important to think for other industries here as well, that you could give them a small discount to get email, to get a little bit more clear of an image, to get that first version of an image. Start putting that picture of that individual together, and hopefully, with that $10 off, they convert. So you'll be able to see that in Customer Journey Analytics that they went from an unknown to an email to a known due to conversion. So hopefully, with the 10% off, that went really well. You could run another A/B test and do 10% off, 20% off, and see which ones do better. And hopefully, in CJA, you can see that through your identities and how they slowly got stronger. And also, for banks, I really want to give this really easy one at the bottom of the page. You can do-- We'll give you your rates. We'll give you a quick email. If you start giving us a little bit of your information, hopefully, you can then retarget them and convert them to be a bank member.
Again, I just want to emphasize, it doesn't need to get perfect. We don't need to get all the way to the mobile app. I think oftentimes, we think we've got to get to the best desired state, but it's important to remember getting from ECID to just an email is still a good state to get started, and then try to get them to that final state.
Awesome. Now we're going to talk about the benefits of an identity strategy. Again, I'm trying to keep with our fun theme here, so sometimes they're funny. So for operational efficiency, we want to reduce redundant data process and storages by unifying those identities. So we want to get them all into that individual trailer.
We want to be regulation compliant. You don't want your sheriff coming out and yelling at you. You don't want to get, that's not good, and the corral of things is not safe. So we want to adhere to privacy laws and governance standards, so with identity strategies, we can do that. We want to be future-ready. You don't want to get stuck in a twister. You don't want to get in that tornado. It's not safe. It's not good. So let's ensure through identity strategy that you can be evolving with your customers across every touchpoint, and Chris will be talking about that a little bit further soon. And then also, this is going to enable those experiences, so you can understand the behaviors they did in Customer Journey Analytics, so you can enhance your personalization down the road. I'm going to pass it to Chris to start telling us a story about where Wells Fargo has seen this. Thanks, Clare. So we've got three things going on in this analogy. We've got cows and cattle being wrangled, belts falling off.
We've got twisters, and we have Glenn Powell. I am not Glenn Powell in any of this, so let's be really clear. But the analogy does work, right? And I said at the beginning, lots of touchpoints, lots of things to coordinate. Marketers trying to piece together pieces for audience building but also, obviously, for tracking. Knowing who's who is critical. Let me tell you a really specific story that I think points to the twistering that's going on. So we're trying to grow our business in checking accounts. We need to incent customers and non-customers to come to us. Therefore, we have promotional programs, $100, $200, $300. And that's really, really important to understand how much money is going to whom and how does that track through. So in our less-than-ideal experience and less-than-ideal process right now, we generate unique offer codes that are used in direct mail or mailed emails, or you can actually see some of these offer codes pop up in some of the ads in mobile banking if you're not a check-in customer. Then some people take those codes and they walk into branches. You sit down with a great person talking about your needs and not needs and making sure it's the right thing. And the branch person generates another code. It's called a marketing offer code. And in that process, we also get an application ID.
After that, we don't want to pressure customers. So they then say, "Well, you don't have to do this right now. You can take this home, and here's a little QR code that you can start the process." So if a customer goes home, they start the process. They take the marketing offer code and then another application ID. Now we don't know who this person is yet. We just know that they've got a bunch of codes, right? They complete the application process. Maybe they start one-time, application code one. Maybe they pick it up later, application code number two. And then finally, over, let's say, a week or so, they actually become a customer. If you're trying to understand what was the effectiveness of each of those channels in driving the outcome, good luck. So it's like a nightmare, right? So it's a twister, if you will, of different kinds of identities to maybe three application codes, probably a cookie ID, a unique offer code at the beginning. And this creates the issue, and I think the opportunity that we're trying to tackle with Customer Journey Analytics coupled with the identity graph.
And I'm sorry, I'm supposed to do transition, sorry. What Matt's going to do now, the first step in that is to assess your graph. - Yeah, that's right. - Yeah, thanks, Chris. I think I got lost somewhere along all of those different identities. That is definitely a twister.
Well, I don't know about you guys, but I'm hot in here. This outfit is not my normal get-up, but it's pretty warm in here.
Yeah, let's start by assessing the identity efforts that you have today. Clare touched upon the qualities of a good identity strategy. And regardless if you're at the beginning of that or you have a well-established identity strategy, it really is important to assess what is in your data today? What identities are prevalent? What are they? Are they durable or non-durable? Getting back to what Clare talked about. So let's talk about that.
As was mentioned in that visual of AEP and CJA, the journey that CJA goes on doesn't start with CJA. It definitely starts with AEP. And so these two screenshots are from within AEP. What identities do you have in your data? Now that left screenshot is from the identity section of AEP where we have some out-of-the-box identities defined, email, hashed email, phone number, ECID. It also has a classification for them in that Type category. Are they durable? Are they non-durable? Plenty of headroom there for you to add in your own custom IDs associated with your organization. The first step is really understanding what they are and adding any that might exist within your organization. On the right, the next step is really, where are these identities located? Are they standalone fields in the schema? I don't know if you can see very well, but the little thumbprint icon in the email in the myCustID, that shows that they're identities.
Are you using a Web SDK deployment? Are you using identity map? Is that where your identities are stored? This is critical in making sure that you set them up and mark them as identities, as noted in the graphic there. That is crucial for not only AJO, but CDP as well, and also now CJA. When you go in and create a connection in CJA, it hinges off of the identity. It's very important to the whole entire system, and we'll get into that a little bit more.
Okay, so now we've established what identities we have, where they're located, how prevalent are those identities in your data today? That's logical next step, right? So let's assess that.
I have a lot of favorite features of CJA, one of which is derived fields, but the other favorite one I have is creating a metric from a dimension. This is a cool feature. What it allows you to do is take a dimension like email, right? You might have a dimension that houses hashed email addresses. You can drag that when you're configuring your data view in as a metric. So that's what I've done here. I have four different dimensions of different identities in my dataset, and I've dragged it into the metric area when I've defined my data view, and now I have a metric of those four identities. Simple count, however many times it's been set on the events. That's step one. Step two is creating a calculated metric off of that dimension that is now a metric. So we'll take one identity, Email set. That was my metric that I newly created. I'm going to take that and divide that over the total events in my data.
What this does is it gives you an authentication or identification rate and tells you how prevalent this is against all of the events in the data. You would repeat this process for any identity found in this dataset, and then bringing it all together in this freeform table here, you would see in the very right, ECID, authentication or identification rate. It's 100%. That's what you would expect if this was a web dataset. The other two columns, you start to see different identification rates based on those identities, and this may help you start to form your strategy on what identity should I use in my organization based on what's prevalent.
There may already be an existing golden ID within your organization that you have, but this can also help guide you in arriving at what that golden ID is. Maybe hashed phone number because it's so prevalent. Maybe that's the one I choose, and that is the one that we use within our organization.
Okay, now shifting gears a little bit, let's talk about a shared device. Now I'm sure most of you guys have heard the term shared device, but just to make sure everyone's aware of what a shared device, it literally is a device that is shared by more than one person where an authentication event happens and more than one person is using that same device. So a couple examples that we've seen and scenarios where we've seen shared devices are these. That first image on the very left, maybe a husband and wife are using a family computer where they're both logging into their bank.
Or maybe there's a kiosk where you can check in for your flight or a hotel or maybe even order food. You have multiple people authenticating, performing some behavior, and checking out on a single device. And lastly, or the last example I have is a call center. Maybe you have a call center where customers call in and the call center agent maybe helps finish or finalize a transaction on behalf of a customer. Again, a single device, multiple people, multiple authentications to that shared device.
Now why is this a problem? Well, it has actually a pretty big impact on your data. As you can see here from this table, we have Cassidy and McKay both using the same exact device. They're both exhibiting very different behavior. One's looking at Product A and one's looking at Product B. How do you attribute any acquisition marketing efforts? Who gets the credit? Not only that, how do you re-market? Who do you re-market to? And which product are you re-marketing? It becomes very buddy very quickly when you start to think about shared devices.
Now you're probably thinking, "Well, I don't know, do we have shared devices in my organization? At what level do I have a shared device problem?" Well, let's talk about that shared device exposure. I like to look at it in four different areas, starting with we need to identify how many devices are shared within my data. If you look at this histogram here, you can see that very left bar shows that most devices have a single person associated with them, which is great news. But we do have some bars of people that have a device that has more than one person on it, upwards of 15 or more on that very right bar. So first step, identifying the devices that are shared.
Second step, how many events are coming from these shared devices? This example, it's 20%. Maybe it's not that high. Hopefully, it's not that high within your organization. But this helps you understand what level of events are coming from these shared devices.
Then the next step is understanding from that 20%, what percent of the events in that are anonymous or unauthenticated, right? So if I take a portion of that 20% and I look at the anonymous events in that 20%, 88% of those events are anonymous. And the reason that's important is because if you have any algorithm or way of attributing identity to these anonymous events, you may have some misclassification. So if we take that 88% and we look at all of the events, now we know that 15% of our events, total events, come from shared devices that are also anonymous. That could potentially be misclassified if there's any algorithm you're using to attribute these events to the right person.
Now I've just walked through this. You're probably wondering how do you do this analysis on your own? Well, besides the awesome belt buckle we gave you, we're going to give you something else as well. We've created the queries for you to do this analysis on your own. That QR code links to some Experience League documents. But we have four different queries that you could run today or when you get home or next week. But allows you to assess the shared device exposure you have within your datasets today. So cool, hopefully, that's just as good as the belt buckles we gave you.
But I will say the belt buckles are cool. So we've been talking a lot about identities. Why so much talk about identities? Adobe Analytics, we don't nearly talk about identities as much. And it's pretty critical because it really is the hinge point at which CJA operates on. So let's go back and dive a little bit deeper into how CJA operates today. As we started, it sits on AEP. So if you look on the very left, you'll see three different datasets. The colored columns start to highlight identities found in each of them. The green, the darker green it looks like is found in dataset one and two, and the lighter green in one and three.
And so those are used in CJA. And when you're in CJA, it tries to combine or join these datasets together on the premise of a person ID, on the identity found in it. So to get the full value out of CJA, all of these datasets need to be aligned to the exact same identifier.
So let's talk about that a little bit more. So for those that haven't been in CJA and looked at the connection screen before, this is inside CJA in the connection screen. Again, big jump from where core analytics is today to CJA. Here, you're picking that person ID. In this example, I have a call center data at the top, and I have a web data in the bottom. I may choose email because that's the identity in there, and I may choose customer ID in the web data. Now two things here. One, if the field that you select as the person ID doesn't contain a value, that row gets dropped from CJA. It requires a value there, which is different from core analytics where every single event had a visitor ID or an ECID, right? So a big difference from that. Also, like I said earlier, to get the full value out of CJA, really these datasets need to be aligned to the exact same ID or identity. So to be able to connect a journey of a customer from your call center and your web data, really both of these should be email in the connection. But as we learned from Wells Fargo and probably all of you in the room, that's not always the case. Now all of these datasets aren't aligned to that right identity, and so we'll get to how we solve for that. Let me jump into a quick example. So in CJA, here's a web dataset. If you pick device ID as the person ID, well, the good news is all the events are going to be brought into the connection. The bad news is now you have a device-centric approach and reporting very similar to what you have in core analytics today. However, if you pick customer ID, that's a problem too, because one, you are missing out on those unauthenticated events. Those first three events and those last two will be dropped from CJA. But the plus side is you do have person-centric reporting, and you actually could probably align this dataset with other channels that may have that customer ID in it.
So how do we have our cake and eat it too? This is done through stitching.
That term stitching, it means a lot of different things to a lot of different people. So I will define it as the way I'm talking about it today. So stitching, sometimes referred to as identity stitching or cross-channel analytics, it really is the process of mapping a persistent ID or ID that's found on every row to a person ID, and then taking that and applying it to other events.
In the case we don't have a person ID, it does have a fallback method so we don't lose out on that unauthenticated traffic.
And all of this is done prior to the data being even ingested into CJA. And the best part of all, it is compliant with any privacy regulation that exists.
Okay, so we don't have 31 flavors like Baskin-Robbins, but we do have two flavors of stitching. We have field-based stitching and we have graph-based stitching.
With field-based stitching, it assumes that all of the identities you want to elevate to are found within that single dataset.
It uses a device split approach when it encounters shared devices.
On the flip side of that, graph-based stitching does not assume that all identities are in that single dataset. It uses relationships that it finds from other sources to help complete the picture of the identity that you're trying to elevate to. And it uses a last-auth approach when it encounters shared device scenarios.
So let's get into this a little bit more and into the details. So with field-based stitching, what we do is we create another column with the best person that we can elevate this data to. It is deterministic based on the fields, the data that's in that dataset. And we pass over the data a minimum of two times.
So as you can see from this data right here, when we run through stitching, I'm going to show you what happens. This additional column gets added, we call it the stitched ID. It's not a proprietary ID, it's just a column title. And it really is either the fallback identifier, which in the first three events is 1234 because we didn't know that those events belong to McKay yet. But once we do know that 1234 that device belongs to McKay, we're going to add him in as the stitched ID.
You'll notice on those last two events there that the event didn't even come in with McKay, but we still were able to put McKay in as the stitched ID. Once we have that mapping and we know that this device belongs to him, we can add in his name, or in this case, his name as the stitched ID in a going forward basis.
And you're probably thinking, "Well, what about those other events?" I want to attribute those back to McKay as well. I did say that we pass over the data a minimum of two times. So the other time that we pass over the data, we call it replay. Through replay, we can go back in time and restate history. We can take those formerly anonymous events and attribute them back to McKay. So now that we know 1234 belongs to McKay, we go back in time and correct it. This is done daily or with a daily look back, 7-day look back, 14 or even a 30-day look back. So we can go back 30 days and correct and true up the data based on additional learnings that we find around these identities.
Okay, so that's field-based stitching. Now the fun thing is graph-based stitching. And both are great, but graph-based was released last year around this time. And the power of it is it leverages the AEP identity graph. So this is the exact same graph that CDP uses, that AJO uses, and now CJA can use it. So again, if we go back to the very beginning of what we were talking about, how we were talking about identities in AEP and marking them as identities in the schema, all of that's important because it gets us to this stage. All of the relationships and links between the different identities come together in the graph. Multiple sources make up the linkage between all of these different identities. And it allows you to really hop from, we'll say, ECID all the way to loyalty ID when you never have that relationship at all. You can traverse it and get to that loyalty ID or to a customer ID, even though there's no direct relationship there.
So again, let's walk through an example.
Much like field-based stitching, there's two passes of the data with graph-based stitching. And again, we also create that stitched ID column based on what we find in the graph. So if we take these first two events, we see 1234, we go to the graph and hey, there's a relationship between 1234 and McKay. So now we can add that in as the stitched ID.
Now pause there, that is huge. This dataset never knew that 1234 belong to McKay. But now through the power of the graph, we can go and get McKay's information and augment and enrich this data with his name on that stitched ID column, which is really cool.
5678, we go to the graph. Hey, 5678 doesn't belong, it's not in there yet. We don't know that this belongs to McKay yet. So we have to put it forward so we don't lose that event in our analysis. Last two events, as you would expect, 5678, go to the graph and look, the relationship is now there, 5678 is tied to McKay. And now we can pull back and add McKay to our stitched ID column.
So just like field-based stitching, we want to fix that third row there, that 5678, that doesn't look right. I know it never works out perfectly like this, but hey, it's my example. I can make it work perfectly.
So on our replay, which lets us, again, go back that 7, 14, 30 days in time, we can now go to the most updated version of the graph, which has that linkage between 5678 and Matt. And now we can go, "Hey, graph, do you have a linkage between this?" "Oh, I do." Here's the customer ID of McKay. I'm going to add it to my stitched ID column. So the power of this is now I've aligned this dataset to customer ID. Other datasets like call center or any other CRM data might already be aligned to customer ID. So I've taken my web data, aligned it to the same exact identity that other datasets in my org are aligned to. And now when I go and create my connection in CJA, I have all of these datasets aligned to the exact same identity. And so I can follow a customer journey through all of these different channels together. Now I'm sure it doesn't work as seamlessly as I just talked about here. So I want Chris to come up and talk about some of the challenges that he faced as they implemented graph-based stitching. - Chris. - Earlier again, sorry. - Wardrobe malfunction. - There we go, thank you. So this is a dense subject, right? Hence the need to make it as fun as possible. When this was announced last year, I just went right over my head in the session. I took the session slides and I read them over and over and over again. But I'm going to make it even more complicated, unfortunately. But there's maybe two takeaways before we get to this. So the first is, if you have any use case that sounds like our use cases, right? So where you've got event data that has different identifiers, right? It's not always ECID, or it's not always the customer ID, then you want graph-based stitching. And the reason is, number one, you're not going to be able to identify it, but you're going to lose rows, right? So again, big difference in Adobe Analytics. Everything's in ECID, the world is easy, right? Here, you're trying to merge different datasets. They all have different identifiers. If you just declare a single identifier, then you lose the rows. The data goes away. You've got to create a different connection to that. You can't put them together. Graph identity stitching allows you to keep the rows. And that was the thing I ended at with team midway through the year. I said, "Yes, let's take this, let's bring it on. I want the rows of data because if I can't have the rows of data, then I can't join them." So it was as simple as that.
So let me go to the next slide. A little bit, some people always like stats, right? So this gets a little bit more complicated.
Other things we needed to do to make this work. First is to actually discover the behavior of customers. Talk about shared devices. How often does this actually happen? Isn't it just once in a while people share the same computer? No, it turns out they do it a lot. And this was totally dumbfounding to me, right? This literally means people are giving their phone or their PC to other people, and then logging in at different times. There's quite a few people. Maybe retail banking is examples of this, I don't know. But totally shocking. And what was happening is we were getting lots of collapse. So into...
CRM IDs, or we call ECNs, where that just can't happen. So that was a big wake-up call. The second big wake-up call was trying to find other identifiers that we could do to use the merging, like hashed email, hashed phone, or just plain old email and phone. Again, lots of sharing. And you think about it and say, "Yeah, well, some of our very best customers...
They'll have multiple accounts with us. And they'll purposely use different phone numbers and emails to separate concerns, right?" My home loan's going to go to that email. And my wife manages the checking account, so we're going to use that email. And so we were trying to use that, and it's like, "Okay, that's a problem, right?" So Matt's already talked to us a little bit.
But we started to-- Okay, now we got a problem collapsing. How long is it taking to authenticate, and what does this lookback thing feel like? So pleasantly surprised that actually 97% of our ECID traffic authenticates within a 7-day window. That's pretty good, actually.
A lot of that is because people are still using login experiences on the web, particularly. Well, it's web and mobile, but so that was really good. So that means that we weren't having a lot of hanging, ECIDs that might be different, but they were still authenticating.
And the seven-day lookback window, I think it's, yes, true...
For field-based stitching, you call it replay, right? So field-based stitching and graph-based stitching, I think the key thing is...
When you set up a new event dataset, connect into it, the initial load can backfill. So it isn't, you start it, and then you only get seven days when you initiate, and you can ask to backfill. The backfill might take a very long time, depending on how far back you want to go.
But you top up, if you will, and that's where you establish a base, and you top up after that.
One other really big thing. So when we're getting device collapse, so what do you do? The first thing we did was we called Adobe and said, "There's nothing to fix this, what do we do, right?" And we got some smart engineers from Adobe said, "We can fix this." And they created a thing called the penalty box. So penalty box was a, you go ask them to basically untangle, or de-collapse, or re-inflate, whatever the right word is, those things you don't want to collapse. And then about, I think it was two or three months ago, I don't know what the exact name of it is, but essentially it's an identity simulator, which there was a couple of labs this week that you should really go to if you want to get into this, which allows us now to do two things. One is to simulate a scenario. What if customer did this on two different devices, then what if they shared an email address? And critically, you sequence the activity to figure out what would collapse and what would not, and then underneath it, you simulate the rules. So the rules are two things, and you're doing this, by the way, inside AEP, not in CJA.
The rules are two things. One is, what identifiers can never collapse? You can never have two CRM IDs, absolutely cannot happen, right? Particularly in, we cannot send audiences to, we can't be eligible for a home loan to two different people. That just can't-- It has to be the person, so there's an absolute. And then there's a hierarchy. So after the absolute, what's the hierarchy of IDs? And so we're in the middle of that right now, trying to simulate, well, here are the three different kinds of application IDs, and what if we layered in email and phone? What would happen to the graph? And you can't really see it, but if you go in, you can see it, actually. It'll tell you which ones it'll break apart and which ones it'll keep whole. And then you can basically manage your graph that way. And then that then determines exactly what gets stitched and what frame. So big things again are...
Number one, if you don't do GraphDB and you have event rows with multiple IDs, you're going to lose rows and it's going to be a nightmare. So for that reason alone, you want to be doing graph-based stitching. And a second, know that it isn't as simple as just taking in the connection. You've got to also play with this ID simulator and do a hierarchy. Put those two things together, and you have a chance to try the stitching in these journeys.
I think that's it. Clare, are you going to bring it home? - I'm going to bring this home. - Yeah.
Hopefully, everyone had a fun time. I know it was a lot of information. It was pretty dense, but hopefully you got a fun belt out of it and got some good real-life examples from Wells Fargo here. So excited and glad we were able to present today. And just a quick reminder, my name's Clare. I'm an Enterprise Architect. This is Matt, he's a Product Manager, and Chris at Wells Fargo. So thank you again for coming.
[Music]
