Do the props, eVars and events have to be the same across multiple reporting suites?

[ben_rush]

I am confused on this concept. I recall reading, at some point, that if you have a prop, eVar, event, etc in one reporting suite, you have to create it the same way in all of your other reporting suites. Here is an example of that I mean:

Website A has prop25 set to "Product Views" and event3 set to "Product Searches". From what I understand, Website B would also have to have this specific prop25 and event3 also set as what they are in Websiet A ( "Product Views" and "Product Searches", respectively), regardless if you are even using these for Website B.

Well, we are anticipating running out of props and eVars for some of our sites. My question is: Can you have different values for the same prop/eVar/event number from site to site?  It seems logical that Website A could have prop25 set to "Product Views" and Website B could have prop25 set to "Site Search" or something completely different.  Please someone elaborate on this for me. Is is bad practice to have them tracking different things from site to site?  Thanks in advance

[Amit_Kumar]

May be I am confused by your question:

My understanding of your question is that you one report suite(lets call it RS1) and you want to use this for two websites(WebsiteA and WebsiteB)  and you want to have different evars and props bindings for both websites?

Answer is NO

but if you can create a new report suite(lets call it RS2) then you can use different bindings as you can configure everything for RS2 based on the requirements for WebsiteB and configure for RS1 based on the requirements for WebsiteA.

Hope this helps.

[adam_greco · Accepted solution]

Ben,

To answer your question. No, you do not have to use the same variable definitions in every suite.  HOWEVER, there are many reasons why you SHOULD do that.  They include:

1. The ability to switch suites and see the same report for a different report suite
2. The ability to compare the same report in different report suites (without having to use Excel)
3. The ability to use consistent JavaScript code or tag management setups
4. The ability to re-use reportbuilder data blocks with different report suites
5. The ability to re-use dashboards and reports by just changing report suites
6. The ability to see aggregated data in a "global" report suite

And the list goes on...

However, you are correct, that this approach can restrict the number of variables you have overall.  To deal with this, many companies reserve a set of variables that are meant to be used for different purposes and re-used as needed.  For example, you may say that eVars 1-70 have to be standard, but eVars 71-100 can be used differently by any report suite and will not be rolled up to the "global suite" (i.e. blanked out by a VISTA Rule).

I hope that helps...

Adam Greco

http://analyticsdemystified.com/blog/adam-greco/

[ben_rush]

Adam Greco wrote...

Ben,

To answer your question. No, you do not have to use the same variable definitions in every suite.  HOWEVER, there are many reasons why you SHOULD do that.  They include:

1. The ability to switch suites and see the same report for a different report suite
2. The ability to compare the same report in different report suites (without having to use Excel)
3. The ability to use consistent JavaScript code or tag management setups
4. The ability to re-use reportbuilder data blocks with different report suites
5. The ability to re-use dashboards and reports by just changing report suites
6. The ability to see aggregated data in a "global" report suite

And the list goes on...

However, you are correct, that this approach can restrict the number of variables you have overall.  To deal with this, many companies reserve a set of variables that are meant to be used for different purposes and re-used as needed.  For example, you may say that eVars 1-70 have to be standard, but eVars 71-100 can be used differently by any report suite and will not be rolled up to the "global suite" (i.e. blanked out by a VISTA Rule).

I hope that helps...

Adam Greco

http://analyticsdemystified.com/blog/adam-greco/

Thank you!  This was what I needed to know!

[warrensander]

Adam is obviously correct (he always is correct :-) )

but it all depends on what you are doing in those report suites and how you will set those props and evars etc.

you really don't want to maintain too many copies of the s_code, or DTM rules or Processing rules if 90% of the information is common across the report suites. Maybe on suite doesn't get useful information into evar10 or all the evars in the 20's. so just don't run those reports in those report suites, you can use the menu system and hide those reports in those report suites.

Now if you are doing mobile apps vs online that's a good reason to split up report suites. You usually collect very different information in mobile apps vs onliine but you can always have the mobile app send it's calls to 2 report suites one for the mobile app and one where you pick/choose what data to populate.

You can actually do this in your reports suites also. use a processing rule to delete those variables you don't need in a report suite.

If 100 evars and 75 props aren't enough even if you do the split like Adam says you can go to 250 with premium and that should allow enough headway.

The real issues are keeping everything up to date, in sync and understandable to all your users.