Virtual report suites can be used to replace multi-suite tagging. For example, instead of sending data to two separate report suites, you could send data to one and use virtual report suites to limit how much data users have access to. However, access to data is only one of the reasons that separate report suites can be beneficial. Carefully consider the following use cases before making implementation changes with regard to virtual report suites.
The following considerations apply ONLY to cases where you are considering changing your implementation to remove child report suites and rely solely on virtual report suites to control views into data for end users. None of the following considerations apply to normal use of virtual report suites as a way to segment existing report suites and make that data available to users (without dramatically altering your underlying implementation).
|Consideration||Best Practice/Use Case|
|1. Your organization uses the Adobe Mobile Services UI to manage mobile app marketing activities across multiple apps.||
The Adobe Mobile Services UI combines mobile app data from your Adobe Analytics report suites with the ability to send push notifications, run A/B tests, and generate in-app messages. Adobe Mobile Services does not currently support virtual report suites. If your organization has or is likely to have multiple apps, and wants to use this UI to manage these activities in those apps, you should use a global report suite with child report suites for each app.
Use case: You have five different apps, and various mobile product teams use Adobe Mobile Services to send push notifications to each app individually. You use secondary server calls to send data about each app to its own report suite, so that each product team can see their own data and manage their own mobile campaigns in Adobe Mobile Services.
Note: This does not apply if you have multiple apps but do not intend to use Adobe Mobile Services; all app data will be available in Adobe Analytics and can be separated using virtual report suites.
|2. Users at your company need to be able to share segments to the Marketing Cloud for targeting from virtual report suites.||
Use case: Users have access to virtual report suites only, but you want them to be able to create and share segments from Adobe Analytics to Adobe Marketing Cloud for targeting in Adobe Target.
|3. You don't need real-time (or "Current Data") reporting at the virtual report suite level.||
Use case: You are setting up virtual report suites for each of your properties, but each property has a newsroom that relies on the real-time report. You should use secondary server calls.
|4. You do
not exceed unique value limits in your "base" (parent)
Or: You do not care if your users see "Low Traffic" in their virtual report suites.
Use case: You have millions of page names in your global report suite, and you want to be sure that you see every single unique page name in your child suites. You should use secondary server calls.
|5. You do not need different variable definitions and mappings for each individual "child" report suite.||
Use case: The first 50 eVars in your global suite are common to all of your different brands that roll up into it, but the next 50 are unique and different to each brand. You should use secondary server calls.
|6. The segments you are going to use with virtual report suites do not divide the data in ways that may confuse your users.||Remember that a virtual report suite is just
a segment applied to a report suite; all nuances in segmented data apply.
Use case 1: Your virtual report suite is based on a segment defined as "all shopping cart hits". Running pathing reports would show shopping cart pages as the start of the visit, since all hits prior to the shopping cart are excluded. You may want to use secondary server calls, depending on your need.
Use case 2: You have five sites. Your users want to see Visit Number data on a per-site basis, meaning that they want to see the number of first visits, second visits, etc. at a site level.
With a global suite, visit number is typically aggregated across all sites (Visit #1 can be to SiteA, Visit #2 can be to SiteB, etc.). When using a Virtual Report Suite to segment by site (e.g. All SiteB visits), the visit number will correspond to the selected site. In the example just given, a virtual report suite for all SiteB visits would show zero for Visit #1, because Visit #1 happened on SiteA. If this is concerning, you should use secondary server calls.
|7. You have no problem with Adobe Analytics converting various currencies at report run time.||
Use case: You do business in several countries and each country wants to view historical revenue data in their own currency with an accurate historical exchange rate. You should use secondary server calls.
|8. Your company's usage of Adobe Analytics for querying is not extreme.||
Use case: You have a thousand Report Builder dashboards, each with 50 data blocks, that are scheduled to run at the same time every Monday morning. You should use secondary server calls.
|9. You are okay with getting a single Data Feed that includes all of your data.||
Use case: You want to push a Data Feed for Brand A to that team every night for them to use, without having to first segment/ETL a global Data Feed for all of your brands in order to get their data and send it over to them. You should use secondary server calls.
|10. You are using an Exchange (data connectors) integration that only allows one partner account per report suite, and you have multiple partner accounts that you want to integrate.||
Use case: Each of your regional teams has its own DFA account and wants to integrate pre-click display ad data into their report suites. You should use secondary server calls.
|11. Other consideration: Localization in different report suites (e.g., each language referring to the same product differently)||
|12. Other consideration: Multiple visitor counting methodologies (FPC vs. third-party)||