This article walks through the scenarios for which users should utilize a single Apollo property versus when using multiple Apollo properties to manage your implementations makes more sense.
Scenarios Where One Apollo Property is Appropriate
Assumptions
You are implementing using a single tag management platform
3PTs considerations aren’t included
Integrations considerations aren’t included
If there are multiple website/applications, they share a solution design
You have a single website/application with a single Solution Design
Number of Apollo Properties : 1
This is the classic implementation scenario. One Apollo property will correspond to one tag manager property/container.
You have multiple website/applications with a standardized Solution Design (all reporting variables/dimensions are in common)
Number of Apollo Properties : 1
When multiple applications share the same requirements, utilizing a single Apollo application can reduce the level of effort associated with maintaining your implementation.
You have multiple website/applications with slightly varying requirements (there is a standardized Solution Design, but subsets of the websites/applications use some of the variables/dimensions and not others)
Number of Apollo Properties: It depends
Applications share a data layer JSON structure, but just have different Apollo Events that may apply to them
Number of Apollo Properties : 1
If when any given Apollo Event/Data Layer Event is passed for any application, it is expected to always include the same attributes/have the same JSON schema, then 1 Apollo property is appropriate.
Applications have different Event Attribute requirements, so different Data Layer Event JSON requirements
Number of Apollo Properties : Multiple
If applications have different event attribute requirements, then the org will run into false positive error tracking issues with Apollo, thus losing out on the value of these QA/validation features.
You have multiple applications that share a standardized Solution Design (all reporting variables/dimensions are in common), but development teams for the applications can’t deliver updates to Data Layer JSON schemas in tandem
Number of Apollo Properties: Likely multiple
Apollo delivers a single set of requirements, and updates the single set of requirements. If applications are passing different Data Layer Event JSON structures, then the org will run into false positive error tracking issues with Apollo, thus losing out on the value of these QA/validation features.