1 sandbox vs 2 sandboxes for CJA data collection in CJA

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

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