From a finding to a task and a measured follow-up
Understand task deduplication, evidence history, merchant-reported changes, frozen baselines, and the limits of before-and-after comparisons.
On this page
Findings and actions have different statesHow tasks are derivedDeduplication and human decisionsStatuses and evidenceFrozen before-and-after windowsCompatibility gatesWhat a follow-up can claimFindings and actions have different states
Verbesserungen turns supported observations into reviewable work. A suggested action is not a shop edit. An action reported as implemented is not proof that the underlying metric improved. A subsequent compatible measurement provides follow-up evidence, and even that is observational rather than causal.
How tasks are derived
Collectors use stored module evidence to identify an issue and target, such as a product mapping, unanswered buying scenario, or technical finding. Repeated observations update the existing issue rather than creating a new task for every refresh. Optional assistant synthesis is separate from collecting existing facts; it does not require a fresh crawl merely to explain saved evidence.
Deduplication and human decisions
A canonical issue-and-target identity lets a recurring finding retain notes, owner, manually chosen priority, and status. New evidence updates source history and last-seen information instead of erasing the merchant's decision. Concurrent edits use revision checks to avoid a stale browser tab overwriting a later edit. A new observation is not the same event as a new task.
Statuses and evidence
Open and in-progress describe work. Reported or monitoring indicate that a merchant change or follow-up is being tracked. Done is a workflow decision, not an automatic revenue claim. A finding that appears resolved in fresh data still needs the applicable verification before a stronger success statement. Keep the actual implementation date, affected target, source evidence, and notes.
Frozen before-and-after windows
The reviewed follow-up workflow freezes twenty-eight full UTC days before implementation as a baseline, excludes the implementation day, and observes the next twenty-eight full UTC days as follow-up. Changing the implementation date creates a different baseline history rather than silently rewriting the old comparison. Not every source has enough data to populate both windows immediately.
Compatibility gates
AEO and Commerce follow-ups need compatible question versions, model/method, locale, configuration, and formula, plus sufficient eligible observations. The reviewed workflow requires at least three applicable observations for a comparable measurement basis. Search Console follow-up requires complete windows and sufficient impressions; the reviewed minimum is one hundred. Missing coverage or a changed question panel can withhold a delta.
What a follow-up can claim
'The recorded recommendation rate rose by five percentage points in this compatible panel' is an observation. 'This edit caused five points of improvement' needs stronger evidence such as a suitable experiment. Seasonality, model changes, competitors, source updates, and concurrent merchant changes can affect outcomes. If no edit was made, describe the finding and proposed next step without inventing a completed intervention.
Still need help?
Tell us what you expected and what happened.