Tips and Best Practices for new users of virtual report suites.
|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 :
|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:
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:
|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 :
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.