Virtual Report Suite Segmentation for a Franchise Model
A franchise brand has one global report suite with 900 franchise locations. Each location is identified by a locationId eVar (hit-level, set on every hit). Corporate wants each franchisee to see only their own location's data, plus a corporate rollup. There are 900 franchisees; IT wants to avoid 900 report suites. Data governance requires franchisees cannot see other locations' data. Some locations share a locationId prefix by region. The brand also wants a single calculated metric for 'revenue per visit' used consistently everywhere.
1. Design the reporting access model using virtual report suites. What are the tradeoffs versus separate report suites, and how do you enforce isolation?
Read the worked answer
Design:
- One global report suite as the data source.
- 900 virtual report suites, each with a segment on
locationId == <value>, assigned to the corresponding franchisee's login group. - A corporate rollup VRS with no location segment (or a region rollup set).
Enforcement:
- VRS access is controlled by user group permissions; a franchisee group is granted access only to its VRS. Do not rely on the segment alone - the permission boundary is what enforces isolation.
- Ensure the
locationIdeVar is hit-level and reliably set; a missing value would leak data into the wrong (or corporate) view.
Tradeoffs vs. 900 report suites:
- Pros: single tagging implementation, consistent variables, one data feed, lower admin overhead, easy to add locations.
- Cons: VRS segmentation adds query complexity; very large numbers of VRS can strain admin/maintenance; segment logic must be airtight; some features (e.g., certain data exports) need care to respect VRS scope.
Also: audit that no franchisee group has accidental access to the global suite or corporate VRS.
2. How would you implement 'revenue per visit' as a calculated metric that is consistent across the global suite, all VRS, and the corporate rollup?
Read the worked answer
Create one calculated metric at the global report suite level: Revenue / Visits (using the standard Revenue and Visits metrics), with appropriate formatting and a clear name.
Consistency considerations:
- Calculated metrics defined on the global suite are available to VRS built from it, so the same definition applies everywhere - this is the key reason to define it once, not per VRS.
- Segment context: in a VRS, the metric is computed within that VRS's segment context, which is correct - each franchisee sees its own revenue per visit. The corporate rollup computes across all locations. Document that the metric is context-sensitive by design.
- Avoid redefining the metric inside individual VRS; that would create drift.
Caveats to flag:
- If 'visit' is defined differently in any downstream report, reconcile definitions.
- Calculated metrics cannot be used as the basis for certain segment/attribution operations - confirm the metric is used only where supported.
- Validate the metric against a manual calculation for one location to confirm the numerator/denominator pair.