Is there a way to send analytics logs from 2 separate applications into the same report suite? For eg., I have applications A and B, and my report suite is Z, I want to send logs from application A into a workspace in report Z, and logs from application B into another workspace in report Z. If possible, could you please help me how? Also, any documentation in this would be highly appreciated. Thanks a lot!
Solved! Go to Solution.
Views
Replies
Total Likes
It sounds like you are talking about creating a "global suite", one that contains the analytics data of 2 or more sites (that you can see the traffic all together, or create virtual suites to see A or B separately). This is the setup I have with 31 "sites" (though if you also include some of the offshoot extended content on subdomains it's probably close to 100 variations being aggregated) in the same suite.
While I don't have any documentation handy (this would be a good idea for a blog post actually), here are some of the steps we have taken to make sure this was successful:
1. Make sure you have good documentation (I can't stress this enough) - to make sure the data you are collecting is consistent to the correct props/evars/etc with the same data formatting you need to be sure you know exactly what is expected. You don't want to mix different datasets into the same dimension.
2. If the sites are using shared code this is easier, you can actually use the same Adobe Launch (or whatever they are calling it now) on both sites, since you will process the data the same way... if they are two separate code bases, you can have multiple Launch properties set up, you can copy generic rules/data elements between the properties - then going forward just make sure that changes are rolled out consistently between them.
3. Since you will likely be using the Adobe Cloud Id service, this should already set the same ECID for your users on all sites (rather than the old way of unique s_id values per site... so your UVs should flow through properly as the same user on all sites without needing to do custom work
4. Make sure you identify the site with dimensions so it's easier to segment the data later. I like to user the server dimension (sitea.com vs siteb.com), but then I augment this for our "extended/external content" which is still technically site branded.
For instance, we have News sites, each of these brands has an external branded classified site, and another external branded announcements site.... for each site (sitea.com) I track on all three of these in server "sitea.com" regardless of the subdomain. Then I use a prop to track the "variant" or rather "external content type".... for the main version of the site, I leave it empty, on the classifieds variant I populate "classifieds", on the announcements variant I populate "announcements". Now I can use the server to segment content that belongs to site A or B as a whole, I can segment content from all sites for classifieds by using my prop, or I can pull specific variants of my site by using a combination of the two (core site being server = "sitea.com" and propx does not exist; or Site A classifieds by server = "sitea.com" and propx = "classifieds")
5. Make sure you create some virtual suites that segment the data into ways that will most likely be used by your users (having a repository of segments is good, but being able to choose sets of data that are pre-filtered can make this even easier for people.
For the most part, the technical implementation of this the hardest part is just making sure your tracking is using consistent rules. Which is why documentation is so important.
Views
Replies
Total Likes
It sounds like you are talking about creating a "global suite", one that contains the analytics data of 2 or more sites (that you can see the traffic all together, or create virtual suites to see A or B separately). This is the setup I have with 31 "sites" (though if you also include some of the offshoot extended content on subdomains it's probably close to 100 variations being aggregated) in the same suite.
While I don't have any documentation handy (this would be a good idea for a blog post actually), here are some of the steps we have taken to make sure this was successful:
1. Make sure you have good documentation (I can't stress this enough) - to make sure the data you are collecting is consistent to the correct props/evars/etc with the same data formatting you need to be sure you know exactly what is expected. You don't want to mix different datasets into the same dimension.
2. If the sites are using shared code this is easier, you can actually use the same Adobe Launch (or whatever they are calling it now) on both sites, since you will process the data the same way... if they are two separate code bases, you can have multiple Launch properties set up, you can copy generic rules/data elements between the properties - then going forward just make sure that changes are rolled out consistently between them.
3. Since you will likely be using the Adobe Cloud Id service, this should already set the same ECID for your users on all sites (rather than the old way of unique s_id values per site... so your UVs should flow through properly as the same user on all sites without needing to do custom work
4. Make sure you identify the site with dimensions so it's easier to segment the data later. I like to user the server dimension (sitea.com vs siteb.com), but then I augment this for our "extended/external content" which is still technically site branded.
For instance, we have News sites, each of these brands has an external branded classified site, and another external branded announcements site.... for each site (sitea.com) I track on all three of these in server "sitea.com" regardless of the subdomain. Then I use a prop to track the "variant" or rather "external content type".... for the main version of the site, I leave it empty, on the classifieds variant I populate "classifieds", on the announcements variant I populate "announcements". Now I can use the server to segment content that belongs to site A or B as a whole, I can segment content from all sites for classifieds by using my prop, or I can pull specific variants of my site by using a combination of the two (core site being server = "sitea.com" and propx does not exist; or Site A classifieds by server = "sitea.com" and propx = "classifieds")
5. Make sure you create some virtual suites that segment the data into ways that will most likely be used by your users (having a repository of segments is good, but being able to choose sets of data that are pre-filtered can make this even easier for people.
For the most part, the technical implementation of this the hardest part is just making sure your tracking is using consistent rules. Which is why documentation is so important.
Views
Replies
Total Likes
Thanks a lot @Jennifer_Dungan for your helpful answer.
Views
Replies
Total Likes
There is a bit of conceptual clarification, that application A and B is the digital property that are the subject of tracking and measurement. Report suite is the data container on Adobe Analytics to store data and you can definitely able to use one report suite for multiple applications. Workspace is different from report suite, that is the reporting unit and you can now have one workspace project with data from multiple report suites and of course you can have multiple workspace projects for the same report suite.
Please note that there are lots of configuration in Adobe Analytics are report suite based, such as evar, event, channel, and etc. When you are using the same report suite for multiple applications, you need to make sure that the same configuration is applicable to all related application.
When you are using one single report suite for multiple applications, you need to have a way to differentiate data from different application within the same report suite. For website, it can be as simple as the hostname if your application A and application B are two different websites running on two different hostname, or you can explicitly use an evar to indicate the application. From here you can than create virtual report suite for application A and application B. You can find more about virtual report suite at https://experienceleague.adobe.com/docs/analytics/components/virtual-report-suites/vrs-about.html?la....
Views
Replies
Total Likes
Thanks a lot for your help @leocwlau
Views
Replies
Total Likes
Views
Likes
Replies
Views
Like
Replies