A rise in mentions should trigger human review when it exceeds normal variation for a comparable period, the collection is healthy, and planned activity does not explain it. Give potentially serious individual posts a separate review route. Treat missing data as a collection problem, and send repeated mentions of the same issue to one owner.
Social listening alert thresholds need these conditions written down together. A percentage increase alone cannot tell a launch from an unexpected complaint cluster. The policy below is a starting recommendation. Its numbers are hypothetical choices, not platform rules or industry benchmarks.
Define the count before setting its limit
Write one sentence specifying what the alert counts. For example, count unique public posts matching a saved brand query, by publication time, within a fixed hourly window. State the timezone, sources, languages, query version and treatment of reposts. Keep original posts and amplification counts separate if both matter.
A count describes the material your collection can retrieve. It does not measure the views of all customers. X's search documentation, for example, distinguishes recent search covering seven days from full-archive access. It also documents pagination and developer-account prerequisites. An unfinished retrieval or an unavailable historical window cannot support the same comparison as a completed one.
For each source, retain:
- The latest successful collection time and the period it covers.
- Whether all result pages were retrieved or a limit interrupted collection.
- Query and access changes that could alter the count.
- Publication timestamps separately from collection timestamps.
Before tuning an alert, remove duplicate posts from the listening sample. Otherwise, changing collection behavior can look like a change in conversation.
Compare periods with similar activity
Build the reference history from comparable windows. Separate working hours from overnight hours where their patterns differ. Compare a launch window with previous launch activity when suitable history exists. Keep source coverage and query definitions consistent.
Record the middle of the historical counts and their spread. A feed that often varies between low and high counts needs a different limit from one that stays close to its middle.
NIST's control-chart guidance explains that threshold placement changes the risk of investigating ordinary variation. It also shows why distribution shape matters. A multiplier chosen for convenience does not create a known false-alarm probability.
For a starter policy, combine a relative increase with an absolute floor and an allowance above previously observed variation. Test that policy against saved periods before enabling notifications. Where history is sparse, mark the baseline provisional and use scheduled human review rather than presenting the threshold as validated.
Hypothetical threshold calculation
Suppose eight comparable, healthy, non-campaign hourly windows contain the following unique-post counts. This small set demonstrates the arithmetic; it does not establish a reliable long-term baseline.
| Input | Hypothetical value |
|---|---|
| Historical counts, sorted | 12, 16, 18, 20, 20, 24, 28, 32 |
| Baseline B, the median | 20 |
| Observed upper count U, the maximum | 32 |
| Relative threshold, 2 times B | 40 |
| Variation allowance, U plus 10 | 42 |
| Absolute floor | 30 |
| Review threshold, largest of those three thresholds | 42 |
Under this illustrative rule, send a volume-review alert after two consecutive healthy hourly windows each exceed 42 posts. A count of 42 itself does not exceed the threshold. The persistence requirement delays review, so use it only where that delay fits the team's response needs.
The historical maximum is a rough reference, not a statistical upper confidence bound. A single unusual historical window can raise it too far. Inspect that history, record exclusions and test other windows before adopting the rule. Freeze the chosen baseline during an active issue so that rising counts do not automatically raise the threshold.
Write separate actions for spikes, campaigns and gaps
Sprout Social's listening-metrics article treats mention volume, sentiment and campaign performance as separate measures. Apply that distinction when deciding what deserves an interruption.
Before a campaign starts, record its dates, expected posting schedule, keywords and reviewer. Label campaign-linked posts while keeping them visible. Scheduled activity may explain extra mentions, but it does not explain away the content of a complaint.
The following cases use the hypothetical threshold above. The campaign row is a separate scenario; the 48 and 52 rows are consecutive windows.
| Case | Observed result | Team action |
|---|---|---|
| Ordinary variation | 28 posts, collection complete | Keep in the digest |
| First elevated window | 48 posts, collection complete | Record a pending volume signal |
| Persistent increase | Next window has 52 posts | Notify the listening reviewer once |
| Planned campaign | 90 total: 72 campaign-linked, 18 other | Campaign reviewer checks content and plan; assess the 18 separately |
| Collection gap | Source collection failed; no trustworthy count | Notify the data owner; label coverage incomplete |
| Recovery import | Older posts arrive after an outage | Assign posts to publication windows; do not count the import as a new spike |
The campaign split accounts for every post once: 72 plus 18 equals 90. Decide classification rules before using that split, and leave uncertain posts visible for review. If comparable campaign history is unavailable, ask the campaign reviewer to assess the rise rather than silently disabling alerts.
Missing data needs its own state. AWS's alarm documentation distinguishes missing observations from observations above or below a threshold. Its setting depends on the metric and purpose. For mention monitoring, an unsuccessful collection should remain unknown rather than becoming a zero.
Continue reviewing healthy sources separately during a partial outage. Do not close an existing issue because the combined count fell while one source disappeared. Explain the affected source and time range using a listening coverage-gap note.
Send one review request with enough evidence
Assign one named role to volume alerts, one to collection failures and one backup for each. Define staffed hours and the response expected outside them. Do not imply continuous coverage if nobody owns it.
A useful notification contains the source set, time window, query version, current count, baseline, campaign label and collection status. Include links to the posts driving the change and a specific request: check relevance, duplicates and whether the change needs escalation.
Create one issue record for the same topic and time period. Add later windows to it rather than sending a fresh notification for every breach. Set a reminder if nobody acknowledges it. Reopen or escalate when new evidence changes severity, even while repeat-volume notifications remain suppressed.
Keep a separate route for a potentially serious individual post under the organization's existing safety or incident procedure. It should not have to accumulate enough mentions to cross a volume floor. Human review determines what the post establishes. Use the verification procedure before escalating a potential brand issue.
At each policy review, record which alerts required action, which repeated known information, and which relevant changes people found without an alert. Review missed cases as well as notification volume. For the next monitoring period, choose one query, name its reviewer, and replay the policy against a normal window, a campaign window and a collection gap before turning notifications on.
