Notification Grouping & Batching
Why it matters
One notification per like scales linearly with your viral posts — a post with 500 likes creates 500 bell pings, and the user stops opening the app. Grouping collapses that into 'Alex and 499 others liked your post,' which preserves the signal without the noise. Without batching, push-notification open rates crater, email digests become unreadable, and heavy users disable notifications platform-wide rather than per-type, which you cannot recover from.
Severity rationale
Medium because ungrouped notifications actively drive users to disable the channel, which is hard to reverse.
Remediation
On notification creation, upsert into an existing unread row keyed by (userId, type, targetId) — append the new actor to an actorIds array and increment similarCount instead of inserting a new row. Render the grouped form as 'FirstActor and N others your post.' See the notification creation path:
const existing = await db.notification.findFirst({ where: { type, targetId, userId, readAt: null } })
if (existing) return db.notification.update({ where: { id: existing.id }, data: { actorIds: [...new Set([...existing.actorIds, actorId])], similarCount: existing.similarCount + 1 } })
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Social Features & Engagement Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from community-social-engagement·automated