Timing a re-engagement push is a guess. Every game team makes it. Most guess wrong.
Fuzzy scheduling lets you tell Jest the day, not the minute. When your notification earns a push slot, Jest picks the moment based on when that player is most likely to engage.
Instead of deciding exactly when a player should receive a notification, you decide roughly when it should happen. Jest handles the timing.
Two Ways to Schedule
JestSDK.notifications.scheduleNotification now takes two modes.
Exact with scheduledAt. The notification is eligible at a specific instant.
Fuzzy with scheduledInDays. You give us a target of 1 to 7 days out. We treat it as approximately that many days, anchored to the player’s natural rhythm. We may shift delivery slightly in either direction around their next “day” based on when they actually play.
// Fuzzy: "about 3 days from now, give or take, whenever this player tends to play"
JestSDK.notifications.scheduleNotification({
body: "We miss you! Come back for a special reward.",
ctaText: "Claim Reward",
priority: "medium",
identifier: "comeback_day3",
scheduledInDays: 3,
});One parameter. Most of the value in this post lives in what that parameter lets us do on your behalf.
Two Surfaces
Every scheduled notification targets two surfaces. They behave differently.
The first is the Library tab on Jest.com. Unscoped. Uncapped. Precise. Schedule something for 3:42 PM and it shows up at 3:42 PM.
The second is push. SMS and RCS, delivered to the native messaging inbox. This surface is scarce by design. Jest selects at most one notification per player per day, across every game on the platform. One slot. One chance to earn the tap. Spend it badly and players reach for the opt-out.
Every notification you schedule is really doing two jobs. Sit in the Library at the exact time. Compete for the push slot. Fuzzy scheduling only touches the second one.
What Fuzzy Does
Fuzzy hands both the day and the hour to us, inside a bounded window.
You set scheduledInDays = 3. We read that as “around three days.” The actual delivery can shift up to 12 hours earlier or later, anchored to the player’s next natural play day. For a morning player, it settles in their mornings. For a late-night player, in their nights. A churned player and a daily player scheduled on the same call will see the notification on different clocks.
If the notification wins the push slot, we choose the moment inside that window using what we know: when the player typically reads their messages, quiet hours and regional compliance rules, the priority you set, and everything else competing for that same slot across the platform.
If it loses the slot, it still appears in the Library on schedule. You lose nothing.
Exact scheduling binds both surfaces to a moment. That is correct when the moment carries information. A raid at 7 PM. A sale ending at midnight. Energy full in four hours. The time is the point.
It is wrong when the moment carries no information. Pinning a “we miss you” nudge to 2:17 PM means firing at 2:17 PM whether the player is on the subway, asleep, or in a meeting. The clock was never the message.
When to Use Each
Default to fuzzy. Reach for exact only when the clock is load-bearing.
Fuzzy fits most of what you want to send.
- Comeback nudges.
- Daily reward reminders.
- Day 1, day 3, day 7 re-engagement.
- Streak and progress prompts.
Exact is for the cases where the moment carries the meaning.
- A live event starts at 7 PM ET.
- A sale ends at midnight.
- Energy refills in exactly four hours.
Before you reach for exact, ask whether the mechanic can be reshaped to tolerate a window. A lot of “timed” systems are only timed out of habit. Energy that refills in roughly four hours loses nothing. Events that run for a few hours lose nothing. A daily reward that unlocks once per active day, rather than at a fixed clock tick, loses nothing. You gain the right to send at the moment each player is reachable.
Pair fuzzy scheduling with entryPayload to fast-forward the reward on arrival. Schedule a fuzzy “your energy is full” nudge for tomorrow. Attach a payload that tells the game to treat energy as full on entry, even if the simulated timer has a few minutes left. The push lands when the player is reachable. The game honors the promise the moment they tap. The clock never got in the way.
JestSDK.notifications.scheduleNotification({
body: "Your energy is full!",
ctaText: "Play Now",
priority: "high",
identifier: "energy_full",
scheduledInDays: 1,
entryPayload: {
grant: "full_energy",
},
});The notification represents a promise. The payload ensures it is kept on arrival. Timing becomes a detail the platform handles, not a contract the game enforces on a clock.
A clean test: if you would be happy for the push to land anytime that day, make it fuzzy. If you would not, ask whether the mechanic can be bent until you would.
Why the Platform
Send-time decisions on Jest are a balancing act. Which message is most likely to convert for this player. Whose turn it is. Whether the player is reachable. What the compliance window in their state allows. How to keep the channel from burning out.
No single game has the signal to answer those questions. We do. We see engagement across every game on the platform, and we own the delivery pipeline end to end.
Fuzzy is how you opt into that machinery. You describe the window. We handle the rest.
Try It
Fuzzy is live in the SDK. If you are already calling JestSDK.notifications.scheduleNotification, the migration is one line. Swap scheduledAt for scheduledInDays.
Full API reference lives in the notifications documentation. Strategy guidance lives in the notifications best practices guide.
Ship it on your next re-engagement push. Let us do the timing.