Overview
Observer monitors exist to catch analytics problems before a human notices the numbers look off. A monitor pulls a metric from GA4 or Adobe Analytics on a schedule, compares it to a threshold, and sends an alert if the condition is breached. Common use cases are "fire an alarm if daily sessions drop below baseline," "page me if conversions tank," or "let me know if a critical event stopped firing entirely."
Because Observer checks at a fixed cadence, it's not a real-time firehose. It's a scheduled health check that catches the kinds of problems (broken tags, bot surges, tracking regressions) that matter over hours and days rather than seconds.
Navigate to Monitors
Open Observer > Monitors from the left sidebar. You'll see a list of every monitor on your property, including its current state, the last time it ran, and whether the latest check passed or triggered an alarm. Click Add Monitor to create a new one.
Select data source
Pick the source: GA4 or Adobe Analytics. GA4 monitors use an OAuth connection against the GA4 Data API. Adobe Analytics monitors use per-property credentials configured in your service connections, so you'll need to set those up in advance if Adobe is a new source for this property.
Enter the property ID or report suite that scopes the query. This determines which data the monitor can see. For GA4 that's a numeric property ID; for Adobe it's a report suite ID.
Define the metric
Choose the metric you want to track: sessions, conversions, revenue, events, or whatever matches the behavior you're watching for. Pick an aggregation: SUM for totals, COUNT for occurrences, AVG for averages, and MIN or MAX when you care about extremes rather than central tendency.
The right metric depends on what failure mode you're trying to catch. Use sessions to detect traffic drops, conversions or revenue to detect funnel breakage, event counts to detect a specific tag going dark. A monitor should target exactly one failure hypothesis; if you want to watch multiple things, create multiple monitors.
Set the threshold
Define the condition that constitutes an alarm. Observer supports the usual comparison operators: greater than, less than, equal to, not equal to. A threshold like "sessions less than 1000 per day" catches traffic drops; "conversion rate less than 5%" catches funnel degradation.
Set the threshold at a level that represents real trouble, not normal fluctuation. Too-tight thresholds produce noisy alerts that get ignored. Too-loose thresholds miss incidents until they're already severe. Look at a few weeks of historical data and set the value at the bottom of the normal range, with a small cushion.
Choose a schedule
Decide how often the monitor runs: Hourly, Every 4 hours, or Daily. Pair the schedule to the metric's volatility. A revenue number can be checked daily because daily swings are the meaningful unit; a real-time event count might deserve an hourly check so outages are caught faster.
Set the timezone so thresholds evaluate against the right local day boundary. A "daily sessions" check that reads the wrong timezone will report the first hours of the new day as a catastrophic drop every morning.
Save and activate
Save the monitor. Observer starts running it on the schedule immediately. When the threshold is breached, the configured notification group receives an email with the metric value, the threshold, and a link back to the monitor detail page so anyone who responds can see historical context.
Alarm deduplication prevents alert fatigue: the same alarm won't fire again for 25 hours, so a single ongoing incident produces one email, not one per scheduled check. Monitors auto-disable after 5 consecutive failures (for example when API credentials expire) so broken monitors don't silently spam you. Check the historical trend view periodically to spot gradual degradation that wouldn't breach the threshold on any single day.
Troubleshooting
Monitor auto-disabled after a credentials change
Five consecutive failures trigger auto-disable. Usually this means the OAuth token expired or the Adobe credentials were rotated. Fix the service connection in Settings > Service Connections, then re-enable the monitor from its detail page. It will start running again on the next scheduled tick.
Alert fired but the metric looks fine in the analytics UI
GA4 finalization lag is the usual culprit: the API can return lower numbers for recent windows than the GA4 UI shows because data is still being processed. Consider moving the monitor's lookback window back by 24 hours, or switch from hourly to daily to let GA4 settle before evaluation.
Threshold never fires even though metric clearly breached
Verify the metric and aggregation match what you expect. Sessions with SUM is a running total, not a per-day count. Check the monitor detail page's run history to see the actual values the check computed; if they don't match what you see in GA4, the query shape or the property ID is probably wrong.