Dear visitor, despite all the challenges, our team continues operating at full speed.

We are ready to help with any questions you may have. Please fill out this quick form and we'll get back to you.

Fill the form
Get Free Trial
Get Free Trial

Custom Aggregations

posted on June 6th, 2020

Answered
Patrick Berens asked on June 6, 2020

Hi Support,
I’m trying to use the new Custom Datasource API, however, I’m still finding limitations that are making my project difficult to achieve. Specifically, it doesn’t support custom aggregations so I can’t utilize all the features of my datasources and APIs. Right now I’m working on Percentiles, but later I’ll likely need more aggregations.

  1. Is this on the roadmap soon? It seems like for Custom Datasource API it would just be passing a string around representing a custom aggregation name then backend would need to implement it correctly.
  2. If this isn’t on the roadmap, can you recommend a way to do this? I’ve thought about possibly doing it on the backend and passing it back as a field, but when I hack it I can’t seem to display summary information I want.

Here is what i want things to look like in one of my simple pivot tables:

Rows:
– Domain

Column:
– Date (year/month/day)

Values: min, p50, p99, max

Then I would obviously like to graph this, so I can see percentile changes over time. I also sometimes will want to have “domain” and then “subdomain” both in rows as a second pivot table. 
Thanks,
Patrick

1 answer

Public
Illia Yatsyshyn Illia Yatsyshyn ⋅ Flexmonster ⋅ June 9, 2020

Hello, Patrick,
 
Thank you for reaching out to us.
 

  1. Our team would like to kindly inform you that the possibility to define the custom hierarchy is going to be added with a major update version 2.9. We will notify you as soon as the feature is released.
  2. As for now, we recommend considering using the following workaround.

    Add the custom server-side logic that would scan the uniqueName property of each received measure. In case the uniqueName matches the measure that needs to be aggregated in the custom way, apply the desired aggregation.

    Also, we recommend modifying the response on the /fields request in the way the measure mentioned earlier does not have any available aggregations ("aggregations": ["none"]). It is required in order to restrict the user to change the aggregation through UI (the chosen option will be ignored anyway). Please note that such a workaround limits the number of possible aggregations to the one specified on the server.

    Detailed information about the /fields request and the structure of the response on such request can be found in our documentation.

 
Our team hopes it works for your case.
Please let us know in case you have any additional questions on this point.
 
Regards,
Illia

Please login or Register to Submit Answer