
How to Optimize Session Fill Rate in Your Matchmaker

This article is the practical companion to Edgegap's matchmaker documentation on fine-tuning expansions. It translates the configuration concepts into plain language and actionable decisions. For the latest syntax, configuration examples, and version-specific details, the documentation page remains the authoritative reference.
If you're coming from the overview article on how session fill rate affects hosting costs, this is the follow-up. You know fill rate costs money. This covers what to do about it.
The strategies below are ordered roughly by impact and ease of implementation. Not every one applies to every game, but most studios with a live matchmaker will find at least two or three they haven't fully used yet.
Start With a Diagnostic, Not a Fix
Tuning matchmaking configuration without a baseline is guesswork. Before changing anything, establish three things:
Your current fill rate, per region. A global average is not enough. Regional fragmentation is often where the real problem lives. See "Regional Fill Rate" below.
Your peak vs. off-peak variance. A matchmaker tuned for 10,000 concurrent players at peak will behave very differently with 800 players at 3am. These two conditions often need separate treatment.
Where sessions are losing fill. Are lobbies never reaching minimum player count and timing out? Or do they start full but drain mid-match? The answer determines which lever to pull first.
If you use Edgegap's matchmaker, the analytics dashboard provides fill rate metrics, match counts, and expansion stage data over time. For studios that want to model the cost impact of a specific fill rate target before making changes, the fill rate calculator is the right starting point.
The Primary Lever: min_team_size and max_team_size
This is the single highest-impact configuration change most studios haven't made. And it's also one of the simplest.
By default, many matchmakers are configured to require a full lobby before a session can start. A game with 8 players per match will hold out until all 8 are ready. If the pool is too thin to assemble them, the matchmaker works through its expansion stages, progressively widening skill and latency constraints. If a full lobby still isn't possible by the end of the final expansion stage, or by ticket expiration, the ticket cancels and players re-queue.
Separating min_team_size from max_team_size changes the fallback behavior. The matchmaker still holds out for maximum fill for as long as possible. But at the end of an expansion stage or at ticket expiration, if enough players for a minimum-size lobby are available, the session fires rather than cancelling. The matchmaker has waited as long as it reasonably can, assembled as many players as it could, and delivered a match rather than returning everyone to the queue.
The tradeoff is a real one: a session that starts below maximum capacity is a slightly different player experience than a full lobby. The right answer depends on your game mode. For casual and co-op formats, a partial start is generally preferable to a cancelled queue and a frustrated player returning to the lobby. For competitive formats where team symmetry matters, it may not be. Profile-level configuration lets you apply this selectively, which the "Profile Strategy" section covers.
Once a partial session starts, backfill can recover toward full capacity during the match itself. That mechanism is covered in the next section.
For concrete configuration syntax and worked examples, see the player_count rule documentation.
Expansion Rules: Trading Time for Fill
Expansion rules are the matchmaker's mechanism for relaxing constraints over time when a full lobby can't be assembled quickly. They're the primary tool for improving fill rate in low-CCU conditions without degrading match quality at peak.
What Expansions Actually Do
When a player enters the queue, the matchmaker applies the initial ruleset: strict skill difference, tight latency thresholds, required game mode or map overlap. If a match isn't found within a configured window, expansion rules loosen one or more of those constraints and the search widens.
Each expansion stage is time-triggered. At 30 seconds, skill range might widen. At 60 seconds, latency tolerance might increase. At 3 minutes, minimum team size might drop. The matchmaker works through these stages until either a match is made or the ticket expires.
The result is a system that delivers high-quality matches when the player pool supports it, and acceptable matches when it doesn't, rather than delivering no match at all.
How to Sequence Them
The order in which constraints relax matters. A poorly sequenced expansion can produce matches that feel worse than a longer wait would have.
As a general principle:
Relax skill constraints before latency constraints. A slightly unbalanced match is less disruptive than a laggy one. Players tolerate skill variance more than poor connection quality.
Relax latency constraints before minimum team size. A full lobby with moderate latency is preferable to a partial lobby with good latency.
Make minimum team size the last expansion, not the first. It's the most visible change to players. Use it as a last resort before ticket expiration, not an early fallback.
Expansion intervals should also reflect your session length. A game with 5-minute matches has players cycling back into the queue frequently, which naturally increases the pool available at any moment. You can afford tighter initial rules and shorter expansion intervals. A game with 30-minute matches needs to get the match right the first time. Wider initial tolerances and fewer expansion stages are often better.
One more consideration worth getting right: expansion margins should grow with each stage, not stay uniform. As earlier rounds run, players near the parameter averages get matched first. What remains in later rounds are the outliers at the edges of the allowed range, and there are structurally fewer of them. A uniform expansion step that worked well at the first stage will find a much smaller pool at the second. To account for this, each expansion should relax by a larger margin than the previous one. If you widen max latency from 100ms to 150ms in the first expansion, the next step should go further, from 150ms to 250ms, rather than another uniform 50ms. The same logic applies to skill range. This keeps later expansion stages effective even as the unmatched pool shrinks.
For the exact expansion configuration format and a worked example with staged relaxation across 30s, 60s, and 180s, see the Rule Expansion section in the documentation.
The Low-CCU Problem
This is where many studios miscalibrate. Expansion rules are typically tuned during testing or shortly after launch, when player populations are concentrated and queues move quickly. Those same rules often fail silently during off-peak hours or in secondary regions where the pool is a fraction of peak size.
The symptom is higher ticket expiration rates and lower fill during low-traffic windows, even when the matchmaker appears healthy overall.
The fix is usually not looser global defaults. That degrades match quality at peak. The fix is a separate matchmaking profile for low-CCU conditions, with faster expansion intervals and wider tolerances from the start. The "Profile Strategy" section covers how to structure this.
Backfill: Improving Fill After Match Start
Every lever discussed so far operates at the moment of match creation. Backfill is different. It operates after a session has already started, filling empty seats left by leavers or improving occupancy in sessions that started below maximum capacity.
One important behavior to understand: when backfill is configured and the profile rules allow it, the matchmaker prioritizes filling an existing in-progress session over starting a new one. A player entering the queue can be routed into an open seat in a live session rather than waiting for a fresh lobby to assemble. This directly improves fill rate across your active server fleet, not just at the moment of match creation.
Replacing Leavers
When a player disconnects or abandons mid-session, the server creates a backfill ticket representing the empty slot. That ticket re-enters the matchmaking queue and can be matched with a player who is searching for a game. From the incoming player's perspective, they join an in-progress session. From the server's perspective, the seat is filled and the session continues at higher occupancy.
For game modes where a leaver would otherwise cause a restart or a degraded experience, backfill meaningfully extends both session lifespan and average fill.
Filling Partial Lobbies
Backfill also applies when a session started below maximum capacity through partial-fill matching. If a session starts with fewer than the maximum players under the min_team_size / max_team_size strategy described above, the server can immediately issue a backfill ticket for the remaining slots. Those seats can be filled while the session is already running, recovering toward full capacity without requiring the match to wait before starting.
Both use cases share the same implementation path. The server creates and manages backfill tickets, handles abandonment timers for incoming players, and cleans up any open backfill tickets when the session ends. The backfill documentation covers the full lifecycle, including ticket creation, assignment handling, and server-side cleanup.
Backfill is not appropriate for all game modes. Competitive formats where team composition is fixed, or modes where joining mid-match creates an unfair disadvantage, should not use backfill. For casual, co-op, social, and open-world formats, it is one of the most effective fill rate tools available.
Profile Strategy: Matching Your Matchmaker to Real Conditions
Most studios launch with a single matchmaking profile and tune it globally. This works at scale with a healthy, concentrated player pool. It breaks down as the game matures, the playerbase diversifies across regions and time zones, and different game modes attract different audience sizes.
The answer is intentional profile segmentation. Three scenarios cover most live titles:
Competitive vs. casual game modes. Competitive modes should run tight constraints: strict skill matching, hard latency limits, no partial fills, no backfill. Casual modes should run looser: faster expansion, backfill enabled, partial fills acceptable. Running both on the same profile forces a compromise that serves neither well. Separate profiles let each mode behave appropriately for its audience.
Peak vs. off-peak hours. If your CCU variance between peak and low-tide is greater than 60%, a single profile will either over-constrain during low-CCU windows (causing ticket timeouts and poor fill) or under-constrain at peak (causing quality degradation). A dedicated low-CCU profile with faster expansion intervals and wider initial tolerances handles off-peak conditions without touching the peak configuration.
Pro or challenger tiers. High-skill players represent a small fraction of the population and don't follow the bell-curve skill distribution that most expansion settings are designed for. A dedicated profile for top-ranked players with its own skill thresholds and longer expansion patience produces better matches for this segment without distorting the experience for the majority.
For configuration examples covering competitive, cooperative, and social game modes side by side, see the profile configuration section in the documentation.
Regional Fill Rate: Fixing the Hidden Problem
As the companion article established, aggregate fill rate hides regional outliers. A healthy global average can mask a single region running at a fraction of expected fill, paying two or three times the cost per player as a result.
Once you've identified an underperforming region through the analytics dashboard or per-region fill rate tracking, the options are:
Apply a region-specific expansion profile. Secondary regions with smaller player pools need faster, wider expansions than primary markets. Rather than loosening global defaults, create a profile variant with earlier expansion triggers and a lower minimum team size for that region specifically.
Consolidate active servers during off-peak. In regions where player population drops significantly outside peak hours, running the same number of active servers as during peak means paying for capacity that will never fill. Reducing the minimum active server count during low-traffic windows, and relying on dynamic scaling to bring capacity back at peak, cuts idle cost without affecting player experience.
Use latency rules to match across nearby regions without splitting pools. The latencies rule allows players from different geographic regions to match on a shared server, as long as both fall within the configured latency thresholds. For regions with thin populations, this effectively consolidates matchmaking pools rather than forcing each region to fill sessions independently. Players get a match. Servers run fuller.
Accept slightly wider latency in sparse regions. If the player pool in a region is too thin to fill sessions within latency constraints designed for a dense market, the latency rules may need to be relaxed for that region. A match with 80ms ping is better than no match. Region-specific profiles make this targeted rather than global.
The key discipline is treating each region as its own fill rate problem rather than a line item in an aggregate. What works for North America at peak will not work for secondary regions or audiences at any hour.
Measuring the Impact of Changes
Fill rate optimization is iterative. Configuration changes should be evaluated against the baseline established in the diagnostic step, not against intuition.
The primary signals to watch after any change are fill rate per region, ticket expiration rate, and expansion stage distribution. If fill rate is improving but ticket expiration is also rising, the changes may be producing more matches but losing more players to timeout before they get there. If the expansion stage distribution shifts heavily toward later stages, your initial rules may still be too tight for your actual player pool.
Edgegap's analytics dashboard (available at the Enterprise tier) provides these metrics out of the box, including per-minute rates over custom time periods and time-series views of fill rate and expansion behavior. For studios that want to model the cost impact of a target fill rate before testing it live, the fill rate calculator remains the fastest way to translate a fill rate improvement into a dollar figure.
Changes to expansion rules and profile configuration are low-risk to test incrementally. Start with the highest-impact change (usually min_team_size / max_team_size separation), measure for one to two weeks across both peak and off-peak windows, then move to the next lever. Stacking multiple changes at once makes it difficult to attribute improvements to specific decisions.
For the latest configuration syntax, version notes, and worked JSON examples for every scenario discussed in this article, refer to the Edgegap matchmaker documentation. The documentation is updated with each matchmaker release.
For the cost framing behind these optimizations, see the companion article: How Session Fill Rate Affects Your Multiplayer Hosting Costs.
Written by
Jakub Motyl, Product Manager at Edgegap








