-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Port to GA Reporting API v4 #21
Comments
I had intended to do that and made some headway a little while ago actually--the connector requires some rather easy re-jiggering--but the main issue is that the formatting of the V4 api calls is not simple. Much more flexible and powerful to be sure, but it had me questioning what this wrapper should even look like for the V4 api. That is, what the current tool does is allow the user to be sloppy with their queries, simply providing things as a (basic) dictionary or keywords arguments while the internal parser reformats the request to a valid call to the API. With V4, the ability to automatically reformat the request is more tricky owing to the flexible request structures. Thus, to do this, there needs to be some consensus as to what a V4 version of this module should even look like. Should it simply require the user to get the formatting correct themselves and forgo any sort of parser, or should the current simplifications be maintained? And if the simplifications are maintained, then how can the ability to use the more flexible V4 calls be implemented as well? As in, what would it even look like in relation to this module? This brings up another (related) problem as well (which I should put in another issue but I'll just mention here for now) in that since GA returns data in a JSON-like structure, if the request is for anything but a 'flat' dataset, the returned frame is somewhat useless as it does not have a means of figuring out a multi-index structure on it's own. I see this as related as it's a problem of how to "automatically" get pandas and JSON to play nice together in terms of the user experience... |
Definitely to the point.
I'd vote in favor of the former: letting users get the formatting right themselves. My experience with this module is that i soon ran into the limits of the simplification and then had to dig into the magic to understand how to go beyond.
I dont really get that point, somehow imo the V4 returns a table in json format whereas the V3 returned a table in array (of rows) format. It's merely a matter of parsing the JSON object notation and translate it as a dataframe, yet i might be wrong ... Could surely get some inspiration from the GoogleAnalyticsR module that came out recently: That could also help https://github.com/googleanalytics/gav4-python |
ugh, R. I'll take your word that it's good :-) However, since I'm also happy with this module simply wrapping "correct" queries and reformatting the returned object to a pd.DataFrame object, I'll find and complete the V4 connector and push that shortly as it will basically do the job. As for the JSON issue I tacked on at the end, I'll find an example that demonstrates what I mean and open an issue for that as well. |
Please give it a try and improve it if you can. :-) |
Any intent to do the port?
https://developers.google.com/analytics/devguides/reporting/core/v4/
The text was updated successfully, but these errors were encountered: