Développer ma barre des réalisations de la Communauté.

Submissions are now open for the 2026 Adobe Experience Maker Awards

1 sandbox vs 2 sandboxes for CJA data collection in CJA

Avatar

Level 6

Hello,
I would like to know how is everyone configuring their Sandboxes ? 
Do you usually use one for dev and another for prod. 
Or have 1 for both prod and dev? 

 

Below are for 1 sandbox ( Dev+ prod)
Pros - having 1 sandbox for AEP<>CJA data collection is that - We just need 1 AEP variable data element and reference the schema once in tags. 
Cons - hard for access management since everything is just one sandbox now


Below are for 2 sandboxes ( Dev & prod)

Pros - having 2 sandboxes for AEP <> CJA data collection is better for validating and testing, easier for access manage and change management. 
Cons - having 2 sandboxes will create a problem when we have to reference the schema in a AEP variable data element, each time we want to publish the libs between dev to prod. We will have to change it and higher maintenance.

Sujets

Les sujets facilitent la catégorisation du contenu de la Communauté et vous aident à retrouver le contenu le plus pertinent.

2 Replies

Avatar

Community Advisor

Hi @gautham_madala 

same as i the classic Adobe Analytics, I would never mix productive and non-productive traffic. Even though it's possible to apply filtering in your CJA data view, I would always go for a strict separation, even if that comes with a more complex setup and implications like you mentioned.

If you have multiple non-prod environments, then it's ok'ish to have them share a sandbox.

 

But that's just my opinion ☺️

Cheers from Switzerland!


Avatar

Community Advisor

Hi @gautham_madala ,

 

Here’s how most teams approach the 1 sandbox vs 2 sandboxes question for AEP ↔ CJA data collection and the trade-offs you already listed are pretty much spot-on.

1 Sandbox (Dev + Prod in the same)

Typical in:

  • Smaller organizations or PoCs

  • Teams with tight governance and fewer simultaneous developers

  • Environments with low risk of bad data polluting prod

Pros

  • Simpler: only one schema, dataset, and data element mapping in Tags

  • Fewer variables to maintain; no duplication of schemas or datasets

  • Lower operational overhead

Cons

  • Testing in live data stream → any experiment/test can pollute prod data

  • Harder to manage access — all developers need some form of prod access

  • No isolated “safe space” for schema or mapping changes

2 Sandboxes (Separate Dev + Prod)

Typical in:

  • Enterprises with strict governance & compliance

  • Teams with multiple parallel development efforts

  • Situations where schema changes happen often

Pros

  • True isolation: dev data never touches prod

  • Easier access control — dev sandbox can be wide-open, prod tightly locked

  • Safer schema evolution/testing without risk to prod data or reports

  • Easier to test new components in CJA connections without touching prod reports

Cons

  • More maintenance:

    • Schema definitions must be duplicated (and kept in sync) across sandboxes

    • Tags AEP data element must be updated per environment when promoting libs

  • Slightly slower deployments — changes have to be migrated & re-referenced

Common Industry Patterns

  • Large orgs: Almost always 2 sandboxes - the extra work is worth the data safety, especially with multiple developers or high-visibility dashboards.

  • Small orgs or MVP stage: Start with 1 sandbox, then split to 2 once dev complexity or governance requirements grow.

  • Hybrid compromise:

    • 2 sandboxes for schema + dataset level separation

    • But keep shared “reference” documentation so schema changes are easier to replicate

    • Automate migration with the AEP API for schema export/import to reduce manual work

Thanks.

Pradnya