Analytics: clean up & consistency #1292
Labels
estimate: m
Medium
needs more info
An item that is missing information or requires further discussion.
Comments
tcrammond
added
the
needs more info
tcrammond
added a commit
that referenced
this issue
Feb 25, 2019
Stopped sending settings becaues the data is not really in a reportable format. This may be handled in #1292.
tcrammond
added a commit
that referenced
this issue
Feb 26, 2019
Stopped sending settings becaues the data is not really in a reportable format. This may be handled in #1292.
tcrammond
added a commit
that referenced
this issue
Mar 1, 2019
Stopped sending settings becaues the data is not really in a reportable format. This may be handled in #1292.
tcrammond
added a commit
that referenced
this issue
Mar 1, 2019
- Add storage permission to manifest - Refactor db.js to use storage.sync api via webextension-polyfill - Refactor background storage usage to handle promises - Refactor popup storage usage to handle promises - Refactor Settings storage usage to handle promises - Refactor GA storage usage to promises, stop sending settings. Stopped sending settings becaues the data is not really in a reportable format. This may be handled in #1292. - Refactor DB message-handling to background page. We cannot have more than one message handler taking the same messages; it breaks everything.
tcrammond
added a commit
that referenced
this issue
Mar 4, 2019
- Add storage permission to manifest - Refactor db.js to use storage.sync api via webextension-polyfill - Refactor background storage usage to handle promises - Refactor popup storage usage to handle promises - Refactor Settings storage usage to handle promises - Refactor GA storage usage to promises, stop sending settings. Stopped sending settings becaues the data is not really in a reportable format. This may be handled in #1292. - Refactor DB message-handling to background page. We cannot have more than one message handler taking the same messages; it breaks everything.
tcrammond
added a commit
that referenced
this issue
Mar 13, 2019
Extension settings are saved in synced storage. - Add storage permission to manifest - Refactor db.js to use storage.sync api via webextension-polyfill - Refactor most storage usage and browser messaging to use promise format - Refactor GA storage usage to promises, stop sending settings. Stopped sending settings becaues the data is not really in a reportable format. This may be handled in #1292. - Refactor DB message-handling to background page. We cannot have more than one message handler taking the same messages; it breaks everything. - Reduce storage access when using default project - Add method to retrieve multiple storage values at once Closes #1296.
tcrammond
added a commit
that referenced
this issue
Mar 13, 2019
Extension settings are saved in synced storage. - Add storage permission to manifest - Refactor db.js to use storage.sync api via webextension-polyfill - Refactor most storage usage and browser messaging to use promise format - Refactor GA storage usage to promises, stop sending settings. Stopped sending settings becaues the data is not really in a reportable format. This may be handled in #1292. - Refactor DB message-handling to background page. We cannot have more than one message handler taking the same messages; it breaks everything. - Reduce storage access when using default project - Add method to retrieve multiple storage values at once Closes #1296.
toggl-button-bot
added a commit
that referenced
this issue
Mar 13, 2019
# [1.23.0](1.22.2...1.23.0) (2019-03-13) ### Bug Fixes * Ensure only one websocket is created ([e3d1cbe](e3d1cbe)) ### Features * Migrate settings when upgrading to 1.23.x ([7b497da](7b497da)), closes [#1296](#1296) * Use WebExtension synced storage ([f936868](f936868)), closes [#1292](#1292) [#1296](#1296) * **settings:** Add "Reset settings" feature to Settings ([d1fc44f](d1fc44f)), closes [#1317](#1317)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This needs some digging into and a plan made.
Notes:
Some analytics events are becoming duplicated, or mixed up between versions of the same service integration.
Settings usage is being sent to analytics, but this data is practically unusable in the current form. We should find another way to analyse "Which settings are being used?" if time permits.
It appears that the "id" of analytics time entry events (e.g.
jira) is derived from class name, and as these change over time the data is getting messed up.The standard time entry actions are also not clear in the way events are sent to analytics right now.
Edit:
Please also make sure events are actually being sent when an entry is created. We had a huge dip in the usage stats and we're not sure whether there's some problem in telemetry or if we indeed have low usage of the tool.
The text was updated successfully, but these errors were encountered: