About Nexters
Nexters is one of the largest game developers on the market, with a player base to show for it.
Its flagship franchise, Hero Wars, is the better-known name to most players, probably from the ads where a hero rescues someone from a trap. It runs on both mobile, as an iOS and Android RPG, and the web, playable in Chrome and Safari with no install. Every player communication on each platform runs on Pushwoosh.
The challenge: keeping a player, over and over
Mobile gaming is a massive market with billions of players, and every studio fights in a red ocean for each user. As acquisition costs keep rising, the winning move is to work the base you already have, and that has a trap built in: stay quiet and players drift, send too much and they turn notifications off after a few pushes in a week.
The studios that win react to what the player is actually doing, in the moment they do it. Triggers tied to real in-game behavior have cut churn by double digits, where generic blasts barely move it.
For a game the size of Hero Wars, that comes with a hard technical floor. Reaching the right player at the right in-game moment, across every surface they use, means a platform that can absorb an enormous, constant stream of events without slowing down. Volume comes first. On top of it sit the targeting and frequency control that keep the communication useful instead of noisy.
Before the build: a setup that could take the load
Before working with Pushwoosh, the Hero Wars team already had 2 solutions, but they didn’t fully fit. Their main tool was expensive to scale, with licensing tied to data points, so cost climbed with usage. A second platform sat alongside it as a fallback, handling separate tasks the main one didn’t cover. The team was splitting the job across 2 vendors and paying 2 bills for it, so finding a better option was only a matter of time.
The main question was holding the load. Nexters came in processing up to a billion events a month, and the deciding factor was whether a new vendor could carry that volume without buckling. Not every platform can. Pushwoosh confirmed it could take the throughput.
With that settled, the focus moved to fit, and the platform supported every scenario Hero Wars already ran. Customer Journey Builder is an advanced automation tool, and the studio’s existing logic mapped onto it without any losses. On top of that, Pushwoosh could bring over historical data, templates, and the full user base for the switch.
Pushwoosh technical account team worked directly with the Nexters teams to set up their scenarios and wire up the integration: events, event attributes, and the API calls behind their backend-triggered campaigns. A live-service game runs every day, so the switch had to happen without breaking the communication already going out.
In production the setup holds the volume it was bought for. Hero Wars streams over a billion events a month into Pushwoosh, with peaks around 50,000 event requests at once. For a game running on millions of monthly players, the load never became the bottleneck.
How it all runs
Hero Wars builds its communication on a rich set of in-game events, and the logic behind it gets messy fast: groups acting at once, players running several things in parallel, countdowns that move mid-flight.
Customer Journey Builder is built to model exactly that kind of complexity, and it does it on the same billion-events-a-month stream the platform already absorbs. Sending a message was never the hard part in gaming. The hard part is handling tangled, fast-changing game state at volume, and that is where the platform earns its place.
Every meaningful player action arrives in Pushwoosh as an event from the game backend, with 35 custom events on the web project and 27 on mobile, and marketers wire journeys on top of them in Customer Journey Builder with no code, so the event is both the trigger and the data the journey runs on.
Cross-platform user tracking: how it works
Hero Wars runs on both mobile and the web, and Pushwoosh runs the communication for both from one service. Instead of managing each platform and channel on its own, the team runs mobile push, web push, and email from a single system, all coordinated around the same in-game events.
The game backend sends an event for every meaningful player action, and each event carries its own data in attributes: which player and account it belongs to, a timestamp, the session and operation it came from, and event-specific fields like the time a notification should fire. The same event can drive more than one channel, so a message set up to go by push can fall back to email when push isn’t available.
Group entries: one event, a whole roster of players
Most journeys handle recurring messages tied to what a player does in the game. Normally a journey starts from an event the usual way: the player does something, the game sends an event for that player, and that player enters the journey. One event, one player.
Customer Journey supports group entries: a journey can start for every player named in an event, not only the one who triggered it.
Players band together for a raid, and everyone in the party can be pulled into the same journey from one backend event. A guild coordinates a shared push, and every member gets their own message off that single trigger. The same holds for activity that runs across a group from building to battle: one event names all the players taking part, and each of them enters the journey and receives a notification tied to what the group is doing.
Multiple sessions
Most customer journeys assume a user goes through a flow once: they enter, move through the steps, and exit. That fits a typical lifecycle, like a welcome series or a single purchase follow-up.
A Hero Wars player is doing many things at the same time, each on its own clock: putting up two or three buildings at once, joining a guild rally, sending troops on a march, all running in parallel. One pass through a journey can’t capture that.
Take the Realm mode, where players send troops on marches and put up buildings like camps to grow their base. A player can start one building, then a second, then a third, with each one finishing at a different time and each completion owing the player its own notification.
Pushwoosh supports multiple sessions per user so one player can sit in the same journey many times over, each session tracking a separate build.
Rescheduling: when the countdown changes
In Hero Wars, players train batches of troops to build up their army, and training isn’t instant. You queue a group of units and a timer counts down, often for hours, until they’re ready. The game schedules a push to fire the moment that timer hits zero, so the player knows their troops are done.
The catch is that the timer can move. Players can spend boost items to cut the wait, or pay to finish training on the spot, and the moment they do, the push scheduled for the original time no longer matches reality. A player who sped things up doesn’t want a “your troops are ready” message an hour after they already collected them.
The journey handles this with a cancel event underneath. When a new event arrives for a player already in the journey, signaling the timer has moved, it clears the queued push and schedules a fresh one for the updated time. The player gets a single correct notification when training actually finishes, instead of a string of mistimed ones.
Planned campaigns: keeping up with the game calendar
A live-service game like Hero Wars runs on a constant calendar. Every month brings something new with a start date and a deadline: a unique hero or piece of gear dropping, a seasonal event tied to a holiday like Christmas or Oktoberfest, a new season opening. Each of these only lands if players hear about it while it’s live, and most of them expire, so timing is the whole game.
That turns the game calendar into a communication calendar. The team builds each campaign in Journey Builder ahead of time, one per event, reaching players across push and email from the same flow. Campaigns like it are lined up in advance and fire automatically when their moment arrives, with no last-minute setup on the day.
Email: getting real value from gaming’s most underrated channel
The same event layer and cross-platform view that drive push also make email work, and email is where it pays off in a place most studios rarely look. Hero Wars built a real retention channel on it, because the platform already knows each player across mobile and web and can reach them by email the moment push isn’t enough.
Pushwoosh also gave the Hero Wars team a way to grow the email base directly from the mobile game. Players who register with an email in the app are collected as subscribers and dropped into a welcome series automatically.
How a send works
Every Hero Wars email runs as a one-time journey on the web project. The mechanic is simple and effective: take the target segment, check email reachability and subscription status, send.
Before any of that, Pushwoosh helped validate the base so it can stay efficient and protect domain and IP reputation, keeping bounce and complaint rates low. Unsubscribes are managed natively, so once a player leaves, that address drops from future sends automatically.
How it works in practice
Every month the game drops something new: a unique hero, gear, abilities, or a seasonal event like Christmas, Oktoberfest, or Easter. Example: any new character launch gets a three-email arc:
- Early Access. The new hero is announced ahead of release.
- Adventure Start. The launch goes live, and the email sells the experience.
- Reminder. A final note that the hero is still available and about to leave.
Push fires in parallel on launch day to mobile and web players. Email carries the story, push drives the action. Seasonal events run as their own standalone sends.
Working with design: premium templates on the platform
The Hero Wars email templates are a craft of their own: long, richly illustrated landing pages held to flawless brand styling. Pushwoosh supports that level of execution inside the builder.
The team built the logic once, and Pushwoosh handled the rest, with proactive support that fit the client’s requests as they came.
Integrations
Events reach Pushwoosh from the game backend and from attribution partners. On top of the event flow, Pushwoosh built custom support to receive audiences from AppsFlyer and Adjust, with the integration relying on a shared identifier kept in sync on both the attribution side and in Pushwoosh, so segments map to the same players across systems. The capability is in place and coming into use.
Build retention that keeps players in the game with Pushwoosh. Learn more at pushwoosh.com.
