Segmentation, Calculated Metrics, and Virtual Report Suites
This domain tests whether the architect can build reusable, correct analysis components. Segments combine container logic (hit, visit, visitor) with conditions and sequential logic. Candidates must know that container choice changes meaning: a hit container counts only qualifying hits, a visit container includes all hits in a qualifying visit, and a visitor container spans all visits. Sequential segmentation requires ordered matching and has performance implications. Segment stacking (AND/OR of multiple segments) and exclusion logic are common test areas.
Calculated metrics combine existing metrics with arithmetic, functions, and filters. Know the difference between metric-level and segment-level filters, how division handles zero denominators, and why a calculated metric can produce surprising results when its component metrics have different attribution.
Virtual report suites apply a segment, a set of curated components, and variable-visibility settings to a base report suite. Understand what a VRS can and cannot change: it can scope data via segment and curate the UI, but it cannot alter underlying collection or retroactively redefine variable persistence.
Traps: using a visit container when the question is about qualifying hits; building a segment with 'visitor' scope for a same-visit question, inflating results; assuming a VRS segment filters raw data for all users; and creating calculated metrics whose numerator and denominator use different scopes. Questions often hinge on container scope.
Rule of thumb: match the container to the question. If the answer should count only the qualifying action, use hit scope; if it should describe the whole session containing the action, use visit scope.
Worked example: 'conversion rate for visitors who viewed the promo' requires a visitor-scoped segment for the population and a hit-scoped count for conversions; mixing scopes yields a rate above 100 percent.