Join Mark Stringham, Co-Founder of Metric Partners Consulting, and Mike Maziarz, Product Manager for ObservePoint, for the webinar DTM to Launch: How to Ensure a Smooth Migration.
Discover how to:
- Implement a 4 phased approach to seamlessly execute the transition
- Automatically validate your migration at every point to ensure accurate data collection
- Identify and overcome common migration challenges
All right. Well, hello everyone. My name is Aunica Vilorio. I'm the Partner Marketing Specialist here at ObservePoint, and I will be hosting today's webinar, DTM to Launch: How to Ensure a Smooth Migration with Mark Stringham, Cofounder and Adobe Analytics Architect for Metric Partners, and Mike Maziarz Product Manager here at ObservePoint.
Mark Stringham, Co-Founder of Metric Partners, is a seasoned technology professional with 15+ years of experience in digital analytics. Mark has consulted, implemented and managed the success of top brands in digital analytics, including Fortune 500 clients in the media industry, and is passionate about client relationships, team leadership, technical consulting, implementation, and business development. Mark has architected Adobe Analytics measurement strategy for brands of all sizes and considers himself to be an Adobe Launch evangelist.
Mike Maziarz is a Utah native who loves golf, basketball, and data. Before coming to ObservePoint, Mike worked for technology giant Vivint Smarthome, where he was responsible for workforce management, retention, and business intelligence. Mike has been with ObservePoint for over five years, first as a data governance consultant, and now as the product manager.
Now before we begin, please note that we will be doing a ten minute Q&A at the end of the webinar, so please enter any and all questions or comments in the chat and we will address them at the end of the presentation. With that I’ll turn the time over to Mark.
Thank you so much. And thanks everybody for joining today. I'm really excited to be here and spending some time with ObservePoint as well. So, you know, when you think about a DTM to Launch migration there's a lot to know, and it seems like a pretty simple process and for many people it is. And so, you know, if you think about it, many of you have probably already said, okay, I'm going to upgrade to Launch. And so, I go into DTM and there's a little button that says upgrade to Launch. And that will actually start a process. So, Adobe actually has APIs on the back end that will take you, it will actually migrate your properties from DTM to Adobe Launch. There's nothing that you have to do except for push the button.
And that process will automatically begin. What they do at that time is they will then start to migrate the extensions that you have in DTM, data elements, rules, and conditions, custom code where applicable, anything that anything that can be migrated to Adobe Launch will be migrated with that simple step of the upgrade to Launch button. So, this is really a five-step process. And one of the first things that you'll want to do is inside of Adobe Launch, once you go inside of Adobe Launch, you have the ability to then access the Adobe Launch activation code or the script. If you've, used DTM in the past, this is the exact same script that sits at the top of each page, usually in the head of each document that you're going to track.
And you can, you can actually go inside of Adobe Launch, grab that script and do a replace. Now some of you may be asking, "Gosh, you know what I know that I don't have to do that, or you don't have to do that right away." And, and you're exactly right. Adobe has actually said, if you want to keep your DTM script in place when you migrate and push all of that information via their APIs to Adobe Launch and the new property is created, then that's exactly what will happen. And so, Adobe actually says, if you want to keep your if you want to keep your DTM script up there, because maybe you don't have the time or the dev resources to make that switch, you can do that. So just from my perspective, and maybe it's because I'm kind of obsessive compulsive about making sure things are done correctly, we recommend that if you can, that you do make that switch from that, that you do replace the Adobe Launch with the DTM script with the Adobe Launch script, if you can.
And there's, there's a couple of reasons for that. We'll get into a little bit more about that in just a second, but again, one of the first things you want to do when you migrate you push that button, you'll want to be able to test whether your migration is complete. And by that, what I mean by that is all of the things that get transferred or pushed over need to be working exactly as they were when you had them within DTM. So that's the goal of any migration. The goal is to make sure that whatever you had working at the time of that you migrated from DTM to Launch also now works in Launch. And so, we're going through the process of making sure those things will happen. So, again, the first step is to add the DTM or, excuse me, the Adobe Launch script in a dev environment, so that you can then begin to test how the migration will react now within Adobe Launch.
Step two. So, Adobe Launch is actually built on a framework. So, if you think about tag management for a second, tag management is really just an execution too. It's designed to execute what you tell it to do. So that means tags or third-party tags or analytics, or you name it that a number of things that can run through a tag management. So, Adobe has actually installed their own framework, which is called Core. And that's an extension that you will see as you get inside your newly created Adobe Launch property. And the Core extension actually gives you all of the access to the Adobe functions and core pieces of Adobe Launch that are necessary. That will come out of the box out of the gate. You don't have to do anything with that.
If you were an Adobe analytics customer or user, then this extension and all other extensions should be migrated. What's important here is actually what you should look at within your extension that that can be, that could potentially cause problems or think there are things to consider. So again, step two, let's take a look at our extensions. So inside of inside of our extensions, there's a number of things that we need to look at, you know, do we have the right configurations? Are we actually hosting our own library? And if we are, what does that now mean for an Adobe Launch deployment in this, in this screenshot, what you see is this client actually hosting their own library. So, they have an app measurement library version it's quite old from years ago.
And so when you go inside of Adobe Launch, you can actually see whether Adobe is hosting the library or whether you're doing something unique. And so what you see right here, you see the custom library that the client is hosting in Adobe Launch. You'll notice up here on the right, on the left. You see two red dots. Adobe Launch has the ability to kind of go through your code and tell you if you've got errors or issues that you need to worry about. And in this case, there are at least two items that Adobe Launch has flagged as potential errors. Well, you might say, "Well, gosh, it was working fine in DTM. Why wouldn't it work in Launch?" That's a great question. And we don't know. All we do know though, is that Adobe Launch actually behaves differently than DTM.
And so how things are configured or factored or your custom code is presented in your configuration, excuse me, in your extensions matters. And so, in this case, you might say, "Well, you know, hey, they're hosting their own custom their own library. And so, what should you do in this case? And so, in fact, we have multiple clients right now that are doing this exact same thing. They're hosting their app measurement library themselves, because they had to do some customization somewhere down the line and they've got issues like this. Well, as, you know, Adobe now offers, or continues to offer, to host the library for you and update it for you. And so with very little, I mean, there's very little exception as to why you shouldn't, or can't host the library yourself.
And so our recommendation to this particular customer would be, well, number one, let's take a look at the code that you're using and what might be an issue. But you know, honestly we want to we want to tell them, "Hey, you know what you need to, you need to let Adobe host that code so you don't have to worry about any upgrades, excuse me, or migration or anything like that." And so, again, this is an example, this is a live example. I have several clients doing this exact same thing where they push the button they migrated and the code that was working in DTM is not going to work in Adobe Launch because of the way things are the way things are designed in DTM. And so the same can be said in your extensions where you have custom code that you want to, maybe you have a do plugin section or something like that. That's a very common set of code that that's custom. Well, the same thing should be done there. It needs to be reviewed. You need to see, "Hey, will this actually work inside of Adobe Launch? And in addition, is there a better way for us to do what we're doing or what we were doing and DTM, is there a better way for us to do that in an Adobe Launch?" Excuse me. okay. So, step two is you gotta check your custom code and check your extensions to make sure your configurations are good and make sure that your custom code is going to work within Adobe Launch. One thing I wanted to share, actually, we just saw this yesterday, so I want to share something with you that we just found. I'm actually gonna share my screen.
And this is the same property. If I go to my data elements now, again, this is a migrated implementation from DTM to Launch. So, everything that was working or was in DTM is now in Adobe Launch. So that includes their data elements. So, the elements will be passed as well. One thing we found interesting that the way that the client actually named their data elements, they actually named it with colons and periods and things like that. We found that that kind of naming convention works fine in DTM, but in Adobe Launch, it doesn't. I don't know the reason I'm assuming that a data element would be a string. So I don't know why that would be a problem, but that's also something that you should be aware of is that when you go through and look at your data elements and other things, you might have naming conventions that no longer work in Adobe Launch.
So what that meant for this particular client was, well, you know, they were pulling things from the data layer, they were using the, the data elements and their global page load rule. And then all of a sudden it stopped working. And we figured out it was because of the way that the data element was actually named. They were using periods and colons and things like that. So, I thought that that was very interesting. And I wanted to share that with this group, because naming conventions matter. Don't assume that when you migrate and push that button, that everything is going to be fine. In many cases it is so Adobe has made that process very clear and very easy for most, but also if you've got custom situations, those things need to be reviewed and tested. So I'm gonna jump back here.
Okay, so that's step three, step four. This is a solution design. All of you should be familiar with this, or at least know what it is. It's a variable map, right? And as you are, obviously as you migrate to a dev environment and then do some testing. You've got to do use case testing. Use case testing means what are the key conversion paths, funnels, events that matter to the business, you've got to make sure those are tested because the goal with this migration is that you should have the exact same data in Adobe Launch that you had in DTM. And the only way to do that is to really test your implementation.
So that's a question. Has the migration been fully tested and what use cases should be considered? You know if I've got an econ funnel, all of the steps of that funnel, click action, click activity, different things like that, all of those things need to be tested within Adobe Launch to make sure that the code that you've got is going to work as designed. And actually, we're going to get into some great ideas and great ways that ObservePoint can help you in this testing process. ObservePoint has been instrumental in helping us identify certain issues between the migration. And I'll show you an example of that in just a second. But again, step four is you've got to test that migration in your dev environment before you go to production.
You know, obviously once it's been tested guys, it's time to publish with DTM, there was kind of a two-step process, right? You kind of saved you saved your changes in a staging environment, and then you published to production. Well, the publish process is much more rigid and structured in Adobe Launch. And I'm preaching to the choir to many of you. So, this is nothing new, but you need to remember that obviously you've got to be able to publish, to be able to test. That doesn't mean that you need to be, you know, if you're going to test in your dev environment, you don't need to publish to production to do that. Obviously, you're just going to publish to the environment where your Launch code is, and that's a great place to start, but you're not going to be able to see anything until your property is published in the proper environment. So that's kind of a no brainer, but it's just something to be aware of. Also note that when the migration happens, that there are no builds created. So, what you're looking at here is a screenshot of the same client that's done a migration, and there's no build for them to look at. And so you've got to create that build it also may mean that you've got to review that process to make sure it's done correctly.
So, kind of getting back to the, the question of how ObservePoint can play a role in helping you validate well, it's obvious you think, "Well, shoot, maybe they can help me look at my solution design and look at data as it comes in, or look at data as the image request goes out. And sure, that's an awesome way to do it. There are many other opportunities here for ObservePoint to help us. But the key here, I want to stress, you have to have the same data in Adobe Launch that you had in DTM, and you might be thinking, rolling your eyes like, "Of course, Mark, why wouldn't you do that?" Well, that's actually a big concern people. The clients that that we work with, they're like, "Well, am I going to have the same data? What happens if I migrate how does that, how does that work?" And so, a tool like ObservePoint, that's exactly what, what you need to make sure that the data is the same across the migration platforms. Let me give you an example of that.
This is kind of small. And so, I apologize, but what you see here is actually data coming directly from ObservePoint that shows two columns there that are outlined in red. The first column there, is on the left, is our page names that were found with the current DTM deployment, the column on the right, the second column in that red box is actually page names that were found after the Adobe Launch migration. So this is a great example of how a tool like ObservePoint can help here, because you can see in the column on the left, you can see that we actually have page names that were not picked up with the current deployment in DTM, but on the right Adobe Launch, pick them up. And so, what that tells us is that there are timing issues. Now, there are timing issues, Adobe Launch, behaves differently in certain circumstances, and it looks like for the better, because now you've got page names and you've got a whole slew of other things that are picked up where in DTM they were not. And so again, that's another really important part of your migration. You know, we can't just assume that if we push that button that everything's going to work like it did before. We looked at custom code, that that could be a factor. We looked at data elements that could be a factor. And now what we see is just typical performance. So, there are performance issues to consider and not necessarily for, it's not a bad thing at all, but to what you're seeing here is that Adobe Launch behaves differently. And we'll talk a little bit more about that. As we talk about, some things that ObservePoint can help us to do.
So with that, I'll turn it over to Mike to talk about how we can use ObservePoint in a four phase approach to help you in this process.
Awesome. Thanks, Mark. Really awesome stuff there. And we're just going to be building upon that and kind of going a little bit deeper and teach in those areas. So really appreciate you setting that up. So, Mark, broke it down into a nice five-step kind of process. Five steps sounds so easy, right? But you know, there's a lot of details to those five steps. And so, we're gonna try to help there as well and look at this, you know, cause when it comes to migrations, now there are a lot of moving parts and it can be easy for you to become overwhelmed. And so whether it's from copying or recreating all these tools, rules, and data elements that the Mark mentioned, you know, updating some deprecated methods to ensure there are no errors thrown, making sure everything still works correctly and there are no gaps in the data, the list goes on and on. And so to help we've broken up, broken down this process into four smaller phases, which will also point out a lot of areas where you can automate these phases as well, as much as possible, to make it even easier.
So the first step we're gonna look at here is phase one catalog. And so, what I mean by this is, so at a minimum your kind of the goal of a successful tag management migration is to maintain at least status quo of your analytics tracking. So, while you're moving from your legacy to your new tag manager solution, you're going to hopefully at least keep the same baseline. And so, because that's the main goal, you'll want to establish that baseline or a snapshot or a catalog of your current implementation, that you have something to check against as you create your new mutation with Adobe Launch, and you can do this one of two ways. You can either get this catalog or tag inventory via manual efforts or automation. So some things to consider if you're looking at either of those options you know, if there's a manual approach, just keep in mind that could take some more time than it would with automation as well as more effort on your part.
And you know, you may not be able to get as deep into your site or check everything just because of abandonment with the automation it's much easier to grab a list of what's on your site currently. You can do it faster, you have more depth and you also remove that human error component as well, so you have of greater accuracy. And one other nice thing about doing it with the automation is you, basically, are creating tests, which you can reuse. So, as there's multiple phases of this migration you could reuse those tests, you know, from a dev to staging to production and then continually as you're always making changes and updates to your site.
So the next step here is strategize. So now that you've kind of gotten that catalog the next step is, you know, what are the options you're going to go with? Are you going to go with manual testing options? So, there are some tools out there to help you. If you go for the manual testing option, you've probably heard of Charles Fiddler even your Chrome dev tools. Chrome has probably the best dev tools of all the browsers out there for you to sift through that network traffic and then parse out those requests. There's also the ObservePoint tag debugger. So, we have our premium solution, which will do a lot of the automation for you, but we also offer a free tag debugger as well. You can download it directly in the Chrome store. It's, I would say, you know, obviously a little bit biased, but I would say it's probably the best tool that you can use out there. And you can even do some exporting, record your user flows all within that tag debugger. So, I would definitely check that out. And then, like I said, we have our premium solution as well, like a tool, like ObservePoint that can do this to automate testing for you. So you know, just kinda reiterate again, it allows for a much better experience that you can, you know, set up these scans and you can apply a rules so that way you're alerted, you know, if something doesn't match your expectations. So if you've set the expectation to be this that you have in DTM, and you want it to be the same you know, ObservePoint can alert you and point out areas in your site where it's not matching you know, down to the page level tech level and variable level and not just for an Adobe tag for all technologies.
So let's jump into the next phase here of the actual migration process. So, there's two different methods you can go with. There is the lift and shift. So just kind of taking what you have and moving it over, as much as you can, or starting fresh. Now, if we're going with the lift and shift method it's probably because you either have, you're pretty happy with what you have, or you have a relatively simple implementation and that you don't wanna change too much. So, you could probably use this, that magic button that Mark mentioned of upgrading to Launch. So, one of the greatest benefits of this option is that you won't have to replace your DTM embedded code as part of your upgrade process. Adobe will actually just link your old DTM embedded code to your new Launch mutation. So you won't have to go back and switch code across your site.
Now you can't deploy DTM and Launch on the same page to work in tandem if you do this method because they're using the same satellite object and so once you kind of do that, you're using one or the other. And then also as you kind of do this process, you want to make sure that you double-check that you aren't using any deprecated or unsupported satellite methods before making this change? And I believe Search Discovery actually has a tool that can, you know, doing a quick assessment for you on that to verify that, you know, if you do this method, it'll pour over just fine for you. So here's some basic steps to consider when you're doing this migrate to a Launch button.
So the first thing, and this is kind of a reiteration of kind of what Mark said, but you know, you're going hit that upgrade to Launch button, find your new property in Launch. Second, you can do that test and dev. So, development environments in Launch are intended to be used as you iterate through changes to ensure that the business logics you're configuring actually behave as you expect. And then you can test and stage. Staging environments in Launch are intended to be deployed on your own staging environment. So, this would be one that's very closely related to production as much as possible. This is a good area of where you can actually implement ObservePoint's, or doing your manual testing, and do your test in this kind of environment, cause it's going to mimic as much as possible your production environment. So, you can get a really good idea. Oftentimes use those same automated tests that you have configured for production. You can use this same environment as well. So, getting a really good feel before you make this transition.
And then step 4, you know, link your Launch production environment to your DTM production environment via that embedded code process described above. And then lastly, you can publish the prod, that's step five, that Mark mentioned as you post to prod. Your thoroughly tested, hopefully process, you know, we've talked about here in step three and four, will be delivered into the browser immediately. So, because this Launch container tag will overwrite the DTM one, your browsers will already retrieve this information. So, some benefits to this approach, the main benefits of lift and shift is that it's relatively hands off. Your data elements and rules, including custom code will be migrated over to Adobe Launch. Once you push in Launch to production your embed code will automatically begin referencing that Launch script instead of the DTM.
Yeah, really quickly guys. One thing I wanted to bring up with this lift and shift, this is actually a lot of what we see people say, "Well, I just want to migrate and kind of get going." One of the things that people don't recognize or realize now is, and I'm going to share my screen really quickly and show you an example of this, is that, this is, actually a live environment of Launch, and I'm going to go in and get my activation code now that goes in the head. This is the default. By default, now Launch says, "Oh, you want an asynchronous deployment." And if you're not aware of what that means, and you've done a DTM to Launch migration, that could be a problem. The reason is because DTM deployment historically is synchronous, which means top to bottom.
So as the page loads, DTM interacts with each element as it has, it happens and then the actual page load executes. Asynchronously means that some of these rules and some of the code and scripts will act independently of the actual page load itself. One thing to remember that DTM is a synchronous load. If the goal for you is to keep things as they are, or as they were, you will want to do a synchronous deployment. So, when you go in and get your activation code, this is what you'll see. You'll see the app that the async deployment. If the goal is to keep things the same, you'll want to disable this and actually get the Launch script for a synchronous deployment. We can talk about, I mean, there's lots of things to, just to discuss or consider as you want to go asynchronous. One of the benefits of Adobe Launch going asynchronous is actually designed to help with page performance and some different things, but they're all are always caveats and gotchas to that. So do not assume that if you just do a straight migration and then you go get your activation code, that asynchronous is what you should add, because there could be other things to consider with the way the page behaves or data loads or different things like that, that asynchronous will not work unless things are adjusted. So be aware of this when you go get your activation code. If you want to go, synchronous to keep things exactly the same. You'll want to go grab a synchronous load, at least for now. and then you can explore what an asynchronous deployment may look like in the future.
Awesome. Thanks, Mark, for that insight. There we go. Back up and running now. So, let's jump in here. So, we talked about the lift and shift method, and let's talk about starting fresh. So, if you're determined to start fresh, it's probably because you're open to make some improvements in your implementation. And so here are some considerations you should make for the following aspects of your Adobe Launch implementation. So, with extensions and DTM, all tags that weren't Adobe analytics or Google analytics had to be implemented as custom HTML tags. So, unless you have a special edge case, most likely you're going to want to convert those HTML tags to extensions in Adobe Launch. So, this can be done either incrementally or all at once, as you migrate. Set up will be different for each of those extensions, but here are some of the questions you should consider as you evaluate migrating those text tags to extensions.
So first, which HTML snippets could you convert to corresponding extensions?
Second, have you set up a different tracking IDs or report suites for analytics solution to correspond to your various development environments i.e. dev staging production. And then do you have any outdated tags that you should update or sunset? This is a really good time to look at what is on my site. Should it still be there? You know, let's try to do some cleanup here, some data governance, so to speak. The next area here is these data elements. So, like an Adobe DTM, data elements in Launch are dynamic values you can use within the Launch interface to pass information through different vendors. So, as you migrate to Adobe Launch so here's some potential improvements you could possibly make as well.
We talked about naming conventions. This is a good opportunity to update those as well as looking at your data layer. So, there was a big rush to get a data layer onto your site a couple of years ago, few years ago as was the new hot thing. So maybe it's just a really good time to kind of reevaluate that data layer, make sure it's, you know structured and performing as you'd expect, and maybe make some improvements at this time as well.
And lastly the rules. So unlike in DTM, where rules were divided up into page load rules, event-based rules, and direct call rules. Launch actually now has a single interface for exposing these rules. So, some things you want to consider or look at when migrating rules over from DTM as well, are, you know, is there a better naming convention for these rules we could be using? Do we have duplicate rules or rules that we could combine to possibly accomplish the same objective? And then you know, how can we use rule ordering to improve accuracy as well.
Mike, really quick on those rules that you brought up a great point, because what we see a lot of is that rules are created, sometimes they're just created because somebody needs something done and they done. So, there's no kind of, left hand, doesn't know what the right hand is doing with rules. So oftentimes we'll go in and look at a migration and it's possible that you have five or six pages of rules, right? And you bring up a great point. Is there a way to consolidate that, to make your implementation more efficient or to put, kind of put some things together that will help you not have to manage so many rules inside the interface. And this isn't unique to DTM or Launch, it's just, that's more of a framework or kind of a strategy. One of the things that we try and do with our clients and people we talk with is we've talked to them about putting together a framework that will help them to make these rules you know, make the processes more efficient. And so we actually do provide a framework that will help those, that have pages and pages of rules, consolidate them down to just a very few. And so, when you do migrate from DTM to Launch and you're looking at where you might be able to improve there are some really great ways to make that happen. And, you know, again, we can take it offline, but anybody that's interested, we actually have a framework that we that we deploy to help people consolidate and make your implementation more manageable and more efficient and scalable, as opposed to just adding rules and rules and rules. And how do I manage this and where does it live and things like that. So just want to throw that in there.
Awesome. That's a great call out. And that's why we're having the call, you know, so you can point out those ways to make it easier. So I appreciate that.
So let's, let's jump into kind of the bread and butter of ObservePoint here is the actual testing part. And so, when you think about testing, the essence of testing really is comparison. So, whether you're comparing your Launch implementation against documentation or against, you know, production to a previous staging environment, whatever that may be, that's kind of where you want to focus and kind of what you will be testing around. And your option for testing, like I mentioned before, are kind of that manual or automated approach. I pointed out some tools that are available to you. And so, depending on the resources you have available, and the complexity of your implementation you'll want to at least consider these areas for testing. So, first, you know, prioritize the most important parts of your site. So, your critical conversion path. So, what is is delivering, what is the money-making flow path for your site and for your business? You want to make sure that, you know, every piece of that you know, when the user clicks the add to cart button or whatever, it may be, that that corresponding measurement is firing as expected.
And so ObservePoint can automate that process for you with those journey flows and make sure that, you know, what happened before is the same as now, or if you did make a change, that change actually did in fact go into place. Then there, you want to look at here as well is your top pages. So, you can quickly get a top pages report of your most visible traffic or your key pages, or perhaps even your most popular landing pages with those critical call to actions on them, get those tested as well. And then lastly make sure that you're testing your data layer here as well. So, you can do this manually as well, just within your console. Even the ObservePoint Tag Debugger will pick up actually your data layer as well for you.
So, it'll parse out all those fun arrays and detailed information in there for you ObservePoint, with our software can do that effort for you as well. And so those are the real areas you wanna consider. If you have more bandwidth beyond this, that's great. You can, you know, jump out into various templates pages and the areas of your site as well, that would be great to cover as well. But these are the areas you definitely want to focus on. Make sure you don't miss.
Now, just briefly want to, you know, as we've kind of covered some high level steps involved with this migration, you know how Adobe has helped make it easier for you, how partners like Metric Partners can really help make this easier for you with some of their expertise and insights. And where ObservePoint's helped out. I'd like to kind of share a quick story of a joint customer of Adobe and actually ObservePoint Carnival Corporation and how they leveraged ObservePoint to make this possible.
So, if you aren't aware of Carnival, you know, they're one of the world's largest leisure travel companies. They own companies like Holland America, Princess Cruises, and obviously Carnival Cruises. They have like over 120,000 employees, 11 and a half million guests per year. So, they're doing a lot of a lot of traffic on their site to get these all booked. This year is probably a little bit of an anomaly, but you know, in general, they're generally very busy. And so, as you can imagine for all these booking flows, you know, migrating there's a lot of moving parts here and, you know, underpinning all of these efforts is a robust Adobe experience cloud implementation to collect all this user data and then, you know, serve experiences that are, are wonderful for their clients.
Now, they had kind of four different goals as they were making this transition. So, first was maintaining consistency. You know, since the systems are different, Launch is meant to be an improvement of DTM, and so some older methods were changed or deprecated and kind of making that one to one migration is impossible. Even with that, you know, fancy upgrade to Launch button, it's still not going to be the same. And these migrations are kind of a moving target. So, the carnival team frequently had to make updates to existing implementations upon requests from all the different five different brands and had 10 to 15 new requests coming in from each brand every week. So, you're trying to kind of, you know, migrate while also, you know, keeping the current implementation up to date as well.
So it was just different differences and frequent changes. There was kind of really no easy way for the Carnival team to create a single source of truth to refer to during the migration. So, it was consistently changing. This is probably very similar to many of your businesses as well.
They also you know, had a lot of volume. Since Carnival used a single DTM instance to meet the needs of all these five brands, there was a huge volume of tags that needed to be evaluated and migrated as well. Combine that with the dynamic nature of these implementations, the volume could prove to be kind of almost unmanageable if they had to manually test all this. They also, probably just like your teams, even more so now with, you know, a lot of companies scaling back cause the Carnival team was compromised of just three team members for this project. The time they could use to spend on quality assurance testing was limited as it was without even taking into account the extensive testing requirements that would come with migrating to a new tech platform. So, already hard to do, and then even harder as they're trying to make this migration. Right. So, they, they basically said, you know, going the human testing process is just A) just not possible with the time constraints, and also would be very subject to error given how many people they had. So, they leveraged the ObservePoint audits and journeys to do a lot of this work, and then they could reuse them throughout the process. So, once they kind of set up their tests across these different brands, they had them running in different environments, they're lower environments as well as their production environments. And so, something they said, here's a quote they had, they said, "ObservePoint has really been essential to our success here at Carnival since the very beginning. So, when we knew we were going to have to migrate, we already had ObservePoint in place to help automate this QA testing, and it just became a natural extension." They said, "ObservePoint is uniquely positioned to help anybody who needs to transition between these two tools. It made it really easy for us."
So, you know, it's very complex and you know, between Metric Partners and us we're here to help and make that process a lot easier. So, you know, the bottom line leveraging ObservePoint and expertise from the team at Metric Partners during this Adobe DTM to Launch migration can save time, money, and, you know, really make the task a heck of a lot easier.
So, we'll pass it back over to Aunica and do some Q&A.
Awesome, well, thanks guys. I think that was, that was really good. I think there were a lot of good insights that people will really appreciate as well.
We've had a few questions come in, please feel free as well. Anybody that hasn't submitted questions yet, we'll be happy to answer them. One of the questions that we had at the very beginning was Sharon's that said, "Was the data incorrect if there are errors in custom code. Mark or Mike, do you want to answer that?"
Yeah, I can take that one. So, in, in the case of the screenshot that I showed earlier, where there was a couple of errors in the code, it doesn't necessarily mean it was incorrect because it obviously was working in DTM. But the way that Adobe Launch looks at code and does some editing and things like that, it just means that there are issues or there's something going on with the code as it got deployed that needs to be reviewed. And so, in this case with this particular client, what we would do is look to see what the code was actually designed to do, because a lot of times custom code is doing something for you that you couldn't figure out any other way. And so, what we're going to do in that case is we're going to look at the code, we're going to find, you know, figure out what, what it was designed to do. And then let's find the best way to do it within Adobe Launch so that there's no particular errors or issues. The screenshot that I showed was really a situation where the client was using a custom app measurement library, and you know, most times now that's not necessary to actually use something like that. You can actually manage it through Adobe very well without any issue. And so again, what we would do in this case is we would look to see what the code was designed to do to make sure that that functionality remains consistent within Adobe Launch. But we're going to find a way to do it where we wouldn't have any issues. And so my recommendation for those that are using custom code like that, is that you choose to look at the option of having Adobe manage it and then take out any specific functionality and find a different way to deploy that in Adobe Launch.
We have another question talking about, "Isn't it helpful if we run the DTM to Launch assessment using the search discovery tool?” I think Mike or Mark, do you guys want to take this one Search Discovery is another agency I believe, correct.
Yeah. So, I'm familiar with that tool. You know, I think what I think anything that you can do to help you get an idea of issues that you might encounter. I think it's great. So, there's several tools out there and Search Discovery has that assessment tool, what I think that's you know, if they can give you some insight but remember that's only going to be a sliver of what is there, right? And so, they may evaluate certain things, but there's a whole different side of this that they're not going to evaluate. For example, I showed that slide of the data elements that were named that had had periods or colons in them. You know, that assessment tool is going to help us understand maybe some custom code issues, but it's not going to tell you that you've got issues with your data elements. And so, again, tools like that are awesome to help you. Anything you can do to give you a good insight is great. Ultimately, it's going to be in your best interest to work with those that know inside the tool that can help you, and that's only gonna come if you look under the hood and make sure everything's okay in your migration.
Mark might have a better insight to that than me. I don't know. I'm more of the expert in the ObservePoint side, but yeah.
I look at it in a couple of ways, you know, you obviously, you've got your core extensions, you know, your Adobe analytics, for example, or even your Google Analytics extensions that you can use. And those are designed to get you up and running quickly with your app measurement. In the case of third-party tags, if there are extensions that you can leverage there as well, that's worth exploring. Most of the time, if that goal is simply just to get it migrated as quickly as possible, and then maybe step back later and look at opportunities, most of the time the DTM to Launch migration is sufficient. Like it's going to migrate your third-party tags as they are, and usually those are custom code or custom tags. You know, the thing that I would suggest is you look at the core functionality of your site or these extensions. So analytics is one, the Adobe marketing cloud ID services is another, maybe you've got Adobe target in there as another, so I would consider those kind of core extensions. And then if you've got third party tags that maybe we wouldn't consider core, let's leave those as they are, and then, you know, do your migration and then step back later and say, "Hey, are there extensions or is there code that can help me kind of consolidate all of this?
Perfect. Okay. Kind of following up on that Charice Ordlock asked about, "When you switch your implementation before flipping over to the updated implementation, is there an easy way to have your current implementation and the new Launch implementation running in production at the same time? Obviously, you would need to point them to a different report suite and the server cost call cost would be high, but is this a possible thing to do? Is there a way to do that?" Either of you have answers to that?
Yeah, I mean, so if the goal is to really see compared data from the a live DTM migration and an Adobe Launch migration, I may not recommend that you run them side by side in production for two reasons, Mike referenced this earlier, because you're using the same satellite object and because you've got the same object in play, there might be some conflicts there. The other reason is, if you've got one that's a synchronous deployment and another one that's asynchronous, that's just not going to give you a good data set to compare. What I would recommend that you do, and like I showed kind of earlier is a screenshot of data of what the DTM data looks like in production versus the way that the Adobe Launch data looks in staging or in development, so that you can really compare the values. And then once you can determine that the values are consistent in your Evars and Props and Events, then I would make the switch to production, but I would not typically have both of those implementations running in production at the same time. There would have to be a really big extenuating circumstance for me to consider doing that.
Okay. Awesome. All right. Well, we'll do one more question as we're finishing up here and then all other questions, we'll send out to the speakers so that they can respond to you individually as well. We're going to do Chris Hope asked, "Is there any performance benefit in using a new snippet rather than the existing DTM snippet?"
I can answer that. The answer is yes. So, the obvious performance change would be if you're going to go from synchronous to asynchronous, you'll see some performance improvements there. But also, just the way that Adobe Launch is now configured and kind of works with extensions and load and different things like that, we do see we do see improvement in load time and some other things like that. It's about efficiency and how things behave. So, in my opinion, if you were going to stay synchronous for the initial migration, you're still going to see some performance benefit. And then if you go asynchronous, you're definitely going to see some performance benefit.
Thank you everybody.