# Should we start collecting software usage data?
**URL:** https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873
**Category:** Development
**Created:** [July 29, 2023, 7:52pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873 "2023-07-29T19:52:39Z")
**Posts on this page:** 20
**Page:** 4
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [April 17, 2024, 3:18am UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/61 "2024-04-17T03:18:44Z")
There are many things to do, I would recommend to start with setting up a similar system as used for getting Slicer download statistics:
- Set up an nginx the server (based on Kitware’s recommendation) that returns success (200 OK) and an empty page whenever it receives a valid web request and it logs the request into a file.
- You can run a simple flask application to check the validity of the request (similar to [this](https://github.com/Slicer/slicer_download/tree/main/slicer_download_server) but much simpler as you don’t need to return any real content)
- The request format is something like [https://example.com/telemetry?app=Slicer&app\_version=5.6.2&collection\_start\_date=20240402&collection\_end\_date=20240415&app\_startup=28&module\_DICOM\_activate=12&module\_SampleData\_activate=3&extension\_LungCTAnalyzer\_AISegmentation=18&extension\_LungCTAnalyzer\_ClassicSegmentation=2](https://example.com/telemetry?app=Slicer&app_version=5.6.2&collection_start_date=20240402&collection_end_date=20240415&app_startup=28&module_DICOM_activate=12&module_SampleData_activate=3&extension_LungCTAnalyzer_AISegmentation=18&extension_LungCTAnalyzer_ClassicSegmentation=2)
- Implement a script (almost the same as [this](https://github.com/Slicer/slicer_download/tree/main/etc/slicer_parselogs)) that parses the server logs and saves results into a database and/or json file
- Implement web frontend that can display statistics (almost the same as [this](https://github.com/Slicer/slicer_download_stats)) - we would want the same kind of filtering based on geography, maybe operating system, display of graph; but instead of download count, we could select any of the events (module\_DICOM\_activate, module\_SampleData\_activate, extension\_LungCTAnalyzer\_AISegmentation, extension\_LungCTAnalyzer\_ClassicSegmentation, etc.)
---
### Author:  [@BerDom.Ing](https://discourse.slicer.org/u/BerDom.Ing)
#### Post date: [April 17, 2024, 2:13pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/62 "2024-04-17T14:13:09Z")
Thanks for your guidance. I’ll be working on it.
---
### Author:  [@Bob5](https://discourse.slicer.org/u/Bob5)
#### Post date: [April 18, 2024, 10:04am UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/63 "2024-04-18T10:04:35Z")
“Should we start collecting user data?”
My answer is a big NO !
And I have this on offline machine, if it wont work offline its garbage. If it collects data and I have to agree to that - its garbage.
Have a nice day.
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [April 18, 2024, 12:10pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/64 "2024-04-18T12:10:14Z")
Great, thanks for the feedback! We discuss this topic very openly for complete transparency and to make sure that everyone’s point of view is taken into account.
As you can see from the detailed discussion above, we absolutely don’t want to change Slicer to some online-only service. That would not make sense and you do not need to worry about that.
The main motivation for collecting feedback from users automatically is that most extension developers don’t get any financial compensation for their work; and their enthusiasm is only kept alive by seeing that people use their extensions. Of course everyone is busy, so people do not take the time to give feedback, which often causes developers to lose interest and give up maintaining and improving their extensions. The idea is that we could collect information about how many people use an extension and make it available to its developer, without requiring any efforts from the user. Of course users can opt out, or we could make reporting disabled by default (but then users would need to take an effort to enable reporting if they want to keep their beloved modules alive).
If you have any specific concerns or have ideas on how to do this well then let us know.
---
### Author:  [@Bob5](https://discourse.slicer.org/u/Bob5)
#### Post date: [April 18, 2024, 12:38pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/65 "2024-04-18T12:38:08Z")
Thanks for replay, my answer was a bit ‘shizo’ but backed by many years and many similar examples from past. Just keep an eye on this ‘future’ and how it is used. It can be beneficial or dangerous for end user and even for project.
I cant demand and I dont demand anything (because I didnt contributed yet to project), I was only opinion. Thanks for reading and taking this biased opinion into account.
Thanks for great software (I dont use it commercially, I use it 100% as hobbyst) 🙂
---
### Author:  [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)
#### Post date: [April 18, 2024, 2:13pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/66 "2024-04-18T14:13:06Z")
Hi @Bob5 thanks for the feedback:
> [@Bob5](#):
>
> It can be beneficial or dangerous for end user and even for project.
Can you help describe in specifics the types of dangers that you are most concerned about? That will help guide the progress on this topic. Thanks!
---
### Author:  [@Bob5](https://discourse.slicer.org/u/Bob5)
#### Post date: [April 19, 2024, 12:36am UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/67 "2024-04-19T00:36:06Z")
Like … Spying on users? How could it be bad? I have no idea.
For projects like audacity (audio editor) - it had to drop the idea of telemetry but still have a bad PR to this day. But it was big project with lots of people using it, and after announcing telemetry to improve this program - it headed stright to /dev/null. So they have no choice and revert the idea of telemetry.
So, why its bad and why people dont like it?
-the way the data is sent is not transparent, its different than making a text file, that user can read and sending it via email attachment or similar mean.
-data collection dont really improve the software, like really, some of them are getting worse, and use more resources to just collect the data.
-(CubeIDE - for ARM microcontrollers).
-its slippery slope to collect more and more so called ‘telemetry’ data
-if you want to improve software - first improve bug/issue reporting, is it easy to ‘normal’ user, how its managed, what is the outcome?
Just a couple fast thoughts, thanks 🙂
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [April 19, 2024, 2:07am UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/68 "2024-04-19T02:07:51Z")
“Spying” sounds bad. But would you call data collection spying if it is all done with the explicit consent and full understanding of the user?
---
### Author:  [@Bob5](https://discourse.slicer.org/u/Bob5)
#### Post date: [April 19, 2024, 5:05am UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/69 "2024-04-19T05:05:32Z")
From legal point of view - NO !
From practical point of view - YES of course !
Nobody really reads that stuff, and this fact can be used against user. Its user fault - but still can be used against user (that can assume that nobody will abuse him).
1. Does program provide a clear and easy way to view all data that will be sent (not only data type but FULL data) before sending?
2. can user say yes/no before each data send? Decide when, what and how this data will be sent?
3. can user easily without consequences (that program still works 100% as before), at any time disable / enable telemetry?
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [April 19, 2024, 11:26am UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/70 "2024-04-19T11:26:32Z")
These specifics are very useful. We can very easily implement telemetry so that we can answer Yes to all these 3 questions.
Is there any information that you would be comfortable with sharing and any specific data that you would not want to share? (number of times Slicer is started, specific modules or features used; CPU, GPU, RAM, operating system, screen size information, …)
---
### Author:  [@Bob5](https://discourse.slicer.org/u/Bob5)
#### Post date: [April 19, 2024, 1:46pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/71 "2024-04-19T13:46:06Z")
I think its OK, anything above that can be considered “fingerprinting” like kernel compilation, more specyfic hardware details etc. and even more - like accesing files and usage of fule etc. is in my opinion not apropriate. Thank You 🙂
---
### Author:  [@jamesobutler](https://discourse.slicer.org/u/jamesobutler)
#### Post date: [April 19, 2024, 2:34pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/72 "2024-04-19T14:34:52Z")
> [@Bob5](#):
>
> more specyfic hardware details etc
Do you find the hardware details that Steam collects to be acceptable?
[https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam](https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam)
---
### Author:  [@BerDom.Ing](https://discourse.slicer.org/u/BerDom.Ing)
#### Post date: [May 6, 2024, 3:28pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/73 "2024-05-06T15:28:53Z")
> [@lassoan](#):
>
> - Set up an nginx the server (based on Kitware’s recommendation) that returns success (200 OK) and an empty page whenever it receives a valid web request and it logs the request into a file.
> - You can run a simple flask application to check the validity of the request (similar to [this](https://github.com/Slicer/slicer_download/tree/main/slicer_download_server) but much simpler as you don’t need to return any real content)
> - The request format is something like [https://example.com/telemetry?app=Slicer&app\_version=5.6.2&collection\_start\_date=20240402&collection\_end\_date=20240415&app\_startup=28&module\_DICOM\_activate=12&module\_SampleData\_activate=3&extension\_LungCTAnalyzer\_AISegmentation=18&extension\_LungCTAnalyzer\_ClassicSegmentation=2](https://example.com/telemetry?app=Slicer&app_version=5.6.2&collection_start_date=20240402&collection_end_date=20240415&app_startup=28&module_DICOM_activate=12&module_SampleData_activate=3&extension_LungCTAnalyzer_AISegmentation=18&extension_LungCTAnalyzer_ClassicSegmentation=2)
> - Implement a script (almost the same as [this](https://github.com/Slicer/slicer_download/tree/main/etc/slicer_parselogs)) that parses the server logs and saves results into a database and/or json file
I started working on that here: [https://github.com/BerDom-Ing/Telemetry](https://github.com/BerDom-Ing/Telemetry)
---
### Author:  [@jcfr](https://discourse.slicer.org/u/jcfr)
#### Post date: [June 11, 2024, 6:56pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/74 "2024-06-11T18:56:07Z")
Following up [this morning](https://discourse.slicer.org/t/2024-06-11-weekly-meeting/36652) weekly hangout, sources of the website that will be used to visualize the 3D Slicer application and extensions usage statistics will be organized in the following GitHub repository.
> **[GitHub - Slicer/slicer-usage-stats: Source code of the site allowing to...](https://github.com/Slicer/slicer-usage-stats)**
>
> Source code of the site allowing to visualize Slicer application and extension usage statistics. - Slicer/slicer-usage-stats
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [July 16, 2024, 8:45pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/75 "2024-07-16T20:45:23Z")
A pull request has been submitted that proposes to add `qSlicerCoreApplication::logUsageEvent(QString component, QString event)` method, which can be called by modules in Slicer core and extensions to indicate that certain software feature is used. The application itself does not process the event, just emits a `usageEventLogged(QString, QString)` signal, which can be connected to slots in external modules.
This API can be used for example for implementing an extension that collects usage data and computes usage statistics of various features. If no extensions are installed that processes software usage data then calling `qSlicerCoreApplication::logUsageEvent` has no effect.
>
>
> The new qSlicerCoreApplication::logUsageEvent can be called by modules in Slicer… core and extensions to indicate that certain software feature is used. The application itself does not process the event, just emits a 'usageEventLogged' signal, which can be connected to slots in external modules.
>
> This API can be used for example for implementing an extension that collects usage data and computes usage statistics of various features. If no extensions are installed that processes software usage data then calling qSlicerCoreApplication::logUsageEvent has no effect.
>
> How to test:
>
> \`\`\`
> \# Observe the usage event and print it if any is logged
> slicer.app.connect("usageEventLogged(QString,QString)", lambda component, event: print(f"{component} -\> {event}"))
>
> \# Log an event
> slicer.app.logUsageEvent("TotalSegmentator", "segmentation/ct/total")
> \`\`\`
>
> See related discussions at https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873
>
> \---
>
> This pull request deprecates https://github.com/Slicer/Slicer/pull/7788, as we do not want to put any actual usage data recording into Slicer core, just a hook that allows implementing extensions in the future (that the user can optionally install) that can collect usage data.
>
> @jcfr @pieper @sjh26 @jamesobutler @cpinter
Any questions and suggestions are welcome, preferably at the pull request, so that we have all the discussions related to this proposed change at one place.
---
### Author:  [@BerDom.Ing](https://discourse.slicer.org/u/BerDom.Ing)
#### Post date: [July 17, 2024, 8:44pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/76 "2024-07-17T20:44:41Z")
I’m working on a repo where I’m developing a website to visualize the usage statistics of the 3D Slicer application and its extensions. So far, I’ve managed to create a bar chart that displays modules and functions. When you click on a bar in the modules chart, it filters the functions chart to show only the functions from the selected module.
I would appreciate a review of the charts and would love to hear any ideas on how to improve them.
Here is the repo: [GitHub - BerDom-Ing/slicer-usage-stats: Source code of the site allowing to visualize Slicer application and extensions usage statistics.](https://github.com/BerDom-Ing/slicer-usage-stats)
It looks like this:
Thanks in advance for your feedback!
---
### Author:  [@rbumm](https://discourse.slicer.org/u/rbumm)
#### Post date: [August 2, 2024, 7:32pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/77 "2024-08-02T19:32:44Z")
I recognize that many of you have had reservations about the use of counters in the Lung CT Analyzer extension. In response, I have removed all counters from the extension. Additionally, due to the mechanism being buggy, all related data have been deleted.
Let’s collaborate to develop a more intelligent solution for this issue.
Wishing everyone a wonderful, counter-free weekend!
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [August 3, 2024, 9:27pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/78 "2024-08-03T21:27:30Z")
We are slowly making progress with this. We now have an API in Slicer Preview Release that extensions can use to log usage events:
>
>
> The new qSlicerCoreApplication::logUsageEvent can be called by modules in Slicer… core and extensions to indicate that certain software feature is used. The application itself does not process the event, just emits a 'usageEventLogged' signal, which can be connected to slots in external modules.
>
> This API can be used for example for implementing an extension that collects usage data and computes usage statistics of various features. If no extensions are installed that processes software usage data then calling qSlicerCoreApplication::logUsageEvent has no effect.
>
> How to test:
>
> \`\`\`
> \# Observe the usage event and print it if any is logged
> slicer.app.connect("usageEventLogged(QString,QString)", lambda component, event: print(f"{component} -\> {event}"))
>
> \# Log an event
> slicer.app.logUsageEvent("TotalSegmentator", "segmentation/ct/total")
> \`\`\`
>
> See related discussions at https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873
>
> \---
>
> This pull request deprecates https://github.com/Slicer/Slicer/pull/7788, as we do not want to put any actual usage data recording into Slicer core, just a hook that allows implementing extensions in the future (that the user can optionally install) that can collect usage data.
>
> @jcfr @pieper @sjh26 @jamesobutler @cpinter
The plan is that if the user installs the Telemetry extension and gives permission then the usage events can be recorded and aggregated on a server.
---
### Author:  [@mau\_igna\_06](https://discourse.slicer.org/u/mau_igna_06)
#### Post date: [September 9, 2024, 8:35pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/79 "2024-09-09T20:35:39Z")
NOTE: I think on first iterations of the Telemetry extension we should auto-exclude (or even forbid) telemetry from european citizens because General Data Protection Regulation (GDPR) is very strict. We can always support european users later.
---
### Author:  [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [September 9, 2024, 8:39pm UTC](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873/80 "2024-09-09T20:39:21Z")
We don’t need to exclude European countries, as long as we don’t store any information that can identify individuals (such as email, IP address, hash created from fingerprinting the hardware components, etc.). Since many people would prefer not to be individually identified anyway, it is probably the best to just not store such information, only anonymous, aggregate data.
[Previous page](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873.md?page=3)
[Next page](https://discourse.slicer.org/t/should-we-start-collecting-software-usage-data/30873.md?page=5)