Analytics Strategy and Solution Design
What this domain tests
Solution design is how you architect data collection to serve strategy. Concepts: the Solution Design Reference (SDR), naming conventions, variable allocation planning, report suite strategy (global vs. regional/brand), data layer design, tracking governance, and mapping KPIs to dimensions and events. Understand the trade-off between one global report suite (cross-site rollup, simpler governance) and multiple suites (isolation, different stakeholders, latency).
Traps to watch for
- Questions implying more report suites is always better; usually consolidation wins unless there is a strong isolation or legal reason.
- Confusing an SDR (planning document) with the implementation itself.
- Forgetting that design must include a testing/QA plan and a data layer contract with the dev team.
- Ignoring downstream consumers (data warehouse, Target, Audience Manager) when choosing variables.
Worked example
A retailer with three brands asks for reporting. Design: one global suite for cross-brand rollup plus per-brand virtual report suites for access control, a shared data layer spec (page type, product, user segment), and a naming convention like dimension:pageType. This satisfies strategy (rollup + isolation) without tripling tagging work.
Rule of thumb
Design variables from the question backward: name the report the business needs, then define the dimension and metric that feed it, then the data layer field. If any link is missing, the design is incomplete.