Hi!
We currently have a RS ecosystem that consists in 1 RS for our website and 1 RS for each app.
We are thinking in pros & cons of a big change: putting all the app data into the website RS and then splitting apps & website into multiple Virtual Report Suites, using the curating components feature to make life easier for the teams that need access to a certain app or the website.
The only RS will be harder to manage (but will be only available to the small team of analysts) but we will win in being able to analyze certain contents that we have in the app & the website. And analyze user behaviour between apps & Webiste, when we track login ID (will be the same for apps & website).
We know some cons: Real Time, historical data in a different RS. Do you know other important cons that we should consider?
Do you think that we can achieve all the info we currently have in a mobile app RS in a mobile app VRS?
Thank you!
Roger
Views
Replies
Total Likes
Dear Roger,
Based on the recent push from Adobe, it is best practice for them to capture everything in Single Report Suite and seggregate them into multiple Virtual Suites based on the need.
Virtual report suites have the following limitations:
A virtual report suite is nothing more than a segment applied to a report suite. Because each report suite has its own data warehouse and its own data feed, using multiple report suites results in some benefits that segments do not provide
Go through Virtual Report Suite completely before deciding anything : Virtual Report Suites.
But Adobe's stand is, yes, One Combined Report Suite for Web and App - Then seggegrate by Virtual Report Suites.
Thank You!
Arun
Thank you Arun!
Just one doubt. You say "Settings and variable names can't be customized like in a full report suite". If i am not wrong, it is ok that the settings for the main RS go for all the VRS based on it, but on the names I can customize all the names i want (dimensions, metrics...) when I create the Virtual Report Suite
Views
Replies
Total Likes
Variable names can be customized since the release in November. Before that it was not possible.
Also, before you start, make sure you map out the different variables being used across mobile and web, and that they are matching accordingly. The main issue lies when the structures don't match.
-Hyder
You are right, we are documenting every eVar and seeing if they match correctly. We might create some new evars on the RS to fit the info we collect on apps that we don't on web, but I think most of the evars matches (we might have to change evar names in VRS for our teams better understanding), and the process of moving app data to web RS should be easy with context evars & processing rules
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies