Global report suite

Forum|Forum|8 years ago
August 31, 2017
13 replies
4626 views

Have a question about global report suite. Anyone know how to setup a global report suites? ( detail procedure or video )?

I found in document, it mentioned that I will need to modify the s_code.js file.

I am wondering. if I create a new report suite and call it global report suite and in the DTM side, I add this one into all the properties. then will this report suites can consider as Global report suite? Any difference between thos one with the one if I setup with the s_code.js?

Analytics

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 Alexis_Cazes_

Global report suite is part of what is called multi-suite tagging .

Global report suite is a naming convention and the report suite in itself does not need to be configured differently. The only thing that you need to do is specify the correct report suite Ids list in s.account in AppMeasurement.js (s_code.js is the old library and it is advised that you implement latest of AppMeasurement.js).

Lets say that you are a car company and you have a site section for each country, then under this site section you have a site section for each county and finally a site section for each shop that sale cars.

Then you will want to send all of your data to the the global report suite.

All of the data of a specific country to the country report suite.

All of the data of a specific county to the county report suite

Finally all of the data for a shop to the shop report suite.

The further you go into your site sections then the more report suite will be specified:

Global level s.account="globalreportsuiteid"

Country level s.account="globalreportsuiteid, countryreportsuiteid"

County level s.account="globalreportsuiteid, countryreportsuiteid, countyreportsuiteid"

Shop level s.account="globalreportsuiteid, countryreportsuiteid, countyreportsuiteid, shopreportsuiteid"

Multi suite tagging involve the use of primary server calls and secondary servers calls.

It is important to differentiate primary server calls and secondary server calls. When you do an Adobe Analytics implementation you can specify more than one report suite ID in s.account, which is called multi suite tagging.

The first report suite ID in the list will generate a request to Adobe Analytics (by default image request for web implementation). This request will count as primary server call and will be billed fully.
Any subsequent report suite listed will also each generate a request to Adobe Analytics. Each of these request will count as secondary server calls. Secondary Server calls are billed with a discount.

Another option to multi suite tagging is to use virtual report suites, please read this doc to see if it fits your requirements.

Show previous replies

Alexis_Cazes_

New Participant

1. Best practice is to setup Global report suite and child report suite in the same manner as all data sent on the page will be sent to all at the same time. If not set up in the same manner then it is possible that some data sent will in the wrong reports.

Obviously you will have custom reports for each site section and this will need to be taken into account, even at the implementation level.

I personally abandoned the default way to implement Adobe Analytics meaning using eVars, props and events.

For all of my projects that I have opted to use contextData variables . ContextData allows you to use any variables name convention you want and if you have cross implementation, like mobile IOS, mobile Android, Web javascript, Server side java SDK, Data insertion API , you can specify same variables names and they will be processed in the same manner.

On top of that contextData gives you a lot of flexibility in a multisuite tagging scenario. Same contextData variables can be mapped to different reports (i.e eVar report) in different report suites using processing rules. So there is no more, oh wait eVar number X is available on global report suite but not in child report suite, can't use it.

One important thing to know about contextData is that it needs to set up processing rules per report suite.

Here is how I see contextData: freedom for the developer as they do not need to care which variables names they give and freedom for person in charge to set up report suites as they can map these custom variables to any reports they wish.

1.1 Please be aware to set up to estimate traffic accordingly on global report suite. You are most likely going to get far more hits on Global that the child ones. The estimation needs to be per day, if the value inputed at the creation of the report suite is to low then it will result in latency of data processing.

2. Yes it is best practice to create once report suite per environment to not destroy data in prod with stage testing. I will even as far to add one more dev report suite where you can test any combination of data without any impact of future reporting.

3. s.account variable is part of AppMeasurement.js library. Once you have initialised and instance of the library in object s then you should be able to populate s.account (note that if you use the legacy library H.27.5 you will need to use s_account).

Each report suite that you need to specify will need to go in s.account separated by a comma.

The code should look like:

/************************** CONFIG SECTION START**************************/

s = new AppMeasurement()

//Add your Report suite ID

s.account="reportSuiteID1,reportSuiteID2,etc..."

//Instantiate Visitor ID services

cathyw49544988Author

New Participant

Thanks Alexis. This is exactly what I want. In order to setup like what you said. I have 3 questions:

1. For the global report suite, should I setup exactly the same as regular report suite in the report suite management? ( mean the general, traffic, etc.... )

2. Since we have prod and staging, should I create 1 global for Prod and 1 for staging?

3. How to setup the s.account value?

Alexis_Cazes_Accepted solution