Forum Discussion
Google Analytics connector missing startdate/enddate parameters
intrasight, interesting. I'm not very familier with GA's API, I can talk to the dev who worked on this. Particularly, I'm a bit surprised that the inclusion of Date dimension breaks the aggregation on GA.
PowerQuery's multidimensional model had limited support for additional parameters to the cube. We've only began adding it for SAP and AS. So for the GA connector, the start/end date parameter is automatically populated via the filter on date dimension. I think there's could be a bug in the PowerQuery folding logic, when the date dimension is collapsed, we should not have sent &dimension=ga:date.
I'll follow up on this and get back to you.
It's the same reason that it would be wrong in MDX - you can't aggregate client-side. Have someone who knows MDX look at the GA integration and I'm sure they can straighten it out. Or have them contact me.
I did see the additional parameters in SAP and AS, and thought "that's the solution".
Thanks for investigating.
Thanks for reporting the issue. We are now tracking this issue and will address it soon
Hi,
I agree that parameters would probably have been a better solution for this. We didn't have such a mechanism at the time and alas we went for the filter of the date dimension. Nonetheless, the approach we have today should work and before we go ahead and revise the design, I would like to understand what the problem is.
We don't do any aggregations in Power Query for cubes. All the data that is shown comes back directly from the server. So this isn't the problem. Unless you import the data into Power BI for reporting, in which case measures are always aggregated locally, at the aggregation of the selected dimension attributes, because that's just what the thing does.
When you say you are seeing the wrong number of the user metric.
Are you seeing this number in the (Power) Query Editor or in Power BI reporting whiteboard?
The two requests are likely for computing the previews on refresh for each step and not to compute a single result. If you look at both requests, the only different is that the date dimension is removed in the second one. That's because the first request is the one that is used to refresh the preview in the step before the last.
Thanks,
TristanAll the details of the problem are in this thread. Again in summary, client-side aggregation is being done because of buggy query folding, and because GA is effectively a cube, you are thus giving wrong numbers. This is all just straight-up "M" at this point since obvioulsy I wouldn't move to the next step if the numbers are wrong. I'd be happy to do a web meeting with you next week to show the details. But you can do the same queries which were presented in this discussion thread.
We don't do aggregrations locally. All cube operations (Expand, filters, collapse) always results in a query that is 100% sent and run on the service. When you collapse a dimension, we simply don't request it in the query. This is why the date is gone in the second request you've posted. This is equivalent to not selecting a dimension attribute in MDX:
select {[Measure].[Users]} on 0, filter([Date].[Date].[Date], <date filter>) on 1 from [GA]Then when the date is collapsed, we issue:
select {[Measure].[Users]} on 0 from (select filter([Date].[Date].[Date], <date filter>) on 1 from [GA])I tried the same query on our GA account and the issue doesn't reproduce. I get the same results if I aggregate locally using List.Sum over the column than if I collapse the date dimension attribute.
That being said, you seem savvy and I'm sure you've identified something. I'm very interested in getting to the bottom of this and I'll gladly setup a call.
