Hi All,
Currently, we have observed that our website has 2 different ".min.js" files under the "assets.adobedtm.com" on our homepage and on our sales funnel pages. However, when we check on the Adobe Experience Debugger, it is just calling the using the same production environment.
Homepage:
Sales Funnel:
Due to this setup, we found out that the changing of Adobe launch embed codes in the Adobe Experience debugger is not working.
We would like to ask your advise on how we can improve this that we may able to change the environments we have on the Adobe Experience Debugger since the DTM switch does not work anymore.
Thanks in advance!
Solved! Go to Solution.
Views
Replies
Total Likes
I think so.. honestly I hate the new debugger and don't use it.. the old one was so much better. But since part of the reason I hate the new version so much is that it locks the testing to one suite/one tab, etc.. that trying to compare prod and qa is absolutely impossible... and testing using multiple tabs is impossible as well, that it makes the tool completely useless to me... I raised these concerns with the development team a few years ago, and while they agreed with the assessment, I have yet to see any improvements to the tool in this direction.
I continue to use the old version of the tool, and if/when that stops I would 100% actually rather go back to looking at the network panel than using the new version of the tool (which says a lot).
---------
That said, onto your second question... you can consolidate the two Launch properties, but it will take work, care and a lot of testing.
You will need to open up both properties and compare what is being done (make sure there is no inconsistencies or configurations that contradict one another)... You will need to choose one of these (whichever is used on more pages would be the ideal choice) and start copying rules/data elements/etc from one to the other... but also make sure that the existing rules don't already cover what you need...
You could use Resource Override to override the Launch file on the one that will go away with your dev version of the new main Launch Property, and compare the tracking.. see if the tracking is the same or different and make sure to make adjustments to the new main that keep those pages intact without changing the tracking on the pages it already serves....
Once you have everything merged and tested to your satisfaction, you will need to get your developers or operations team (depending on your organization) to update the Launch reference code for the pages that will be switched from one property to the other.
And of course, after this change is made, you will need to watch for and signs of issues in the event something was missed in testing.
While there is a copy function in launch that allows you to copy full rules or data elements from one property to another.. you must be careful with this as you may already have items that will work as is without the need of duplication... only copy what you really need...
Without knowing your implementation setup, I can't really help focus this down any more... it will be work, but it probably worth it in the long run.
Since the Adobe Experience Debugger is kind of limited (locked to one tab, locked to one file, etc)...and this isn't a scenario that would be in common use... I would recommend using another plugin called Resource Override:
https://chrome.google.com/webstore/detail/resource-override/pkoacgokdfckfpndoffpifphamojphii
You can add as many URL to URL rules as you want, and you could turn then all off at once by the group, or individually per file....
You just code in your production urls and the dev or staging urls that correspond to the correct part of the site.
Just test and make sure they are working once you set up the rules.
@Jennifer_Dungan just to clarify, you mean that the Adobe Experience Debugger can only like redirect one Adobe launch resource. Thus, since we have multiple on site, only 1 will be redirected. Is my understanding correct?
Also, our Adobe launch has been already installed this way when entered the company I'm not really sure why and how this is setup. Is there are way to consolidate these multiple Launch codes/library/resource?
Views
Replies
Total Likes
I think so.. honestly I hate the new debugger and don't use it.. the old one was so much better. But since part of the reason I hate the new version so much is that it locks the testing to one suite/one tab, etc.. that trying to compare prod and qa is absolutely impossible... and testing using multiple tabs is impossible as well, that it makes the tool completely useless to me... I raised these concerns with the development team a few years ago, and while they agreed with the assessment, I have yet to see any improvements to the tool in this direction.
I continue to use the old version of the tool, and if/when that stops I would 100% actually rather go back to looking at the network panel than using the new version of the tool (which says a lot).
---------
That said, onto your second question... you can consolidate the two Launch properties, but it will take work, care and a lot of testing.
You will need to open up both properties and compare what is being done (make sure there is no inconsistencies or configurations that contradict one another)... You will need to choose one of these (whichever is used on more pages would be the ideal choice) and start copying rules/data elements/etc from one to the other... but also make sure that the existing rules don't already cover what you need...
You could use Resource Override to override the Launch file on the one that will go away with your dev version of the new main Launch Property, and compare the tracking.. see if the tracking is the same or different and make sure to make adjustments to the new main that keep those pages intact without changing the tracking on the pages it already serves....
Once you have everything merged and tested to your satisfaction, you will need to get your developers or operations team (depending on your organization) to update the Launch reference code for the pages that will be switched from one property to the other.
And of course, after this change is made, you will need to watch for and signs of issues in the event something was missed in testing.
While there is a copy function in launch that allows you to copy full rules or data elements from one property to another.. you must be careful with this as you may already have items that will work as is without the need of duplication... only copy what you really need...
Without knowing your implementation setup, I can't really help focus this down any more... it will be work, but it probably worth it in the long run.
Thank you so much for your help @Jennifer_Dungan. Will have an assessment on this and will probably continue as suggested.
Views
Replies
Total Likes
Just an update on this issue.
Correct me guys if I'm wrong but this is what I have found out and my understanding on the multiple Adobe launch codes on our assets.adobetm.com.
It seems that Adobe has a function when a site is migrating from a DTM to Adobe Launch which allows to just use the old DTM library JS that is already in place on the website pages with the New Launch code library.
When I have compared the contents of the "satellite-Lib" JS file with the one for our Production Environment JS in Adobe Launch, they are just the same.
So one reason why the Adobe Experience Debugger does not work with multiple launch codes on site, is because Adobe Experience Debugger seems to only redirect one Adobe launch resource.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Like
Replies