Show Menu
TOPICS×

VRS FAQs

Tips and Best Practices for new users of virtual report suites.
Question Answer
Should I consolidate my implementation from multiple report suites into a single "global" report suite and then use virtual report suites to expose different segments of data to my users?
Maybe. Here are some circumstances under which you should consider continuing with individual report suites :
  • If you have variables/dimensions with a large number of unique values, consolidating into a single report suite may cause you to exceed monthly unique value limits in this global suite, leading to truncation ("Low Traffic" as a line item in reports).
  • If you require real-time or "Current Data" reporting for individual segments (e.g. brands, business units, etc.) of your data.
  • If your various report suites each have unique requirements for tracking (i.e., if they use Adobe Analytics variables and events very differently), note that consolidating to a global report suite will not grant you additional variables or events for tracking.
Which settings on virtual report suites are inherited from the parent report suite?
A virtual report suite (VRS) inherits most of the service levels of the parent report suite, such as eVar settings, Processing Rules, Classifications, etc.
The following settings are NOT inherited:
  • Report suite ID
  • Report suite name
  • Permission groups (virtual report suites can be assigned to their own permission groups)
Note: This does not include most user-created entities like Bookmarks, Dashboards, Scheduled Reports, etc.; these items are not inherited from the parent and can be created and used against the VRS specifically (more detail in the next question).
How does working with a virtual report suite differ from working with a base report suite in the Analytics UI?
Once created, a virtual report suite is treated just like a base report suite throughout the UI and is generally supported for most extended features. For example:
  • Virtual report suites show up in the Report Suite selector and can be selected individually just like any other base report suite.
  • DL Reports, Bookmarks, Dashboards, Targets, Alerts, Segments, Calculated Metrics, etc. can all be created against a virtual report suite and behave independently of the parent.
  • Virtual report suites can be individually added to Permissions Groups just like any other report suite.
  • Segments can still be applied when running reports in the context of a VRS; they will automatically be stacked with the virtual report suite's segment(s) when the report data is being retrieved.
How are virtual report suites treated in the Admin Console and Admin API? Can I save features against them like base report suites?
No, virtual report suites are not supported for most Admin features . As mentioned above, a VRS inherits most service levels and features from the parent (for example, eVar settings, Processing Rules, Classifications, etc.), so to make a changes to these inherited settings on a VRS, you must alter the parent report suite.
As a result, virtual report suites are shown in the UI only here :
  • The Virtual Report Suite Manager, where you create and edit VRSs.
    ( Analytics > Components > Virtual Report Suites )
  • The User Management interface, where you edit custom permissions groups. This allows VRS accounts to be added to a permissions group and could be used to create a group that only has access to virtual report suites (if the Admin wanted to deny access to the parent and only allow users access to specific segments).
    ( Admin > User Management )
Note: When you use the Web Services API and attempt to save Feature settings against a VRS, an exception will be thrown. Features can only be set against a base report suite.
Are virtual report suites supported in the SiteCatalyst 14 UI?
No, we do not expose virtual report suites in SiteCatalyst 14. They will not show up for selection in the Report Suite Selector and cannot be selected. We do, however, expose virtual report suites in the SiteCatalyst 14 Admin Console UI when editing a group. In this particular case virtual report suites need to be represented so they aren't accidentally removed from an already-existing group that may already have access to one/many virtual report suites.
I checked "start new visit on launch." Why do I see visits still much higher than launches?
When the start new visit on launch option is checked, the timeout still applies. So, if a user is using the an app for ten minutes with a one minute break in between each action, a new visit starts on launch, then nine additional visits are created when the visit times out. To keep launches and visits as close as possible when using the start new visit on launch option, you should use a timeout that is longer than the session timeout set in the SDK .
I set "start new visit on launch" and set a longer timeout than my SDK. Why are my launches still much lower than visits?
If the timeout is higher than the value set in the SDK, it is very likely that your app is sending in hits while in the background and these hits are registering as new visits. Check for this by using the hit type dimension on the parent report suite to see if there are any background hits.
Note: Background and foreground hits are only differentiated in version 4.13.6 and higher of the SDK. If you are on a lower version, all hits show as foreground. If you are on the correct version of the SDK, you should enabled the Prevent background hits from starting a new visit setting.
Note: If you have disabled legacy processing for background hits in the admin console, they will not show up in the parent report suite but will appear in the virtual report suite.
What version of the SDK do I need to have to track background hits?
You must be on version 4.13.6 or higher of the SDK.