App Analytics

[Wolvan]

It would be interesting to collect anonymous statistics on app usage or at least downloads for example, although I am not sure how much people would be OK with that, so I'd like to get some input on this.

[Wolvan]

Maybe have it a setting that can be en-/disabled in options. And to keep better track, maybe generate a unique ID on first launch which then gets sent to TitleDB?

[ksanislo]

I would think a generated UUID saved in the config file would be plenty, you can add a 'reset tracking id' option that generates a new one if you want, but it's probably not really required.

Here's some Lua stuff on making a random UUID entry, which should be good enough that the chance of a conflict is basically nil.

https://github.com/Tieske/uuid/

[ksanislo]

I haven't tried it, but it should be possible to implement in the query by just adding it to the URL that the request is being made against, like https://api.titledb.com/v0/?device=<UUID>

[Wolvan]

I made this, maybe take a look at it? dd27a1a3a1ef20c0ee7395ca8aacd910323c3274

[ksanislo]

It looks like it should work, have you tested it against the production server yet? I don't see it logged on the server anywhere, maybe Apache is stripping the post query from the log... I'll look into it further.

[ksanislo]

Actually. If you have tested this, since it's not logged you'd have to move it into the JSON list command. You can just name it "uuid" to keep things simple. Put it at the top level equal with the "action" part.

This whole API interface is going to be redone in the next update, and I'll have a much better way to handle this with cookies/auth tokens. For the moment, everything in the json post is logged for debugging, so I can parse an install count out of that right now.

[Wolvan]

Well, I did send applist requests with Homebr3w How about I send it as both GET and POST parameter so we can use whatever both?

[Wolvan]

Alright, I've done the thing that sends the UUID as POST as well now and send a few test requests

[ksanislo]

Alright, that looks good... It should be able to give some much better stats about how many people are using our stuff.

[ksanislo]

If you want to append it to the GET urls for /proxy/ like how we'd tried first, that would let us identify things like installs per client as well...

[Wolvan]

I am appending them to the URL already as homebrewUUID I think?

[Wolvan]

Maybe I am not escaping correctly, is there any special GET parameter escaping I have to do for UUIDs?

[ksanislo]

I'm not sure... the proxy URL will work like this, I just tested it manually from a browser and it fetches and logs as expected.

http://api.titledb.com/v0/proxy/0004000000269500?homebr3wUUID=893d92da-bd7d-4ee3-ce36-d4430dadb954

[Wolvan]

Yeah the URL works, I know. I am asking if I need to encode the UUID because I wasn't sure if dashes are allowed in GET parameters without encoding. But it seems they are so it should work

[ksanislo]

Yeah, it looks like it will be good... The only thing I'd think could be different is just to call it 'uuid' instead of including the app name with it. We already have name/version from the User-Agent header.

[Wolvan]

the reason I went with homebr3wUUID is to keep the property unique. The thing is appended to all Network requests and not only the ones calling TitleDB. I don't want to potentially mess with others sites, if you know what I mean.

[ksanislo]

Do you make direct requests anywhere other than titledb? As a URL parameter, it would be dropped by the redirection from titledb to the final host.

[Wolvan]

I call Github as well, yeah. And if in the future I am calling other places they would also get the parameter. I am trying to keep this as future proof as I can

[ksanislo]

Alright, no problem with how it is now then. The whole of the /v0/ api will be replaced at some point fairly soon with the /v1/ that moves to being a proper REST API and can tie a device to a login directly without these kinds of hacks to get statistics. And don't worry, /v0/ will be emulated using the new backend, so things won't break for existing apps even if they take a while to implement the new methods.

[Wolvan]

Does that mean you are required to log in to use the system from v1? How do I retrieve a token in the first place?

[ksanislo]

lpp-3ds will need to be upgraded to handle cookies, but it should be mostly seamless from your end. I'm developing the backend using best practices for the web, and I'll deal with getting proper client support on the 3DS for any additional features that are missing after I'm done.

[Wolvan]

Alright, that is fair enough. As long as the /v0/ api stays around until then it's OK I think. I already thought I'd had to request an "API Key" kind of deal of some sort from your rest api to use it

[ksanislo]

Right now there's extended attributes that are being requested with the POST url, but no actions use authentication/authorization for what they're allowed to do. This will remain the same in /v1/ for clients that aren't logged in, however if they are authenticated there will also be some extended ability to add/edit entires to provide info that can't be derived from the CIA itself. Being logged in wont be a requirement for apps that just want to browse/install things.

[Wolvan]

Ah, I see. Fair enough then.

[Wolvan]

I didn't get any more feedback so I am just going to add the analytics for the next build of Homebr3w. Commit should be up in a bit.