When to Trigger an Alert

The module flags anomalies automatically. Deciding whether to act on one is a separate judgment. Not every flagged row represents a problem worth escalating. Some are expected seasonal variation, some are noise from low-traffic series, and some are genuine incidents that need immediate attention.

This guide walks through the signals that separate noise from actionable alerts, with concrete examples from the two default cases.

Anomaly detection is not the same as alerting

An anomaly is a deviation from what the model expected. It is a signal that something changed, not a conclusion about whether that change matters.

Alerting is a downstream decision. It applies business context to a detected anomaly and asks: does this require action?

A practical setup treats them as two separate layers. The module handles the first layer. You define the second.

The three checks

Before escalating any flagged row, apply three checks.

1. Is the series reliable?

Look at is_strong_series. A true value means the series had enough history and volume to produce trustworthy signals. A false value means the model has limited data for that series. Flags from weak series carry more uncertainty and should not trigger alerts without additional evidence.

2. How large is the deviation?

Compare metric_value against lower_bound and upper_bound. A value just outside the boundary is different from a value 40% below the lower bound. Large deviations are more likely to reflect a real change; small ones may be statistical noise near the edge of the confidence interval.

3. Does it persist?

Real problems tend to repeat. A single-day anomaly may be a data artifact, a delayed export, or a one-off event. When the same series is flagged on two or more consecutive days, the evidence is substantially stronger.

ga4_events example: purchase drop

You open the Looker Studio template, select ga4_events in the Case filter, and set Is Anomaly? to true. You see the following in the data table:

Date	Time Series	Is Anomaly?	Is Strong Series?	Volume	Lower Bound	Upper Bound
2024-11-14	purchase	true	true	42	98	310
2024-11-15	purchase	true	true	39	101	318
2024-11-14	scroll	true	false	1,204	1,890	4,200

Apply the three checks to the purchase series:

• Reliable? Yes: is_strong_series = true. The model has a solid baseline for this event.
• Large deviation? Yes: volume is 42 against a lower bound of 98, well below the expected range. That is more than a 50% drop.
• Persistent? Yes: flagged on two consecutive days.

Decision: escalate. A purchase event dropping to less than half its expected volume for two days is a high-priority signal. The likely causes are a broken conversion tag, a checkout error, or a campaign that stopped delivering. This warrants immediate investigation.

Now look at the scroll row. is_strong_series = false means the model does not have a reliable baseline for this series. The flag may be real, or it may be noise. Do not alert on this without additional evidence.

ga4_sessions example: organic traffic drop

You switch the Case filter to ga4_sessions. You see:

Date	Time Series	Is Anomaly?	Is Strong Series?	In Training, Not In Detection	Volume	Lower Bound	Upper Bound
2024-11-15	Organic Search	true	true	false	1,840	1,950	4,100
2024-11-15	Organic Social	false	false	true	null	null	null

Organic Search is flagged with is_anomaly = true. Apply the checks:

• Reliable? Yes: is_strong_series = true.
• Large deviation? Marginal: volume is 1,840 against a lower bound of 1,950. That is roughly a 6% miss, close to the boundary.
• Persistent? Not yet: this is the first flagged day.

Decision: watch, do not alert yet. A single-day, near-boundary miss on a reliable series is common. It may reflect a delayed data export, a minor ranking fluctuation, or a quiet weekend. Check again tomorrow. If it repeats, especially with a larger deviation, escalate.

Organic Social tells a different story. in_training_not_in_detection = true means the channel was present during training but produced no data in the detection window. The model synthesizes a placeholder row for it; bounds and anomaly flags are null. This is not a statistical anomaly: the channel has disappeared from the data entirely.

Decision: investigate immediately. A channel present in training that produces no detection data is a stronger signal than a statistical flag. The likely causes are a tracking attribution change, a UTM parameter dropped from a campaign, or a channel that genuinely stopped receiving traffic. This is worth checking even without is_anomaly = true.

When not to alert

Some patterns look alarming but are expected:

• Known campaigns or events. A large paid campaign launch drives session spikes. A sale event drives purchase spikes. If these are planned, they are not incidents.
• Single-day flags on near-boundary values. These are common and usually self-correct.
• Weak series flags. is_strong_series = false rows should not trigger automated alerts without additional filtering.
• Training-window disruptions. If the training period contained a major event (a site redesign, a tracking migration), the model's baseline may be skewed. Review the Training chart in Looker Studio to sanity-check the baseline before acting on detection results.

Next steps

• To build SQL alert logic against the output table, see the Query Library.
• For a full column reference, see the Output Data Dictionary.
• To understand how the model produces bounds and flags, see How Anomaly Detection Works.