Firebase Cloud Messaging

FCM integrates tightly with Google Analytics for Firebase, which automatically tracks notification opens and can trigger sends based on Analytics-defined audiences -- a common pattern for re-engagement campaigns without building custom audience logic from scratch.

Implementation details

Firebase Remote Config and Firebase In-App Messaging are separate, related Firebase products often confused with FCM -- Remote Config changes app behavior/content without a notification, and In-App Messaging shows contextual messages inside an active app session, neither of which is push notification delivery. Server-side sending integrates via the Admin SDK (Node.js, Java, Python, Go, C#) or direct HTTP v1 REST calls, both requiring the same service-account OAuth2 authentication.

Actionable Considerations

1. Use Analytics-defined audiences to trigger re-engagement sends rather than building custom audience segmentation logic separately.
2. Distinguish FCM (push notifications) from Remote Config (app behavior/content changes) and In-App Messaging (in-session prompts) when scoping a requirement, since they're separate products.
3. Use an official Admin SDK for your backend language over raw HTTP v1 calls where available, for simpler auth handling.

FCM itself has no built-in AI -- it's a delivery mechanism, not a content or targeting intelligence layer -- so any AI-driven personalization (predicting optimal send time, generating message copy) needs to come from your own backend logic or a separate Firebase/Google Cloud AI product feeding into FCM's send calls.

Implementation details

Google Analytics for Firebase audiences (which FCM can target) can incorporate predictive metrics like purchase or churn probability if you've set that up separately in Analytics, but that prediction logic lives in Analytics, not FCM. Building an AI-driven send-time optimization layer is genuinely possible using your own historical delivery/open data, but it's custom engineering on top of FCM, not a feature FCM provides out of the box.

Actionable Considerations

1. Don't expect native AI-driven send-time or content optimization from FCM -- treat it as the delivery layer, with any intelligence built separately.
2. Use Analytics predictive audiences (if configured) as FCM's practical entry point for AI-driven targeting, since that's where the prediction logic actually lives.
3. Build send-time optimization as custom logic using your own historical engagement data if you need it, rather than expecting it natively.

Setup means registering your app in a Firebase project, adding the platform-specific config file (google-services.json for Android, GoogleService-Info.plist for iOS, or a web config object), and initializing the FCM client SDK to obtain a registration token for that app instance.

Implementation details

Server-side sending now requires the HTTP v1 API authenticated with OAuth2 access tokens from a Firebase service account -- the legacy server-key-based API was fully shut down in June 2024, so any setup guide or sample code referencing a static server key is outdated. Web push specifically requires generating a VAPID key pair in the Firebase console and registering a service worker, which is a distinct setup step from mobile.

Actionable Considerations

1. Use the HTTP v1 API with service-account OAuth2 authentication for server-side sending, not the retired legacy server-key API.
2. Generate a VAPID key pair and register a service worker specifically for web push, since it's a separate setup path from mobile.
3. Test registration token generation and a real end-to-end send before building broader messaging logic on top of it.

Google retired the legacy FCM HTTP and XMPP server APIs in June 2024, so sending messages now requires the HTTP v1 API, authenticated with short-lived OAuth2 access tokens generated from a Firebase service account rather than the old static server key — integrations still using the legacy key-based calls will fail outright. Each app instance is identified by a registration token rather than a phone number or user ID, and that token can rotate or expire, so apps need to listen for Android's onNewToken callback (or the iOS/web equivalent) and push refreshed tokens back to your server.

Practical Details

FCM distinguishes notification payloads, which the OS displays automatically when the app is backgrounded, from data payloads, which your app code must handle explicitly — mixing the two up is a common cause of messages that "work in the foreground but not when the app is killed." iOS delivery depends on an APNs authentication key or certificate being uploaded in the Firebase console, since FCM bridges Android-style messages through Apple's own push network rather than delivering to iOS devices directly.

Actionable Considerations

1. Migrate any code still calling the legacy HTTP or XMPP endpoints to the HTTP v1 API with service-account OAuth2 tokens, since the old endpoints are shut down.
2. Handle token-refresh callbacks in your app and keep your backend's stored tokens in sync, since a stale registration token silently drops messages.
3. Upload a valid APNs key in the Firebase console and test delivery to killed/backgrounded iOS apps separately, since notification vs. data payload handling differs by app state.

FCM itself is a free, Google-scale service with no per-message cost or capacity you need to provision -- the practical scaling consideration is on your sending side: batching sends via the Admin SDK's multicast methods (up to 500 tokens per call) rather than looping individual API calls per device.

Implementation details

Topics are the practical mechanism for broadcast-scale messaging (sending to potentially millions of subscribed devices with one API call) rather than trying to enumerate individual tokens for a large audience. Message priority (high vs. normal) affects battery and delivery timing tradeoffs at scale -- defaulting everything to high priority undermines battery-friendly delivery for messages that don't actually need immediate wake-up.

Actionable Considerations

1. Use multicast sends (up to 500 tokens per call) or Topics for broadcast messaging, rather than looping single-token API calls.
2. Set message priority deliberately (high only for genuinely time-sensitive messages) rather than defaulting everything to high priority.
3. Use collapsible messages (a collapse key) for updates where only the latest matters, to avoid piling up redundant pending notifications on a device that's been offline.

Firebase Cloud Messaging is Google's free, cross-platform push notification and messaging service, sending to individual devices via registration tokens, to broadcast audiences via Topics (a pub/sub model), or via the Admin SDK's multicast send (up to 500 tokens per call) for batches.

Key benefits

FCM distinguishes notification payloads (displayed automatically by the OS when the app is backgrounded) from data payloads (handled entirely by your app code, delivered even when the app is in the foreground), and mixing these up is the most common source of notifications working sometimes but not others. iOS delivery actually routes through Apple's APNs (FCM bridges to it, it doesn't deliver to iOS devices directly), which is worth understanding since APNs-specific configuration (an auth key uploaded to Firebase) is required for iOS to work at all.

