Upgrade prompt too "noisy"

[netmindz]

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

[netmindz]

What are your thoughts @coderabbitai

[netmindz]

What are your thoughts @copilot

[coderabbitai]

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:

1. 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
2. "Not Now" creates friction - It re-prompts on every page load until decided, which is annoying
3. "Never Ask" is too permanent - Users who decline lose all future opportunities to contribute upgrade data
4. 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:

1. Add alwaysReport: boolean field to version-info.json
2. Check this flag during version change detection
3. Auto-submit without prompt if alwaysReport: true
4. 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: true but 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?