All Collections
Properties
Using a Single Apollo Property to Support Multiple Applications
Using a Single Apollo Property to Support Multiple Applications

Using a single Apollo property to support your implementation(s) can greatly simplify your implementation processes.

Anne Farmer avatar
Written by Anne Farmer
Updated over a week ago

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.

Did this answer your question?