-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Analytics Wishlist #5481
Comments
is tracked #5333 |
Re:
You can tell Piwik a URL to track, without it being correct, its how we handle url redaction currently, so we could have some internal hash that only gets sent to Piwik then it can use its fancy flow diagrams |
@t3chguy the easy bit would be getting the fancy flow diagrams by adding new URL hashes, the difficult part is doing this without allowing the user to go "back" when going "back" doesn't really make sense. |
@lukebarnard1 thats why I'm talking of some internal hash which we pass to piwik but do not put in the URL, so that back will take them out of the flow entirely |
Oh! I see. Honestly I think I'd prefer to not maintain the concept of an "internal" location in the app, and just deal with the fact that sometimes the browser will be pointing at |
This is now obsolete, we're tracking analytics progress elsewhere |
User flows
Discussing these with @lampholder, he and I thought it would be awesome if we could track the various "flows" that users take in Riot. Piwik has pretty good support for this if the #hash changes at every step of the process (e.g. onboarding).
Changing the hash every time we want to indicate a step in a process is one way of doing it, but it's not ideal as the user could decide to press "back" and be confused as to why nothing happens.
Another option would be to track some Piwik Events for the various parts of the process under useful Piwik Event Categories such as "Onboarding v1" or "Group Creation" etc.
Tracking all the modals hasn't been super useful, probably because they're not grouped in a useful way. We might want to revisit how we structure our hierarchy of Event Category, Action, Name.
The text was updated successfully, but these errors were encountered: