Skip to content
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

Why track Exception with Piwik? #28

Closed
d4rken opened this issue Mar 23, 2015 · 5 comments
Closed

Why track Exception with Piwik? #28

d4rken opened this issue Mar 23, 2015 · 5 comments

Comments

@d4rken
Copy link
Member

d4rken commented Mar 23, 2015

I'm looking for a use case or legitimization why we should track and forward exceptions.
Is there a plugin for the service tracker that visualizes them well and allows for organization?
Or to prevent reports from older apps for solved issue?

In bigger apps with 100k+ users, you always have crashs that are out of your control and after a few weeks the "Crash Event" list would be filled with useless stuff and no way to hide or remove these except manual database alternation. I do not see this being useful except maybe to have screenview tracking like start->screen1->screen2->crash. Although this is cool, with bigger usernumbers, i can't see this being favorable over traditional crash tracking (ACRA, Crashlytics etc.).

At least least this should be opt-in, not on by default.
But maybe this can be removed and we don't have to maintain it.

@mattab
Copy link
Member

mattab commented Mar 23, 2015

At least least this should be opt-in, not on by default.

👍

But maybe this can be removed and we don't have to maintain it.

I think it could be useful to users to automatically track exception as Events in their app

@d4rken
Copy link
Member Author

d4rken commented Mar 23, 2015

Explicitly tracking exceptions could have some usecase, but even then it's almost always replaceable with if-checks, then track a normal event, which is better practice.

Automaticially tracking all exceptions needs strong filtering and extra options on the server side.
As i said for small apps 5k-20k active users this could work, but even then i would recommend picking something like Crashlytics that was made for this. Having options to hide processed exceptions, stopping reporting from older app versions etc.

If we venture into higher user counts like 100k-150k users, you will get daily crash that are unrelated to your app, but just got caught in your exception handler. With no server-side organisiation, it will spam the event section until it's unusuable.

I would propose to reduce the crash tracking to method that wraps the normal trackEvent method and just converts an Exception object to a useful message. Then remove everything else including automatic exception catching.

I don't want to throw the current piwik-android-sdk over, I'm just speaking out of experience. Sorry for all the scrutiny.

@mattab
Copy link
Member

mattab commented Mar 23, 2015

Oh it's very useful to have your scrutiny actually!

I would propose to reduce the crash tracking to method that wraps the normal trackEvent method and just converts an Exception object to a useful message. Then remove everything else including automatic exception catching.

Would this change the way the exception are tracked, eg. https://github.com/piwik/piwik-sdk-android#dispatching ? if so please submit the change to documentation with your PR

@d4rken
Copy link
Member Author

d4rken commented Mar 23, 2015

No, it will stay the same, I would basically remove the automatic exception handling and then simplify the exposed API.

I'll make a pullrequest when I'm done with the current one and we can discuss it when everyone can see the changes. I can tag you on the pullrequest if you want.

I'll have a look through the docs though to see if it needs updating.

Alexey did an awesome job with what we already have and i followed this project for some time and wished i could have joined sooner.

I currently have a (very patch worky) self made tracking with json + node.js + couchdb and my goal is to replace that with piwik. It's relatively urgend because i underestimated the user growth and amount of data that is to handle. Piwik to the rescue ;).

Got many more ideas and PRs in mind, i hope @dotsbb will like most of them :o.

@d4rken
Copy link
Member Author

d4rken commented Mar 25, 2015

My concerns are addressed with PR #33 further discussion can be done there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants