Are you ready to level up your mobile analytics app?

Transcript

Hello, my name is Daniel Wright, Senior Technical Marketing Engineer. Welcome to our Experience League Live session. Are you ready to level up your mobile analytics app? My team does these Experience League Live events once or twice a month. For doing one for your product, you will usually see a sidebar ad appear a week or two before the event in the product documentation that you read every day. So next up in a week or so we’ll have an event on all of the new AI tools in AJO and Campaign. So if you use those products, we look forward to seeing you at that next event. Alright, let’s get started with today’s show. So in the red corner representing the SDK product team, we have Principal Product Manager, Mitch Rice.

Hey, Daniel, how you doing? How you doing? All right, and in the blue corner, representing the SDK engineering team, computer scientist Kevin Lind.

Hello, everyone. Morning. Welcome, Kevin. So good to see you guys. So today’s topic, of course, is mobile SDK. But before we get into it, let’s talk a little bit about the fun facts. So Mitch, you like to hike in southern Utah and look at petroglyphs. Can you tell us a little bit more about petroglyphs? Yeah, for sure. So all throughout the American Southwest, there are remnants of the people who used to live there, one of which is are these petroglyphs that are seemingly just about everywhere. So I spent a lot of time hiking around various places and looking at those taking pictures, I actually brought some with me. This is the third time that I’ve been on the show. And first time that I’ve actually brought pictures along with me. So I wanted to share some of those. The first ones that I took were actually just inside the city of St. George. You can see that we’ve got petroglyphs on the ground and then kind of the mountains in the background. On the right, we’ve got some petroglyphs from Canyonlands National Park. I brought some of the some others that I think are probably my favorite. I think this one on the left is probably my favorite. He’s, he’s called the broken hearted man, you can see that he’s got a heart in his chest, usually with these petroglyphs. If somebody’s upside down, it represents that they’ve died. Nobody actually knows for sure. But in this one, this guy has been given the name of the broken hearted man, you can see the tears. Then we got some some sheep. And then actually, there’s there’s quite a few ruins in in the southwestern US as well. And so on the left here, we’ve got the Citadel. This one’s unique because it’s actually built on top of like a 300 foot canyon wall. Really, really incredible. And then on the right hand side, we’ve got the moon house, which is in Bears Ears National Monument. Really, really cool stuff. I think it’s a cool hobby. I spent most of my springs and falls hiking around and seeing these different things. I I yeah, I think it’s a pretty cool hobby. Yeah, that’s incredible. I can’t think of anything more distant from the world of SDK development than being out there in the desert. Looking at that stuff. With my enablement hat on though, I think I did see some tutorials for hunting large game in those petroglyphs. Yeah, for sure. Yeah. And this first one here that it looks like there’s there’s almost an instruction manual here. You’ve got the guys with their swords and their big clubs. Yeah.

Awesome. And then Kevin, I saw that you’ve participated in a nine triathlons, or as I call it five pentathlons remainder two. And that’s the best long division joke I’ve made this week. So for you, which which which parts of that so that’s running, swimming, biking, which is the best which is the worst for you? I’ve always enjoyed the biking the best. Um, I think the swimming is a little bit more memorable, though. Um, you know, swimming from Alcatraz Island to San Francisco was definitely, you know, pretty cool. Um, but yeah, I mean, it’s always like, oh, my gosh, I’m like escaping from Alcatraz. And I’ve got to I’ve got to get there before the bullets get me or right? Well, I mean, running through your head, you always think the sharks are going to get you but there’s there’s no sharks. It’s you’re in there with a with a massive like 200 other people swimming across the bay, which is pretty cool.

You know, and then there’s other lake swims and river swims, you know, swim in Russian River for the monorheal triathlon. Some parts of that the water was probably only a foot deep. So you had to choose whether you just want to kind of crawl over it or get up and run through it. So always interesting. Um, but yeah, I’ve always enjoyed the biking part of it. situation. You’re like the only one doing the crawl stroke. You look pretty silly. Yeah, it’s it’s just it’s however you however you train for it, whether you want to get up and start running or stay stay down in the water. Um, but yeah, and I’ve done the Santa Cruz a few times and then the Wildflower triathlon a few times, and Oakland triathlon, which was pretty cool going through, you know, a major city like that. I can throw it and running through it.

Kevin, do you still do those? Um, it takes quite a bit of time for training to train for all three events to be proficient in them. Um, so now that I have a seven year old son, I don’t do them as much as as I would probably like. But one thing I did take away from from doing it, you see everyone there. I mean, if you watch it on TV, you’re only watching like the top people who are finishing. But there’s people from all walks of life, you know, every age level and every, you know, body shape. So it’s something that like anyone can do as long as you you go out and do it, you know, as long as you’re not super concerned about how long you’re going to take and your time and stuff. Just go out and have fun with it. What if you’re not a super strong swimmer? Like do they let you take water wings or life jacket? In Northern California, you get to wear a wetsuit, which gives you a slight buoyancy, because the water so cold if it’s I can’t remember the exact cutoff. But if the water is a certain temperature, you can wear a life suit. I mean, a wetsuit. Right.

I’m not sure that I’m going to be doing a triathlon anytime soon.

You can do it Mitch, you’ll be like Ray gun out there showing the world that you’re not a super strong swimmer. Oh my goodness. All right. So shall we get into it? Shall we get this mobile SDK stuff? So, oh, and I just wanted to say so my my background is in web development. So my any questions I have are going to be softball questions for these guys. So please, if you’re watching at home, in the office, in the office, in the office, in the office, you’re going to be watching at home, in the office, in your home office, please ask questions through the comments box in YouTube. And I will repeat them for our guests.

Alright, so, Mitch, we’ve had mobile SDKs for experienced cloud products for a long time, I don’t know, maybe 10 years longer. So what is this leveling up all about? I know we have our new edge focus. And I understand you have some slides you want to share to explain why and how people can move to our new approach. Yeah, for sure. So ultimately, what we want to talk about today is how you can go from some of your your solution specific approaches, specifically analytics and move to the move to the sending data to the edge network. What that is going to do is basically allow allow you to start sending data to the platform edge network, which means that you can then use this data for CJA, real time CDP, AJO. So I’ve got a couple of slides here that I want to share that are just going to kind of give you a little bit of overview of what we’re going to cover today. And then Kevin will actually do the demo where we where we make the change from from having that analytics implementation to the edge bridge implementation. And we’ll still be able to see the data flowing in the exact same way that it always has. So let me let me start just by giving a quick overview of platform data collection. So the edge network is actually the heart of platform data collection. It’s comprised of servers that we’ve distributed around the globe, basically, these allow you to interact with the experience platform and the experience cloud applications. So we’ve developed new SDKs in order that allow you to do this. So we’ve got the web SDK, the mobile SDK and the server to server API. So the web SDK and the mobile SDK have both been built from the ground up, they’re open source. And they use a completely new way to communicate with with the platform edge network and the platform applications. The server to server API is actually really unique in that it supports authentication. So if you have any sort of sensitive data that you need to send to the platform edge network, definitely would recommend using the server API because it does support authentication. Across the web SDK, the mobile SDK and the server API, we use the same methods API calls data format is is exactly the same. So the data format is actually called the experience data model or XDM. And anytime that you send data to the experience platform applications, XDM is the is the supported data format. On the other hand, on the other side of the platform edge network, we’ve got all of the Adobe solutions. So you can see here that we’ve got customer journey analytics, real time CDP and journey optimizer, you can see that we also support sending data to analytics target audience manager. Using a simple control panel that we call data streams, you can actually quickly and easily toggle which solutions are sent data, depending on depending on the types of requests that you’re sending and things like that. So the final piece of data collection is event forwarding. So you can use event forwarding to send events to the first to the edge network, but then on to a variety of third party destinations. Those could be data warehouses, conversion API’s. The unique thing here, though, is that this data is forwarded literally in real time. We’re not going to cover too much on on event forwarding today. But it is a really powerful aspect of edge data collection. So here are all of these features comprise platform data collection. And really, they provide kind of a faster, simpler, more flexible way of interacting with the Adobe solutions. A key element of experience data collection is the fact that the edge network is capable of sending data to all of these solutions. So one request sent to the edge network has the has the ability to carry data to all of these solutions simultaneously.

So your state that you want customers to be able to take advantage of? Absolutely, yeah. So the ideal scenario is one where we get away from using all of the various libraries that are solution specific, and then start moving to the SDKs that then support communicating with with all of these different solutions. Yeah, definitely. So we realize that for a lot of customers that that that change or that migration, it’s challenging. And so one thing that we’re going to talk about today is how you can use the edge bridge to actually simplify a migration from from an analytics implementation to one that allows you to start sending data to the edge network into all of these solutions here.

Okay, so today, like you mentioned, we are going to focus on the mobile SDK. Specifically, we’re going to focus on a new extension that we’ve built, called the edge bridge. And really, what we want to do is show you how you can migrate from analytics to the edge bridge with with virtually no implementation changes. So let’s let’s run through what edge bridge is here real quick. So edge bridge is an AP mobile extension that allows you to take that existing analytics implementation and start routing data to the edge network. So analytics has always used two methods, one is track action, and the other is track state. Using the edge, all of the default method is send event. And so basically, what the edge bridge extension does is it allows you to take all of these track action and track state calls, it converts them into send event calls, and then routes that data to the edge network. So really, the the end goal here is deferred for us just to drop in this edge bridge extension. And by doing so, we’ll be able to start routing the data to the edge network without having to make any any significant changes to our existing implementation in the application.

