Global suite or separate Production and Development suites? | Community
Skip to main content
I
iamscottsweeney
October 16, 2015
Solved

Global suite or separate Production and Development suites?

  • October 16, 2015
  • 2 replies
  • 986 views

The idea has been laid out, at my current project, to do away with having separate Production and Development report suites and just dump everything into a single Global suite that the organization would then simply have to segment out between whether they wanted Development or Production traffic. Reasoning; They are tired of having to keep track of which plugin to use, they sometimes forget to switch the plugin when pushing from Dev to Prod and they say it will be easier for THEM to maintain.

My take: The idea is borderline lunacy. You don't co-mingle Dev and Production traffic in a single suite UNLESS said suite is to be used exclusively by advanced users who know enough to segment out what they are looking for and even then the reasoning is sketchy. To the lay person coming in and using the tool, they are not going to know all of the proper ways to filter. Its a recipe for alot of bad reporting. In all my now 17 years in web analytics and work with Fortune 500s have I ever seen an organization even consider this as the default suite for all users. But this is what you get when you have a technical team making decisions for a business tool, it would seem.

I can write something up all day long on the pitfalls of doing this, but would like corroborating documentation to reference. Probably because it is such a basic no-no, I am unable to find anything specific to this. Kind of like how I cannot find documentation on why it is not a good idea to stop breathing. Its just common sense.

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 BrianAu1

Hi Scott,

I agree this is a very bad idea and would recommend they work within a tag management system such as DTM or put in place additional code control within each environment if the development team is having trouble keeping track of DEV and Prod. Segmentation across DEV + PROD is not the answer either as it would force users every time they need to make any segment to have to include/exclude DEV. It is a recipe for confusion for end users due to the added work layers to separate DEV vs PROD, increases potential mistakes with the reporting data, and is general poor data governance.

There is a post below that touches on some general RSID principles, but not specifically DEV vs PROD: http://blogs.adobe.com/digitalmarketing/analytics/site-jumping-how-to-plan-for-a-portfolio-of-sites-inside-adobe-sitecatalyst/

Best,

Brian

2 replies

B
Adobe Employee
BrianAu1Adobe EmployeeAccepted solution
Adobe Employee
October 16, 2015

Hi Scott,

I agree this is a very bad idea and would recommend they work within a tag management system such as DTM or put in place additional code control within each environment if the development team is having trouble keeping track of DEV and Prod. Segmentation across DEV + PROD is not the answer either as it would force users every time they need to make any segment to have to include/exclude DEV. It is a recipe for confusion for end users due to the added work layers to separate DEV vs PROD, increases potential mistakes with the reporting data, and is general poor data governance.

There is a post below that touches on some general RSID principles, but not specifically DEV vs PROD: http://blogs.adobe.com/digitalmarketing/analytics/site-jumping-how-to-plan-for-a-portfolio-of-sites-inside-adobe-sitecatalyst/

Best,

Brian

I
iamscottsweeneyAuthor
October 16, 2015

Thank you for the quick reply. There is currently another major tag management solution in place but the move is towards DTM (currently in POC). Very much appreciate the link as well.

Have a great day, Brian

Terms & ConditionsAccessibility statement

Loading footer...