Analytics: Add more granular click event Actions and Labels for "language" Event Category
Closed this issue · 13 comments
In order to track any potential drop-off related to language selection, I would like to get triggers (and functionality, if possible) updated to reflect the following Actions and Labels:
- User actively selects a language from the pop-up (current setup supports this with language_change, but it also seems like the trigger for this is not "on click" ...? IMHO it should only be a click event.)
- User selects the flag/language icon on the map (open_menu)
- User closes the menu without making a selection (close_menu)
I know the menu currently doesn't have a "close" option, but if makes sense from a dev and UX perspective, I'd like to be able to track that activity as well. There's a large percentage of dupe event actions for the first ~day of this data (filtering out for devs as best I can), and I'm wondering if that's from refresh activity/how the tag is set up or people actively re-opening the menu mid-session to check out languages again. Also, if there are users that are opening the menu and not closing or selecting a language (and instead just exiting), that is a valuable segment were we could be tracking and trying and suss out improvements.
I just confirmed that there's now a language > language_changed event coming through in GA. Screenshot below. Worth noting that this is different than the default GA language report, which I believe is based on the user's browser.
Closing this :)
This seems related to #178.
I just poked around in GA and found two different ways of viewing language info.
@experimatt Correct! We are tracking languages via browser default (first screenshot) and events (second screenshot). However, I don't think this is giving us an accurate picture of how users are interacting with the menu. It currently fires even if users have not selected the option (like if they refresh the page or come back to the page later in the same browser session, but a different tab), which is useful info, but viewed in the context of "how many users do we have that are selecting a different language," the results are skewed, even when selecting for "Unique Events."
I'm not sure what the triggers are for the event tracking on this currently, but I think they may need to be tweaked (per above or something similar) to account for these instances.
This is related to https://github.com/orgs/Twin-Cities-Mutual-Aid/projects/1#card-39774852
I'm still getting my dev environment set up, but I can work on this ticket, since no one is currently assigned?
Reading through the code, looks like the current functionality has the google analytic "language_change" event happen in translator.js every time the language changes, which includes:
- when a user first hits the page and they manually set it
- when the page reloads and the code finds a default value in the query string of the URL
- when the page reloads and the code finds a default value in local storage (from previous times the user hit the page)
- user actively selects a language from the pop-up
Changing the language_change event to only trigger when a user clicks on a language in the welcome popup looks to just require moving the one gtag() call to the onLanguageSelect function for the welcome popup.
To track opening and closing the language popup, I would need to know what event and event_label we'd want to use in order to track that the best.
Questions before developing
- what should the event type and event label be for opening and closing the language popup
- Is it still useful to track all language changes (all the ones listed above), or is it okay to only track language changes in the popup and the popup open/close?
@Dthurow Thanks so much for picking this up! So excited to have you here!!
You can go ahead and assign this issue to yourself and move it into In Progress when you're ready.
Regarding your questions, for #2 - I definitely think that you're on the right track with only tracking language changes from the user explicitly interacting with the popup - when a user first hits the page and they manually set it and user actively selects a language from the pop-up. And regarding question 1, I'm kind of wondering wondering if we need an event for opening and closing the popup? I think the main info we want to get is how many users are using each of the languages we provide and I kind of feel like more accurately tracking the user's explicit interactions might be enough, what do you think??
Lastly - something that's been on my mind regarding analytics for a while is - is there a way to exclude interactions that come from testing or from localhost (or maybe they are already excluded? I know some localhost interactions are called out on the dashboard but wondering if we might completely remove or extract out)? That may warrant a whole separate issue, but it's relevant to this language issue because the tests select language with each run.
Also, if you would like access to the analytics dashboard let me know!
@amaxama, Yeah, I'm not entirely sure if the opening/closing of the language popup would be useful info? My only thought on that was that if a lot of people are opening the popup and then closing it without selecting anything, that may mean there are people who want a language not currently offered on the popup. That wouldn't give any insight into WHICH language they want, but could be worth tracking, depending on how granular you want the analytics to be.
For filtering out test and localhost, I'm not entirely sure. I've tweaked google analytics tracking before but haven't set it up before. I'm sure it's possible in a couple ways, I'd have to research it (and it's most likely a separate ticket just since it's a separate thing from tracking language changes). I know google analytics has a unique ID it sends from the website that links it to the correct profile/website in the dashboard, so I suspect the simplest would be to have a separate ID for dev and test, and set the production ID in the production website. I don't know how you do deploys or the production environment yet though so I wouldn't be able to give suggestions on exactly how to go about doing that.
And I would appreciate access to the analytics dashboard, so I can do some manual testing to make sure my changes come through correctly!
Also, is there a way to link branches to a specific issue without doing a pull request as well? Just did the initial change in a branch issue-178/dthurow/change-trigger-for-ga-language-change-event but since I may need to do more work didn't want to do a pull request just yet. Would like to have some official way to show they're linked though, just for posterity/organization.
@Dthurow Yeah, that's a good point about the open and closing! But hard to make that kind of assumption if we don't know and your point about not knowing which language is key too. I wonder if it might not better be achieved by having a spot for people to request a language instead. But that gets into translation issues so might need a larger conversation so probably can be tabled for the sake of this story.
For filtering - that's totally fair haha I'm not sure how it would work either :) But what you suggest seems plausible! I can make a separate story to explore that. We don't actually currently have separate stage and prod environments 😶 there's lots of room to improve haha 😅 Deployment happens through netlify which provides a preview site based on a pr so we kind of use that as "stage" to check that PR code will be fine in prod (along with functional tests).
I actually realized I don't have the ability to add you to the dashboard. The dashboard was created back when the project started and I was less involved at the time so I'm not actually sure who made it but let me hunt around a little bit to see who might have that access.
Regarding linking the branch, good idea!! It doesn't seem like linking a full branch to an issue is available but it seems like you should be able to link via a commit. But I can't seem to get it to work :/
Lastly - it looks like there's actually another issue regarding language and google analytics as well #154 so would you mind taking a look at that one and taking that into account with what you're doing for this one? Then ideally, when you're done we'll be able to close both issues.
Mmkay, figured out the analytics! I just need your gmail address if you have one! (You can DM it to me)
@amaxama I sent you a DM in the TCMAP slack with my email!
Okay, so it sounds like the only functionality change we want on this issue is changing it so the language_change event only triggers when the user first comes to the website, and every time they open the welcome popup and select a language.
That functionality change should already be taken care of in 844f71c, once I have access to the google analytics dashboard I can do some manual checking to make sure it's all feeding through properly, and do a pull request with those changes.
Looks like #154 is just verifying that the functionality I'm working with is actually working, so me verifying it for this ticket will complete the work for that one? I'll assign it to me and move to in progress and add a comment there.
Looks like you already made an issue for filtering out test and localhost from google analytics ( #270) , did you want me to make an issue for discussing a "request language" feature, or do you want to leave that alone for now?
@amaxama Got access to google analytics, thanks! Verified my changed worked and fed through to google analytics correctly, made a pull request and requested you as the reviewer since we've been talking about this, let me know if I should request someone else to review, or if I'm missing any steps in the dev process!
@Dthurow Thanks for doing this and for verifying it through GA too! Dev process was great! And regarding your question did you want me to make an issue for discussing a "request language" feature, or do you want to leave that alone for now? - you can go ahead and make an issue! Maybe just make sure to tag it with Discussion so it's clear more needs to be figured out with it :) Sound okay?
I created a new issue for the request language (as seen above), and I double checked the changes are happening in prod correctly. Going to move this to closed :)