Okay, so it’s like if you were a customer who implemented our mobile SDK, say five years ago, because you wanted your mobile analytics data in Adobe Analytics, this is going to help you to to get to our latest edge network approach without having to read implement all of the SDK in your app. It’s like a shortcut to getting that functionality with your existing older style of implementation, right? Exactly. Yep, exactly. Yeah. And so let’s chat about like, why you would why you would do this. So ultimately, you know, this allows you to modernize your implementation data that you previously sent with the analytics extension that’ll still continue to flow to analytics, like I said, without any mapping or rework of the implementation. But because the data is now being sent to the edge network, you can now start sending this data and routing it to CGA and real time CDP as well as Adobe journey optimizer. So this adds a lot of flexibility in terms of what you can do with that existing implementation without really having to change all that much.

So it’s like your Adobe Analytics implementation can very quickly become a CJ implementation, a real time CDP implementation, journey optimizer implementation without very much effort. Exactly. Yep. Yep. So I have one final piece of housekeeping here that that I would like to cover. And then let’s let’s kind of get into the meat of this thing. So when it comes to sending data to the edge network, there’s two main data objects that you can send. So the first is XDM. And and basically, this is a completely different way of structuring your data, so that it can be used with the platform applications. So one thing that customers have told us as they’ve been making the jump to edge data collection, is that taking all of their old props, evars, events, products, variable, and trying to reimagine it as XDM is challenging. And so really what this what’s what this solution allows you to do is to kind of skip over that step, at least for the short term. But the other portion of this data object is you can see over here the data object that’s the purple and blue section. And you can see within it that you’ve got this Adobe object, the audience manager object, as well as the target object. Any data that’s included here is going to pass through to each one of those respective experience cloud solutions completely untouched. And so one thing just to note as you’re as you’re structuring your data and using this with the edge and edge bridge extension is that XDM is really a data model for the experience platform solutions. Whereas this data object is been specifically designed to allow the data to pass through to the experience cloud solutions, and keep it kind of separate from this from this XDM object. This is going to help with with kind of long term migration, being able to structure your data in a way that that kind of keeps the data separate, but also allows you to kind of a simple way to start migrating data out of that data object and into XDM.

So what will this this XDM approach, this wouldn’t have been something that you know, that person implementing the SDK for analytics five years ago would have even thought about, well, they need to implement any of this in their mobile app to use edge bridge or how will they start to use these this structure for their data? Yeah, that’s a great question. So the edge bridge extension doesn’t require you to restructure your data at all. So basically, take the existing object and we convert it into this analytics object on the hunter under data, so you don’t have to do anything. All of that conversions automatic.

Cool. So ultimately, what what what we’ve done with the edge bridge implementation is let this is let’s say this is your current implementation here. You’ve got a bunch of track state and track action calls. And that is being sent via the Adobe Analytics extension. As you’re moving to edge bridge from from that implementation, basically, we’re going to drop in some new extensions, but you keep your track action, you keep your track state. Key difference here, though, is that instead of routing the data directly to analytics, we’re now going to route this data to the edge network. And then it becomes eligible to flow through to to analytics and audience manager.

And then if you would like if you want to start sending data to the platform solutions, you can use data prep to take this data that that’s flowing through and then start mapping that index DM. So this gives you a pretty quick way to be able to start routing this data to to the platform solutions. So I’m going to contrast to that if you were with with just the edge implementation. So if you wanted to use just the edge implementation, you can see that your views and buttons would need to be re implemented. So you would then stop using track action track state, you would need to start sending your data using the send event request, you would need to restructure the data into XDM. And in in in in doing that, then you could then you could start sending data to the platform solutions and the experience cloud solutions. And so there’s there’s quite a bit of developer work that’s required if you move to the edge implementation versus the edge bridge.

Okay.

And if anyone is on the call, or on the the show, listening in, if you haven’t implemented our mobile SDKs yet, you would you would start with this approach using this send events. And this edge bridge is for helping customers who’ve implemented previously before our latest versions of the SDK to be able to leverage the edge network.

Yeah, and we are hoping that our naming here kind of is indicative of the lifetime or the lifecycle of some of these extensions. So the edge bridge, you may use it permanently. But I think for most customers, it’s probably going to be kind of a short term thing. And so we’re gonna, we’re gonna have a lot of folks who are on the call, who are gonna say, yeah, edge bridge is the way to go with, you know, we were not in the middle of a re platforming of our application or anything like that. And edge bridge makes sense in the short term. But I think in the long term, a lot of customers are probably going to weigh the pros and cons of edge bridge versus edge. And some may, you know, some may choose edge bridge, depending on you know, how many development resources they’ve got, some may choose to go straight to edge really just kind of depends on on your specific set of use cases.

There’s a question that came in, will edge bridge be, quote, forever maintained? Or is this a quote, stop gap, that will eventually be sunset forcing developers to refactor? And will you know, are we going to phase out edge bridge at some point? We don’t have any plans to do that. So right now, our plan is for this to be a top level extension, just like the rest of them. Yeah. And that’s this whole experience League Live episode about edge bridge, because we want we want people to use it so that they can, you know, easily get started with our newer solutions, like CJA, real time CDP, and so on. Yeah, absolutely. This is really just kind of a way to fast track your your implementation and get you on on edge data collection so that you can start getting value out of out of CJA Adobe journey optimizer and real time CDP. So here’s just a quick comparison. We’ve covered most of these things here. But the key difference is that edge bridge uses track action track state, whereas the edge implementation uses uses the send event API. With an edge bridge implementation, you’re sending props, bars, events, product string, all of those are contained within the data object. Whereas an edge implementation is going to require that you move to XDM. It also supports sending data and the data objects. So if you have data that you want to pass to analytics target audience manager, you can do that as well. But just one thing to note here is that with the edge bridge implementation, only the data object is supported. So there is no support for for the XDM object. If you need to get data into the XDM format, you will need to map data using data prep out of that data object into XDM. So I’ve included some links here at the bottom. Basically, you can click on it or you can you can scan any one of these. They pointed the documentation of round edge bridge as well as our Android and iOS specific documentation for the edge. These are these are more guides rather than documentation. They provide guidance guidance for how you can get from an analytics implementation to an edge implementation on each of these respective platforms.

And Mitch, you mentioned data prep a few times, developers who implemented the mobile SDK, you know, some years back might not be familiar with what that is. Do you is that going to be something you’re going to share later in the in the episode or Yeah, so not today. But if you’re familiar at all with analytics processing rules, think of it as a more modern version of that it allows you to take any sort of input that’s in that data object, and then map it to specific values that you’ve outlined in your XDM schema. So although we’re not going to cover it today, it is a really powerful tool that allows you to, to basically transform your data in a variety of different ways.

And it’s a user interface that you do that. And so it’s not anything that needs to be done in your mobile app. It’s done in the data collection interface. And maybe you don’t even have to do it. Maybe it’s a data engineer who works on your experience platform application that, you know, can be tasked with doing those mappings to XDM. Yes, lots of lots of different processes that can be used to do that part of the switch to using edge. For sure. Yeah. And like you mentioned, all of that’s being done server side. When you make a change, you know, it’s not a matter of having to redeploy an application or anything like that you can you can basically change those mappings on the fly. I think one of the coolest things about data prep is that not only can you map data, but you can actually transform data. So if you’ve got data that’s coming in, that might be a little bit malformed, let’s say you want to make everything uppercase or lowercase or you want to split data out. There’s there’s probably about 70 different functions that are in data prep that allow you to manipulate data in a variety of ways.

And Mitch, there are a few questions that came in. One, will edge bridge support AJL? Yeah, that’s actually a great question. So edge bridge is going to get data into platform so that it can inform AJL. But one thing to keep in mind is that with Adobe journey optimizer, there are separate extensions that are in play there that allow you to then retrieve personalization, retrieve specific messages, and then and then display those. So if you’re going to go the route of using AJL, you can absolutely use the edge bridge in order to get data into platform. But then you’re also going to have to use the messaging extension on top of that in order to be able to get some of the responses and handle those from from journey optimizer. Okay, so if you wanted to do something like trigger an email, you would need to do something like trigger an email message based on actions taken in the app, you’d be able to do something like that with edge bridge. But if you wanted to show the user a personalized message, say through through like a campaign or journey, like within the app, to do that to show different content in the app, you would need to migrate you can still use edge bridge in that scenario as well. So if you’re looking to do personalization, we have we have another extension that’s called the optimize extension. Basically, that allows you to get personalization content back from from both target as well as journey optimizer. And so and so that that can be configured and will work perfectly with edge bridge as well. Oh, okay, great. So edge bridge and optimize can be used in together. Great. Yeah, one way to think about is that edge bridge is kind of a wrapper for the edge extension. And so basically, it’s just converting some of those API’s that were used with with analytics implementations, and basically just taking in and doing some of the heavy lifting. But ultimately, it’s the edge extension that that sits underneath that and is required as well as part of as part of your setup. So we’re not cutting any corners here or anything like that. Basically, the edge bridge basically takes existing data in in in the analytics format, and makes it something that’s usable in the context of edge data collection and the solutions that sit on sit on the other side of it.

A couple of other questions that came in. Donald asks, does this navigate around cookie consent? It doesn’t. So with mobile SDKs, specifically, the concept of cookies is a little bit different than what we see on the web. But that being said, there, we do have a consent extension that allows customers to opt into into data collection or opt out. And then the SDKs will will actually respect whatever whatever decisions that the end user has made there. So doesn’t necessarily get around but things are things are a little bit different when it comes to mobile with the mobile SDK. But ultimately, the concepts are the same in terms of opting in and opting out.

Okay, another question from Kyle, are all metrics and dimensions supported with edge bridge, for example, lifecycle metrics, in addition to customer events and dimensions? Yeah, great question. So all of your custom events and dimensions are supported. So if you if you’ve got evars or props or events, or even the product string that you’ve instrumented in the mobile app, all of that’s going to flow over and continue to flow into to analytics without any without any modifications. Same thing with context data as well. So if you have a bunch of processing rules that you have configured in analytics, you don’t have to reconfigure those, you don’t have to map them in in data prep. All of that data will continue to flow through assuming that you’re sending the data to the same data stream and that you keep those processing rules in place. So you don’t really have to worry about about making any big changes here. Daniel, there was another part of the question, but I forgot what it was. Can you lifecycle data? Yeah, so I’ve actually the next slide is about lifecycle and some of the changes that are that are happening with that. Do we have more questions? Or should we go ahead and move to that? Let’s let’s move to that. And then we can. Okay. So yeah, things are changing a little bit in terms of lifecycle. I think that there are probably two big changes that you need to be aware of. So in the past, we had kind of a session timeout when it came to lifecycle. And what that meant was that you could possibly launch and then close the app multiple times. And as long as that timeout wasn’t bad, then we wouldn’t be sending additional lifecycle calls. Now with lifecycle, basically, we are we’re sending those requests every time the app launches and every time you close it. And so there are going to be some changes in terms of how we’re collecting that lifecycle data. And but but what you’re going to notice as a result of that is that we’re going to see more accurate session length information, which I think is an overall plus. The other thing to keep in mind here as well is that with older versions of the SDK, we used to append lifecycle data to every single request. That’s changing. So so we’re no longer including all of that additional information on every single request that sent to the edge. Ultimately, what that’s going to mean is that using CJA, you’re going to be able to to continue to capture the information that you need to, but it’s going to be done in a slightly different way. So here I’ve got two links to both lifecycle metrics and lifecycle behavior. This kind of outlines some of the changes and some of the things that you need to keep in mind as you’re as you’re going through the process of migrating to edge bridge, because there are there are going to be some differences in terms of lifecycle specifically.

Mm hmm.

There was one. I’ll try to rephrase it as a question is about the data object and XDM. Rajdeep is saying so this approach isn’t equivalent to the data dot underscore underscore Adobe approach. I think you were saying earlier that it takes your existing older SDK implementation for analytics kind of treats that as the data object as a data. So if you’re doing this on the web, there’s a little bit of legwork that needs to be done in order to be able to convert your data into that data underscore Adobe object. But with the edge bridge, you don’t have to do any of that legwork here, we’ve done all of it for you. And so you’ve got the same implementation, you just drop this extension in and you’ll see that that data is flowing in the exact same way that it always has. So that is one difference but but we are still utilizing the same back end, all of the same all of the same functionality. Ultimately, everything that that you do with the edge bridge is going to be focused on converting that data into that into that data underscore Adobe analytics object.

Is there some way or at some point when using our debugging tools that you would see that data dot underscore underscore Adobe, like, would you ever see that object like, and absolutely. And that’s actually something that Kevin’s going to demo for us right out the gate. And we should probably start to try him because he’s put together a really awesome demo that that shows every every single step that’s required in order to make this transition. Great. So should we make that switch? You also have Kevin, let’s do it.

I’m good. Okay. Wait, my screen is showing. Yeah. Okay, so, um, yeah, so so thanks, Mitch. I’m Kevin, and I’m going to demo. I have an application that uses the mobile SDK analytics extension, and I’m going to show how to migrate that to use the edge bridge extension. So first, I want to introduce you to the app that I’m using here. It’s a simple app that has some track action and track state calls for, you know, booking a hotel suite. So here, and then I have my assurance session open. So you can see the events coming in, have some track state on on page view changes. And in here, some track actions for reserving the suite. And another track action for cancellation. You can see the analytics responses coming back for the post processing data. Next thing we also have, if this came in yet, we have this real time analytics report showing. You can see here the page views have come in the product listing, I’m using a product string to list which suites are being viewed.

And also some custom insights for the for the actions. Okay, so the first thing we need to do is we need to go to Adobe Experience Platform data collection. And we need to create a data stream. And so the data stream is going to be the configuration that tells the edge network where to route the data once once it lands there. The first thing we need to do for the data stream is just give it a name. Um, and as Mitch said there’s an option for mapping the data to XPM. But in my scenario, I’m taking out analytics and putting everything in through edge bridge and then having it go directly into analytics again. So I don’t need an XPM schema and I don’t need a data set here. So I’m just going to click Save. And then the next thing now that I have my data stream set up, I need to add a service for that. And I’m going to add in the analytics service, need to give it a report suite name. And in my case, since I’m removing analytics from my, my application, I’m going to use the same report suite that I had previously for analytics. Um, if you are using if your application is going to use both analytics and edge bridge, which is possible, you want to make sure you’re not sending it to the same report suite, because then you’ll get double double counting on all your hits.

Dave, then that’s it. That’s all we need to do. One, one note is that this is all new for our latest version of edge bridge that came out earlier this year. This is a version five on iOS and version three on Android. Previous versions of edge bridge did require a mapping step to map the data to XDM. But that’s no longer required because of the data format changes that we made within the latest releases of edge bridge. So the next step was we need to go into our tags mobile property under data collection, but I already have it tabbed here. So this is my mobile property. As, as I said, I already have the analytics extension assurance and mobile core. So I need to go in and everything that you currently have with with the app that you were just demoing. Yes. So this is what I have with my current app. So got it fairly simple app, but with analytics setup. Okay, cool. So on the on top, we’re just going to layer the the edge, the edge bridge extension. Yes. So we’re going to add in the edge extensions for this. So first, I want to add in the edge extension, which is under this part, it’s the Adobe experience platform edge network, long name, click Install. And in here, I need to add in the data stream that I just created. If I can remember, I just did.

That’s right one. And then for each environment, I’m going to use the same one. At least for for my example. Let’s save.

Alright, and then to use the edge extension, we also need to include the identity extension. Now this case, it says identity, but this is technically the identity for edge network extension. I’ll show a little later, we do have two identity extensions. Okay, so adding that there’s no configuration for it.

And also, in my case, I want to add in the consent extension.

So the consent extension, technically, for example, is not required. So it is kind of optional in this case. However, if you want to be able to control, have your users control whether they are opting in or opting out of sending analytics data to the edge network, then you’ll want to use this extension. So in my case, I’m just going to have it say yes to send, send the data as the default. Okay, so that’s all I needed to do. I’m going to keep the analytics extension here within the configuration. And then the reason is because it’s going to take time for users to migrate to upgrade from the current application to the new application that uses edge bridge. So we want to keep the analytics configuration here. So it doesn’t break any any users current versions of the application. The final thing I need to do is, as Mitch was saying that there were some changes to the lifecycle flow. In particular, we added two new events for when the application launches and when it when the application closes. And those are not automatically sent to the edge extension. And we did that because we didn’t want to automatically opt customers into using the lifecycle extension if they didn’t want to. So in order to get those events to go to the edge extension, we need to create a rule that would forward them. I’m just going to go and create a rule. I already have all this in my tool tips. So that makes it easy. And then for the events under the extension mobile core, there’s an event under application lifecycle called foreground. That’s for application launch. And I want to trigger it also on same thing but for lifecycle background events. And then for the action, use the extension Adobe Experience platform edge network, and forward event to edge network. Save that. Go into my publishing flow. Add all the changes and save.

So while that’s building, basically, we’ve we’ve configured the edge extension, we’ve got edge bridge, well, we don’t have edge bridge, but we’ve got identity, we’ve got consent. And then we’ve also created a new rule that’s going to descend in our lifecycle metrics now when we’re launching the app and when we when we close it as well, or when we back right. Okay, that’s correct. And then that’s a good point. So there is no card in launch for the bridge extension for the edge bridge extension. That is just something that in your application, you’ll need to add in. Um, so for the environments, we the applications already set up for this mobile property. So we don’t need to copy the environment file ID or anything at this point. So now what I’ll do is I’ll go to my application. Running, so I’ll stop it. So this is a Swift UI application. So I’m here in the, the application class. In your application, you might be using an app delegate, or obviously in your Android applications to be using an application class. So this is all very similar code between it. So here I have the code to register the extensions and the code to set up lifecycle callbacks. So here, what I want to do, sorry, well, the first thing I need to do is I need to actually go in and add the extensions within the Swift package manager. Now again, this might be different for your setup if you’re using CocoaPods or Gradle. So first thing I want to remove analytics, because in my case, I don’t want to use analytics anymore. And then what I want to do is I need to go in and add all those other extensions that I had before. So I have the edge extension, target, add an identity.

So you want to keep the analytics extension in the tags or launch property, but you can remove the library from the app itself? Yes, because the launch property of the tags property contains the configuration for it that is downloaded when the application when the SDK launches. Okay. Yeah. So, and then so for I mean, different from web implementation for mobile implementations, you know, there’s still going to be some customers using the older app, they, you know, they won’t all upgrade to the new app at the same time. Okay, so that’s consent. I think my earbuds falling out. And then in this case, then we want to just add in edge bridge too. And one note, since these are recently used these pop up for me, you can put in the URL for for the GitHub URL to search for them. And then those are all on our documentation to under developer.adobe.com. If you go to the current SDK versions, under iOS, you can see we have links to all of our open source repositories for all of our extensions that we have.

Edge bridge, add okay, long as that all gets resolved. There’s a package for edge bridge that you add to your app. But there’s no extension in tags that is called edge bridge.

Okay, yeah. So you won’t have that in your configuration for your tags extension. Um, so same thing here. I need to do is I need to remove the identity extension and analytics. So for me, I only have the the analytics extension, which uses the identity extension. So So in this way, I can remove the identity extension. However, if your application is still using things like target or campaign, you’ll still need to keep the identity extension because those extensions will still use it.

And then I’m going to import the edge consent to edge identity and edge bridge extension. Um, and then for the list of extensions to register, move analytics, and included edge consent and edge bridge, you’ll notice that the for identity, the edge identity extension has the same class name as identity. And we did that. So it’s an easier drop in replacement between the two identity extensions. One notebook, because I did mention if you’re, you know, using analytics, or you’re using another extension that requires identity, you can use both identity extensions in an application at the same time. Um, when that edge identity extension first starts up, it will actually read the EC ID that that exists from your previous implementation for the identity extension. And that’s regardless whether you have it registered or not. Um, however, that’s the only identifier that gets copied over if you have custom identifiers that you set into into identity, you’ll have to use the new edge identity API’s to also set that identifier so it gets sent to the edge network. So these are the changes. If you I go here, I have a little utility class which I handle my track calls, and I don’t have to make any changes to the data I’m sending to the track state calls or anything to my, my track action calls. But there’s no changes there. All it was is that I needed to import the packages and then change the listing of the extensions that I’m using to use edge bridge. Let’s see. Launch the app. And then go back to assurance. So now that we’re in the analytics events view, to be able to see the edge events, we need to toggle this, which it automatically already did for me, just to do the analytics edge view, as opposed to the analytic strict extension views. So here you can see we already have a track state, which was for the homepage here. And we also have these new application launch and application closing application launch events from the from lifecycle. And as I click through the app, can still see I’m getting the same track state calls in reserve room, the track action calls are coming in in again. And then I can cancel the reservation, another event comes in. So that was all I had to do to get this to get to migrate the app that uses analytics to go into use edge bridge. And then here in this analytics events view, you can see it shows the event coming in, you can see the data that I’m sending. So this is all the context data that I passed in using the events products, I have a custom property here. I also have a few custom context variables for reservation status and username. In analytics, I have a processing rule, sorry, that converts these to Prop one and two. And then here it has has the events for all the steps along the way that that handle this event. And in the end, we have an event that comes back from analytics that says here’s the post process data that we received. So one you can see, go all the way down to the props, you can see that my processing rules has has properly configured the reservation status and the username. So all that shows up in here. Another view that we have for looking at, oh, sorry, I want to show one more thing is that when the application goes into the background comes back to the foreground, oops, open the app again, there we go. We’ll see the application launch and close events coming back in. So this is going to happen every time that the app goes to the foreground and comes back to the to the background, it comes back to the foreground. But that was one of the changes that that Mitch pointed out. Nice. And this this tool that you’re using? Is this? No, this? Are you in? You’re in assurance here, right? Yeah. Is that something that users of mobile SDK before edge would have had access to? Or would this being new to customers using edge for the first time? This is something that customers would use even beforehand. If you if you notice at the beginning of my demo, I was actually showing assurance with analytics direct. So we do have views the same view here for analytics events. If we toggle this off, you can see here, everything new that came in is all you know, not working. But we still have all the old events too, that came in that that’s not old events, but the events that were sent direct to analytics. And then we toggle this, then we then we get all the extra data that comes in for for the edge views. Gotcha. There’s also when using the the the platform, we have this events transaction view, which kind of gives more of a graphical representation of like swim lanes of where the data is coming in and being processed. So for example, let’s get through some better events here. So here’s the client set event. So this is actually the the request that’s coming off the client.

It shows the xtm I like using the JSON view, it’s just a little easier. And so this is this points to the question I was asked before about the underscore, underscore Adobe field. So this is the data that’s actually being sent. So you if you remember, you know, I had some custom context data for username reservation status here, and also had the product string, events, and Prop three. So these get elevated outside of context data, you know, their ampersand prefix is removed. We also add in the automatically the application ID. And we also add in customer perspective. The action name in this case is set as link name, and also link type of other. So in your analytics workspace, this will be considered a custom link. And I’ll also show this and in so in this is the analytics service. Here’s the mapping. And so what happens, there’s additional mapping that gets done in analytics when it receives the data. And in so for mobile applications, it takes that link name and converts it into a dot action so that in analytics workspace, the action name is also set up correctly too. And you can see here, this is how the data gets mapped. But then this is the then it shows the event for the analytics hit. And this is the actual data that gets sent into your analytics report suite, you can have access, look at the KV data that gets sent in. So this is handy too, if you’re, you know, doing some queries on some raw data and stuff, you can see exactly what’s being sent in.

And so for this configuration of your app, there are two calls that are going into analytics, the one based on the configuration of your analytics extension and tags. That’s the analytics event. And then there’s also the one that the call that goes to edge and gets sent according to the data stream configuration that you did at the beginning of your demo. And that’s why you are cautioning about configuring the same report suite for both the data stream and analytics extension. That’s for customers who want to use both analytics and edge bridge together. And so some customers like to do that because they either want to do a comparison or they’re actually only migrating, you know, part of their application.

So what that would do is that that will basically take so every track action and track state call would get sent both to analytics directly and to the edge network. So in that case, you don’t want to use the same report suite. In my case, I removed analytics altogether. So I’m no longer sending data directly to the analytics extension, it goes into my report suite from the edge network. So all my network calls for from edge bridge, and if I make consent changes, everything will go through the edge extension that goes directly to the edge network, there’s just the one endpoint. And then from there, the configuration that we had in the data stream tells it that we want to take all of our data and put it into analytics. Analytics has a translator or this mapping, which will then read this data and put it into a format that analytics can read to put into the report suite. And so here, this is also my track state call, very similar, adding in customer perspective automatically and app name, I had events and products. And then the state variable within the track state gets automatically put to the page name, which then analytics will get this update.

There we go.

Analytics puts into as the page name in the GN property.

And then the next steps, if you wanted to add platform apps, you would add additional services to your data stream. And if there are platform app, you do that XDM conversion, right? The data prep mappings that Mitch was talking about? Yes. So this is back to my data stream. You can see I just had the analytics service. It’s very easy now that the data is going there, I can add in Adobe Experience platform. Here, I do need to include a data set. This is basically where the data will land. I can do this one. I can save that. Now this will actually only take the XDM data. The data that we’re sending from EdgeBridge doesn’t have any XDM to it. So it’ll, well, 100% true. Let me show you. For every event we send in, we do send in basically the timestamp and event type. So EdgeBridge automatically sets the event type to analytics track for both track action and track state calls. If you really want, you can use the data prep mapper and you can overwrite this value if you want to have specific values depending on the data that you’re sending in. Let’s see, back here to my data stream. So I add this in. This will actually then receive XDM data. You have the mapping work. I have to edit the data stream itself and add in a schema for it. Let’s see, I think it was that one that I had before. And then this goes through the whole walkthrough for doing the mapping. We’re not going to cover that today because this is going to be a whole other topic. And also the schemas that customers use are specific to their data and their application. So there’s no one set schema that would be used. But this is how that would handle.

Yeah, so it seems like from your demo, it’s mostly UI based changes and then some updates to the packages in the app. And that’s it? Yes. So in my example, I mean, it was pretty basic just using analytics. But all I had to do is just swap out the extensions. There’s a few more extensions because Edge is kind of a general based networking extension. And it’s not very, it’s not specific to analytics, it’s not specific to lifecycle.

So it receives basically all the events that are coming in.

And then changing the identity extension and adding an edge bridge, which then converts to track state and track action calls, adding these to the extension list to make sure that they get registered correctly. And then outside of that, there’s no changes to the track state track action calls. And there’s no changes to your lifecycle implementation. As I said, I had this all commented out. But here you can see this was this would be an example of if you’re doing a sync identifier with a custom a custom identifier for a user, you would have to translate that and set that to the new Edge identity. Oh, okay. Yeah, so that would be a change if you’re using custom identifiers. Okay, good.

Yeah, but the ECI should, but the EC ID value gets automatically transferred over. And so if you’re using both identity extensions, when they first sync up, then they’ll both be using the same EC ID value. Okay. And Raj just asked, I was asking about this earlier, would just one still need the analytics extension in tags? Oh, yes, let me show you that. And so the reason for this is because what tags does is it provides the configuration for the SDK. And it provides it for all the applications. So if I were to go in and say, I want to delete this right now, I would have to disable it and delete it, then the analytics configuration would no longer be provided to any existing applications. So you might have some users that haven’t upgraded to your new version of the app yet. And then that analytics would fail because there’s no more, there’s not configuration for it anymore. So that’s why you need to keep it on. And then you can remove it when you know that all your users have, are no longer using the version of your application that uses analytics. Okay. I see them. That makes a lot more sense. Yeah. Yeah, but with EdgeBridge, with Edge and EdgeBridge, it doesn’t use any of the configuration that’s set up into analytics here. So for me, I just have my report suite and some flags for offline enabled and stuff. But it doesn’t look at any of this anymore. So once you know that your customers are no longer using the version of your application that uses the analytics extension, then you can safely remove it from tags. And what’s the best way to know that no one is using the old version of your app through analytics reports? Yeah, it’s tricky because you could just get a customer who hasn’t been interacting with your app for a while and then somehow fire it up. But it’s always safe to even just leave it in there if you want. So it’s just best on how you want to manage your application. Okay. Well, great, guys. We’re a little bit over time. I appreciate your generosity, sharing everything with us, including your hobbies. And let’s just end it out with an unrelated cool tip. So I’ll give the unrelated cool tip. This time, this is if you grow strawberries, maybe frustrated with all of the squirrels and birds that eat those delicious red berries, just as they are ripening. So the tip is you take a little rock about the size of a strawberry, you paint it red, you put it in your strawberry patch, and those silly animals will think those are the strawberries, try to eat them, and get discouraged and they’ll leave your bed alone after that. So there you go. Cool tip. Mitch, Kevin, thanks again. And thank you for having us. Appreciate you giving us the opportunity to show some of the stuff that we’ve been working on. My pleasure. Take care. All right. Thanks, everybody. Appreciate it. Thank you. Bye.