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!
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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.