Dynamic variables

[ghost]

Hi Pete,

We tested superproxy to make a public dashboard and this is really a promising tool ! Actually we would really like to use it for one of our clients. But we need to insert a dynamic value into the request :

https://www.googleapis.com/analytics/v3/data/ga?ids=ga%3A25810321&dimensions=ga%3AyearMonth&metrics=ga%3Avisitors&segment=dynamic%3A%3Aga%3AcustomVarValue1%3D~DYNAMICVALUE&start-date=2013-01-01&end-date={today}&max-results=5

We need the final user to be able to choose a dynamic value to update this request. Would it be possible in the future to predetermine some custom dynamic variables to make dynamic requests ?

Thanks a lot, Benjamin

[timelf123]

This would be incredibly powerful.

We would probably use this feature to create a template report, and then dynamically pass in a profile ID for example, to view the report across different profiles

[esoubihe]

I really need to filter ga:hostname dynamically based on the URL the page is being embedded. This would be a great feature.

[timelf123]

I wish my Python skills (or lack thereof) were up to this task. Hopefully someone else has a similar use case and can tackle this one. And now onto my rambling...

Consider the following use case:

1. Many GA profiles/views
2. Query has same structure -- the only difference is the profile/view combo being queried

For example, unique visits by device category, for each view. Currently this means for 10 views, you need to load 10 queries into SP, which is far from ideal when you are working with 50+views and multiple queries for each.

@pfrisella Is this a separate issue maybe called "Query multiple profiles/views at once"? From my intrepretation of the core reporting API, you cannot pass in multiple ga:ids, but we could query each ID and combine the results

[timelf123]

@pfrisella Is this feature on your radar still?

[joaogarin]

Hello all,

is this something on the pipeline?Or is there any solution to make something like this work?I have exactly the same scenario.

Thanks in advance

[joshuaheng]

@pfrisella any updates if this feature is happening?

[timelf123]

the main issue I can see arising is How to cache when the queries are dynamic?

Maybe we need to restrict the dynamic variable to profile id?

Pete has not been available lately, so if we want this feature we will likely need to develop ourselves and PR (or fork if @pfrisella is not available to merge)

[pfrisella]

While my answer is yes, I'd like to work on this, time is the issue so I can't promise anything in the short term. There are other issues that need to be fixed which would take priority over new features.

However, I'd be happy to review pull requests and merge. That was the point of placing this on GitHub.

Also, it'd be helpful to better understand how you imagine the workflow for queries with dynamic variables. Would you define these in the UI? As timelf123 pointed out, maybe you need restrictions otherwise you just end up with an open proxy to your data and you start losing benefits of caching.

[WillemPaling]

I would think that you would set up a query definition as per normal, then define a filter field as dynamic. Then it would be up to GA Super Proxy to cache requests for each different value of the dynamic filter field.

So you might have a single query set up that shows you realtime visits by page, with a dynamic filter set up on ga:pagePath, and then you could use that same query to get subsets for different sections of the website (e.g. support, shop, community). Or, you might have profile ID set as a dynamic variable, and similarly, use the same query to get the same data for different profiles.

That way it would not be a public proxy to your GA data, just to a filterable view of your GA data.

Not a trivial code change though :)

[bgd42]

Indeed, such a feature would be very useful. To vary on @WillemPaling 's remark, less code intrusive would be to generate all the interesting queries and save them in superProxy. For such generation we need an API to save new query definitions. E.g. in terms of how this API can look, we can go from config file for loading queries to REST endpoint to load one query at a time.

This way superProxy remains simple, straight forward, and we can build tools for (auto)generating the queries. Going for form POST-ing on /admin/query/create looks like a hack and also needs authentication.