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?
Solved! Go to Solution.
Views
Replies
Total Likes
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.
Another option to multi suite tagging is to use virtual report suites, please read this doc to see if it fits your requirements.
Views
Replies
Total Likes
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.
Another option to multi suite tagging is to use virtual report suites, please read this doc to see if it fits your requirements.
Views
Replies
Total Likes
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?
Views
Replies
Total Likes
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
Views
Replies
Total Likes
This is very helpful. I don't know how to use APPMeasurement . I just download the "JavaScript" from code manager. Then I saw appMeasurement file. I guess I will need to change this file. I didn't see Config section in my AppMeasurement.js code.
1) Once I add the code you mentioned before, should I load this code back to server? How to?
2) when I add the s.count, should I add 1 s.count for each report suite? Like you mentioned before? Do you have sample code for this? I only have Global level, I don't have country level.
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"
3) How could I know the file I am using is the latest version. I don't want to overwrite existing version if there is any.
Views
Replies
Total Likes
I think you will need to involve your developers to implement the library and release it to your production environment (I guess they might need to check in dev and/or stage prior prod).
You won't see the config section it is just a comment in the code that I put to show when my config start and stop.
1. As I said you will need your developers to release the code changes to production.
2. The different levels that I provided are example. s.account is the variable that you will need to use but the value inside it will need to be dynamic. Your developers will need to put in place a logic that will populate a variable based on lets say the URL.
Lets say the new variable is s_account and we use function setAccount()
Then the javascript should code should look like:
function setAccount() {
//Logic to set correct comma delimited report suite IDs
}
var s_account = setAccount()
s = new AppMeasurement()
s.account = s_account
3. When you download the zip file for the AppMeasurement it should always generate latest version of the code. In general all Analytics and visitor ID services library are updated once a month during the MR (last Thursday of the 3 week of the month).
To check the version of the library that is installed:
As I said I think you will need your development team involvement from now on if you want to release your files to production.
You might also want to ask if they are using a Tag Management System on your website that you could use to implement Analytics. Adobe provide DTM, so you could it but it will need to be implemented on your website as well.
Alexis,
Really like your idea of using contextdata and processing rules.
Could I add the code such as "s.contextData['article_title'] = 'Weekend Concert Controversy' in Customize Page code section . Write in the open editor? Since I will need to get data from datalayer on the page, so you have sample code to get data from page and assign to a s.contextdata ?
thanks
–
Views
Replies
Total Likes
I haven't done DTM in a year or so but I do not think it changed much in terms of core functionality.
1. If you have a datalayer then I would advise you to create a data element for each element in the datalayer. The reason behind it, is that you might need to reuse the value in another variable and using data element is the best solution.
1.a. I wrote a simple tutorial on how to extract data from a complex JSON object: DTM and Data Element based on JS ARRAY and JSON ARRAY · alcazes/Adobe-Analytics-from-A-To-Z Wiki · ...
2. I believe the analytics object s or whatever you entered as name is not usable by default so you will need to extract it before hand. (if you choose the option that DTM manage the analytics library)
The code would look something like this:
//Extract analytics object
var s = _satellite.getToolsByType('sc')[0].getS();
//Use your data element to populate your contextData
s.contextData['article_title'] = _satellite.getVar("THE NAME of your DATA ELEMENT");
That should do it.
If you have any issue, let me know and I will try to get a more detailed example.
Last Friday, I tried to create a data element and directly grab data from data layer on the page and save it in a eVar. Then I use the classification rule to get each data element in data layer. it worked for me now. Right now, I have a question, will each component like postTitle act like an eVar ( consistent through the whole vist? ), if I want to assign the postTitle to another eVar, how could I reference this variable? Like dataelement %elementName? or direct call the name of this variable?
# | Select Rule Type | Enter Match Criteria | Set Classification | To | |
---|---|---|---|---|---|
1 | Regular Expression | postTitle:(.*?)\| | postTitle | $1 | |
2 | Regular Expression | siteTitle:(.*?)\| | siteTitle | $1 | |
3 | Regular Expression | siteUrl:(.*?)\| | siteUrl | $1 | |
4 | Regular Expression | pageType:(.*?)\| | pageType | $1 | |
5 | Regular Expression | pageSubType:(.*?)\| | pageSubType | $1 | |
6 | Regular Expression | author:(.*?)\| | author | $1 | |
7 | Regular Expression | postCount:(.*?)\| | postCount | $1 | |
8 | Regular Expression | pagePostDate:(.*?)\| | pagePostDate | $1 |
Views
Replies
Total Likes
A classified value in a classification report will persist as long as the key (from the eVar report where you send the initial value) linked to this classified value persist. So if the value expires or a new value is set in the same evar for the same visitor, then the key and its related classification will expire.
In terms of data elements, you can reuse them in any eVar that you wish in DTM. If you want to reference them in another eVar using the interface then yes you will need to use %Name of Data element%, I believe that as soon as you will type % it should give you options to choose from and the more you type the more detailed options it will give you.
If it is in a code section then you will need to use satellite.getVar("THE NAME of your DATA ELEMENT");
Alexis,
Thanks for explanation. Now I understand that the classified value will be persist. I read the document mentioned that the classification rules will run periodically like every 4 hours and can back about 1 month. So I just want to make sure the classified value will store in the report suite. There is no need to run in the air every time when I try to use it. Then we will have performance issue
My second question I guess I didn't ask clear enough. Since we used another way to get some value, like siteTitle Right now, we already have an eVar3 for siteTitle. Now I would like to directly get it from data layer. Since I don't want to break the existing report, so I prefer to assign the new classified value to eVar3. In the case, in a page load rule, how should I assign this value. eVar3 set as ??????
I tried: %siteTitle% -> can not find. If I use "siteTitle", I guess it will assign string "siteTitle" to eVar3. or could I call it s.siteTitle?
Another question I have is, if I already have a data element name is siteURL and when I give this name to a classified value, then what's going to happen?
Thanks
Views
Replies
Total Likes
Your code implementation and classification are two distinct things. It is not possible to set a classification at a code level.
At a code level when you set s.eVarX="value" then this value will be sent to analytics and assign in report eVar3. You cannot change this value in eVar3 report, it will be as it is send (unless there are additional processing like VISTA rule or Processing rules set).
Then once you have all of the keys that you want in your base report eVarX you can decide to create additional classification reports for report eVarX. Each classification report value will be directly tied to a key, and more than one key can have the same classified value.
If you put any new value in an evar, in a direct call rule or any rule, that was set prior by another rule, then the new value will overwrite the old value, which will result in loosing initial value.
For data element in DTM, if you cannot see it when you type %siteTitle% then you must have not created the data element correctly. I think we are deviating too much of the initial topic in this post. As it is linked to DTM, I would advise you to create a new POST under Dynamic Tag Management
Thanks Alexis. I agree.
Views
Replies
Total Likes
Alexis,
I really have a lot of interest in using the context variable. as the example you mentioned in the previous message:
/Use your data element to populate your contextData
s.contextData['article_title'] = _satellite.getVar("THE NAME of your DATA ELEMENT");
After I setup the s.contextData['article_title'] variable, will this context variable be able to sent to the adobe server when a rule fire? Do I need to use the process rule to assign this context variable to a eVar or Prop?
Will context variable available to workspace?
Thanks
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies