RCS has had a long runway. The protocol has been in development for over a decade, and for most of that time it was held back by fragmented carrier support and Apple's absence from the standard. That’s since changed. Apple has adopted RCS, joining Android, and the result is that RCS messaging is now available on the vast majority of smartphones worldwide.

For brands that have been running their mobile messaging on SMS, this raises a practical question: is the upgrade worth it now, or is it still too early? Below, we break down where RCS stands in 2026, which use cases are already delivering clear ROI, what limitations still exist, and what a realistic migration looks like for a team that's currently SMS-only.

Where RCS stands in 2026

RCS upgrades the native messaging app on a user's phone into something closer to an app experience. Instead of plain text with a character limit, brands can send messages that include verified sender profiles (brand name, logo, and checkmark), high-resolution images and video, interactive product carousels, and tappable action buttons like "Track Package" or "Complete Purchase." Messages are delivered over data or Wi-Fi rather than the legacy cellular network that SMS relies on.

The tipping point was Apple's adoption of the standard, which effectively made RCS available across both major mobile platforms. That's what moved it from "promising but fragmented" to "production-ready." Our research shows that 45% of mobile teams are actively exploring or planning to adopt RCS this year, according to The 2026 State of Customer Engagement Report.

For a deeper look at the technical differences between the protocols, see our breakdown of the signs you're ready to upgrade to RCS.

Where RCS is already delivering ROI

The strongest case for RCS comes from use cases where the interactive capabilities directly translate into measurable business outcomes.

Interactive commerce

This is where the ROI case is most clear-cut. An abandoned cart message sent via RCS can include a carousel of the exact products a customer left behind, with images, prices, and a one-tap "Complete Purchase" button. Compare that to an SMS that says "You left items in your cart! Visit [link] to check out." The RCS version eliminates friction by letting the customer act without leaving the conversation, and early adopters are reporting click-through rates 3 to 7 times higher than equivalent SMS campaigns.

The same applies to product launches, flash sales, and personalized offers. Rich cards with product imagery and direct action buttons consistently outperform plain text with a shortened URL.

Transactional and service messages

RCS makes utilitarian messages more useful. An airline can send a boarding pass with a QR code and a "View Flight Status" button. A healthcare provider can send an appointment reminder with an "Add to Calendar" action. A retailer can send a delivery notification with a real-time tracking button. All of these interactions happen inside the messaging app without requiring the customer to open a browser, download an app, or navigate a website. That reduction in friction compounds across millions of messages.

Brand trust and verification

In a messaging environment increasingly cluttered with spam and phishing attempts, the verified sender profile is a meaningful differentiator. When your brand name, logo, and verification badge appear in the message thread, the recipient knows the message is legitimate before they even read it. This visual trust signal improves open rates and sets RCS apart from the anonymous short codes and phone numbers that SMS relies on.

What to know before you commit

RCS is production-ready, but there are a few practical factors to plan around.

Not every user can receive RCS yet

Adoption is broad but not universal. Older devices and some regional carriers don't support RCS, which means you need a reliable SMS fallback for any message you send. The good news is that any modern engagement platform handles this automatically: if the recipient's device doesn't support RCS, the message downgrades to SMS or MMS without manual intervention. You don't have to choose between channels. You build for RCS and fall back gracefully. Apple's initial RCS implementation also has some feature gaps compared to Android's (most notably around encryption in one-on-one conversations), but these are edge cases that don't materially affect business messaging use cases.

Per-message costs compared to SMS

RCS messages cost more to send than SMS. That's a real line item to account for. But the comparison that matters isn't cost per message. It's cost per conversion. If an RCS abandoned cart message converts at 3 to 5 times the rate of an SMS version, the higher per-message cost pays for itself several times over. The right approach is to start with your highest-value campaigns (cart recovery, promotional offers, booking confirmations), measure the lift, and expand from there based on data.

Verification takes time

Brands can't self-register for RCS. The verified sender profile requires an application process through a messaging aggregator, and approval typically takes 8 to 16 weeks. This is worth factoring into your planning timeline. If you're targeting a major campaign or seasonal push, start the verification process well in advance.

For tips on navigating this, see our guide on how to streamline the RCS approval process.

The migration path for SMS-only brands

Start with a platform that supports both

The most important decision is choosing an engagement platform that supports RCS and SMS natively, with automatic fallback built in. This means you're not ripping out your SMS infrastructure. You're adding RCS on top of it and letting the platform handle delivery logic based on each recipient's device capabilities.

OneSignal supports RCS alongside push, email, SMS, and in-app messaging, which means you can coordinate RCS campaigns with your existing channels through a single journey builder rather than managing a separate tool.

OneSignal also handles the aggregator coordination and verification process, so your team can focus on the campaign strategy rather than the carrier paperwork. For more on how OneSignal is investing in RCS, read why RCS matters now.

Phase it in with A/B tests

Most teams phase RCS in alongside SMS rather than replacing it overnight. Pick one or two high-value campaigns where interactivity will make a measurable difference (abandoned cart recovery is the obvious starting point), run A/B tests comparing RCS and SMS performance, and use the results to build the internal business case for expanding to more use cases. This is how you prove ROI with real data from your own audience rather than relying on industry benchmarks.

For a broader look at building an SMS and RCS strategy that delivers results, we've published a separate guide on that topic.

The verdict

RCS in 2026 is no longer a bet on future potential. The device support is there, the feature set is mature, and the use cases with proven ROI are well established. The remaining limitations (cost, carrier gaps, verification timelines) are real but manageable, and none of them are reasons to wait.

For brands still running on SMS-only, the practical move is to start with your highest-conversion campaigns, measure the lift RCS provides, and scale from there. The brands that adopt now will have verified sender profiles, optimized creative, and performance data while their competitors are still evaluating whether to start.If you're ready to add RCS to your messaging strategy, explore OneSignal's RCS capabilities or get in touch with our team to start the verification process.

Most teams start their search for a customer engagement platform by comparing feature lists. That makes sense on the surface, but it's often the wrong starting point. The factor that actually determines whether a platform works for your team is how well it integrates with your existing data infrastructure and how quickly your team can get value out of it.

A platform with an impressive feature set that takes months to implement, requires dedicated engineering resources to maintain, and locks key capabilities behind enterprise pricing tiers will cost you more than the subscription fee suggests. That's why more teams are evaluating Braze alternatives based on practical fit rather than feature ceiling.

This guide walks through how to match a customer engagement platform to your data stack, your team's resources, and the level of complexity you actually need.

Why your data stack should drive your CEP decision

A customer engagement platform is the system that unifies customer data and manages communication across channels: email, SMS, push notifications, in-app messages, and more. But the platform is only as useful as the data it can access and the speed at which your team can act on it.

When your CEP and data infrastructure don't connect cleanly, you end up with fragmented user profiles, siloed channel data, and an inability to build the kind of unified customer journeys that actually drive retention. And when a platform doesn't integrate easily with your existing tools, your team spends more time managing the platform than using it.

Matching a platform to your data infrastructure

Most organizations fit into one of three data architecture patterns. Each one has different requirements from a customer engagement platform, and the right choice depends on which pattern describes your team.

The data warehouse-centric stack

Some large organizations run everything through a data warehouse like Snowflake or Redshift, with dedicated data engineering teams managing the pipelines. Teams in this position sometimes gravitate toward heavyweight platforms that offer deep, native warehouse integrations.

But it's worth asking whether you actually need that level of architectural coupling. Warehouse-native CEPs tend to come with long implementation timelines (often months, not weeks), high engineering maintenance costs, and interfaces that require technical resources to operate day-to-day. For many teams, the data they actually use for messaging, behavioral events, user attributes, and channel engagement, can be piped into a more flexible platform through standard integrations or APIs without rebuilding their entire data flow around the CEP.

If your team has the budget, the headcount, and the timeline for a full enterprise implementation, that path exists. But a growing number of teams with warehouse-centric stacks are finding that a platform with strong API connectivity and out-of-the-box integrations covers their actual use cases at a fraction of the cost and implementation time.

The CDP-driven stack

Many modern teams use a Customer Data Platform or product analytics tool like Segment or Amplitude to centralize user data and event streams. For this setup, the key requirement is a CEP that integrates with your CDP in real time and lets your marketing team act on behavioral data without filing engineering tickets.

Look for platforms with native, two-way integrations that allow marketers to build segments and trigger campaigns based on behavioral data from their analytics tools. The CEP should function as the action layer for insights your CDP surfaces, not as a second data warehouse that requires its own complex configuration.

OneSignal integrates with Segment, Amplitude, Mixpanel, and other major data platforms, allowing teams to connect their existing analytics infrastructure and start building cross-channel campaigns on top of it. This is the kind of setup where measuring outcomes and proving campaign ROI becomes straightforward, because the data is already flowing.

The API-first and lean stack

Startups and mid-market companies typically run a mix of third-party services and internal tools, with limited (or no) dedicated data engineering resources. For these teams, the most important thing a CEP can offer is a fast path to value: a well-documented API, stable SDKs, and an interface that marketers can use without developer support for every campaign.

This is where the gap between high-overhead platforms and more agile alternatives becomes most obvious. A platform that gates its API behind premium tiers, requires months of engineering time to implement, or needs a dedicated admin to operate is going to slow down exactly the teams that can least afford to wait.

OneSignal was built for this profile. The API is fully accessible on every plan, SDKs are well-documented and actively maintained, and the dashboard is designed so that marketers and developers can both work in it without stepping on each other. For teams where technical flexibility and speed matter, that combination is hard to beat.

What else to evaluate

Implementation time and total cost

The subscription fee is the number you see. The implementation cost is the number you feel. Some high-overhead platforms take three to six months to fully implement, during which time your engineering team is pulled away from product work and your marketing team is waiting to launch campaigns they could have been running on a faster platform from week one.

When evaluating Braze competitors, ask how long it takes to go from signing the contract to sending your first production campaign. If the answer is measured in months, factor that delay (and the engineering hours behind it) into the real cost of the platform. OneSignal's setup process is designed to get teams live in days, not quarters.

Cross-channel orchestration

A customer retention platform should let you treat email, push, SMS, and in-app as parts of a single journey, not as separate tools with separate dashboards. The ability to build automated sequences that adapt based on real-time behavior (send a push, wait to see if it's opened, fall back to email if not) is what separates a messaging tool from an engagement platform.

If you're currently managing channels through separate systems, you're leaving coordinated, cross-channel engagement on the table. This is an area where a unified platform delivers compounding value over time.

Journey building and automation

Building complex, behavior-driven journeys used to mean committing to a platform designed for teams with dedicated engineering resources and the budget to match.. That's less true than it was a few years ago. Modern alternatives now offer visual journey builders with branching logic, behavioral triggers, wait conditions, exit rules, and cross-channel messaging steps that cover the vast majority of real-world use cases.

Before assuming you need the most complex (and expensive) journey tool on the market, map out the actual automations you'd build in your first 90 days. Most teams find that their requirements, abandoned cart recovery, onboarding sequences, re-engagement flows, post-purchase nurture, are well within the capabilities of a platform like OneSignal, which offers all of these through its Journeys builder.

How to choose the right Braze alternative

Rather than starting with a platform and working backward, start with your own team's profile:

• What does your data infrastructure look like? If you're running Segment, Amplitude, or a similar CDP, prioritize platforms with native integrations that let your marketing team act on that data directly.
• How much engineering time can you commit? If the answer is "not much," cross off any platform that requires a multi-month implementation or dedicated technical admin.
• What channels do you actually use? If mobile push, web push, and in-app messaging are core to your strategy, make sure the platform excels at those channels natively rather than treating them as add-ons.
• What's your real budget, including implementation? A platform that costs less on paper but takes twice as long to implement may not be cheaper in practice. Factor in the full cost of getting to production.
  

For teams that are mobile-first, value speed-to-value, need strong cross-channel capabilities, and want a platform that both developers and marketers can use effectively, OneSignal consistently comes out ahead in these evaluations. It's why the platform is one of the most widely adopted Braze alternatives on the market today.

Remember… the right platform is the one that fits

The best customer engagement platform is the one your team can actually use to its full potential, not the one with the longest feature list or the biggest brand name. Evaluate candidates on integration fit, implementation speed, total cost, and how quickly your team can get to production campaigns. The answers to those questions will narrow the field faster than any feature matrix.

Explore OneSignal's platform features to see if it's the right fit for your stack, or see how OneSignal compares to Braze directly.

You've been in this meeting before…

Retention is slipping, someone pulls a cohort of users who haven't opened the app in 30 days, and the team puts together a win-back campaign. A push notification, maybe an email with a discount attached, send it out, see what happens. A few users trickle back, but most don't. The campaign gets marked as complete and everyone moves on.

Elephant in the room: 30 days of inactivity is a long time, and you may need to adjust expectations if you think (essentially) cold-calling someone with a 15%-off code is enough to get them back through the door. Sometimes it is! But most of the time it buys you one session and not much else.

The teams with the strongest retention numbers treat re-engagement as an always-on system. One that’s always watching for the behavioral signals that precede churn, and always responding before the user would ever land on a 'lapsed' list.

Does this look like your win-back campaign?

A static win-back campaign has a fixed structure. A user crosses a threshold (usually days since last session), they enter a flow, they receive a predefined sequence of messages, and then the flow ends.

Everyone in the segment gets roughly the same treatment regardless of how they used the product, which channels they prefer, or what drove their disengagement in the first place.

The typical setup:

• Trigger: user inactive for 14/30/60 days
• Message 1: "We miss you" push notification
• Message 2: Follow-up email with a coupon or feature highlight
• Message 3: Maybe an SMS if the first two didn't land
• End of flow

There are two structural problems here. First, the trigger fires after the user has already disengaged, which means you're always playing catch-up. By the time someone has been inactive for 30 days, the relationship has cooled significantly and the cost of re-acquisition is high.

Second, the flow doesn't adapt. A gaming user who stopped playing because they hit a progression wall gets the same message as someone who churned because they never discovered the social features. A food delivery customer who only orders during football season gets the same "come back" email as someone who was ordering weekly until last month.

This system is structurally incapable of responding to the specific reason a user is cooling off, because it wasn't designed to detect that in the first place.

Building a re-engagement system that responds before users churn

A dynamic re-engagement system doesn't wait for the 30-day mark. It starts responding to cooling signals much earlier, and it adapts its approach based on what kind of user is cooling and why.

Here's what that looks like in practice and what your tooling needs to support it:

It monitors behavioral patterns, not strictly inactivity thresholds.

Instead of triggering on "last session was 30 days ago," it watches for changes in engagement patterns. A power user who normally logs in daily but hasn't opened the app in 3 days is a very different signal than a casual user who visits once a week and missed a week. A dynamic system treats those differently because the appropriate response is different.

To pull this off, you need segments that update dynamically based on behavioral data, not static lists. That means tagging users with properties like last session date, session frequency, and feature usage, then building segments that automatically shift users between engagement tiers as their behavior changes. Most modern engagement platforms support this. In OneSignal, segments recalculate automatically as tag and event data updates, so a user who goes quiet moves into your "cooling off" segment without anyone pulling a manual report.

It branches based on user context.

When a user enters a re-engagement flow, the system checks what they were doing before they cooled off. Were they active but not converting? Did they hit a paywall and bounce? Are they a seasonal user who always drops off this time of year? Were they engaging with the product but ignoring your messages? Each of those paths calls for a different message, a different channel, and a different cadence.

The practical requirement here is a journey builder with yes/no branching that can check segment membership or message interaction data at each step. You set up the flow once with conditional paths for each user context, and the system routes people down the right branch automatically. The entry trigger can be a custom event (like "paywall_viewed" or "cart_abandoned") or segment-based (like "was active 14 days ago, hasn't returned"), and each branch gets its own messaging sequence.

It respects channel preferences as data.

If a user hasn't opened a push notification in two weeks but clicked your last email, a static campaign might still lead with push because that's what the flow specifies. A dynamic system routes the re-engagement message through the channel the user actually responds to. It might start with a push, wait to see if it's opened, and fall back to email or in-app only if needed. The channel sequence adapts to the user rather than running the same playbook for everyone.

This requires two things from your tooling. First, all your channels need to live under one roof so the system has a unified view of how each user engages across push, email, SMS, and in-app. Second, your journey flows need wait steps and branch logic that can check "did the user open this push?" before deciding whether to send the follow-up via email instead. If your push provider and email provider are separate tools with separate dashboards, this kind of cross-channel sequencing is painful enough that most teams just don't do it.

It knows when to stop.

This might be the most underrated difference. Static campaigns end when the sequence runs out. Dynamic systems include explicit cooling-off logic: if a user completes the full flow without re-engaging, they're tagged and suppressed from promotional sends for a defined period. No more stacking three different re-engagement campaigns on top of each other because each one operates independently. The system recognizes when further outreach is doing more harm than good and backs off before it pushes the user from "inactive" to "unsubscribed."

The mechanics here are straightforward but easy to skip: tag users at key points in the journey (e.g., "winback_attempted"), set exit conditions that pull users out when they re-engage or when the sequence completes, and use re-entry rules to prevent someone from cycling back through the same flow too soon. The tagging piece is especially important because it's how you coordinate across multiple journeys. Without it, your abandoned cart flow, your feature adoption flow, and your win-back flow can all fire on the same user in the same week without any of them knowing about the others.

What changes when you build this kind of system

The shift from static campaigns to dynamic systems changes the shape of your entire retention strategy, not just your re-engagement metrics.

When you have a system that responds to early cooling signals, your win-back campaign doesn't need to do as much heavy lifting because fewer users reach the point of full disengagement. The users who do churn are the ones your system already tried to reach through multiple channels and approaches, which means the remaining churn is more likely to be genuine product-fit issues rather than messaging failures you could have prevented.

Your channel health improves too. A dynamic system that monitors opt-out velocity and routes users to preference centers before they unsubscribe protects your reachable audience in a way that static campaigns can't. You stop losing channels you can't get back.

And your team spends less time building one-off campaigns. Instead of launching a new win-back flow every quarter with slightly different copy, you're maintaining a system that runs continuously, learns from engagement data, and routes users through the appropriate path automatically. The upfront investment is higher and the ongoing operational cost is lower.

Ready to put this into practice?

The concepts above are deliberately framework-level. The harder (and more valuable) work is translating them into specific flows for specific retention scenarios: the gaming app whose D30 retention is falling apart, the eCommerce brand whose users opt out faster than they can grow the list, the subscription app that loses people at the paywall, the food delivery service whose seasonal users never become year-round customers.

We've been building out exactly those flows in detail. Our upcoming Breaking the Churn Loop webinar brings together leaders from Crocs and Ringier to share the exact journey flows, channel timing, and branching logic behind retention strategies that actually compound. If the patterns in this post feel familiar, the webinar is where we get into the specifics of how to build the system.

Save your seat and prepare to break the churn loop →

When your product is invisible until it breaks, how do you build loyalty?
At a recent Surge event in Singapore, Terry Williams, who leads My Republic's consumer business across sales, marketing, products, and customer service, sat down for a fireside chat about how a broadband provider in one of the world's most price-competitive markets is rethinking customer engagement from the ground up.

The conversation was packed with real examples, honest failures, and a refreshingly unconventional playbook. Here are the key takeaways.

1. If your product is invisible, create new reasons to show up

Broadband is the definition of a "set it and forget it" service. Customers sign up, and the next time they hear from their provider is usually a renewal notice, or an outage. Terry was blunt about this: most telcos leave a blank space between installation and recontract. "They're going to be like, 'Okay, you're in'... and then blank space… and then 'please give us your money again.'”

My Republic decided to fill that gap with customer touchpoints that actually provide value: community events, a loyalty program, in-app experiences, and even a physical retail store. The goal is to make the brand part of a customer's life, not just their monthly bill.

2. Start with a niche, then expand adjacently

My Republic built their initial identity as "the gamer ISP", a positioning so strong that 85% of gaming cafes in Singapore now run on their network. But rather than staying put, they expanded into gamer-adjacent spaces: trading card games, esports events, and collectibles.

Singapore is the second-largest market in the world for trading card games per capita, behind only Japan. My Republic validated that overlap through surveys, customer calls, and conversations at gaming cafes and events, and found that their gamer customers were deeply into TCGs as well. That insight led to Card Arena by My Republic, a trading card game hub at Suntec City that's become one of the most successful card shops in Singapore, and Card Con, a convention that drew 15,000 attendees across a single weekend.

3. The installation is your first date, don't blow it

Terry compared the broadband installation experience to a first date: "If you have a bad installation experience, you're probably not going to stay married for long."

Most providers treat installation as a logistical step. My Republic treats it as the most important moment in the customer relationship. That means pre-installation education so customers know what to expect, chatbot support and video guides for self-troubleshooting, and fail-safes, like providing a temporary Wi-Fi unit if the connection doesn't come up on time.

4. Know your customer… or end up with 350 unsold hats

The most memorable moment in the conversation was a candid failure story. At Card Con 2, My Republic invested in branded merchandise: custom shirts, tote bags, mouse pads, and 350 hats designed by a professional artist. Almost nobody bought them.

"I have 350 hats. If anyone wants one, come by the office. Seriously, you can have a hat."

The lesson? You can't skip the customer research step. Data and surveys are useful, but they're not enough. You have to go to the events. You have to call customers. You have to get your product managers talking to real people. "If you're just living inside your own office and asking all your co-workers what they like, they're going to be very different demographics."

5. Build engagement that's a value exchange, not a giveaway

Terry drew a sharp contrast between generic perks ("here's a free ticket to a movie or a free thing for Sephora") and engagement that's actually tied to what your customers care about. The former is expensive and only resonates with maybe one in ten people. The latter builds real loyalty.

My Republic's approach: if you're a broadband or mobile customer, you jump to level seven in their new tiered loyalty system. That unlocks discounts on trading cards at Card Arena, free spins in their mobile games, early access to events, and other benefits their core audience genuinely values. They even built Paka Rocket Adventures, a mobile game that now has 10,000 daily active users, with in-game rewards tied to their loyalty ecosystem.

The result is that customers don't mind paying a small premium for My Republic because they're getting tangible value back in a space they care about.

6. Community is the moat when price can't be

Here's the competitive reality: in Singapore, you can get 1 Gbps broadband for around $30 a month. In Canada, that same speed costs roughly $100. Singapore is one of the cheapest broadband markets in the world, and mobile pricing follows a similar pattern.

When everyone is competing on price, the only path to survival is differentiation. Terry was direct: "If we didn't do this, we would die. There's no way around it. If everybody's competing on price, there's just going to be consolidation."

The community strategy is paying off. My Republic is one of the only non-new-entrant broadband companies in Singapore that's still growing. Sales are trending up, churn has come down significantly, and Card Arena's revenue is contributing meaningfully to their P&L. They're shifting ad spend into community investment, bringing down cost per acquisition in the process.

7. If you can only fix one thing, fix how well you know your core customer

When asked for a single piece of advice for anyone running a subscription business, Terry's answer was simple: know your loyal core.

"Figure out who your loyal core is. The people who are interacting, giving you feedback, adding comments on social media, recommending your company. Get in touch with them, find out what they really like. Then when you're building engagement campaigns, make sure whatever it is is good for that core person. Don't do something that's vanilla for everybody."

The payoff? "You won't be staying up at night because you're worrying about churn. You'll always have them to carry you through."

The bottom line

My Republic's story is a case study in what happens when a company stops treating customer engagement as a retention tactic and starts treating it as the product itself. They've gone from broadband provider to community builder, to the point where new customers are discovering them through trading cards, not the other way around.

As Terry put it: "People are already starting to see us. They're like, 'Oh, you guys are the trading card company.' And we're like, 'No, we're actually a broadband company.' They're like, 'Oh, we didn't know you had broadband.' And we're like, 'Well, do you want to sign up?'"

It's working exactly how it's supposed to.

Whether you're filling the gap between signup and renewal or building loyalty touchpoints your customers actually look forward to, it starts with being able to reach them on the right channel at the right time. OneSignal makes that part straightforward.

The first hour on any new customer engagement platform is usually wasted. You poke around the dashboard, open a few settings screens, maybe start configuring something before realizing you needed to do something else first. Here's a faster path: the specific setup steps that matter most, in the order you should do them.

This guide provides a focused, 60-minute action plan to cut through the noise. We will prioritize the critical first steps to configure your platform correctly and launch your first automated message. Most teams complete this initial setup in under an hour, building a solid foundation for the sophisticated strategies that follow.

Successful implementation of a customer engagement platform hinges on deliberate, prioritized actions. By focusing on data integrity and a single automated workflow first, you can demonstrate value immediately and build momentum for your team.

The first 15 minutes: Foundational setup & data integrity

This phase is non-negotiable. Every future act of segmentation, personalization, and messaging will be built upon the foundation you lay down right now. Get this right, and you set your entire engagement strategy up for success.

Action 1: Configure your user identity system

Your first and most critical action is to tell the platform how to recognize a unique user across every device and channel. A true customer engagement platform is designed to manage and optimize the end-to-end customer journey across all touchpoints. This process starts with a unified user profile, which prevents duplicate data and ensures every interaction contributes to a single source of truth for each customer.

To do this, map your internal user ID from your database to the platform's "External ID." A detailed quickstart guide can walk you through the precise process. Using a stable, non-personally identifiable unique ID is a firm best practice that will save you from major data cleanup headaches down the road.

Action 2: Install the SDK & connect your first channel

Next, you must install the Software Development Kit (SDK) to build the bridge that allows data to flow from your digital properties into the platform. This is what enables message delivery.

For a website, begin with the Web SDK; for a mobile app, choose the appropriate mobile SDK. To gain immediate momentum, focus on configuring just one or two primary channels, such as push notifications or in-app messaging. The goal is to centralize conversations from your most important channel first. You can easily integrate other channels like email and SMS later, once this core setup is validated.

Minutes 15-45: Activating your first automated journey

With your foundation secure, it is time to shift from passive configuration to active engagement. You will now build and launch a simple, high-value automated workflow that showcases the platform's power and delivers an immediate return on your time.

Action 3: Choose a high-impact welcome journey

Start with a new user welcome journey. This is a classic low-effort, high-impact workflow that engages every new user at the peak of their interest. It improves onboarding, sets the tone for future communications, and delivers measurable results.

According to the 2026 State of Customer Engagement Report, push notifications in the first 30 days after an install drive a 75.8% impact on long-term retention. Furthermore, behavior-triggered messages like a welcome journey outperform standard broadcasts by up to 9x, making them essential for cutting through the noise.

The journey's logic is beautifully simple:

• Trigger: A user signs up or opens the app for the first time.
  
• Action: Send a single, welcoming push notification or in-app message.

Action 4: Build the workflow

Modern platforms provide visual journey builders that let you map out this entire workflow without writing a single line of code. For now, resist the temptation of complex, multi-branch logic. The goal is to establish a clear baseline you can optimize later.

Create a new journey, select the "new user" trigger, and drag a message block like "Send Push Notification" onto the canvas. Your objective here is to drive value with a simple workflow and achieve a quick, motivating win.

Action 5: Write your message (With an assist from AI)

Staring at a blank message composer can be intimidating. This is where an AI message composer becomes your creative co-pilot. It is one of the most powerful user engagement tools for apps available today, helping you craft clear, compelling copy in seconds.

Use the AI tool to generate ideas with a simple prompt, such as: "Write a friendly 15-word push notification welcoming a new user to our app and hinting at the value they'll find." Review the generated options, pick the one that best captures your brand's voice, and give it a final polish.

Minutes 45-60: Test, launch, and plan for day two

In this final stretch, you will validate your work, activate the journey for real users, and define a clear path forward. This ensures you leave your first hour with a tangible accomplishment and a roadmap for what comes next.

Action 6: Test and verify

Never launch blind. A broken link or poorly rendered message can sour a customer's first impression. Before activating the journey for everyone, it is crucial to send and test your notification by targeting a test device or a user segment containing only your own ID. Take a moment to see how the message looks in a real-world notification center.

Run through this simple pre-flight checklist:

• Did the message deliver successfully?
  
• Does it look and read exactly as intended on the device?
  
• Does the click-through action lead to the correct destination?

Action 7: What to defer for later

To protect your focus, knowing what not to do in your first hour is just as important as knowing what to do. Conclude your session by parking advanced features for another day. Mastering the fundamentals is the key to unlocking more powerful tactics down the line.

Save these items for after your initial setup is live and validated:

• Complex multi-channel messaging platform workflows, such as the sophisticated sequences needed for creating a strong messaging campaign across multiple channels.
  
• Intricate A/B testing with multiple message variants and control groups.
  
• Advanced segmentation based on granular user behaviors.
  
• Setting up webhooks or custom API integrations.
  
• Configuring multi-language or localized messaging.

To wrap up

In just one hour, you have transformed an empty dashboard into a fully configured platform running an automated engagement campaign. It’s this focused approach that explains why one in every five new apps uses a platform like OneSignal to onboard, engage, and retain customers. By following this prioritized plan—securing your data foundation, activating a single journey, and testing rigorously—you have built an essential base for future success.

This initial, focused effort is the key to unlocking the long-term power of a customer engagement platform. It creates the momentum you need to build a sophisticated messaging strategy that drives lasting retention and growth for your business.

Here’s a quick exercise. Install a clean build of your app on a test device, and use it the way a real customer would for a couple of days. Let the notifications pile up without clearing them. Then open that notification center and look at it with fresh eyes. What you see is an unfiltered record of the experience you’re creating, message by message. And for a lot of teams, the gap between the strategy they think they’re running and the reality sitting in that tray is humbling.

How to run a notification center audit

The goal is simple: experience your mobile messaging strategy the way an actual user does. Not in a dashboard, not in a journey builder, not in a Figma mock. On a real device, in real time, with real context.

• Install a clean build of your app on a test device. Don’t use a staging environment with debug flags. Use the same build your customers download.
• Trigger a range of notifications. Browse products, abandon a cart, complete a purchase, go inactive for a day, come back. Hit as many of your automated flows as you can.
• Let them accumulate. Don’t clear your notification tray for 48 hours. Let the full picture build up the way it does for someone who checks their phone a few times a day but doesn’t obsessively swipe away every alert.
• Review with honest eyes. Open the tray and ask: does this feel helpful or noisy? Is the timing right? Would I tap any of these? Would I mute this app?

What you find will fall into a few predictable categories. Let’s walk through each one.

Common anti-patterns (and how to fix them)

Notification clustering

This is the one where three messages land in a 15-minute burst: a promotional offer, a cart reminder, and a shipping update, all stacked together like the app is having a panic attack. Each message might be reasonable on its own. Together, they train the user to ignore everything from you, because the cognitive cost of sorting through the pile isn’t worth it.

The fix: Frequency capping and Intelligent Delivery. A good notification management system lets you set limits on how many messages a single user can receive in a given window, and spaces non-urgent sends to arrive when the user is most likely to engage rather than whenever the campaign happens to trigger. Batch low-priority updates into summary notifications where it makes sense. Not every event in your system needs its own push.

Redundant multi-channel messages

You know the one. A push notification says “Don’t miss our summer sale!” and then an email arrives 10 minutes later with the exact same copy and the exact same hero image. Then maybe an SMS for good measure. The user hasn’t even had time to read the first message before channels two and three pile on.

The fix: Sequenced, cross-channel journeys with fallback logic. A multi-channel messaging platform should let you define a primary channel and escalate only if the first message goes unread. For example: send a push. If it’s not opened within two hours, follow up with an email. If the email goes unread for a day, try SMS as a last resort. Each channel has a distinct role in the sequence, not a redundant one. OneSignal’s re-engagement Journeys builder walks through exactly how to set this up.

Wrong message, wrong channel

Sending a generic 20%-off promotional blast via SMS or RCS is a fast way to get users to block your number. A text message carries an implied urgency. When someone sees a text from a brand, they expect it to matter: a delivery is arriving, an appointment is in an hour, a security code is needed right now. Using that channel for a promotion you could have sent via email or push violates the unspoken contract users have with each channel.

The fix: Define a clear role for each channel and stick to it.

• Push notifications: Timely, contextual, high-value. Cart reminders, price drops, breaking updates.
• Email: Longer-form content, transactional receipts, newsletters, onboarding sequences.
• In-app messages: Contextual prompts while the user is active. Feature announcements, feedback requests, onboarding tips.
• SMS and RCS: Genuinely urgent. Authentication codes, delivery-day alerts, time-sensitive confirmations.

For more on setting up each channel properly, OneSignal’s channel setup documentation covers the technical side, and our multichannel marketing glossary entry is a useful reference for the strategic framing.

Stale and irrelevant messages

The abandoned cart notification for an item you already purchased on your laptop. The “we miss you” push that arrives while you’re literally using the app. The event promotion that lands two hours after the event started. These are all symptoms of a messaging system that’s operating on stale data, or no behavioral data at all.

The fix: Real-time behavioral triggers and proper segmentation. Your notification system should know that a user already converted before it sends a conversion nudge. It should know that a user is currently active before it sends a win-back message. This is table stakes for any customer engagement platform in 2026, and if your current setup can’t do it, that’s the gap to close first.

Building a healthier strategy

Personalize at the behavioral level

"Personalization" that starts and ends with a first name merge tag is not going to move your metrics. The notifications that actually get tapped are the ones that reflect what a specific user did (or didn’t do) recently: the category they browsed, the feature they haven’t tried, the subscription that’s about to renew. Behavioral data is the difference between a message that feels relevant and one that feels like it was addressed to a mailing list.

Measure, learn, adjust

Run your audit once and you’ll find problems. Run it quarterly and you’ll track whether you’re actually fixing them. Pair the qualitative audit (looking at your notification tray) with quantitative monitoring: delivery rates, open rates, click-through rates, and conversion events per channel. If your push CTR is climbing but your email open rate is dropping, that’s a signal about channel preference you can act on.

OneSignal’s engagement trends dashboard and engagement analytics make this kind of ongoing measurement practical without building custom reporting.

Your notification center is a mirror

A cluttered, repetitive, poorly timed notification tray isn’t a minor UX issue. It’s a direct readout of strategic gaps: missing coordination between channels, absent frequency controls, stale data powering automated flows, or simply no clear philosophy about what each channel is for.

A clean tray, on the other hand, one where every message feels timely, relevant, and distinct from the last, is the output of a team that has done the hard work of defining channel roles, investing in behavioral data, and building journeys that adapt to what users actually do.

The audit takes 20 minutes. The patterns it reveals will tell you more about the state of your engagement program than a month of dashboard reviews. Start there, fix the worst offender first, and work forward.

For a broader look at where engagement strategy is headed this year, the 2026 State of Customer Engagement Report is worth reading alongside this exercise.

The way apps are built has changed forever. New tools like Lovable, Bolt.new, Base44, v0 by Vercel, Replit, and more allow anyone to go from idea to fully functional web app in hours, not months. No traditional development team needed.

But there is one more piece of the puzzle these tools can’t handle: distributing your app through the App Store and Google Play Store as a native iOS and Android app. For that, you need a native app, which means you need to build a native app from scratch. It's exactly what these tools are meant to help you avoid.

This is where WebViewGold comes in. It turns your website or web app into a beautiful native iOS and Android app without ever having to write native code. And by combining WebViewGold with OneSignal, you can have push notifications integrated into your app from the very start. Push notifications are one of the most powerful re-engagement tools available to any app developer.

In this post, we’re going to walk through exactly how to turn your vibe-coded web app into a native mobile app with push notifications.

The vibe-coding revolution and the distribution gap

If you have created a web application with one of these tools in recent times, you probably know how incredible the experience is: Describe what you want in natural language, then watch the AI create a complete application. And then even deploy to the web in one click.

The application you create is a real application, hosted at a public URL, identical to an application that a professional development team might create. The quality of tools such as Lovable, Bolt, and Base44 has gotten to a point where many of these applications are, in effect, production-ready.

However, web applications and native applications are different. To get a presence in the iOS App Store or on Google Play, Apple and Google require a native application, a compiled binary to review. Your application's URL is not enough.

This is the distribution gap. You have a great product. You just need a native wrapper to ship it through the channels your users actually expect.

What is WebViewGold?

WebViewGold is a wrapper tool for building a native iOS app using Swift and Xcode, and a native Android app using Java and Android Studio, which loads your existing website or web app inside a high-performance native shell. What this gets you is a completely native app binary, with its own icon, splash screen, title, etc., which will pass muster with both Apple and Google.

The key insight: from Apple's and Google's perspective, you're submitting a native app. From your users' perspective, they're using a native app. From your perspective, your existing web app is your codebase, and you change it once, and it instantly goes live on iOS and Android, no app update needed.

What WebViewGold is not

WebViewGold is not a cross-platform solution, like React Native or Flutter, where you have to implement your code in a different language. WebViewGold is not a low-code solution, where you build a new app using their tool, replacing your existing product. WebViewGold is a wrapper, and your web application remains exactly as it is, with WebViewGold providing a native container for your web application, which can then be distributed through the App Store or Google Play.

Which platforms does WebViewGold work with?

Any platform that produces a public web URL. That includes all of the major AI-powered and no-code builders:

It also works with traditional HTML websites, WordPress sites, web apps built with custom code, SaaS dashboards, internal tools, e-commerce stores - anything accessible via a URL.

How to convert your web app to iOS & Android: step by step

WebViewGold offers two setup paths. The easiest requires nothing more than a browser.

The Cloud Builder: no Xcode, no Android Studio

WebViewGold Cloud Builder is a browser-based build system. It is a completely server-side compilation of your native application. It is configured with a visual interface, and with the click of the Build button, your application is complete and ready to be uploaded to the App Store Connect or Google Play Console as an IPA or APK/AAB.

This is the recommended workflow for anyone who built their application with Lovable, Bolt, Base44, or any other similar tool and does not want to set up a local native development environment. The results are the same as if you had built your application locally using Xcode and Android Studio.

The developer path: Via Config.swift / Config.java

If you prefer to build locally, WebViewGold has Xcode and Android Studio projects that have a single configuration file for each platform: config.swift for iOS, config.java for Android. All of your app’s configuration – your app URL, name, icon, App ID for push notifications, etc. – is in one file. No native code required.

Adding OneSignal push notifications

Once your web app is encapsulated within the native shell, you gain access to the native device features, such as push notifications. This is arguably one of the biggest advantages of creating a native app compared to simply launching your web app within the browser.

Push notifications provide the means to reach your users before they even think about your application. This is arguably the single biggest feature for apps built on vibe-coding platforms that makes the distinction between an application and a product.

Why push notifications matter for vibe-coded apps

Most applications developed with the help of AI tools can effectively address one particular issue. However, the question of retention, i.e., how to retain users, is something different. It is something the application alone can’t help with. One of the best retention tools is push notifications:

• Alert users about something relevant happening within the app, such as “you got a new message,” “you completed a task,” “your status was updated”
• Re-engage users who haven’t opened the app in days with a relevant message
• Announce new features, content, or updates as soon as they go live

With OneSignal and WebViewGold, adding all of this to your app requires exactly one configuration value: your OneSignal App ID.

Setting up OneSignal

• Create a free account on onesignal.com.
• Click on New App/Website. Select your platforms: Apple iOS +/or Google Android +.
• OneSignal will walk you through credential creation: APNs Auth Key for iOS, Firebase Server Key for Android.
• Copy your OneSignal App ID from your dashboard.
• Paste it into your WebViewGold Cloud Builder (or Config.swift/java for local builds).
• That’s it! Your push notifications are live.

What you get: Native features on top of your web app

WebViewGold does not simply wrap your URL; it provides your app with a full range of native capabilities not available to your competitor’s web apps in a browser.

As discussed above, native push notifications that work even when your app is closed. Configure your segments, schedule your campaigns, run your A/B tests, and automate your journeys – all from your OneSignal dashboard.

Deep linking

Send your users directly to a specific page in your app from a push notification, email, or shared link. WebViewGold automatically routes deep links. Simply configure your target URL in OneSignal.

Native navigation & gestures

Swipe-to-go-back, pull-to-refresh, native loading animations, and other native behaviors are included in WebViewGold’s native shell. Your users get the native gestures they’re accustomed to on iOS or Android without modifying your web app.

Offline support

WebViewGold allows your app to cache content so it can display it or your own offline page in the event of no network connection. Browsers vary in support for offline support.

Custom splash screen & icon

Your app launches with your custom splash screen and features your icon on the home screen, just like other native apps. Configure these in the Cloud Builder or config file.

In-App Messages (via OneSignal)

OneSignal’s in-app messages feature allows you to display overlays, banners, or modals in your foreground app. No permission required. Great for onboarding, feature announcements, or promotions.

App Store & Google Play submission

One of the first questions that comes to mind: will Apple, or Google, accept an app created in such a manner?

The answer is: yes, they will. There is an important caveat, though: Apple has a set of rules for apps, called App Store Review Guidelines, and one of them is that an app created with a web view should have some real value added to it, apart from being a simple wrapper for a website.

The WebViewGold apps that pass the review at Apple's App Store share a number of properties:

• They're real apps: they contain a real web application, not just a marketing website.
• They're not simple web views: they utilize various features, such as push notifications, deep links, etc.
• They have a real look and feel: they have a real app name, a real app icon, a real splash screen, etc.

The apps created with Lovable, Bolt, Base44, and similar tools tend to pass these tests naturally: they're real apps, not marketing tools.

The full workflow: vibe-code → native app → push notifications

This is basically what the entire workflow looks like:

• Make your own web app using Lovable, Bolt, Base44, v0, Replit, or any other means. Host it on a public URL.
• Make a OneSignal account. Set up your iOS/Android push credentials. Grab your App ID.
• Fire up your WebViewGold Cloud Builder. Plug in your URL. Set up your app’s identity. Plug in your OneSignal App ID.
• Hit Build. Download your IPA/APK/AAB files.
• Submit to App Store Connect and Google Play Console. Follow the standard review process for each store.
• Go live. Send your first push notification from your OneSignal dashboard.

Frequently asked questions

Does my web app have to be developed using a certain framework?

Nope! WebViewGold works perfectly well with any URL you throw at it – React, Vue, HTML, WordPress, Webflow, Lovable, Bolt, Base44, etc. As long as your web app is accessible over HTTPS, you can use WebViewGold.

What happens when I update my web app?

Updates to your web app are automatically reflected in your native app immediately. No new build is required, and you don’t have to submit your app to the App Store either.

Can I use my own custom domain?

Yes! WebViewGold can load any URL you set – your Lovable project’s URL, your custom domain, etc.

What about offline support?

We support various types of caching in WebViewGold so you can make sure your app behaves as desired when there’s no network available – either by displaying some content or a custom offline screen.

Will WebViewGold work for my web app’s authentication/user accounts?

Yes! WebViewGold behaves exactly as a native browser when it comes to cookies, session storage, and local storage – so user accounts and authentication should all work as expected.

Do I need a paid plan from OneSignal?

Nope! To get started, you can use OneSignal's Free Plan, which supports thousands of subscribers and has access to all features related to push notifications.

We are excited to announce updates to roles and permissions in OneSignal to give teams more control over access across organizations and apps. These changes are designed to improve flexibility, support least-privilege access patterns, and make permission management more intuitive as teams scale.

No action is required and these updates do not change your current pricing.

Here’s a quick breakdown of the updates to the following roles:

Editor

• Permissions Removed: delete or export users and subscriptions
• Permissions Added: import users and subscriptions, full management of test users, full management of dynamic content

Composer (new role)

• Permissions: send a test notification, add and view test users, add dynamic content, and edit dynamic content that isn't tied to live published content

Viewer

• Permissions Removed: export any data

Understanding org-level and app-level roles

OneSignal roles are structured across two levels. Organization-level roles define baseline access across all apps in an organization. App-level roles provide more specific permissions within individual apps and always grant higher levels of access than org-level roles.

This model allows teams to manage broad access centrally while still tailoring permissions at the app level.

Introducing the Team Member role

We are adding a new organization-level role called team_member. This role does not grant any app permissions on its own. Instead, access is explicitly assigned through app-level roles.

This provides a clean starting point for least-privilege access. Users only receive access to the apps and capabilities they are explicitly granted.

All new users invited to an organization or app will automatically be assigned the team_member role. This role can be updated later if broader access is required.

Updates to existing roles

We have also updated several existing roles to better align with common workflows and improve security.

The Editor role will no longer be able to delete or export users and subscriptions. It will now include the ability to import users and subscriptions, as well as full management of test users and dynamic content.

We are introducing a new role called Composer, which is currently in limited release. This role is designed for users focused on messaging and content creation. Composer cannot export data or delete labels. It can send test notifications, manage test users, and create or edit dynamic content that is not tied to live published content.

The Viewer role will no longer have permission to export any data.

Changes to app-level role assignments

We are also updating how app-level roles can be assigned.

App-level roles must now grant more access than a user’s organization-level role. A user cannot be assigned a more restrictive role at the app level than they already have at the org level.

For example, a user with a Viewer org role can be assigned Composer, Editor, or Admin at the app level. A user with an Editor org role can only be assigned Admin at the app level.

These rules will be enforced on both the client and server side to ensure consistency.

Unlike in the past, app-level roles must grant more access than a user's org role. In other words, you can't assign a more restrictive role at the app level than what the user already has at the org level. Here's a quick reference:

These rules will be enforced on both the client and server side.

What you need to do

Most of these changes will be applied automatically and we don’t expect any breaking changes.

Still, if you manage team access, we recommend reviewing your current role assignments with the updated rules (especially if you currently assign roles at the app level).

Why we are making these changes

These updates make it easier to manage access at scale while reducing the risk of over-permissioned users. By separating baseline access from app-specific permissions, teams can more confidently control who has access to what.

You can always review the latest updates in our changelog at:
https://documentation.onesignal.com/release-notes/changelog
https://documentation.onesignal.com/docs/en/manage-team-members

If you have any questions, please reach out to our support team.

Onboarding tours, in-app tutorials, and deep product walkthroughs all have their place, and they work well for users who are already invested in your app. But those users are still a subset. The larger group, the one that determines whether your engagement metrics trend up or flatten out, is the one opening your app for 30 seconds between other things. The quick check while waiting for coffee, a scroll between meetings, a tap from a push notification that leads to maybe 20 seconds of actual attention.

That's where micro-journeys come in: short, automated, cross-channel sequences where every touchpoint is designed to deliver value inside a single brief session. This guide covers how to structure them and walks through three real examples you can build in OneSignal.

Why micro-Journeys outperform traditional flows

Traditional engagement journeys tend to assume a linear path. User signs up, user gets a welcome email, user opens the app, user completes onboarding, user converts. It’s neat, tidy, and almost never how it actually plays out.

Micro-journeys work because they respect this reality. Each touchpoint is designed to be complete on its own. If a user only sees one message in the sequence, that message should still make sense and still drive value. If they see all of them, the experience compounds.

Anatomy of a good micro-Journey

The best micro-journeys share a few structural traits:

• One goal per sequence. Not three goals stapled together. If the journey is supposed to drive a first purchase, every step should support that single outcome.
• Short time horizons. Most micro-journeys run 3 to 7 days, not 30. You're working with a narrow window of intent, and the longer you stretch it, the more users leak out.
• Channel-aware delivery. The right message on the wrong channel is still the wrong message. A time-sensitive reminder belongs in push. A product recommendation with visuals belongs in email. A contextual nudge while someone's already in the app belongs in-app.
• Built-in branching. The sequence adapts based on what the user does (or doesn't do). If they complete the goal after step one, they exit. If they don't engage with a push, you try a different channel instead of repeating the same one louder.

Three micro-Journeys you can build in OneSignal today

Each of these uses OneSignal Journeys, which supports automated cross-channel sequences with push, email, SMS/RCS, in-app messages, wait steps, yes/no branching, time windows, and webhooks. Here's the step-by-step for each.

1. The 72-Hour Activation Nudge

Goal: Get a new user to complete one meaningful action (first purchase, first bookmark, first content save) within three days of signup.

Why it works: Most users who don't activate within 72 hours never will. This journey front-loads value while intent is still fresh and adapts channels based on what's working.

2. The Abandoned Browse Recovery

Goal: Convert a user who browsed a product or content category but left without taking action.

Why it works: Browse abandonment is earlier in the funnel than cart abandonment, so the messaging needs to feel helpful rather than urgent. The time window step keeps you from pinging someone at 2 AM.

3. The Lapsed User Win-Back (Light Touch)

Goal: Re-engage a user who hasn't opened the app in 14+ days without being aggressive about it.

Why it works: Most win-back sequences go too hard, too fast. This one leads with a low-pressure push, only escalates to SMS for users who opened but didn't act, and exits users who come back on their own. The exit condition does the heavy lifting.

Four rules for designing micro-Journeys that actually work

1. Assume every message might be the only one they see. If a user only gets step three of your journey, does it still make sense on its own? If the answer is no, rewrite it. Micro-journeys should be sequential but not dependent.

2. Branch on behavior, not just time. A wait step followed by another message is a drip campaign. A wait step followed by a yes/no branch that adapts the channel or content based on what the user did? That's a journey. Use OneSignal's branching to check for opens, clicks, and segment membership before deciding the next step.

3. Set exit conditions aggressively. The moment a user completes the goal, they should leave the journey. Nothing erodes trust faster than getting a "come back!" push from an app you're actively using. OneSignal lets you set exit conditions based on custom events or segment membership, so there's no excuse for this.

4. Use tags to coordinate across journeys. Tag users as they progress (e.g., "activation_nudge_sent", "browse_recovery_sent") so other journeys and campaigns can exclude them. This is how you prevent the pile-up problem where a user gets three automated messages from three different flows on the same Tuesday morning.

Start designing for the sessions your users want

Users have trained themselves to get what they need from an app in under a minute, and nothing about that trend is reversing. The notification tray is only getting more competitive, and the threshold for earning a tap keeps rising. We’re seeing more and more marketers designing sequences tight enough that a single touchpoint can carry its weight on its own, even if the user never sees the next one.

Micro-journeys are how you do that at scale. And if you're using OneSignal, the building blocks (cross-channel messaging, behavioral branching, time windows, tagging, exit conditions) are already in the Journeys builder waiting for you. Start with one of the three examples above, measure what happens, and iterate from there.

If you’re not using OneSignal, we are here to make it pain-free by including access to our Journeys builder from the start.

You built the campaign, wrote the copy, segmented the list, and hit send. A day later, half your audience hasn’t opened it. The instinct is to treat this as a problem to fix... fix that subject line, adjust that send time, and voilà.

Sometimes that’s the right call. But more often, the unopened email is telling you something more useful than “your subject line wasn’t catchy enough.” It’s a data point about how that user prefers to be reached, what kind of message earns their attention, and whether email is even the right channel for the job.

Below, we walk through how to read that silence, decide what to do next, and build an engagement strategy that treats non-response as input rather than failure.

First, Diagnose the Silence

Before you change anything, figure out which kind of “ignored” you’re dealing with, because the cause determines the response.

Technical hurdles: Did the message actually arrive?

The most basic question is whether your email made it to the inbox at all. Misconfigured DNS records, poor sender reputation, or an unverified domain can quietly route your messages to spam, or prevent delivery entirely. If your open rates dropped suddenly across your entire list (rather than for a specific segment), start here.

OneSignal’s email troubleshooting documentation covers the most common deliverability issues and how to resolve them. And if you’re evaluating your email infrastructure more broadly, our breakdown of what to look for in an email service provider is a useful starting point.

Content and context: Was the message worth opening?

If delivery isn’t the issue, the next question is relevance. Was the email personalized to the user’s behavior, or was it a batch-and-blast to your entire list? Was the value proposition clear in the subject line and preview text, or did the recipient have to guess why it mattered?

These are real factors, and they’re worth testing. But they’re also the advice that every “how to improve open rates” post already covers. The more interesting question is the one most teams skip.

Channel preference: Was email the right vehicle?

Some users are buried in email. They have 4,000 unread messages and a relationship with their inbox that is, generously, adversarial. These same users might tap every push notification within minutes or respond to an SMS inside of 30 seconds.

This is also worth keeping in mind: users who go quiet on one channel are not necessarily disengaged from your product. For more on that distinction, read Rethinking ‘Inactive’: Why Your Quiet Users Might Still Be Valuable.

Choosing your next move: Retry or rechannel

Once you’ve diagnosed the likely cause, you have two options: try email again with a different approach, or move the conversation to a different channel entirely. The right choice depends on the message and the user.

When to send a follow-up email

A follow-up makes sense when the message is high-value, non-urgent, and there’s a reasonable chance the first email was simply lost in the noise. Think: a detailed product update, a renewal reminder, or an onboarding sequence where the next step matters.

If you do follow up, make it count. Don’t just resend the same email—offer a new angle, simplify the ask, or test a different subject line. And always make it easy to opt out. Respecting unsubscribe preferences isn’t just a compliance issue; it protects your sender reputation and keeps your remaining list healthier. Our guide on how to manage email unsubscribes covers the mechanics.

When to escalate to push or SMS

If the message is time-sensitive, action-oriented, or better suited to a quick glance than a full read, another channel is probably the better play.

Push notifications work well for in-app actions, cart abandonment, flash sales, and anything where context matters more than detail. They’re visual, tappable, and land directly on the lock screen—but they require their own strategy to be effective. If you’re seeing low engagement on push too, Why Most Push Notifications Go Unread and An Open Letter From Your Ignored Push Notification are both worth reading.

SMS is the highest-urgency option. Delivery rates are near-universal, and most texts are read within minutes. Reserve it for messages where delivery truly can’t wait: appointment confirmations, security alerts, or a last-chance offer that expires in hours. Overusing SMS burns trust faster than any other channel.

Building a smarter multi-channel strategy

Treating each ignored email as a one-off problem to fix is reactive. The better approach is to build a system that learns from non-engagement over time and routes messages accordingly.

Using engagement data to map user preferences

Every interaction (and non-interaction) adds to your picture of how a specific user prefers to communicate. A user who consistently ignores emails but opens every push notification is giving you a clear channel preference, if you’re set up to read it.

Over time, this data lets you shift from broadcasting on a single channel to routing each message through the channel most likely to reach that individual. An unopened email becomes the input that makes the next touchpoint more effective.

Why this requires a unified platform

In practice, this kind of cross-channel orchestration falls apart when your email tool, push provider, and SMS vendor are all separate systems with separate data. You end up with fragmented user profiles, duplicated messages, and no clean way to say “if email is unopened after 24 hours, send a push instead.”

A customer engagement platform that unifies email, push, SMS, and in-app messaging under one roof solves this. It gives you a single view of each user’s engagement across every channel, and it lets you build automated journeys that adapt based on behavior.

If you’re evaluating platforms, our comparison of top Braze alternatives for email and push in 2026 breaks down what to look for and how OneSignal stacks up.

When email is the only scalable channel in your toolkit, every message becomes an email by default: product updates, flash sales, onboarding nudges, cart reminders, feature announcements. Some of these messages belong in email. Many of them don’t. But when you don’t have push notifications, in-app messaging, or SMS available, everything gets forced through the inbox regardless of whether it’s the right fit.

The result is predictable: subscriber fatigue, declining open rates, rising unsubscribes, and a sender reputation that quietly erodes with each ignored campaign. The fix is to stop making email carry the weight of your entire communication strategy.

This guide lays out a framework for identifying which messages actually belong in email and which ones should move to a different channel, so every email you do send earns its place in the inbox.

The hidden costs of over-emailing

The damage from sending too many emails isn’t always obvious. Unsubscribes are visible, but the subtler costs (inbox fatigue, lower engagement across your entire list, spam complaints that chip away at deliverability) compound quietly in the background.

And the environment is getting less forgiving. Major inbox providers like Microsoft and Google have tightened their sender requirements over the past two years, placing a higher penalty on low-engagement sends. If a significant portion of your list is ignoring your emails, that silence actively hurts your ability to reach the subscribers who do want to hear from you. For specifics on what’s changed, read our breakdown of Microsoft Outlook’s new sender requirements.

The underlying issue is that audience attention is finite, and every email costs a withdrawal from that account. A message that doesn’t deliver value doesn’t just fail on its own, it makes the next email less likely to be opened, too.

For a deeper look at the mechanics of this, see 7 Easy Solutions to Mitigate the Risks of Over-Messaging.

A framework for choosing the right channel

Sending fewer emails starts with having real alternatives, and knowing when each one is the better choice. Here’s how to go about it.

When email IS the right channel

Email is best suited for messages that are content-rich, non-urgent, and benefit from being read at the recipient’s own pace. It’s where you build relationships over time, not where you drive split-second actions.

Good fits for email: newsletters and curated content roundups, welcome sequences and onboarding flows, transactional receipts and shipping confirmations, educational content and long-form storytelling, product changelog summaries.

Even when email is the right channel, volume discipline still matters. Segment your list so each subscriber receives content that’s actually relevant to them—not every campaign you run. Our guide on email segmentation best practices covers how to do this well. And if you’re sending fewer emails, each one carries more weight, which makes A/B testing and send-time optimization significantly more important.

When to use push notifications instead

Push notifications are the right choice when a message is time-sensitive, action-oriented, and better consumed in a glance than a full read. They land directly on the lock screen, and they don’t compete with 47 other unread messages to be seen.

Good fits for push: flash sales and limited-time offers, abandoned cart reminders, breaking news or urgent account alerts, real-time delivery and status updates, re-engaging users who haven’t opened the app recently.

Every message on this list is something many teams currently send via email, but each one would perform better as a push notification because the value of the message is tied to immediacy. An abandoned cart email sent 6 hours later competes with everything else in the inbox. An abandoned cart push sent 20 minutes later lands on the lock screen while the purchase intent is still warm.

For detailed guidance, see our push notification best practices guide.

When to use in-app messages

In-app messages reach users while they’re actively engaged with your product, which makes them the highest-context channel available. They’re not interruptions; they’re additions to an experience already in progress.

Good fits for in-app: onboarding tips and feature walkthroughs, personalized recommendations based on current activity, feedback requests and app store review prompts, contextual announcements (e.g., a new feature relevant to what the user is doing right now).

These are messages that would feel out of place in an inbox. A tooltip explaining a new feature has maximum impact when the user is looking at that feature—not when they’re scanning emails over coffee the next morning.

Putting a multi-channel strategy into practice

Start by reviewing your last 30 days of email campaigns and asking a simple question for each one: was email the best channel for this message, or was it the only channel available? If the answer is the latter for more than a handful of sends, that’s your clearest signal that email is carrying load it shouldn’t be.

While you’re auditing, clean up the list itself. A smaller list of engaged subscribers will outperform a bloated one every time, and it protects your sender reputation for the messages that genuinely belong in email.

Move to a unified mobile engagement platform

If your email provider, push notification service, and in-app messaging system are three separate products with three separate dashboards, building cross-channel journeys is painful enough that most teams default back to email.

A customer engagement platform that unifies email, push, SMS, and in-app messaging solves this by giving you a single view of each user’s behavior and a single place to orchestrate messages across channels. The decision of “should this be an email or a push?” becomes something you can act on—and even automate—rather than just debate.

This is what separates a modern email service provider from a customer engagement platform: the ability to treat email as one channel among several, rather than the only tool in the box. If you’re evaluating options, our comparison of top Braze alternatives for email and push breaks down what to look for, and the OneSignal email product page shows how it works in practice.

Send less, mean more

The brands that get the best results from email in 2026 are the ones that have built a system where each message goes through the channel it’s best suited for. And email is reserved for the messages that genuinely benefit from being read in an inbox.

That shift requires two things: a framework for deciding which channel fits which message (which you now have), and the tooling to actually execute on it. Get both right, and you’ll send fewer emails, see better engagement across every channel, and stop burning through your audience’s attention on messages that would have worked better as a push notification or an in-app prompt.

A tale of two launches.

You shipped it on a Saturday. A weekend project. Maybe a utility app, maybe a clever AI wrapper, maybe a niche tool that scratches an itch nobody else bothered to scratch. You used Cursor, or Replit, or Vibecodeapp. The stack doesn’t matter. What matters is that it works, it’s live, and on Sunday morning you posted it to r/SideProject.

By Sunday night, it’s on the front page of Hacker News. Your Vercel dashboard looks like a hockey stick. Your database is sweating. You’re refreshing your analytics tab every thirty seconds, watching the concurrent user count climb past numbers you’d never planned for.

This is the moment every indie builder dreams about. It’s also the moment that separates the apps that become real products from the ones that become screenshots in a Twitter thread about “that one time I went viral.”

What happens next depends almost entirely on what you set up before the 15 minutes of fame: specifically, whether you have any way to talk to the people who just showed up.

Let’s walk through two versions of the same story.

World one: The silent viral spike

Days 1–2: The high

Your app hits 12,000 signups in 48 hours. You’re running on adrenaline and cold brew. The Reddit thread has 400 comments. People are posting screenshots. A couple of YC founders DM you on Twitter. You feel like you’ve made it.

But here’s the thing: all you have is a signup flow and whatever core feature you shipped. There’s no onboarding sequence. There’s no welcome message beyond a default confirmation email from your auth provider. There’s certainly no push notification infrastructure. You didn’t think you’d need any of that yet.

Most of those 12,000 people try your app once. Some poke around for a few minutes. A few power users dig in. But the majority (the ones who signed up because the Reddit thread looked cool) are gone within the hour, and you have no mechanism to bring them back.

Days 3–7: The build sprint

You’re energized. You take the week off from your day job (“family emergency”) and start shipping features. You build the three things people asked for most in the Reddit comments. You fix the worst bugs. You add a proper settings page. The app is legitimately better now.

But who are you building for? You don’t actually know much about your users. You know how many signed up. You can see some aggregate page views in your analytics. But you don’t know which features they tried, where they got stuck, or what made the power users stick around.

You’re building on vibes and Reddit comments.

Week 2: The email

You want to tell your users about the new features. The problem: you have no messaging infrastructure. Your auth system has their email addresses, so you export the list to a CSV, paste it into your personal Gmail (or maybe a free Mailchimp tier), and send a blast.

The email’s subject line is something like “Exciting updates to [App Name]!” You write it in twenty minutes. It goes to all 12,000 addresses at once. There’s no segmentation because you have nothing to segment on. There’s no personalization because you don’t know anything about these people beyond their email.

The open rate comes back at 22%. That’s roughly average for a bulk email from an unknown sender, which is exactly what this is. A few hundred people click through. A few dozen re-engage. Most don’t.

You send another email the following week. The open rate drops to 16%. A handful of people unsubscribe. The ones who don’t unsubscribe simply ignore you. Your app is already fading from their memory, replaced by whatever new thing hit the front page this week.

Week 4+: The plateau

Traffic is back to baseline. Your analytics dashboard, which briefly looked like a rocket ship, now looks like a cliff followed by a flat line. You have maybe 200 weekly active users from that original cohort of 12,000. That’s a 98.3% churn rate on your viral spike.

You didn’t lose those users because your app was bad. You lost them because you had no way to build a relationship with them after signup. No onboarding to show them the good stuff. No timely nudge when they hadn’t opened the app in three days. No way to tell them “hey, that feature you wanted? It’s live” in a channel that actually reaches them.

You had 48 hours of attention and no infrastructure to convert it into retention.

World two: The prepared viral spike

Same app. Same Reddit post. Same 12,000 signups in 48 hours. But in this version, you spent an extra afternoon before launch setting up OneSignal.

It wasn’t a heroic effort. You added the SDK, configured push notification permissions and in-app messaging, and wired up a few basic event triggers. You did it because you’d read enough post-mortems from other indie devs to know that “we’ll add engagement tooling later” is the most common last words of a promising side project.

Here’s how the same viral spike plays out differently.

Days 1–2: Onboarding at scale

As those 12,000 users sign up, they’re opted into a welcome sequence. Not just a generic “thanks for signing up” email, but an actual mobile onboarding flow. The first in-app message fires when they land on the dashboard for the first time, pointing them to the feature that Reddit was raving about. A second message triggers if they haven’t tried the core workflow within the first session, offering a quick walkthrough.

For users who grant push notification permissions (and in this world, you actually ask at a contextually appropriate moment rather than on first page load, because the OneSignal SDK lets you control that timing), you now have a direct channel to their device. That’s a fundamentally different relationship than “their email address sitting in a CSV somewhere.”

On day two, you send a push notification to users who signed up but didn’t complete the core action. The message is specific: “You created an account yesterday but haven’t [done the thing] yet. Here’s a 30-second walkthrough.” The re-engagement rate on this message is 4x what you’d get from email because it arrives on their lock screen, in real time, while your app is still fresh in their mind.

Days 3–7: Building with signal

You’re still doing the same build sprint; cranking on features, fixing bugs, improving the UX. But now you’re not building blind. Because you instrumented your app to trigger OneSignal Events when users complete key actions (finished onboarding, used the export feature, hit the paywall) you now have segments that actually mean something. You can see that users tagged “completed_core_workflow: true” within their first session are your power users, and users who never triggered that tag bounced from the same screen.

This changes your roadmap. Instead of building what Reddit commenters suggested (a vocal minority), you prioritize the friction point that’s actually causing drop-off. You ship a fix on day five and create an in-app message in OneSignal’s dashboard, targeting the segment of users whose tags indicate they stalled at that step. The message fires via a programmatic trigger you set in your code: when a user lands on the screen where the fix lives, OneSignal displays it. No batch send, no blast. It shows up in context, at the moment it’s relevant.

Crucially, you’re not blasting everyone with the same message. Your power users (the ones who show they’ve already hit every feature) get a different notification than the users who signed up and never came back. You build two segments in OneSignal: one filtered on “features_used greater than 3,” another on “last_session_date more than 5 days ago.” The power user segment gets a push about the new feature you just shipped. The lapsed segment gets a re-engagement nudge that highlights the core value prop they missed. Same tool, different messages, because the tags you set give you something to filter on.

Week 2: Multi-channel engagement

In World One, this is when you sent the Mailchimp blast. In World Two, you’re running a coordinated multi-channel strategy without thinking of it in those terms.

Users who are active in the app see in-app messages about new features: contextual, non-intrusive, triggered by their behavior. Users who opted into push get timely notifications when something relevant to them happens. Users who haven’t opened the app in a week get an email. The right message arrives in the right place at the right time, and that’s not a marketing platitude; it’s just what happens when your engagement stack can actually see what users are doing.

The result: your email open rate is north of 35% because you’re only emailing people who aren’t reachable via push or in-app, and the content is relevant to their actual usage pattern. Your push notification tap-through rate is above 8%. Your in-app messages have a 40% interaction rate because they fire at the exact moment the user would benefit from them.

Week 4+: Retention compounding

A month out from the viral spike, traffic has come down from the peak. That’s inevitable; no one sustains front-page-of-Reddit traffic forever. But the floor is dramatically higher. Instead of 200 weekly active users from the original 12,000, you’re sitting at 2,400. Same app, same viral moment, 12x the retention.

And here’s where it compounds. Those 2,400 active users are generating the kind of engagement signals: feature usage, session frequency, workflow completion. You can A/B test your onboarding messages. You can identify which notification cadence maximizes weekly retention without triggering unsubscribes. You can spot your most engaged users and turn them into advocates.

The viral spike was the same. The difference is everything that happened after.

The infrastructure you set up before you need it

There’s a reason we framed this as two versions of the same story rather than a feature comparison chart. The gap between World One and World Two isn’t about having access to more marketing tools. It’s about whether you can build a relationship with your users outside of the moments when they happen to be inside your app.

If you’re vibecoding a side project the temptation is to defer everything that isn’t the core product. Engagement tooling feels like a “scale problem,” something you’ll set up when you have real users. But the catch-22 is that without it, you can’t keep the users you get.

The practical reality of modern app development is that users make a retention decision in their first 48 hours. They either form a habit or they forget you exist. If you can’t reach them during that window with onboarding guidance, with timely nudges, with proof that your app is alive and improving, then you’re relying entirely on their intrinsic motivation to come back. And for the vast majority of users, intrinsic motivation loses to the next notification from the next app.

What this looks like in practice

If you’re building right now and haven’t thought about engagement infrastructure yet, here’s the minimum viable setup that would have changed World One into World Two:

Push notifications with permission timing. Don’t ask on first load. Ask after the user has experienced value. After they’ve completed the core action, after they’ve had their “aha” moment. And, don’t ask generically. With the OneSignal’s SDK you have programmatic control over when the permission prompt fires and what that prompt looks like to highlight key value and drive opt-in rates.

A full onboarding sequence, not a one time welcome email. Two or three in-app messages that trigger based on behavior, not time. First message on dashboard load. Second message if the user hasn’t completed the core workflow. Third message highlighting a non-obvious feature that power users love. All easy to do right from the OneSignal Dashboard or using our MCP with your favorite tool.

A lapsed-user re-engagement flow. If someone hasn’t opened the app in 72 hours, send a push. If they don’t respond, send an email 48 hours later. If they come back, show an in-app message about what’s new.

Basic segmentation from day one. Even simple segments (e.g. active in the last 7 days, completed onboarding, hasn’t tried feature X) let you avoid the “same blast to everyone” trap. OneSignal creates these segments from the events your app is already firing; you just need to tag them.

Virality is a window, not a destination

The vibecoding era has made it dramatically easier to build and ship software. That’s genuinely great. But it’s also created a generation of apps that are optimized for launch and completely unequipped for the day after. When the spike comes, will you be able to handle it? Will you be able to keep those users?

Engagement infrastructure isn’t a growth hack. And it’s not a heavy implementation. It’s a single SDK, set up in minutes with Cursor, that is plumbing you’ll be happy you implemented before the water starts to run.

If you’re building something right now, set up OneSignal before you post it to Reddit. Your future self (the one staring at the analytics dashboard at 2 AM, watching the numbers climb) will thank you.

AI filtering is increasingly sitting between the send button and the notification tray. Whether it’s  on iOS or in Gmail, mobile teams are finding that AI-mediated operating systems are starting to decide what gets surfaced and what disappears. Our 2026 State of Customer Engagement Report found that 48% of teams are already monitoring its impact on reach, and 17% say it's actively affecting deliverability right now.

Behavior-triggered messages are outperforming standard sends by up to 9x on CTR. Teams using automated cross-channel journeys are getting better results while sending fewer messages.

We brought in three mobile engagement experts practitioners and asked them to pressure-test the findings against what they're actually seeing:

• Baris Girgin, Associate Director of UA at Zynga
• Yarin Ben Yaakov, Product Manager at Candivore (creators of Match Masters)
• David Reyneke, Founder of Wallabout Collective

Here's what stood out.

The first session is a deal you're making, not a tour you're giving

The report finding that 75.8% of teams say push has the greatest impact on retention in the first 30 days after install tends to get filed away as validation and moved on from. The panel's point was that it's actually the starting premise for a harder question: what does that window actually require of you?

Yarin, whose team recently overhauled Match Masters' onboarding experience, made the distinction between educating users and qualifying them, and why the difference matters more now than it used to.

"We understood something: the players coming in are different types. Some are experienced in casual games. Others are completely new to it. Because of that, we wanted to give the player the opportunity to either play the tutorial or ignore it completely. And then we want to address that when we talk to them through push. If a player ignored the tutorial, it doesn't make sense to mention it in the message. But if they started it or completed it, it makes a lot of sense to talk about the mechanics they learned… rather than sending a generic push notification that doesn't relate to what they experienced."

Baris framed his team's approach similarly, except the sequencing starts even earlier, at the ad level.

"We have ads that cater toward different motivations. Some people like the challenge. We try to create an experience that's a bit more challenge-focused in the beginning of their journey. And then we try to shift that into the communication as well. We try to showcase areas where users can actually gain value from push notifications before we ask them to opt in. In this way, we can create an initially transactional relationship, where we're sending notifications that are beneficial to the user."

David's version of this came from client work, specifically a meal plan app called Homemade Method that solved its content problem by not trying to create content at all.

"Most of their content is inspired by what's being generated by their own Facebook community. Instead of trying to figure out what content to build, they're basically using the community to build the content strategy for them. You insert yourself into a conversation that's already going on."

The through-line:

The most effective early experiences are the ones that reflect the user back to themselves. Whether it's matching your first push to what someone actually did in their first session, building your ad creative around the motivation that brought them in, or letting your own community tell you what content to make, the teams seeing the strongest early retention are mirroring rather than broadcasting.

Segmentation is both an inclusion and an exclusion problem

Our data shows behavior-triggered messages outperform standard sends by 4–9x on CTR, but that stat tends to focus attention on the messages you should be sending. What the panel spent more time on was the messages you should be holding back.

Baris described his team's approach to segmentation in terms that flipped the default framing:

"One great approach to segmentation is using dynamic tags that are constantly being updated based on player activity and preferences. That way we can identify what the player engages with the most and create segments around that.

But on the other hand, we can identify what they least engage with, and we would know that a push notification about something they don't interact with won't deliver value. So we can exclude them from receiving that push. It's not only about including players. It's also about excluding players we know it's not relevant for."

Yarin added a nuance that doesn't come up often enough: timing against global live events.

"Our game operates globally. If we start an event for the player base, we start it for all of them at the same time. The push notification tells a player there's an event going on. But the event might start when it's the middle of the night for that player. So we have to be cautious and suppress those notifications for players in that situation.

Even though it's relevant in the moment, it might not be relevant for them, because they're sleeping. And if we send it later, they might have already woken up and seen the event anyway."

David summed up the longer-term version of the same problem: what happens when your segment definitions stop reflecting reality.

"Over time, there are people who have been around for ages and there are people that have been around just for a year, and their initial experience with the app is drastically different. Some people love old school programs. Others are more interested in trying new things. We're constantly trying to re-evaluate the audience and figure out new ways to offer different things that might be more personalized, and just being realistic that not everyone is going to be the same 'active customer.'"

The through-line:

A segment is only as good as its exit logic. Knowing who to message matters, but knowing who to leave alone (and when) is what separates relevant communication from the kind that quietly trains users to tune you out.

AI is an amplifier. Don't ask it to be the voice.

Our report found that 65% of teams are experimenting with AI in their messaging workflows, but only 8% have fully operationalized it. The panel's experiences help explain the gap.

David, whose agency has shifted from a marketing shop to what he now calls a "general tech solutions consultancy," described what AI has genuinely changed, and what it hasn't.

"We are able to cast a much wider net and test a lot more variants and figure out where our human-limited amount of time should actually be spent adding the most value. But I don't think AI is as useful for building full copy and creative. It should be used more as a signal, something that supercharges your efforts. It can't be fully depended on as a marketing function. We still need a human touch to everything, or it comes off as very disingenuous when customers start to feel too much AI coming at them."

Yarin's team uses it specifically to solve a problem that's more practical than philosophical: notification blindness.

"If we use the same variety of content, the player might develop some sort of blindness to it — they see the same message type or the same text over and over, and at some point they'll ignore it. One way to mitigate that is to create a larger variety. It's either you hire a full-time copywriter and a graphic artist, or you use AI tools to enhance.

But make sure there's a human somewhere along the funnel to make sure it stays relevant and doesn't lose context. It can also be quite risky in localizing. If you don't know what you're reading, you don't know how it relates to what you're trying to say."

Baris described the same logic applied to localization (using AI to move fast on testing without waiting two weeks for a translation agency) while flagging the same caveat: human review is non-negotiable when you can't verify the output yourself.

On LLMs specifically, David made the case for using them as a data activation layer rather than a content layer.

"We're using LLMs to query the data we're already collecting on our customers to create much more hyper-targeted smaller segments, and pretty much anyone on the team is empowered to do that now. There's not as much back-and-forth with an engineer or data scientist. Everyone is able to work across all these different functions and apply it to their specialty."

The through-line

The teams getting the most out of AI are using it to make better decisions about what to test, who to target, and where human judgment is actually needed.

The bet everyone is making on the next 12 months

We closed by asking each panelist the same question: if you had to bet on one thing that will matter most for engagement over the next year, what would it be?

They all landed in the same place, each from a slightly different angle.

David:

"I think we finally have tools to make personalization a reality and to scale it. The way that you treat each individual customer is going to be how you take advantage of the future of your business."

Baris:

"Technology changes quite fast, but human nature and how we behave doesn't change as fast. At the end of the day, what we try to do is build a relationship with the user. The relationship is about first providing value and earning trust, and then becoming a place they choose to spend their time, because everybody has limited time. It's a privilege to have people come to your game and spend an afternoon there. Personalization is how you show them you understand the value of that."

Yarin, who spent much of the session talking about the mechanics of onboarding and segmentation, pointed to something more fundamental when asked to zoom out:

"The one thing that is most relevant to all players is that they are primed to look for gifts, freebies, discounts… whatever free thing they can get. This is the one thing that always delivers on the promise. Use it as much as possible."

It's a reminder that even as the infrastructure around messaging gets more sophisticated, the reason users engage hasn't changed much. They want something that's worth their time.

Want to go deeper on the data behind these conversations? Download the 2026 State of Customer Engagement Report for the full benchmarks, trend analysis, and channel-by-channel breakdowns. Or watch the full webinar to hear the panel discussion in their own words.

A technical explainer on permissions, privacy, and who decides what your app can do.

There’s a conversation happening right now about a government app and its use of location data.

OneSignal’s SDK has been named in that conversation, so we want to do what we always do: be transparent, be technical, and be clear.

Here’s how location works in our SDK.

Location is off by default

OneSignal’s SDK does not collect location data out of the box. Full stop.

For location to be active in any app using our platform, two separate things must happen, both of which are outside of OneSignal’s control:

1. The developer must explicitly enable it. Location collection is a feature that app developers choose to turn on. It requires adding specific permissions to their app’s manifest (Android) or Info.plist (iOS), and then calling our SDK’s location methods in code. If a developer never enables this, the SDK never asks for or touches location data.

2. The user must grant permission at the operating system level. Even after a developer enables location, the user’s device will present a native system prompt — controlled by Apple or Google, not by OneSignal — asking whether the app can access their location. The user can say no. They can say “only while using the app.” They can revoke permission at any time in their device settings.

This is how every modern mobile SDK that supports location works. It is a double opt-in system: developer opt-in, then user opt-in.

What happens when location is enabled

The location data is associated with the user’s device record within the developer’s OneSignal account. It is not sold. It is not shared with third parties. It is not used for purposes outside of the developer’s own messaging campaigns.

The developer decides. The user confirms.

The key distinction in this conversation, and in any conversation about SDK-level data collection, is who makes the decisions.

OneSignal provides tools. We don’t make the choices about how those tools are used in any individual app. The developer decides which features to enable. The operating system enforces user consent. And the user has the final say.

This is true of virtually every major SDK in the mobile ecosystem — analytics, crash reporting, attribution, push notifications. The SDK provides capability. The developer activates it. The user approves it.

What we believe about privacy

We’ve built OneSignal around a principle: give developers powerful engagement tools, and give users control over their experience.

That means:

• Location is off by default and requires deliberate developer action to enable.
• We respect the permission frameworks that Apple and Google have built to protect users.
• We do not sell user data. Period.
• We publish clear documentation on every data point our SDK can collect, and how to configure it.
• Developers can disable location collection entirely with a single line of code.
  

We believe that transparency is the best response to any question about data practices. Not vague reassurances, but documentation, code samples, and clear architecture.

A note on the broader conversation

When any app, government or otherwise, makes choices about what data to collect, those choices deserve scrutiny. That scrutiny is healthy. It’s how the ecosystem gets better.

But it’s important to distinguish between the tool and the implementation. A push notification SDK that supports location-based messaging is not, in itself, a surveillance mechanism — any more than a database is a surveillance mechanism because it can store personal data.

The questions worth asking are: Does the app need this data for its stated purpose? Is the user clearly informed? Can they opt out? Those are questions about app design and policy, not about the underlying infrastructure.

Read the docs

We publish everything. If you want to understand exactly how our SDK handles location, down to the API calls and configuration flags. Here’s where to start:

Location Opt-In Prompt Documentation

Mobile SDK Location Reference

Privacy & Personal Data Overview

We’d rather you read our docs than take our word for it. That’s kind of the point.

OneSignal is the customer engagement platform trusted by one in four app publishers to deliver push notifications, email, SMS, and in-app messages. We believe great messaging starts with user trust.

Six months ago, most marketing teams had AI filtering on their "things to watch" list. Then iOS 26 shipped expanded notification summaries, Gmail started routing messages through Gemini before users ever open their inbox, and the "things to watch" list suddenly became much more immediate.

A new layer of infrastructure, AI filtering, is making decisions about your messages before your customers ever do. How much of your audience is actually seeing what you send? Which channel still has the biggest impact on long-term retention? Is a 9x lift in engagement actually possible, and what's the one variable that explains it?

The 2026 State of Customer Engagement Report is officially out, and aims to equip senders with answers to all of those questions. It's built on aggregated data from the OneSignal ecosystem, billions of messages sent across push, in-app, email, SMS, and RCS, combined with a survey of marketers and product teams across industries.

Download the Report

What follows are the stats that shaped this year's findings, and what they mean for the way you build in 2026.

48% of marketers are already concerned about AI- filtering deciding which messages get seen. 17% say it's already impacting deliverability.

→ What it means

The old assumption that a sent message is a seen message no longer holds. Teams that are still measuring success purely by send volume or open rate are optimizing for a metric that's increasingly disconnected from actual engagement.

The shift this report calls out isn't "should you care about AI filtering?" It's how quickly you build messaging strategies that hold up under it.

Behavior-triggered messages outperform standard sends by 4–9x on CTR.

→ What it means

This is the widest performance gap in this year's data, and it isn't close. A message that arrives because something just happened (a search, a purchase, an abandoned step) earns attention in a way that a scheduled broadcast doesn't, because it maps to a moment the user is already in.

In an AI-filtered world, this structural advantage only grows: messages tied to real behavior signals are more likely to clear OS-level prioritization filters, because they look like what they are: immediately relevant. Teams still running mostly scheduled sends have a clear, high-ROI optimization in front of them.

75.8% of teams say push has the greatest impact on long-term retention in the first 30 days after install, more than email and in-app combined.

→ What it means

The first month is still the fight that matters most. Push isn't losing ground as a retention channel… but the standard for what a good push looks like has risen. Before a notification reaches a user, operating systems are increasingly summarizing, grouping, and suppressing. Which means the first 30 days have become about building an “attention credit score”: demonstrating to the OS, and to the user, that your notifications consistently lead somewhere worth going.

45% of mobile teams are actively exploring or planning RCS adoption in 2026.

→ What it means

RCS is no longer an "eventually" conversation. What the report makes clear is that the teams moving on this now are first in line to earn this new relationship surface. RCS turns the inbox from a place where messages arrive into a place where customers now enjoy a conversational and app-like experience. The expectations for text marketing are about to soar.

63% of teams using automated Journeys report better results with fewer messages sent. 78% report higher revenue from users included in Journey flows.

→ What it means

Automated sequencing is how teams at any size get compounding returns without compounding effort. The data here runs counter to the instinct to "send more." The teams reporting better performance aren't sending more at all; they're sending in the right order, stopping when the job is done, and letting behavior drive when the next message goes out.

The lift is consistent: among teams that can tie Journeys to revenue, the majority are seeing double-digit improvements.

65% of teams say they're experimenting with AI in their messaging workflows. Only 8% have fully operationalized it.

→ What it means

The experimentation phase is widespread, but real integration is rare. That gap makes sense, since AI is arriving faster than most teams can build the governance around it.

The clearest early wins are in low-stakes, high-frequency work: subject line testing, copy variants, send-time optimization. The longer-term promise, AI identifying when a message is warranted versus when silence is better, is where the real leverage sits, and most teams aren't there yet.

Even more insights in the full report…

The 2026 State of Customer Engagement Report not only includes expanded tactics and frameworks for the above findings but also industry-level benchmarks for:

• Push opt-in rates
• Session duration
• 1/7/30-day retention
• Annual churn rates

Download the 2026 State of Customer Engagement Report →