Fourteen Data Views, Three Hundred Components, Nine Definitions of Revenue
A global consumer electronics brand runs one CJA dataset for 14 country markets, and the Center of Excellence maintains a separate data view per market plus a global 'sandbox' view. The component library has grown to 312 components; 'Revenue' alone exists as nine variants (gross, net, net-of-returns, local currency, USD, and four market-specific calculated versions). Analysts in three regions have started building their own segments against raw fields because they no longer trust the curated ones. Governance requires that the CFO dashboard, built on the global view, ties to local market P&Ls each month. A merger added two new markets that onboard in 60 days with a different currency and a fiscal calendar starting in April. The team has two CJA admins and no dedicated data engineering support.
1. Diagnose the root cause of the component sprawl and propose a curation model that assigns each kind of logic to the right layer.
Read the worked answer
Root cause: the same concept was allowed to live in three places with three owners. Nine Revenue variants is a symptom of solving market-specific definitions in the component layer instead of deciding where each definition belongs.
- Dataset schema: raw, source-faithful fields only - transaction amount, currency code, tax, refund flag, order status. No business logic and no renaming.
- Data view: the definition layer. One view per market is legitimate, but every view must expose the same six component names (Revenue, Orders, Units, AOV, Refund Rate, Margin) mapped to market-appropriate derived fields. Currency conversion and fiscal calendar are data view settings, not metrics.
- Calculated metrics: only genuinely reusable formulas such as AOV = Revenue / Orders. Never encode a currency or calendar difference in a calculated metric.
Then retire the sprawl deliberately: identify components unused for 90 days, deprecate with a sunset date, and hide rather than delete so live projects fail visibly rather than silently. Handing analysts a trustworthy curated set is the only thing that stops them rebuilding on raw fields.
2. How would you onboard the two merged markets given the different currency and an April fiscal-year start, without creating a fifteenth variant of everything?
Read the worked answer
Treat onboarding as configuration, not modelling.
- Currency: each new market's data view sets the base currency and uses daily FX. If the local P&L is reported in local currency, publish a clearly labelled local-currency view rather than a calculated metric with a hard-coded rate that will silently rot.
- Fiscal calendar: set the custom calendar at the data view level (fiscal year start April). Do not attempt to reproduce a fiscal calendar with segments - Workspace date comparisons will disagree with finance every time, and nobody will notice until quarter close.
- Parallel run: three months of side-by-side comparison against the market P&L before either market appears on the CFO dashboard.
- Naming contract: identical component names and descriptions across all views, so cross-market analysis does not need a mapping spreadsheet.
- Onboarding gate: maximum 40 components, each with a named owner and a one-line definition, enforced by the two admins before the view is published.
3. Analysts distrust the curated components and build on raw fields. How do you migrate them without breaking existing projects or triggering a political fight?
Read the worked answer
Migration fails when the old thing is removed before the new thing is proven.
- Instrument usage first. Pull 90-day component usage to see which raw fields actually drive analysis and which analysts depend on them. This turns a debate into a list.
- Prove parity. Rebuild the top ten analyst-created segments from curated components and publish a side-by-side project showing identical populations. Trust follows evidence, not announcements.
- Deprecate on a calendar. Thirty days' notice, descriptions updated to point at the replacement, admin-level hiding rather than deletion so nothing breaks without warning.
- Lock the schema. Restrict calculated-metric creation in the global view to the CoE; keep a 'lab' view where power users retain raw-field access.
- Accept the exception. Curation exists to guide the majority. Blocking the three analysts who genuinely need hit-level grain buys you a rebellion and no governance win.