Compound identity

A notification ID can repeat. Which supplied fields keep the records apart?

Start with package + ID, then expose distinct tag and user tuples hidden inside that weak group. Missing group-key and post-time fields remain warnings rather than guessed values.

Quick answer

Package plus notification ID can be too weak for deduplication

An Android notification ID is meaningful inside an application’s notification operations, but a diagnostic listener may also expose a tag and user or profile context. If two supplied rows share package + ID while their tag or user aliases differ, treating the weak pair as one universal dedupe key can collapse legitimate records.

The included example contains three rows with the same package alias and ID. Adding the supplied tag and user aliases reveals three stronger tuples: one room record in the personal profile, one direct record in the personal profile and one room record in the work profile. The worksheet reports one weak collision group with three distinct stronger identities. It does not claim that this tuple is universally complete for every Android version or listener.

Browser-local worksheet

Inspect weak and stronger identity tuples

This is a collision worksheet, not a universal Android dedupe-key generator. Your listener version and event source still determine which fields are available and meaningful.

Aliases only · no device access

Ten comma-separated columns: sequence, origin (callback/snapshot), package alias, notification ID, tag alias, user alias, group key, summary flag, optional post time, observed time. Use short aliases—never paste notification text, names, phone numbers or account data.

No diagnosis yet

The worksheet does not connect to Android, Tasker or AutoNotification. It classifies only the identity rows shown above.

Weak grouppackage + notification ID is useful for inspection but may combine legitimate records.

Stronger tupleThe worksheet adds supplied tag and user aliases, leaving absent fields explicit.

Separate dimensionsGroup key, summary state and post time are displayed as diagnostic context, not silently promoted into one universal key.

Use only fields your listener actually supplies

Keep package aliases consistent across the trace and retain the numeric or redacted notification ID. Add a stable tag alias when the source distinguishes tags. Add a user or profile alias when the capture exposes that boundary. A blank value remains blank; Replay Trace does not copy another row’s field or invent a default identity.

Group key, group-summary state, post time and observation time are displayed as separate diagnostic dimensions. They can help explain lifecycle behavior, but automatically concatenating every available value creates a brittle key that may change for an ordinary update. Start by finding where the weak pair collides, then inspect the smallest documented field set relevant to the current source.

A collision is not automatically a duplicate

Same weak pairPackage + ID matches, so a two-field map would place the rows together.

Different supplied contextTag or user aliases produce more than one stronger tuple inside that weak group.

Decision still externalThe worksheet does not know notification meaning and cannot authorize suppression.

Test a proposed key against new posts, updates, grouped children, summaries and multiple Android profiles. Log the key and the action outcome with harmless data before using it to prevent a task from running. A key that stops an apparent replay may also hide a legitimate update if its lifecycle assumptions are wrong.

Choose the next diagnostic view

Use the callback timeline when the question is whether a repeated identity looks new, replayed or updated. Use the batch multiplicity worksheet when several activations share an observed time. The method page lists the exact bounded rules and failure conditions.