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

Track time spent on a webpage #3

Closed
sharon-wang opened this issue May 23, 2020 · 4 comments · Fixed by #23
Closed

Track time spent on a webpage #3

sharon-wang opened this issue May 23, 2020 · 4 comments · Fixed by #23
Assignees
Labels
GftW x DEV Hackathon Part of our hackathon prototype

Comments

@sharon-wang
Copy link
Member

How much time is being spent on each webpage?

Use cases for tracking time:

  • ratio of time spent on web monetized vs non-web monetized sites
  • how much time spent on web monetized sites (estimate how much money the user would stream to the site if they are not yet streaming payment)
@sharon-wang
Copy link
Member Author

Tracking time spent on a webpage can be challenging, as it requires us to determine when a user is active on a website. It seems to me that the Page Visibility API is a good bet for getting close to tracking time reasonably well.

However, there's some tricky pieces - from the linked doc above:

Note: While onblur and onfocus will tell you if the user switches windows, it doesn't necessarily mean it's hidden. Pages only become hidden when the user switches tabs or minimizes the browser window containing the tab.

So, that means we'll have to make a judgement call. If a user has multiple application windows open and navigates away from their browser to another app, but the browser is still open, do we consider them to be active on the webpage open in their browser? I think that depends on what content is on the webpage. For example, if the site hosts audio, then even if the user clicks on a different app, they're still consuming content from the webpage. So, we'd likely say they're active in this case. However, if it's an article or a video, then we'd probably consider them to be inactive. Then, we have to consider the case where a user has multiple monitors. They could have their browser open on a different monitor and may or may not be engaging with the content. They might be engaging in the content while also using another application. For example, if they were taking notes on the content in the webpage - they'd primarily be using another app, but they're actively using the content in the webpage.

For the purposes of our prototype, I think we can keep it simple and make the assumption that if the browser window isn't their current window, then they aren't "active". We'll only track time spent when the user's primary window (the one currently in focus) is the website we're recording time for.

@vezwork Would like to hear your input.

@vezwork
Copy link
Member

vezwork commented May 27, 2020

I think the assumption for the prototype makes sense. I think the stats based off that assumption would still seem reasonable, and as long as we document the assumption/tradeoffs I think it is all good.

If we want to dig into it a bit more, I found the source code for a time tracking extension: https://github.com/Stigmatoz/web-activity-time-tracker. This may give us some ideas of how this is done effectively.

@sharon-wang
Copy link
Member Author

sharon-wang commented May 28, 2020

Upon further research of Page Visibility API, I don't think it's the best fit for our purposes. Looks like one of its main use cases is to pause/disable content when a user doesn't have the webpage visible. For example: if the site has video content, the site might want to pause the video if the user no longer has that window visible.

@vezwork Thanks for the resource! They're got a lot going on there, very cool. Looks like they're using the windows API, which seems more promising, alongside the tabs API. I think I can work with these APIs to calculate time spent as well as visits (#7) without things getting too complicated.

@sharon-wang sharon-wang added the GftW x DEV Hackathon Part of our hackathon prototype label May 29, 2020
@sharon-wang
Copy link
Member Author

Upon further, further research, the Page Visibility API, does seem like the way to go. It's simple and allows us to avoid having to use background scripts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GftW x DEV Hackathon Part of our hackathon prototype
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants