[do not merge] Add privacy-first tracking#1531
Open
ksen0 wants to merge 1 commit into
Open
Conversation
Member
Author
|
#1401 has been merged, tracking should also be added to filter. I'll have to think a bit more about it, but maybe tracking terms that get results and only when theres "enough" of a pause during typing; in this case I don't think it's needed to track number of results |
Member
Author
|
Feedback is welcome! But please do not merge we are checking if we need to update privacy policy to make this usage clear. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Relates to / partially addresses #1242 - part of working on this issue, Fathom Analytics has been setup. Fathom Analytics is a privacy-first tool that does not use cookies. It therefore has a few limitations relative to something like google analytics, but I believe it can address all or most of our actual needs. We do not currenlty use google analytics on the reference site (though it is used on the p5.js editor)
I am approaching these trackers like in a video game / game analytics. Running and editable code sketch block anywhere on the site is a conversion event on a per-user basis, so we can see % of unique users who did that.
Same for spending a certain amount of time focused on a page, or achieving a relative scroll depth. It is possible to use a secondary variable to see relative scroll depth or focus time conversion per user on each page:
Finally, specific to the Search topic, terms are logged only when there are exact matches (string appear in the reference). Otherwise, they are redacted as "[FUZZY]", because that might include personal information. While unlikely, this follows the principle of data minimization: unless we have a good reason to collect the data, might as well not. Right now, there is no data. This would already be much better.
In all cases, the number of search results is included as a second component of the string, so the events can be exported and analyzed.
Possible other changes
Maybe scroll % should only trigger after 30s? If someone scrolls up and down in the first 30s does that "count?" We should also see if we can notice such a pattern in the aggregate data.
Possibly search term count buckets should be applied, like with the others, such as:
Other Focus and Scroll buckets can be used, especially if informed by the previous studies about whats "enough" time. Scroll % would be useful on other parts of the site, too, but in my opinion it is better to roll these analytics out based on what actually corresponds to an active question.