One Global Report Suite or Thirty-Six Local Ones
A retailer operates three brands across twelve countries, giving 36 brand-country combinations. Each combination has a separate marketing team and P&L, and legal requires German and Brazilian customer data to remain in-region for reporting. The current architecture uses 36 report suites, each with its own eVars and props. The analytics team has 100 eVars and 250 props per suite and wants cross-brand funnel reporting plus a single-currency finance view. Order data can arrive up to 72 hours late, and two new brands will launch next quarter. The Adobe contract permits 50 report suites. Product managers have asked whether virtual report suites alone can replace the 36 suites and still satisfy the residency requirement.
1. Recommend a report suite architecture. Address the global suite, virtual report suites, and the residency constraint.
Read the worked answer
Decision: Use one global report suite for the nine brand-country pairs that are not under residency restrictions, keep separate report suites for Germany and Brazil, and create virtual report suites (VRS) for each brand and country view on the global suite.
Reasoning:
- VRS are query-time segment views over one report suite. They do not create a separate data store, so they cannot satisfy a legal data-residency requirement. Germany and Brazil therefore need separate report suites (or a separate Experience Cloud organization and data-center arrangement), not VRS.
- For the remaining pairs, a global suite gives cross-brand funnel reporting and avoids duplicating 100 eVars and 250 props across 36 suites. Brand and country become eVars, and VRS filter on those values.
- The global suite also makes the add-on brands cheaper: adding a brand is a new VRS and a new eVar value, not a new suite with its own variable map.
Caveat: VRS rely on segment definitions. A badly written segment can silently change historical numbers, so segment governance is mandatory.
2. How should brand, country, and currency be captured so the architecture works? Address late-arriving order data.
Read the worked answer
Capture brand and country as low-cardinality eVars with an expiration that matches reporting needs. Set them on every hit, including link and download hits, not only page views. If cross-visit brand behavior matters, use visitor expiration for brand; otherwise visit expiration is enough for country.
For currency, do not rely on the report suite currency setting alone on a global suite. Send s.currencyCode per hit with the local ISO code and a converted s.currency value if finance needs a single-currency view; the report suite base currency converts revenue using daily rates. Alternatively, send a normalized USD revenue event and keep local currency in a separate eVar for local teams.
Late-arriving orders should be sent as a separate purchase event with the original transaction ID in an eVar so deduplication is possible. Do not backdate timestamps unless the implementation can guarantee ordering. Classify country into region and brand into portfolio using SAINT so reporting hierarchies do not consume more eVars.
3. What migration and governance risks matter before cutover?
Read the worked answer
- Historical continuity: Data in the 36 suites does not automatically concatenate into the global suite. Define a cutover date, keep old suites read-only for trend comparisons, and document which reports switch to the global suite.
- Variable-map drift: The old suites used different eVar and prop meanings. Freeze the global map before migration and map every old variable to a new one in a spreadsheet. A silent mismatch will produce plausible but wrong reports.
- VRS history: VRS segments apply to historical data too, so a segment edit rewrites history. Version-control segment definitions and require review before changes.
- Residency suites: Germany and Brazil need their own data feeds, classifications, and access controls. Do not let a global VRS become a workaround for residency.
- Governance: Create a change board for eVars, a naming convention for VRS, and a staging suite used to test every release.