Expand my Community achievements bar.

Join us for the next Community Q&A Coffee Break on Tuesday April 23, 2024 with Eric Matisoff, Principal Evangelist, Analytics & Data Science, who will join us to discuss all the big news and announcements from Summit 2024!
SOLVED

Test Report Suite overwriting all report suites - How can I prevent it?

Avatar

Level 3

Hey all, so we currently have [Report Suite A] and we are creating a [Report Suite B] to feed new values (evars/props/contextdata), My issue is the following:

 

Step 1. User arrives at website: Report Suite A page call

Step 2. User scrolls down the page and a new module on the site which reports to [Report Suite B] upon entering viewport (video/photo carousel interaction/view). It fires the s.tl call and sends it to [Report Suite B]

Step 3. User then clicks on the navigation menu which is suppose to send to [Report Suite A] gets overwritten with [Report Suite B]

Step 4. When the user lands on another page, [Report Suite B] is still taking precedence and overwrote Report Suite A

 

I've created a new tracking object to not interfere with [Report Suite A] and I clear the new tracking object for both Report Suite A and Report Suite B, but it still occurs.

 

Any idea why?


Unfortunately we have everything in a protected lower environment so I am unable to provide any URL.

 

Thanks all!

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

It sounds like s and sz aren't fully separated... the account should be set in s_account... and for the sz it should be sz_account

 

So that when you call s_t() it should use "s.account" and when you call sz_t() it should use sz.account.

 

Basically your sz version should have everything separated... Launch should be called s_t() and s_tl() and using all the s specific items....

 

If you are comfortable debugging in your browser's console... you can check what these items are set to....

So when your site load, check the value of s.account (it should be report suite A) and I assume that your second suite will be loaded also when the site loads, and it should have an sz.account set to (report suite B). In the custom code of your Launch property, for testing only, you can add a console.log(s.account) as part of the Set Variables (you should be able to then see if that value gets overwritten?). You can also check other s object items... to see if there is potential overlap....

 

Its a little hard to help, since I can't see everything that you have set up... 

 

While I can't guarantee this will work, you could also try to force the s.account in the custom code of your Set Variables to your suite... but you will also need to check which environment you are in, to set it properly for QA, Staging and Prod... and this will basically overwrite the extension set up (and you would need to probably add this to all your rules....) which isn't ideal...

 

The best solution really would be to try and find where the two objects are being overlapped... and try to get them separated....

 

 

OR while it does come at a cost, work with Adobe to set up Vista Rules... Adobe can process rules and transform them and then send them to another suite.... they may even be able to prevent that tracking from going to the main suite (since you want multimedia on the separate suite)....

 

Since these are complex rules, it requires an Adobe Engineer to support, which is why it will cost money to set up (not sure what those costs might be.. we were looking at something similar during a transitional period from one suite to another, but decided that for a short term temporary solution it wasn't worth it), but for you, being a permanent solution, it might be better to avoid all the headaches?

View solution in original post

6 Replies

Avatar

Community Advisor

Both suites are using a shared s object.

 

While I know logically that you can have 2 tracking objects on the same site, and give the second one a unique object... I don't know exactly how to do that... plus, the appMeasurement.js file for the second suite I believe would need to be self hosted (as I don't think Launch provides the ability to make changes... they do have the option to "use existing AppMeasurement.js file, which you would then have to host yourself and add to the site)

 

BUT, this would also require you to essentially code all the tracking through custom code... let's say your second report suite was set up to use the s_media object. You would need to manually set your dimensions and events using:

s_media.prop1 = "something";
s_media.eVar1 = "something else";
s_media.events = "event1,event2";
s.media.t();

 

 

Many years ago, before Launch was a think, we had a partnership with another company and made a white label site for them... we used our Adobe Analytics files and tracked into our suite, and they provided their own AppMeasurement file to us, and back in those days the developers set all the parameters like above to fit their needs. I don't know how they generated their files to use a different s object though....

Avatar

Community Advisor

Also, since the original report suite isn't back on the next page, I am guessing this is a Single Page Application?

 

Meaning the AppMeasurement file and all the declarations such as s_account are set once... and once modified, it doesn't reload the config to your main account.

 

This is why if you need to do this, you really need to isolate your objects and configurations....

Avatar

Level 3

Yes, this is a SPA site. We have the page Report Suite A page load rule firing when it moves on to the next page but picks up the Report Suite B still. So I am using s object for Report Suite A and then sz object for Report Suite B. After sz object (Report Suite B) fires, all the legacy rules that is tied to Report Suite A picks up Report Suite B.  

 

Your comment about isolating the objects within two difference .js does make sense. We have one locally hosted on our website and our development environment adobe hosted, this could probably explain why it works in our lower environment but when pushing it to our production site, it doesn't work and overwrites. I'll need to do a few more tests and configurations and hope to provide an update.

 

P.S.

If anyone else has any suggestions or comments, please feel free to share as well. Appreciate everything and everyone!

Avatar

Correct answer by
Community Advisor

It sounds like s and sz aren't fully separated... the account should be set in s_account... and for the sz it should be sz_account

 

So that when you call s_t() it should use "s.account" and when you call sz_t() it should use sz.account.

 

Basically your sz version should have everything separated... Launch should be called s_t() and s_tl() and using all the s specific items....

 

If you are comfortable debugging in your browser's console... you can check what these items are set to....

So when your site load, check the value of s.account (it should be report suite A) and I assume that your second suite will be loaded also when the site loads, and it should have an sz.account set to (report suite B). In the custom code of your Launch property, for testing only, you can add a console.log(s.account) as part of the Set Variables (you should be able to then see if that value gets overwritten?). You can also check other s object items... to see if there is potential overlap....

 

Its a little hard to help, since I can't see everything that you have set up... 

 

While I can't guarantee this will work, you could also try to force the s.account in the custom code of your Set Variables to your suite... but you will also need to check which environment you are in, to set it properly for QA, Staging and Prod... and this will basically overwrite the extension set up (and you would need to probably add this to all your rules....) which isn't ideal...

 

The best solution really would be to try and find where the two objects are being overlapped... and try to get them separated....

 

 

OR while it does come at a cost, work with Adobe to set up Vista Rules... Adobe can process rules and transform them and then send them to another suite.... they may even be able to prevent that tracking from going to the main suite (since you want multimedia on the separate suite)....

 

Since these are complex rules, it requires an Adobe Engineer to support, which is why it will cost money to set up (not sure what those costs might be.. we were looking at something similar during a transitional period from one suite to another, but decided that for a short term temporary solution it wasn't worth it), but for you, being a permanent solution, it might be better to avoid all the headaches?

Avatar

Level 3

Just an update, I haven't been able to try it yet but will try it out today or this weekend and provide an update. I have things separated but will have to try that recommendation of separating and avoiding the App measurement to be shared

Avatar

Community Advisor

Good Luck! This is not an easy process... and the only time I dealt with it, the partner provided the file with all the separations... who knows how long it took them to get it working... 

 

I really wish there was documentation about how to create a new AppMeasurement file that uses a custom s object to prevent corruption when trying to do independent tracking.