Jul 27, 2026 · 4 min read · GameMantra Team
Event overlap: when two events compete for one wallet
Running two events at once looks like twice the opportunity. If both ask the player to spend the same currency, they are splitting one budget, not doubling it.
A busy calendar feels like good operations. Two events running concurrently reaches more player types, fills more of the week, and gives the team more to report on.
Whether it produces more revenue depends entirely on a question that often goes unasked: are these two events drawing on the same resource?
The resource, not the calendar
Events compete when they ask for the same thing. Two events that both cost premium currency are competing directly — a player has one balance and one willingness to top it up, and each event is trying to capture the same units.
Two events where one costs currency and the other costs time are not competing in the same way. A player can do both. The constraint is different for each, so the calendar genuinely does double the surface area.
Most overlap problems come from treating the calendar as the constraint when the wallet is. A team plans around whether there is room in the schedule and whether the themes clash visually, and both of those get checked. Whether the two events are asking the same player for the same currency in the same week frequently does not.
The result is predictable in hindsight. Both events show lower participation and lower spend than they did when they ran alone. The team concludes the events underperformed, when what actually happened is that one budget was divided in two.
Why splitting is usually worse than sequencing
If the total spend were the same either way, overlap would be neutral — the same money arrives, just split across two events. It generally is not neutral, for two reasons.
The first is that partial progress is worth less than complete progress. Event structures usually reward finishing: a completion bonus, a final tier, a set that only pays off assembled. A player who splits their budget across two events and completes neither gets the worst of both. They spent, and they did not get the payoff that makes spending feel worthwhile. That experience makes them more cautious about the next event, which is a cost that lands after the reporting period.
The second is that the decision itself deters. A player facing one event evaluates one thing. A player facing two events with a limited budget has to compare, prioritise, and pick — and a common resolution to that comparison is to defer both. Choice between similar options routinely converts worse than a single clear option, and events overlapping is a manufactured choice.
Run sequentially, the same two events each get a player's full attention and a full budget, and both can be completed. The total spend is usually higher and the completion experience is intact.
Overlap that works
Not all concurrency is competition, and some of it is genuinely additive.
Events with different resource costs stack cleanly. An event that asks for currency alongside one that asks for daily participation are not competing — a player can engage with both, and each reinforces the other's engagement.
Events aimed at different player populations stack too. A newcomer event and a veteran event overlapping is fine, because the players who can meaningfully participate in each barely intersect. The apparent overlap on the calendar is not overlap in practice.
Events at very different price points can coexist, though less cleanly. A small recurring offer alongside a large seasonal event does not usually cannibalise, because the players who buy the small thing and the players who commit to the large one are often different, and for those who do both the amounts are not comparable.
The pattern in all three is the same: overlap is safe when the two events are drawing on different pools, whether that pool is currency, time, or a segment of the player base.
See how we schedule around player state rather than the calendar →
Reading whether it happened to you
The clearest evidence is in participation rather than revenue. If two overlapping events each show meaningfully lower participation than the same events showed running alone, and the total across both is close to what one produced solo, they were competing.
Completion rate is the sharper signal. Competing events show a distinctive pattern: normal starts, poor finishes. Players engage with both, get part way into each, and stop. A drop in completion rate with stable start rate is close to a signature.
The third check is what happened in the weeks after. Competing events tend to depress the following event too, because players who spent across two and completed neither are less inclined to commit to the next one. If your event performance sagged for a month after a busy fortnight, the busy fortnight is the more likely cause than anything about the individual events.
The practical adjustment is small. When planning two events into the same window, write down what each one asks the player to spend. If the answer is the same resource from the same players, either separate them or make one of them cost something different. The calendar has room. The wallet is what does not.
Share this post
See what this looks like for your game.
SDK for Unity and Unreal. A 20-minute call to walk you through it.