← Blog · July 30, 2026
A Firebase push token database that has never been pruned tends to overstate your reachable audience by 20–40% within a year. Tokens accumulate from uninstalls, app data clears, OS upgrades, and device migrations — and Firebase never proactively tells you which tokens are dead. You find out at send time, when the FCM API returns messaging/registration-token-not-registered on specific tokens in the response.
Prune on send, not on a schedule. A scheduled prune requires you to attempt a delivery to find out a token is invalid — you end up either sending fake pings to test tokens (which counts as a send and can confuse analytics) or calling a validation API that FCM does not officially expose at scale. The send response already gives you exactly the information you need: process the per-token error codes after every broadcast, immediately delete tokens that return a permanent error, and update lastSeen for tokens that delivered successfully.
FCM's sendEachForMulticast API accepts at most 500 tokens per call. A broadcast to 50,000 devices requires 100 sequential or parallel FCM API calls. This is often the first thing that breaks when a push service grows — a naive implementation that sends one batch works fine until it does not. Handling partial failures, collecting error codes per token, and retrying transient errors without duplicating successful deliveries is non-trivial to get right.
Treating all tokens as interchangeable ignores real behavioral differences. Web push tokens (VAPID-based) have different delivery characteristics and opt-in rates than Android FCM tokens. Test device tokens used during development should not be in the same send pool as production users. Segmenting by platform, environment, and recency (active in the last 7 or 30 days) lets you build audience estimates that reflect real reach rather than total stored tokens.
Pushbrain tracks platform, environment, last-seen timestamp, and a test-device flag on every registered token. The Health tab for each app shows active-7-day, active-30-day, stale, and reachable-estimate breakdowns so your device count reflects what you can actually reach, not just what has been registered.