Keep the send list tied to valid app registrations

Identify the registration model actually deployed

Checked November 7, 2026, Firebase's registration guide describes FID-based registrations alongside co-supported legacy registration tokens. It recommends maintaining freshness evidence and distinguishes stale from expired registrations. Verify the deployed SDK and server path rather than assuming every app has migrated or that an old token tutorial covers the current integration.

Ask engineering to name the registration model, platform and app release represented in the campaign system. Keep this technical identity separate from the signed-in account and the user's communication choices. A valid route can belong to an app that is now signed out or used by someone else. Use only synthetic placeholders in campaign exercises and share aggregate diagnostics instead of copying real registrations into slides or general-purpose spreadsheets.

Define freshness from an observable event

Record what updates the freshness timestamp: an app-side registration event, a successful upload to the server or another verified signal. A nightly database job that touches every row does not demonstrate that the devices have returned. Ask how a failed upload is retried and how old and new identifiers are reconciled under the actual implementation.

Choose the organization's stale-registration policy with the technical and privacy owners, distinguishing inactivity from a definitive invalid response. Do not import one platform's expiration period into another. Explain the tradeoff between retaining a potentially returning installation and repeatedly targeting an abandoned route. Keep the policy purpose narrow; registration hygiene should not become a reason to gather unrelated behavioral history or revive marketing permission that the user withdrew.

Interpret rejection evidence before removing eligibility

Firebase warns that an invalid-argument response can describe a bad payload, not only an invalid registration. The payload must be known valid before that response is treated as registration-invalid evidence. Ask the technical owner to preserve the error category and relevant sanitized context so a malformed campaign does not cause a mass purge of legitimate routes.

Separate terminal invalidity from temporary provider failure and from an unknown outcome. A timeout is not proof that the registration no longer exists. When a route is confirmed invalid, have the authorized owner retire its sending association through the approved process while preserving any required minimal audit record. Do not delete a customer's account, consent history or valid registrations on other devices merely because one technical address fails.

Test account transitions and reporting consequences

Use controlled synthetic accounts to test sign-in, sign-out, account switching, reinstall or registration refresh as supported by the app. Check that an old account's targeted content cannot follow the device into a different user's session. The correct technical treatment depends on the application, but the acceptance question is concrete: which current account, if any, is this route allowed to represent?

After hygiene changes, compare delivery metrics with the changed eligible-registration denominator visible. A higher rate after removing stale routes is not automatically improved creative effectiveness. Record the policy change and which population was excluded. Recheck associations after SDK migrations or changes to registration callbacks. The result should be an explainable, appropriately protected sending population, not a larger database of addresses whose ownership nobody can establish.

Make the reasoning concrete.

A fictional reading app stores one registration against a subscriber account. A shared tablet changes users, while a malformed campaign payload generates invalid-argument responses for many otherwise active installations.

The app corrects the payload before classifying registrations and tests that the former account no longer receives targeted content on the shared tablet. It keeps real identifiers out of the worksheet.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Model

   Which registration model, platform and SDK path does this record represent?

2. Freshness

   What observed event updates its timestamp?

3. Error

   Is the response terminal for this route, temporary or ambiguous?

4. Association

   Which current account and communication choice may this route represent?

5. Reporting

   How does cleanup change the eligible-registration denominator?

Watch for the wrong conclusion.

• Treating a registration as permanent proof of person or consent.
• Deleting routes for invalid-argument errors without validating the payload.
• Refreshing timestamps without observing fresh app registration evidence.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not supplier implementation instructions or measured business results. Sources support only the specifically attributed platform facts. Supplier controls, contracts and local requirements can change; verify the actual placement and current provider guidance before implementation.

• Firebase: Best practices for FCM registration management →Primary platform documentation · Supports: Supports dated co-support of FID registrations and legacy tokens, freshness and stale/expired distinctions, and invalid-argument caveat. Account association safeguards are original editorial acceptance requirements.