I’m trying to stabilize my average playtime and retention. I’m stuck because every time I publish even a minor update, my metrics go completely “down the river.” I have to revert to an older version every time just to keep the game alive, which means I can’t progress or add new content at all.
Since I only have around 15 DAU, the graphs vary heavily from day to day, but there is a clear trend that playtime goes down immediately after an update. Another strange thing is that badge completion for joining the game also drops. That badge is supposed to fire almost as soon as a player joins, so it’s weird that it’s not being awarded to everyone anymore.
2. What is the issue?
The game seems to break for a lot of players right after the update. When I test it myself, I do not notice any changes at all, which could mean it’s either memory or CPU related. However, when I check, the client memory on mobile is around 1.1 GB and CPU metrics aren’t looking bad either.
Also, if you wonder why there is a huge drop on March 18 without an update: I ran ads that day and the game had some race conditions when players joined and left quickly, causing people to not be able to play at all. I tried to fix it, but touching the scripts just made the playtime drop even more.
Screenshots:
Retention:
Whenever I notice playtime dropping and badge rates not being 100%, I revert to the last stable version. This fixes the stats, but I can’t publish any new content because I don’t know what’s causing the drop.
I’ve looked at the error messages and there are zero errors related to this. I also checked the Creator Hub for similar issues but couldn’t find anything. My client memory is around 1.1 GB on mobile I’ve heard some say this is normal due to the heavy Roblox engine, but is that true for a Tycoon?
Also, my game has around 400 MB of Untracked Memory . Is that also normal, or could this be the reason players are crashing during the join process?
I also already activated StreamingEnabled and set most object collisions to Box format before*I even noticed these update-related drops, so they shouldn’t be the cause.
I get that, but the metrics correlate perfectly with every update I push. In the last stable version, the badge completion rate is consistently at 100%, but as soon as I publish an update, it drops immediately.
The immediate playtime drop after updates combined with the badge award issue suggests you’re hitting script errors on client-side rather than pure performance problems. Here’s why: if clients are crashing or encountering errors, players leave immediately (tanking playtime), and if badge-awarding scripts fail early, that metric breaks too.**Start here:**1. Check your Output window during live gameplay — open the game while logged in as a player (not Studio), play normally, and watch for errors. Client-side errors won’t show in Studio’s output but will destroy player experience. Have someone else test on mobile simultaneously.2. Review what actually changed — even “minor” updates can break things: - Did you rename any RemoteEvents or RemoteFunctions? This breaks old clients until they rejoin. - Did you modify DataStore calls? Players with cached data might hit errors when new code expects different structures. - Did you change the badge script’s parent, disabled it, or alter when it fires?3. Test on actual mobile devices, not just the emulator. The 1.1 GB memory usage is relatively high for mobile—if you’re approaching memory limits, scripts fail silently under load.4. Use version control — publish to a private test place first before pushing live. This lets you A/B test and revert faster.5. Implement error tracking — wrap critical scripts in pcall() and log errors to a DataStore. With 15 DAU, manually tracking what breaks is actually feasible:luapcall(function() -- Your badge code hereend)At your scale, the issue is almost certainly silent script failures. The badge award drop is your smoking gun—that’s not a performance problem, that’s code not executing. Focus debugging there first.
I would recommend you doing more in depth tests. Personally before releasing a game I play it in Roblox (not just Roblox Studio) using my phone and PC to see the difference as 100% of the time always find race conditions occurring on mobile which nearly never occur on computer because of performance issues, network connection and so on. Also check data for specific devices, for example - mobile, using roblox filters. Also why not try asking active players for issues they had experienced regarding joining in the experience.
The immediate playtime drop after updates combined with the badge award issue suggests you’re hitting script errors on client-side rather than pure performance problems. Here’s why: if clients are crashing or encountering errors, players leave immediately (tanking playtime), and if badge-awarding scripts fail early, that metric breaks too.**Start here:**1. Check your Output window during live gameplay — open the game while logged in as a player (not Studio), play normally, and watch for errors. Client-side errors won’t show in Studio’s output but will destroy player experience. Have someone else test on mobile simultaneously.2. Review what actually changed — even “minor” updates can break things: - Did you rename any RemoteEvents or RemoteFunctions? This breaks old clients until they rejoin. - Did you modify DataStore calls? Players with cached data might hit errors when new code expects different structures. - Did you change the badge script’s parent, disabled it, or alter when it fires?3. Test on actual mobile devices, not just the emulator. The 1.1 GB memory usage is relatively high for mobile—if you’re approaching memory limits, scripts fail silently under load.4. Use version control — publish to a private test place first before pushing live. This lets you A/B test and revert faster.5. Implement error tracking — wrap critical scripts in pcall() and log errors to a DataStore. With 15 DAU, manually tracking what breaks is actually feasible:luapcall(function() -- Your badge code hereend)At your scale, the issue is almost certainly silent script failures. The badge award drop is your smoking gun—that’s not a performance problem, that’s code not executing. Focus debugging there first.
