1 sandbox vs 2 sandboxes for CJA data collection in CJA

[gautham_madala]

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.

[bjoern__koth]

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 ☺️

[pradnya_balvir]

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