A campaign calendar should change the first hypothesis in an anomaly investigation, not decide its conclusion. Record what changed, where its effects should appear and when those effects should end. Then compare the alert with that expectation. A planned email launch can make a traffic spike unsurprising while leaving its size, an organic decline or a checkout problem unexplained.
Test gradual deterioration by injecting a labelled decline into a separate copy of the monitoring data, fixing the detector settings, and recording the first alert against a deadline chosen beforehand. Keep stable and sudden-drop tests separate. A detector can catch a crash yet miss a decline that never crosses its single-day threshold.
Choose an alert threshold by comparing the consequences of missed incidents with the work created by alerts, then reject any setting that breaks a critical-incident or investigation-capacity limit. The quietest setting is not necessarily the least costly. A threshold that suppresses routine warnings can also suppress the one interruption that needed immediate attention.
A sparse-data detector needs an explicit way to say that it lacks enough evidence. A clean alert log can otherwise conceal unscored incidents, uncertain baselines and missing observations. Evaluate the counts and exposure behind each decision, then report false alerts alongside missed events and abstentions. A threshold alone cannot establish that the system is ready to act.
A conversion rate of 7% in two consecutive weeks does not clear every checkout path. One group can deteriorate while another improves enough to leave the total unchanged. To detect that failure, compare each eligible segment with its own baseline and retain its alert even when another segment offsets the loss.
An overall conversion rate can fall even when no channel performs worse. It is a weighted average: channels supplying more sessions contribute more to the total. Before changing a landing page or cutting a campaign, hold the channel mix constant and compare the channel rates. Then separate the observed change into a mix component and a within-channel rate component.
A low event count does not tell you whether tracking stopped. Locate the first stage where the same expected events disappear. If matching events have been processed but are not yet visible in the selected report, investigate reporting latency or report selection. If eligible business actions continue but their events are not emitted, waiting for a dashboard refresh cannot recreate them. Events emitted but still waiting for delivery are a third condition, not proof of either a reporting delay or permanent loss.
A public sample catalogue should show what happens to bad shopping data, not merely display a clean export. ScaleGrowth can make the demonstration useful by releasing a fictional input file, the mapping rules, row-level diagnostics and a corrected output together. The decisive condition is reproducibility: another person should be able to recover the same rejected rows and the same mapped values from the retained files.
Before connecting a commerce integration, separate two decisions: whether the merchant can support the selected shopping task, and whether the destination platform has approved that merchant and integration. A complete catalogue, a working application programming interface (API) or an account connection cannot answer both. Start with a bounded objective, request the records that could disprove readiness, and keep platform status in a separate field.
A supported currency does not establish a supported market. An agent may request euros for an item that a merchant will sell in Germany but not deliver to France. The useful boundary test is whether the merchant resolves the actual destination, checks that market's catalogue and returns the correct price or refusal. A plausible currency code is not enough.