Do the props, eVars and events have to be the same across multiple reporting suites? | Community
Skip to main content
ben_rush
ben_rush
January 21, 2016
Solved

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

  • January 21, 2016
  • 4 replies
  • 3198 views

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

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by adam_greco

    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/

    4 replies

    Amit_Kumar
    Amit_Kumar
    Level 10
    January 21, 2016

    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.

    A
    adam_grecoAccepted solution
    Level 2
    January 21, 2016

    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
      ben_rushAuthor
      January 22, 2016

      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
      warrensander
      Level 6
      January 29, 2016

      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.

      Terms & ConditionsAccessibility statement

      Loading footer...