Adobe Analytics API 2.0

Compare ReportSuite & Segment Scans (aanalytics2 v0.2.7)

Hello world,

on this blog post, I would like to go over the new things that came with the aanalytics2 version 0.2.7.
This is recap of what new features came in the last release and I will try to explain the different use-cases.

As usual, you can have a look at the 0.2.7 version release by following the link.

I have to say that most of the features that came in that release came from a discussion I had with Frederik Werner. Discussing on how he was using the wrapper to have some information directly available, we could established some easy new features that makes sense to develop.

Also, I had the chance that most of the discussions were turning to be a pretty easy feature to implement. There are some features that I have in mind for some time but because they take a lot of time, I am not eager to start (for free on the weekend) and waiting to have a project that would allow me to develop it. Or maybe Adobe will finally create a budget for this….

Compare ReportSuite

The first feature is the capability to compare reportSuite.
Most of the time, when I develop the adobe analytics API 2.0 support I am considering my clients and most (all?) have quite a streamlined implementation that could be replicated through different report suite.

In a way, the same configuration is applied on multiple reportSuite. This is the perfect setup to allow using Segments or classification in the same way from different workspace reportSuite setup.
However, I can understand that there are number of clients that have the “almost” similar setup. Or that they have hard time seeing if something is set differently.

For that use-case, I have developped a capability to compare reportSuites and it will compare all of these setup and returns if the dimension or metrics is different.

The method compareReportSuites takes a list of reportSuite and compare the dimensions (default) or metrics based on the comparison selected.
It returns a dataframe with multi-index and a column telling which elements are differents
The arguments are the following:

  • listRsids : REQUIRED : list of report suite ID to compare
  • element : REQUIRED : Elements to compare. 2 possible choices:
    • dimensions (default)
    • metrics
  • comparison : REQUIRED : Type of comparison to do:
    • full (default) : compare name and settings
    • name : compare only namessave : OPTIONAL : if you want to save in a csv.

It is to note that description are not compared because they were harder than expected to be supported and are not critical for the setup.

The scans Segment and Calculated Metric methods

Another element that is quite hard for people to know is what the segment or calculated metrics is based on.
You do have the findComponentUsage method but this method is expensive.
If you have a large amount of data to processed, you can use the different parameter to limit the search but it will still go to search on all components (Segments, Calculated Metrics, Projects), even if you want to search only segments, per example.

Also, it is very nice if you know what you want to search. It may be that you have a segment and you want to know how it is built, especially what is inside.

The problem is quite similar with Calculated Metrics.

For that reason, I have build a scanSegment and scanCalculatedMetric methods.
Both methods will take one argument.
It could be either the definition you have retrieve with getSegment or getCalculatedMetrics, using the full parameter.
Or it could be the id of the segment or calculatedMetrics.

It would returns almost the same dictionnary. The only different that the segment will return the main scope used for the segment creation.


'dimensions' : {"variables/referringdomain","variables/evar3"},
'metrics' : {"metrics/bouncerate","metrics/visits"},
'rsid' : "rsid",
'scope' : "hits"

Calculated Metrics

'dimensions' : {"variables/referringdomain","variables/evar3"},
'metrics' : {"metrics/bouncerate","metrics/visits"},
'rsid' : "rsid",

Project update

Most of you may be aware of the capability I have provided around retrieving Workspace information. Here I come back to the use-case that the report suites you are using at your company may not have the same configuration.
Therefore, when you retrieve a Workspace project, this project could have 2 very different Report Suites attached to each panel.

As I am flattening the results in a dictionary, such as the results will look like this:

    "id": "5f9182b5d398fd031133662e",
    "name": "My Workspace Project Title",
    "description": "",
    "rsid": "my.rsid.used",
    "ownerName": "Surname LastName",
    "ownerId": 200225502,
    "ownerEmail": "",
    "template": false,
    "curation": false,
    "version": "27",
    "nbPanels": 2,
    "nbSubPanels": 51,
    "nbElementsUsed": 26,
    "segments": ],

You may have mix dimensions or events that are from different reportSuite.
In case, it is not clear, the rsids key is a list of reportSuite.

So in order to account for that and returns more context for each dimensions and metrics, I have added a parameter when you are retrieving a project (getProject) or building the Project instance.

You will be able to see that a pameter calls rsidSuffix has been added to many methods:

  • getProject
  • Project class instantiation
  • getAllProjectDetails
  • findComponentUsage

When you are using this parameter (set it to True), you will have the rsid added to your dimension name with the following separator “::“.
So the result will look like the following:


Because this is also supported in the findComponentUsage, you can technically find a component from a specific reportSuite used.
I have also added other attributes on the project instanciation that will help using the results (reportType, version, curation).

Video Demo

I know lots of you like to watch the video to have an idea on how to use these different elements. Therefore, you will find below the video demo.

Leave a Reply

Your email address will not be published. Required fields are marked *