How I ended up building a Fortnite Creative tracker that actually works
I don't usually bother writing about this stuff, but I keep seeing people struggle with custom Creative maps that supposedly track stats and nobody can figure out how the backend works. I spent about three weeks reverse-engineering the whole system for my own map. Here's what I found. First, let's clear something up. A tracker for Fortnite Creative doesn't work the way most people think. You can't just slap a leaderboard widget on a canvas and call it done. The actual tracking is driven by data stores — the same persistent cloud storage system Epic built into Creative — combined with triggered circuit logic that writes and reads values based on player actions. If your map doesn't use a DataStore, you have no persistence. Period. Every time a player leaves and comes back, their stats reset. I learned that the hard way on my first build.
Understanding the Tracker For Fortnite Creative Ultimate architecture
The "ultimate" systems I've seen around use a combination of three things: a player-to-key mapping system, a background write loop, and a read-back trigger for UI updates. The key insight nobody talks about is that DataStore reads are async. When you fire a GetPlayerData call, the value doesn't come back instantly. If your UI update logic runs synchronously right after, it's going to display stale or empty data. The workaround is to use a local cache variable that gets populated inside the OnDataStoreRead callback, then trigger your UI refresh from there instead of from the same event chain. Here's how I set it up for a custom map that needed kill tracking, win counting, and objective timer stats: Step one — establish a unique player key. I used the convention "creative_tracker_mapname_player_" concatenated with the PlayerID attribute. This has to be consistent across every write and read operation, otherwise you'll end up with orphaned data entries that stack up in your DataStore and eventually hit the 10-megabyte per-key soft limit. I accidentally left test accounts floating around for two weeks before realizing the store was lagging because of bloat.
Step two — write operations. Every time a tracked event fires (a player elimination, for example), you trigger a SetPlayerData call. The data payload should be a JSON string, not individual keys. The JSON approach is faster because it's a single write call instead of five separate ones, and parsing on the read side takes microseconds. My payload looked something like {"kills":12,"wins":3,"avg_time":45.2} for a given player key. Step three — read and display. This is where most maps fail. You need an OnBeginPlay trigger that fires GetPlayerData when a player spawns in, then uses a timer or a synchronous check to refresh the UI canvas elements. Canvas text elements update based on parsed JSON values. I use a simple string concatenation to format the display — kills shows as integer, wins as integer, average time rounded to one decimal. Step four — cleanup and boundary checks. I initially forgot to handle the case where a player had never played before. The first time someone joined, the DataStore returned empty. My map crashed because the JSON parser tried to read numeric fields from a null value. The fix was a conditional check: if the return payload is empty or malformed, initialize the JSON with default zero values before parsing. This took me maybe forty-five minutes to debug because the error wasn't obvious in the Event Log.
Get the Full Details
Common pitfalls that waste hours
One thing that tripped me up constantly is the DataStore write throttling. Epic limits how frequently you can write per player. If your elimination trigger fires a write on every kill event without any kind of debounce or batching, you'll hit the throttle within a single match and writes will silently fail. I solved this by batching writes on match end instead of per-event. Every elimination gets counted in a local variable, and when the match ends, a single SetPlayerData call writes the delta. It cut my failed writes from roughly eighty percent down to zero. Another issue is cross-session data merging. If you don't handle the merge logic properly, a player's new session stats will overwrite their historical totals instead of accumulating. The fix is to read the existing data, add the session delta to the stored values, then write the merged result back. It's an extra read cycle but it prevents data loss. I've seen maps lose weeks of player stats because the developer skipped this step.
What this approach can't do
I need to be straight about the limitations. DataStore-based trackers hit real walls with large player bases. Once your map gets more than a few thousand active players, read latency starts climbing. I noticed my own map's leaderboard refresh times go from about two hundred milliseconds at low population to over a second when thirty or more distinct players have active DataStore entries. There's also the per-entity limit — each DataStore key has a size cap, and if your JSON payload grows too large with detailed stats, you'll start getting write errors. For most custom maps this isn't a problem, but if you're tracking granular per-round performance data for a competitive scene, you'll need a different architecture. If you need real-time leaderboard integration across multiple maps or a centralized stats system, a DataStore-only approach won't cut it. You'd need to bridge into the Fortnite Creative API or use an external service. That's outside the scope of what's practical for most map makers, but it's worth knowing so you don't hit a wall after investing a bunch of time.
The working reference setup
I don't host a download link here, but I can tell you exactly what you need to assemble. You need a canvas with text elements for each stat you want to display. You need a DataStore component configured to your map ID. You need OnGameStart and OnMatchEnd events to trigger the batch write logic. You need per-player Spawn events to trigger the data read and UI refresh. And you need a JSON parse function, which is built into Creative's logic — it's under the Data section of the function catalog, just not very visible. If you put those pieces together in the right order, the system works reliably. I've been running mine for six weeks now with consistent results. The trick is patience with the async flow. Most people rush the read-back logic and blame the system when nothing displays. Slow down, check your callbacks, and verify the JSON format is valid on every write. That alone will save you most of the frustration. The hardest part is really just getting the initial plumbing right. After that, adding new tracked stats is straightforward — define the key in your JSON schema, increment the appropriate field on the triggering event, and add a canvas element bound to the parsed value. I added objective completion time tracking to my map in about twenty minutes once the base system was working.
