Notifications

Overview

Jest allows games to re-engage players through notifications delivered on the platform and, selectively, to the user’s messaging inbox.

This guide covers best practices for designing notification strategies on Jest, including scheduling patterns, reminder content, and attribution. For API usage and implementation details, see the Notifications SDK documentation.

How notifications work on Jest

At a high level:

• Games schedule notifications using the Jest SDK.
• Scheduled notifications always appear in the Library tab on Jest.com.
• At most one notification per user per day across all games on the platform may also be delivered to the user’s messaging inbox.
• The platform selects which notification to deliver and when, taking into account notification priority, observed player behavior, delivery availability, and compliance requirements.

This model allows games to focus on notification strategy while the platform handles delivery, cost, and compliance.

Library notification

SMS notification

RCS notification

Notification recommendations

General notification guidelines

• Deeply integrate notifications with your game. Notifications perform best when they reference real in-game state, such as rewards waiting to be claimed, time-limited events, or progress the player has already made.
• Keep notification text to 100 characters. If your notification is longer than that, it might get truncated if we have to send it via SMS, which has character limits.
• Only use basic characters. Emojis and other similar special characters might get removed by Jest if we have to send the notification via SMS.
• Do not mention the game’s name in the notification. The game name is automatically shown on the Jest platform and added to text messages.
• Upload images in advance. Make sure any images you plan to reference are uploaded and approved in the Developer Console. If a notification references an unapproved, invalid, or archived image, it will automatically fall back to your game’s Hero image.
• Avoid sensitive content in the notification body. Any content related to SHAFT (Sex, Hate, Alcohol, Firearms, Tobacco - including gambling/drugs) is not allowed and will be blocked.
• Avoid time-critical notifications. Texting has mandated quiet hours, which means messages may get delivered earlier or later than originally scheduled.
• Schedule notifications generously for maximum impact. The platform itself will handle message delivery ensuring minimal spam and user frustration.

Scheduling recommendations

We recommend a rolling notification strategy such as:

• When a user logs in for the first time, schedule daily notifications for D0–D7.
  • To maximize the percentage of players who receive a notification, start scheduling reminders as soon as a registered user logs in. Schedule notifications that do not require specific trigger logic as early as possible.
  • In these cases, it is often more effective to use fuzzy scheduling (scheduledInDays) rather than exact scheduling (scheduledAt). Fuzzy scheduling works well when a notification is relevant at any point during the day, allowing the platform to choose an appropriate delivery time per user. Exact scheduling is better suited for fixed events or deadlines where timing matters.
  • This approach is similar to how many native mobile games use local notifications for early lifecycle messaging.
• As players progress, replace generic reminders with notifications that reflect their in-game progress.
• When a player returns to the game, unschedule any previously queued notifications and replace them with updated ones.

Beware of the inbox groundhog day trap

Beware of the Inbox Groundhog Day challenge in notification scheduling, where highly engaged users end up receiving the same reminder over and over.

A typical flow looks like this:

• A player starts the game, triggering a Day-1 (D1) notification scheduled for the following day.
• The D1 notification is delivered.
• The player returns to the game.
• Upon re-engagement, the system schedules another notification for the next day.

The problem emerges when the newly scheduled notification is drawn from the same template or list as the original one. As a result, the player receives the exact same D1 reminder again the following day. Thus, for the most retentive players, the system unintentionally creates a loop - sending the same message day after day, like reliving the same inbox moment over and over.

Example of the Inbox Groundhog Day trap

Common solutions include:

1. Tie notifications to player progress: whenever possible, base notifications on the player’s actual state or progress in the game. Progress-driven messaging naturally evolves over time, ensuring that reminders feel timely, relevant, and different with each send.
2. Rotate through a notification bank: when progress-based messaging isn’t feasible, use a rotating pool of notification variants. Cycling through a predefined bank helps prevent repetition and keeps messages fresh, even if the underlying trigger remains the same.

Both approaches reduce message fatigue and help ensure that engagement from your most loyal players is rewarded with variety - not repetition.

Notification content

Ingredients of a compelling notification

• Make each notification feel fresh. Repeated or recycled reminders quickly lose their impact. Small variations go a long way in keeping players curious and engaged.
• Keep notifications short and intriguing. The goal is to spark interest, not explain everything. Tease the experience and invite players back into the game to discover more.
• Lead with emotional relevance. Notifications should feel meaningful from the first send by referencing something the player cares about - progress, rewards, characters, or unfinished actions. Urgency can be layered in when it naturally fits the player’s state.

Call to action (CTA)

Notifications are most effective when they clearly tell players what to do next. Using strong verbs and direct language helps turn attention into action.

Clear calls to action consistently increase:

• Open rates
• Return sessions
• Conversion on the next in-game action (for example, continuing a story or starting the next level)

Simple CTAs like “Come back and play” work, but the strongest notifications are tied directly to game context and what the player stands to gain by returning. Examples include “Finish your next level,” “Claim your reward,” “Your puppy is hungry,” or “Your dragon wants to play.”

Customization

Personalized notifications feel more relevant - and perform better. Jest supports dynamic variables in messages, allowing you to tailor notifications to each player, such as referencing their name or in-game character.

Many onboardings collect custom inputs - such as a player, character, or pet name. These values are passed to the game as an entryPayload parameter called customName - see Entry payload for technical details. Such custom inputs can be reused in notifications to make them feel personal and intentional. Default values should be set so every reminder still reads naturally, even when no custom input is available.

Personalized notifications consistently drive higher open rates, which in turn improves retention.

Notification analytics

While the optional identifier parameter is useful for managing scheduled notifications, it’s not the best tool for analytics or in-game attribution. Instead, we recommend using the entryPayload field when scheduling notifications.

Any data passed in entryPayload is preserved when a player opens the game from a notification and can be accessed after login via JestSDK.getEntryPayload(). This makes it ideal for tracking which reminders bring players back - and for triggering contextual in-game behavior.

Example

JestSDK.notifications.scheduleNotification({
  scheduledInDays: 1,
  body: "There's a present waiting for you!",
  ctaText: "Claim",
  attemptPushNotification: true,
  identifier: "callback_tomorrow",
  priority: "medium",
  entryPayload: {
    notification_template: "present_waiting_v1",
    notification_offset: "D1",
  },
});

If a player enters the game from this notification, the entry payload will be available after login as:

{
  notification_template: "present_waiting_v1",
  notification_offset: "D1",
}

The notification_template field makes it easy to A/B test different notifications and understand which copy or framing is most effective at bringing players back.

The notification_offset field allows you to analyze when players return - such as whether engagement is stronger on Day 1, Day 2, or later reminders.

You can then use this data to drive in-game logic.

const entryPayload = JestSDK.getEntryPayload();

if (entryPayload.notification_template === "present_waiting_v1") {
  // Trigger template-specific logic
}

By consistently tagging notifications with both a template identifier and a timing offset, you gain clear insight into which reminders perform best - and when they are most effective at bringing players back into the game.