Virtual Report Suites

Choosing between global and individual report suites leaves one promise hanging: go global so your data stays together, but still give each team its own focused view. The Virtual Report Suite (VRS) is how you keep that promise. A VRS is a saved lens over a real ("parent") report suite. It stores no data of its own and collects nothing new; it simply shows a filtered, curated slice of the parent's data at query time.

If you know database views, you already know this

When a database table grows to hundreds of columns and millions of rows, administrators rarely hand people the raw table. They create a view: a defined window onto the table that might expose a hundred columns instead of a thousand, or only the rows a particular role is allowed to see. The view looks and behaves like its own table, but it stores nothing. There is no second copy in memory. Every query against the view actually runs against the original table; the view is just a saved set of constraints layered on top.

Why bother? Almost always for scoping and safety. You do not want the development team browsing the marketing budget, you do not want a customer seeing your true product cost, and you do not want a vendor paging through your full customer list. A view lets each audience see exactly the slice that is theirs, and nothing more, without ever duplicating the data or putting the original at risk.

A virtual report suite is that same idea applied to Adobe Analytics. One global report suite holds all the data once. On top of it you define a VRS for each property or team, and each one shows only its slice. Nothing is copied, nothing new is collected, and because there is no second store, there are no extra server calls.

One suite, one differentiator, many views

The practical move is the opposite of what instinct suggests. Instead of spinning up a separate report suite per website, you run one global suite across all of them, plus anything you add later, and you capture one differentiator variable on every hit: a "site" or "brand" dimension carrying values like commercial-vehicles, consumer-vehicles, heavy-vehicles. That single dimension is the seam. Each VRS is just the global suite segmented to one value of it. Notice the wording: you are creating views of the data, not new report suites. That distinction is the whole point.

What a VRS lets you do

• Filter to a slice (segment-based): a VRS is really "the parent suite plus one or more segments." A commercial-vehicles view is the parent filtered to that brand value; a mobile view, filtered to app traffic. (Segments have their own module.)
• Curate the components: hide or rename the dimensions, metrics, and segments a given team does not need. This is quietly one of its best uses, a sprawling global suite can feel overwhelming, and a curated VRS hands a regional analyst only the dozen things they actually work with.
• Override the time zone: a VRS can carry its own time zone, so a team in Singapore sees their local day boundaries even though the parent is set elsewhere. If you do not set one, it simply inherits the parent's.
• Redefine the session (advanced): using report-time processing, a VRS can change what starts a new visit, useful for app contexts where the default session rules do not fit.
• Inherit history instantly: the moment you create a VRS it already contains all of the parent's past data. A brand-new individual report suite collects only forward from its creation date; a VRS starts complete.

In practice that covers most "give this group their own view" needs: regional views, per-brand views, website-versus-app views, or simply a stripped-down view for executives who want five numbers, not five hundred. Some of what a VRS shows is inherited wholesale from the parent and can only be changed there; a smaller set of settings the VRS is free to override on its own.

This is why the VRS changed how analytics architects design. For the price of a single global implementation you get the per-team separation that used to require multiple suites and the server calls that came with them. It is the rare upgrade with no surcharge, business-class seating at the economy fare. Adobe has offered it for roughly a decade, and it quietly rewrote the default: collect once, view many ways.

Classifications follow the same logic: you build them once on the parent suite and every dependent VRS inherits them automatically, but you cannot define a classification on a VRS itself. Classifications covers them in full. This is also why defaulting to a global suite is safe: you can carve out as many focused VRS views as teams need, after the fact, without ever having split the underlying data. A VRS is a small, low-cost piece of the machine, easy to overlook, and doing a great deal to keep the whole thing running.

Three sections in, and every decision so far has been about boundaries: how many suites, and who sees which slice. What none of them has touched is the panel where a report suite is actually configured, and where a handful of settings quietly decide whether your data is clean or quietly wrong. That is Report Suite Settings.