Implementation Considerations

• Use Topics for broadcast-style messaging to segments, and per-token sends for personalized, individual messages -- they're not interchangeable patterns.
• Decide deliberately between notification and data payloads (or both together) based on whether you need OS-level display or custom in-app handling.
• Upload a valid APNs auth key in the Firebase console specifically for iOS delivery, since FCM doesn't reach iOS devices without that bridge configured.

Real engagement measurement for FCM comes from Google Analytics for Firebase's notification open tracking, not FCM itself -- FCM handles delivery, while open/conversion attribution is an Analytics integration layered on top.

Implementation details

Message priority and timing genuinely affect perceived engagement -- a high-priority notification arriving at an inconvenient time (respecting user time zone) tends to drive more opt-outs than a well-timed normal-priority one, so timing strategy matters as much as content. A/B testing subject/body copy and send timing through Firebase's experimentation tools (or your own logic layered on FCM) is the practical way to improve engagement over time, rather than assuming one message format works universally.

Actionable Considerations

1. Track notification opens through Google Analytics for Firebase, since FCM itself doesn't provide engagement analytics natively.
2. Respect user time zones and activity patterns when scheduling sends, rather than defaulting to a single global send time.
3. A/B test message copy and timing rather than assuming one approach works for your entire audience.

The most common real-world issues are messages that display in the foreground but not when the app is backgrounded or killed (a notification-vs-data payload mismatch), missing iOS delivery (an APNs configuration problem), and silent delivery failures from stale registration tokens that were never refreshed on the backend.

Implementation details

Firebase Console's Cloud Messaging section shows delivery reports and can help distinguish a client-side rendering problem from a server-side send failure. The HTTP v1 API returns specific error codes (like UNREGISTERED for an invalid/expired token) that your backend should handle by removing that token, rather than continuing to send to a dead registration.

Actionable Considerations

1. Test delivery specifically to backgrounded and killed app states, not just foreground, since notification vs. data payload handling differs by app state.
2. Handle UNREGISTERED and similar token-invalid error codes by removing that token from your backend, rather than retrying indefinitely.
3. Check APNs configuration first for any iOS-specific delivery problem, since FCM bridges through Apple's push network rather than delivering directly.

Server-side authentication for sending is handled through a Firebase service account's OAuth2 credentials (required by the HTTP v1 API), which should be stored server-side only -- never embedded in client app code, since it grants full send access to your Firebase project's messaging.

Implementation details

Registration tokens themselves aren't secret credentials in the traditional sense (they identify a device instance, not authenticate a sender), but they should still be treated as sensitive data tied to a specific user, stored securely in your backend and not exposed publicly, since misuse could enable spam to that device. User notification consent (the OS-level permission prompt) is a separate concern from FCM configuration entirely, and respecting a user's declined permission means your app should track that state and not repeatedly re-prompt inappropriately.

Actionable Considerations

1. Keep service account OAuth2 credentials server-side only, never in client app code, given the full send access they grant.
2. Store device registration tokens securely on your backend, tied to the correct user, rather than treating them as disposable.
3. Respect OS-level notification permission state in your app logic, rather than repeatedly re-prompting a user who declined.