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

Question

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!

Jennifer_Dungan · Accepted Answer

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!

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?

Jennifer_Dungan · Answer

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....

가입하기

소셜 로그인

커뮤니티에 로그인

소셜 로그인

파일을 바이러스 검사 중입니다.

이 파일은 다운로드할 수 없습니다