Criteria for choosing an operating model
Consider an app that sends a push notification when an order changes status. Marketing asks to “send only to customers who signed up but have not purchased, and stop follow-up messages once they buy.” If selecting recipients, changing sending rules and checking results all depend on the development team's schedule, the decision now extends beyond a push API.
Direct operation centered on FCM is reasonable when transactional notification rules are stable and developers can handle changes, monitoring and incidents. When campaign owners frequently change audiences, timing and follow-up actions, there is more reason to consider the operational tools in a platform such as OneSignal. A hybrid can preserve existing transactional notifications while introducing a platform for marketing. This decision depends on the work and responsibilities involved, rather than a user-count threshold.
However, “FCM is only for developers, while a platform needs no development” is inaccurate. Firebase offers Notifications composer for nondeveloper message creation, plus Analytics-based targeting and messaging experiments. OneSignal still requires implementation work such as SDK configuration, user identification and business data integration.[2][3][9][11]
The unit of comparison is the operating model covering delivery, customer data, campaign changes, observability, controls and eventual migration. Before counting features, list who will repeatedly do which jobs after adoption.
Compare options at the same level
Here, “direct operation” does not mean building Google's delivery infrastructure. It means using FCM and the necessary Firebase components with your own backend and operating procedures. FCM supports Apple platforms and the web as well as Android, and requires both a sending server and receiving clients.[1][4]
Notifications composer means that not every message has to be sent through code. But console targeting and the capabilities implemented through the server API are not equivalent feature for feature. The official documentation scopes Notifications composer messaging A/B tests to Android and iOS apps with Google Analytics integration. Firebase's support for web A/B testing should not be interpreted as identical support for web push messaging experiments.[2][3][21]
OneSignal brings user and subscription information, segments, message creation and Journeys into one operating environment. Its delivery network is not completely separate from FCM, however. Push for Android apps distributed through Google Play uses FCM credentials; Apple platforms require an APNs connection. Apple push sent through FCM also passes through APNs. Using FCM and OneSignal together does not, by itself, provide two independent push delivery networks.[9][10][4][13]
OneSignal Journeys connects app and web push, email, SMS and in-app messages. That combination may be valuable when several channels are required, but it does not eliminate your service's channel setup or data integration. Availability for the actual destination country, channel and account must also be checked.[13]
Do not compare a single FCM API with an entire platform. Equally, do not label the whole Firebase ecosystem “FCM” and assume every operational capability is already configured.
From channel setup to campaigns and handover — Connect the SDK and channels, verify key campaigns and hand over an operating setup the internal team can continue.
Build an operating responsibility matrix instead of a feature checklist
The table below is an example allocation of operational responsibilities based on documented feature conditions. “Custom implementation” includes reusing existing systems and configuring or integrating components. “Provided” means the tool exists, rather than that your business rules and operational responsibilities are automatically complete.
| Recurring task | Direct operation centered on FCM | Adopting OneSignal | Responsibility retained by your organization |
|---|---|---|---|
| Maintain app/web integration and receiving behavior | Provided + custom implementation. Use FCM SDKs/APIs while implementing receive handling and registration management.[1][6] | Provided + custom implementation. Use SDKs and platform configuration tools; app integration, FCM/APNs credentials and release verification are still necessary.[9][10] | Development: SDK changes, app releases and configuration management across test and production |
| Connect one customer's devices, channels and business data | Custom implementation. Maintain the connection between membership/business data and recipients. FCM app-instance registration information alone does not constitute a customer model.[1][6] | Provided + custom implementation. Use the User/Subscription model, while implementing External ID links and account switching.[11] | Data and development: identity rules, source accuracy and propagation of changes/deletions |
| Change audiences, copy and schedules; run messaging experiments | Provided / conditional. Use Composer targeting and sending. Messaging A/B tests have Analytics and supported-platform requirements.[2][3] | Provided / conditional. Use segments, Journeys and A/B tests. Check plan-specific availability of required filters, limits and experiments.[12][13][19] | CRM: objectives, audiences, exclusions and outcome criteria. Development: data needed for new business rules |
| Control follow-up messages after purchases or cancellations | Custom implementation. Design how the backend and other components connect events, waiting/exit rules and other channels.[1][2] | Provided / conditional. Custom Events and Journeys are available. Events must still be collected and integrated; paid-plan and feature-access conditions apply.[14] | CRM and development jointly: which facts start or stop a flow, and what to do with delayed or missing data |
| Separate authoring, sending and configuration permissions | Provided + verification needed. Firebase has campaign/API IAM roles. Assess whether they meet internal approval requirements.[8] | Provided / conditional. Organization and app roles exist, with different plan and permission scopes.[15] | Security/operations owners: least privilege, personnel changes and consistency between approval records and actual permissions |
| Collect delivery/response data and connect it to business outcomes | Provided / conditional. Console reports, the Android aggregate Data API and BigQuery paths exist. Distinguish their scope, setup and latency.[7] | Provided / conditional. Use receipt confirmation and event export, checking SDK, plan, platform and retention conditions.[16][17] | Analytics and development: message/business-event joins, denominator definitions and unobserved gaps |
| Diagnose incidents and stop incorrect sends | Custom implementation and operation. Distinguish faults in your sending logic/data path from faults in external delivery services.[4] | Custom implementation and operation + conditional support. Use platform support and contract provisions; internal data/app errors and campaign decisions remain your responsibility.[19] | Service owner: user impact, stop-send authority, internal recovery and vendor escalation ownership |
| Move to another operating model | Custom implementation. Owning your data and code does not remove the cost of changing SDKs, sending paths and procedures. | Provided + custom implementation + verification needed. CSV/API export paths exist. Verify whether the required data remains available and can be reused in the new system.[18] | Technical owner: preserve data/configuration, define rebuilding scope, parallel operation and exit conditions |
Permissions deserve more scrutiny than counting accounts. OneSignal's current role documentation distinguishes Composer, which can author but cannot send or activate production messages, from Editor, which can also send. It lists both roles for Professional and Enterprise plans. This distinction does not replace the complete internal approval process; also check what happens to permissions after a downgrade.[15]
For observability, similarly named metrics must not be treated as identical. OneSignal's Confirmed receipt is a device SDK acknowledgment, unlike Delivered, which means the delivery service accepted the request. Paid-plan and SDK conditions apply, with extra configuration for iOS. FCM also provides reports and data export, so direct operation cannot be classified as unobservable. In either model, distinguish acceptance, device receipt, user response and business outcomes such as purchases.[16][7]
How do three different situations change the decision?
A small app focused on transactional notifications: direct operation may suffice
Design example. The app sends booking confirmations and schedule changes, rules seldom change, and the existing backend holds the required business data. If developers can check sending results and handle incidents, maintaining FCM-centered operation may be simpler. Adding a new customer data model and operating tool for unnecessary multistep campaigns offers little justification.
The reverse can also apply. Even a small app may benefit from a platform if nondevelopers often change copy, audiences and timing and must wait for development each time. First check whether Composer is sufficient, however. Neither “small app, therefore custom development” nor “marketing owner, therefore a separate platform” automatically follows.
A service with frequent campaign changes: focus on how much change work can move
Design example. The team varies follow-up messages for signed-up nonbuyers, customers approaching renewal and customers whose activity has declined. If the data is ready and CRM staff actually operate those scenarios, the range of changes they can make in segments and Journeys becomes the platform's value.[12][13]
But buying a platform without feeding purchase status still leaves staff waiting for developers. OneSignal Custom Events are data sent by apps, websites or external systems. Event collection, Journey triggers and event-based segment filters are distinct features. Event-based segments require event storage to be enabled; official documentation describes storage as rolling out across apps. Verify that the actual account supports the required campaign conditions and storage feature.[14][12][22]
If Composer and internal operating screens already handle the necessary changes, more campaigns alone do not justify an immediate migration. Compare the repetitive work eliminated by the new platform against the new integration and training work it introduces.
An organization with complex data and permission controls: requirements come before scale
Design example. Several business units serve the same customers, authors and senders must be separated, and outbound data must be controlled. Review data paths, access scope, audit and export requirements before campaign features.
A platform meeting the required roles and administrative controls may reduce internal tool development. Conversely, maintaining direct operation can be justified where established internal controls work well and an external platform cannot readily satisfy essential requirements. Remember that direct FCM operation also uses an external cloud delivery service. Sending from your own backend does not mean no data leaves your organization.[4]
The required outcome is agreement on who will verify and own specific data, permission and recordkeeping requirements, rather than a plan labeled “Enterprise.”
Calculate TCO for the same scope, rather than comparing monthly subscriptions
Firebase's pricing page lists FCM as a no-cost product. This does not make backend execution, data storage/analysis or operating staff free. A OneSignal plan name likewise does not determine total cost: channels, billing units, features and support scope must be reviewed together.[5][19][20]
The following is a design example for cost assessment. Apply the same comparison period and service scope to both options, identifying separately what can reuse existing systems.
| Cost group | Inputs to collect | Easily missed question |
|---|---|---|
| Initial implementation and transition | SDK/backend integration, customer identification, event/permission design, testing, operator training and initial data cleanup | What must our team still implement after buying the platform? |
| Monthly platform and infrastructure | Base contract charge, channel usage, execution/storage/query costs and required add-ons | Are send counts being confused with billable audience counts? |
| Recurring operational labor | Time for maintenance, campaign changes, observability checks, incidents and security/access reviews | Have both eliminated and newly introduced tasks been included? |
| Data and support | Event export, retention/queries, external operations support and separate support contracts | Have costs already included in the subscription been counted twice? |
| Parallel operation, shutdown and future migration | Dual operation, subscription/configuration verification, campaign rebuilding and retirement of the previous system | Can necessary data and operating knowledge be recovered when the contract ends? |
For a comparison period of H months, summarize costs as follows.
Total cost over H months = initial implementation/transition cost + platform, infrastructure, operational labor and separate support costs over H months + shutdown/migration costs included in the comparison scope
Calculate labor as “time per task × the organization's hourly cost,” avoiding double counting between initial implementation and monthly maintenance. Keep possible future incident losses and migration costs separate from committed expenditure as scenario items. Assigning a monetary value to time freed by a platform does not necessarily mean cash spending falls by that amount.
When assessing OneSignal costs, do not treat mobile MAU, web push subscribers and email volume as the same unit. MAU in particular is not simply the number of registered members or push opt-ins; current billing documentation describes it using mobile Subscriptions. Match the actual account's billing model and measurement period, including any necessary event storage and export costs.[20]
If you already use OneSignal and are assessing free/paid boundaries or plan changes, the OneSignal paid-plan transition guide provides separate decision criteria. Choosing direct operation versus a platform and choosing a plan within that platform are different decisions.
From customer data to campaigns ready to build — Review data and measurement, then define key campaigns and an implementation sequence around business goals.
Follow this sequence to reach an adoption decision
The following is an editorial decision procedure for putting the responsibility matrix into practice, rather than an official product adoption standard.
First, eliminate options that fail mandatory conditions. List required channels and device environments, data paths, separation of permissions, records and exports. If an essential feature is unsupported or its availability remains unconfirmed, resolve that before comparing prices.
Second, identify what blocks current operations. Distinguish missing sending functionality, absent business data, waits for campaign changes and missing incident ownership. Retain a maintain-and-improve option when existing direct-operation tools and staff can resolve the issue. Do not assume a platform solves every bottleneck.
Third, verify which recurring work the platform actually removes. Reproduce a representative scenario from audience changes through review, sending and result checking. Record what nondevelopers handled independently, what still required development and where required controls failed. For an existing operational system, compare future incremental cost and improvement rather than assuming a complete rebuild.
Fourth, choose direct operation, platform adoption or a hybrid with clear responsibilities. Direct operation needs owners for changes and incidents. Platform adoption needs owners for data supply and campaign operations. No option can replace a missing owner with a tool name.
For a hybrid, transactional notifications can stay in the existing backend while marketing campaigns move first. To prevent both paths from sending the same business notification, first define ownership by event, shared identity rules, opt-out propagation, consolidated observability and exit conditions. These are requirements for the operating design, not automatic consequences of installing two SDKs.
Agree on the work that remains before making the decision
A team has reason to retain direct operation when messaging is narrow and stable, or even when it is complex but existing systems and staff can handle it. A platform is excessive when adoption, integration and learning burdens exceed the operational capabilities the team will use. It fits when campaign owners repeatedly improve campaigns using ready data and can move that change work into the platform.
Choosing the cheapest delivery mechanism or longest feature list does not complete the decision. Separate the work your team will retain from the work assigned to external tools, then compare costs and controls over the same scope. That is the practical distinction between direct FCM operation and adopting a messaging platform.
If platform adoption is decided but SDK/data integration, key campaign verification and operational handover remain undefined, IXC's app push adoption and onboarding service describes the areas to agree on.
