Upgrade prompt too "noisy"
The new prompt after an install or upgrade talks about "one time action", which was meant to convey this is not on-going monitoring/tracking, but that's possibly a little too literal at the moment.
We are seeing a much lower conversation rate between the download stats and the reporting of install/download which implies users were ok for the initial report, but possibly now saying "never again" for the upgrade.
This gives us a few issues, one is that we can't differentiate downloads for installs Vs upgrades, we won't actually know what % are on the latest release - meaning we don't know how many people are holding off upgrade due to anxiety about stability, had to downgrade due to bugs etc.
Also, during first install we don't know how many LEDs or if users are using a 2D matrix, only when they next upgrade version (as there is no ongoing monitoring)
Should we swap the prompt to allow automatic reporting of your next upgrade, or would 4 prompts be too many (yes, yes always, skip, never)
If we do add option for yes - always, how best to word the privacy policy to cover this use case; not all the time, just on later upgrades but without prompting
What are your thoughts @coderabbitai
What are your thoughts @copilot
[!TIP] For best results, initiate chat on the files or code changes.
π§© Analysis chain
π Script executed:
#!/bin/bash
# Search for telemetry, reporting, or analytics related code
rg -i "telemetry|reporting|analytics" -C3 --type-add 'web:*.{html,js,json}' --type web --type cpp --type c
# Search for prompt or dialog related to install/upgrade
rg -i "(one.time.action|upgrade.prompt|install.prompt)" -C3
# Search for privacy policy references
rg -i "privacy.policy" -C3
# Look for any stats or metrics collection
rg -i "(stats|metrics|collect)" -C3 --type-add 'web:*.{html,js,json}' --type web --type cpp --type c | head -100
Length of output: 11685
π Script executed:
#!/bin/bash
# Get the full version upgrade prompt implementation
rg -A30 "showVersionUpgradePrompt" wled00/data/index.js
# Look for the "one time action" text specifically
rg -i "one.time" wled00/data/index.js
# Check for any version storage or tracking
rg "version.json|versionInfo" -C5 wled00/data/index.js
# Look for any settings related to automatic reporting
rg -i "(auto|always|skip|never)" wled00/data/index.js | head -50
Length of output: 5374
π Script executed:
#!/bin/bash
# Get the complete showVersionUpgradePrompt function
rg -A60 "function showVersionUpgradePrompt" wled00/data/index.js
# Get the button handlers
rg -B5 -A10 "versionReport(Yes|Skip|Never)" wled00/data/index.js
# Look at the reportUpgradeEvent function to understand what data is collected
rg -B5 -A40 "function reportUpgradeEvent" wled00/data/index.js
Length of output: 5720
@netmindz Great question! I've analyzed the current implementation and have some thoughts on improving the conversion rate while respecting user privacy.
Current Issues
The main problems I see:
- Ambiguous "one-time" wording - Users may interpret "one-time hardware report" as "if I agree, I'll never be asked again," which could be why they're choosing "Never Ask" instead
- "Not Now" creates friction - It re-prompts on every page load until decided, which is annoying
- "Never Ask" is too permanent - Users who decline lose all future opportunities to contribute upgrade data
- Missing upgrade tracking - You need upgrade metrics to understand version adoption and stability
Recommendation: 4-Option Approach
I think adding a 4th option makes sense, but the wording is critical:
Option 1: Clearer 3-button approach (recommended)
β
"Yes, and ask me next time"
βοΈ "Skip this version"
π« "Never ask again"
Benefits:
- Clearer expectations - users know they'll be asked again
- "Skip this version" replaces "Not Now" and stops the annoying re-prompting
- Still tracks upgrade patterns for users who said yes once
- No privacy policy changes needed
Option 2: 4-button with auto-reporting
β
"Yes, once"
β
β
"Yes, always report upgrades"
βοΈ "Skip this version"
π« "Never ask again"
Benefits:
- Power users can opt into automatic reporting
- Gets you the upgrade metrics you need
- Respects user choice with granular control
Concerns:
- 4 buttons might overwhelm users
- Need privacy policy update (see below)
Updated Prompt Wording
Replace the current question with something clearer:
Current: "Help make WLED better with a one-time hardware report?"
Suggested: "Share this device's hardware specs to help improve WLED? No personal data, just chip type, LED count, etc."
Remove "one-time" entirely since it's confusing. The user can see from the buttons what their ongoing commitment is.
Privacy Policy Considerations
For the "Yes, always" option, add this to the privacy policy:
Automatic Upgrade Reporting: If you choose "Yes, always report upgrades," your device will automatically send hardware configuration data when you upgrade to a new WLED version. This includes only the technical specifications shown in the initial report. You can disable this at any time by [method TBD - perhaps in settings UI or by deleting version-info.json].
Key principles:
- Make it clear it's ONLY on upgrades (not continuous monitoring)
- Explain it's the same data as the one-time report
- Provide a way to opt-out later
Implementation Notes
If you go with Option 2, you'd need:
- Add
alwaysReport: booleanfield toversion-info.json - Check this flag during version change detection
- Auto-submit without prompt if
alwaysReport: true - Maybe add a settings UI to change this preference later
Alternative: Softer "Never Ask"
Consider making "Never Ask" less permanent by changing it to:
-
"Not interested" - Still sets
neverAsk: truebut feels less aggressive - Or provide a way to re-enable prompts in Settings UI
Would you like me to help draft the specific code changes for any of these approaches?
@coderabbitai "skip this version" doesn't sit well with me as an option as actual version number is not something that users are making a decision about. Either they feel ok giving us details of their hardware setup or they do not, they shouldn't be hiding the fact that they tried a nightly build before swapping back to a stable release, for example.
[!TIP] For best results, initiate chat on the files or code changes.
@netmindz You're absolutely right - that was a misguided suggestion on my part. Users aren't making version-specific decisions; they're deciding whether they're comfortable sharing hardware data at all. And hiding upgrade patterns (like nightlyβstable swaps) would defeat the purpose of tracking version adoption and stability.
Revised Recommendation: 3-Button Approach
Given your feedback, I think the solution is simpler:
β
"Yes" (this time, will ask again next upgrade)
β
β
"Yes, always" (automatic reporting on future upgrades)
π« "Never ask again"
Key Changes:
-
Remove "Not Now" entirely - This is what's creating the re-prompting friction. Either they decide now or they decide "never."
-
"Yes" means one-time but will be asked again - The prompt wording should make this clear:
"Share this device's hardware specs to help improve WLED? (No personal data - just chip type, LED count, etc.)"
Remove "one-time" language completely since it's misleading.
-
"Yes, always" for power users - Those comfortable with automatic reporting can opt in and never be bothered again. This gets you the upgrade tracking you need.
-
"Never ask again" stays - For users who fundamentally don't want to share.
Benefits:
- No version-specific decisions - just frequency preference
- Captures upgrade patterns from "Yes" users when they're prompted again
- "Yes, always" users provide automatic upgrade tracking
- No annoying re-prompting on every page load
- Still respects user choice with clear opt-out
Button Copy Options:
Option A (Explicit):
- "Yes, this time"
- "Yes, always report upgrades"
- "Never ask again"
Option B (Simpler):
- "Yes"
- "Yes, and don't ask again"
- "No thanks"
I prefer Option A because it's clearer that "yes, always" means future upgrade reports, not continuous monitoring.
Privacy Policy Update:
For "Yes, always":
If you choose to always report upgrades, your device will automatically send the same hardware configuration data (chip type, LED count, 2D matrix usage, etc.) when you upgrade WLED versions. No behavioral data or usage patterns are collected. You can disable automatic reporting at any time in Settings β Info.
Does this approach align better with what you're trying to accomplish?
π§ Learnings used
Learnt from: netmindz
Repo: wled/WLED PR: 5093
File: wled00/util.cpp:1159-1182
Timestamp: 2025-11-20T00:04:04.829Z
Learning: In WLED PR #5093, the deviceId feature is designed for opt-in usage reporting that tracks only version/upgrade information (non-behavioral data), not user activity patterns. The deterministic salt approach (MAC + "WLED" + chip model/revision) is acceptable for this limited use case, as correlating MAC addresses to version history represents minimal privacy risk compared to behavioral tracking.
I would suggest to make it three options:
- Report once
- Report on all updates
- Not now (ask again on next update)
since updates are not something the average user does very often, I feel it would be ok to drop the "never ask" button. As an option could add checkmarks and make it simple "Yes" and "No" each with a "make this permanent" checkmark with proper wording.
How about a tickbox to save the choice (default on)?
eg. [ Report this update ] [ Skip reporting ] [*] Save my choice for future updates
I feel it would be ok to drop the "never ask" button.
I have the exact opposite feeling - a "permanent opt-out" is IMO probably the most important feature for any reporting permission system. The people who are opting out are the most likely to be strongly opinionated about it, and nagging them about it every time is most likely to produce backlash.
(Personally that kind of nag is just one step below "please rate my app" nag screens... I hate to admit it but I'm one of those people who sometimes 1-stars apps just for a nag popup interrupting what I'm doing)
I feel it would be ok to drop the "never ask" button.
I have the exact opposite feeling - a "permanent opt-out" is IMO probably the most important feature for any reporting permission system. The people who are opting out are the most likely to be strongly opinionated about it, and nagging them about it every time is most likely to produce backlash.
(Personally that kind of nag is just one step below "please rate my app" nag screens... I hate to admit it but I'm one of those people who sometimes 1-stars apps just for a nag popup interrupting what I'm doing)
fair enough
I would suggest to make it three options:
- Report once
- Report on all updates
- Not now (ask again on next update)
since updates are not something the average user does very often, I feel it would be ok to drop the "never ask" button. As an option could add checkmarks and make it simple "Yes" and "No" each with a "make this permanent" checkmark with proper wording.
This with a 4th "No and never ask again" option would be perfect I think.