Multi-tenancy in Adobe Analytics

Multi-tenancy in Adobe Analytics

A few weeks ago I introduced the concept of multi-tenancy in the Adobe Experience Cloud. Adobe Analytics has had support for multi-tenancy for a very long time. Recently, all user administration for Adobe Analytics has been moved to the Admin Console, where you now configure everything. Read on if you want to know how to configure multi-tenancy in Adobe Analytics with this new setup.

Understanding multi-tenancy in Adobe Analytics

Before going to the more technical details, one needs to understand how multi-tenancy works in Adobe Analytics. If you are familiar with this tool, then you will understand it immediately: use different report suites for different tenants. A more complex explanation is to use a report suite strategy, where you, as the administrator, will configure the access for each tenant in a way that a tenant cannot see the data of another tenant.

If the previous explanation makes no sense to you, let me explain it in more detail. A report suite is like an individual database in a RDBMS. All report suites are completely isolated; in other words, data is not shared between them. You can create as many report suites in Analytics as you want, as Adobe does not charge for the number of report suites. The main limitation is the complexity to manage hundreds or thousands of report suites, if you have too many. Thanks to this isolation, Adobe Analytics supports natively multi-tenancy.

In summary, for Adobe Analytics, tenants = report suites (sort of…)

Report suite strategy

As I explained above, in the most simple approach, each tenant should get a set of report suites, with exclusive access to this set. Other tenants should not get access to this set. If you can use this simple solution, go for it, and ignore the rest of this section.

Unfortunately, in the real world, this solution is not always applicable. Multiple tenants in big corporations tend to roll-up into groups of brands or departments. While each tenant should only access its own data, managers of these groups will want to see the data as a whole. As a consequence, you need to be able to show aggregated data from multiple tenants while keeping each tenant isolated. This conflicts with how report suites work.

In order to solve this issue, you need a report suite strategy. Typical options are:

  • Multi-suite tagging. Basically, you send the data from each tenant to two report suites. One report suite will only¬†be accessed by the tenant, while the other will only be access by the manager. This is probably the best technical solution; however, it is going to be more expensive, as it involves secondary server calls.
  • Virtual report suites. Alternatively, you can have groups of tenants sharing a single “physical” report suite. You then create segments to get each tenants data. Imagine these segment as masks. With these segment, you create multiple virtual report suites. Finally, you grant access to each virtual report suite to the expected tenant and grant access to the report suite only to the manager. The main drawback is that the data from multiple tenants is actually combined in the same report suite; if the implementation is not robust enough, it can lead to data leaks.
  • External tools. Finally, you can keep individual report suites per tenant, without multi-suite tagging. This means that you have strict separation and no additional cost in Adobe Analytics. But when you need to create reports that include the data of multiple tenants, you combine it in an external tool. Examples of such external tools are Adobe Data Workbench or Microsoft Excel with the ReportBuilder extension.

It goes without saying that, if you decide to go with multi-suite tagging or virtual report suites, you need a common SDR for all implementations. Since each website will have its own needs you will need to allow for some flexibility. The easiest solution is to reserve some variables (eVars, props, events…), common to all websites, and leave the rest of the variables to be individually configured per website. The reports for the multi-tenant managers should only include the common variables, but each tenant can create reports using all variables.

Product profiles

This is the final link between report suites and tenants. In the case of multi-tenancy in Adobe Analytics, each tenant will get its own product profile. So, here is where you need to make sure each tenant accesses only the data they should.

Once you have implemented your report suite strategy, you need to go to the Analytics product in the Admin Console, where you will see the list of product profiles. You will notice that there are some out-of-the-box product profiles.

Adobe Analytics product admin

To create a new product profile, start by clicking on the “New Profile” button:

Populate the name and description of the profile. I suggest that, for the name, you follow a naming convention. Click “Next”. For now, disable Triggers and create the new profile. This wizard does not offer a step to actually configure the product profile, so you will need to click on the newly created profile and select the “Permissions” tab:

The important part for multi-tenancy in Adobe Analytics is the report suites list. This is where you select which report suites this product profile has access to:

Obviously, you also need to configure metrics, dimensions and tools. However, this is an administrative decision unrelated to multi-tenancy. In general, I would recommend adding all metrics and dimensions and the most common tools.

Finally, you can start adding users to this product profile. You can also add admins, so they can add other users. You can then name an admin per tenant, who can add more users only to the product profile he managers, giving you the chance to delegate this task without risking the integrity of the solution.

1 thought on “Multi-tenancy in Adobe Analytics”

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.