How FCM is built

FCM sits between your server and the user’s device. Your server cannot push a message directly:
there is no direct connection to a particular handset. FCM solves that — it holds persistent
connections with billions of devices and routes messages to them.

Your server → FCM API → Google servers → The device (Android / browser)
                                      → APNs → The device (iOS)

Routing is by push token: the unique identifier of a device inside the FCM ecosystem. At first
launch the app receives a token and must store it on the server.

FCM message types

Type How it appears The app Suitable for
Notification message A system banner, automatically Not required Simple notifications, promotions
Data message The app decides Must be active, or a background service Rich push, custom logic
Combined A system banner plus data A background handler Deep link plus notification

FCM in e-commerce

The usual push scenarios through FCM:

  • Order status. Your order has been handed to the courier — transactional messages, high delivery
    priority.
  • Personal promotions. A discount on a category drawn from the affinity profile. Triggered
    manually or by an automated campaign.
  • Price drop. The price has fallen on an item in the wishlist or recently viewed.
  • Back in stock. An item from the wishlist is available again.

Important: delivery quality depends on several things at once: a current token, the right TTL
and the right priority (HIGH for important messages, NORMAL for marketing ones). Watch the delivery
rate in the FCM console — above 85% is normal.

Token management

The most common technical problem with FCM is stale tokens in the database. How to avoid it:

  • Subscribe to onTokenRefresh and update the token in the database on every change
  • On a NotRegistered or InvalidRegistration error, delete the token immediately
  • Clean out tokens that have not been used for more than three months on a regular schedule
  • Store the date of the last token refresh for diagnostics