Dashboard guide
The dashboard is where you build, test, and run workflows. A workflow watches one action, measures whether a follow-up action happens, and decides what to do about traffic that looks fraudulent. This guide covers every configuration field, the workflow lifecycle, and how to read the results of a run.
Configuration
Every workflow is defined by the fields below. Sensible defaults are filled in for you — adjust them to match the action you want to protect.
| Field | What it means | Recommendation |
|---|---|---|
| method | The action you want to watch — the event name you send when a user attempts something, e.g. checkout-attempt or login. | Use the exact event name your integration already sends. This is the traffic the workflow protects. |
| target_method | The desired outcome that follows the action, e.g. checkout-completed. SignalGate measures how often the action leads to this outcome — your conversion. | Pick the success event that legitimate users reach. Genuine traffic converts; abusive traffic rarely does. |
| analysis_window | How far back the workflow looks when measuring conversion and evaluating traffic, in hours. | Start with 96 hours (4 days). Widen it for low-volume actions so there is enough traffic to learn from; narrow it for high-volume actions that shift quickly. |
| conversion_threshold | Shown as a percentage. Roughly, the conversion floor a slice of traffic must clear to be considered legitimate — slices that convert well below it are candidates to act on. | Keep it low (default 0.5%). Values of 3% or higher are aggressive and tend to catch legitimate users — the form warns you at that point. |
| min group size | The minimum number of similar events a pattern must cover before the workflow will act on it. Smaller groups are noisier and riskier to act on. | Default 50. Lower it (floor 10) to react sooner on low-volume traffic; raise it to demand more evidence and reduce false positives. |
| schedule | How often a live workflow refreshes its view of your traffic, e.g. 1h. | 1 hour suits most workloads. Shorten it to adapt faster to changing attacks; lengthen it for stable, slow-moving traffic. |
| action | What happens to traffic the workflow flags:
| The default is block. Prefer to observe first? Start with dry_run_block, then switch to block once the predicted impact looks right. |
| effort | How much compute the workflow spends analyzing your traffic — Low, Medium, or High. Higher effort uses a larger model and more compute per run, going deeper but taking longer. | Medium is a good balance. Use High for hard-to-separate traffic; Low for simple, high-volume actions where speed matters. |
block. That is still safe to create: a new workflow starts as a draft and enforces nothing until you start it — we recommend reviewing its dry-run results before you do. Prefer to observe live traffic first? Switch the action to dry_run_block.The workflow lifecycle
A workflow moves through a small set of states from first draft to live enforcement. The dashboard shows the current state on every workflow.
| State | Meaning | What to do |
|---|---|---|
| draft | Created and configured, but never run. It is not affecting any traffic. | Review the configuration, then start a Dry Run. |
| dry-running | A dry run is in progress. Results aren't ready yet. | Wait — the dashboard refreshes automatically when the run finishes. A run can take a while on large windows. |
| ready | A dry run completed successfully and results are available to review. | Read the run results. If the predicted impact looks right, Start the workflow to go live. |
| active | Live. The workflow runs on its schedule and applies its action to real traffic. | Monitor it. Pause or edit any time. |
| paused | A live workflow that has been stopped. It keeps its configuration but no longer affects traffic. | Start it again to resume, or edit it first. |
Run outcomes
Each run reports an outcome. Here is what each one means and how to respond.
ok— the run completed and produced results. You can review them and decide whether to go live.error— the run failed before it finished. Double-check the action and outcome names, then run it again. If it keeps failing, contact support.timeout— the run took longer than allowed and was stopped. Narrow the analysis window or lower the effort level, then run it again.
Why Dry Run first
A Dry Run shows you exactly what a workflow would do — before it touches a single real request.
When you Dry Run a workflow, SignalGate evaluates your recent traffic and reports the predicted impact without enforcing anything. You see how many requests would be blocked, and how your conversion is predicted to change once that suspicious traffic is removed. Nothing in production is affected.
check()) takes effect after the workflow is fully live, not after a dry run.Reading run results
After a run, the Run results strip summarizes the impact. Every number is scoped to the analysis window shown in the chip.
| Readout | How to read it |
|---|---|
| action | How many of the watched actions happened in the window — the volume of traffic the workflow evaluated. |
| target action | How many of those actions reached the desired outcome — your successful conversions. |
| conv now → conv pred | Your conversion today versus the predicted conversion once the workflow removes flagged traffic. The +Npp badge shows the change in percentage points — a positive number means cleaner traffic and a healthier conversion rate. |
| blocked (·N%) | How many actions the workflow would block, and what share of total traffic that is. A warning appears if the blocked share is high — a sign the configuration may be too aggressive. |
| window chip | The analysis window every number above is measured over. Read the results as “over the last Nhours.” |
A good result blocks a modest share of traffic while predicting a meaningful conversion lift. If the blocked share is large but the lift is small, you are likely catching legitimate users — loosen the threshold or raise the minimum group size and run again.
The recommended pipeline
A repeatable path from idea to live enforcement. Follow it for every new workflow.
- 1
Create a draft
From the Flows card, choose New flow. A new workflow starts as a draft in test mode — it can't affect real traffic until you promote it.
- 2
Configure it
Set the action and outcome (
methodandtarget_method), then adjust the window, threshold, minimum group size, schedule, action, and effort. The defaults are a safe starting point. - 3
Dry Run
Click Dry Run to preview the impact against your recent traffic. The dashboard refreshes automatically when the run finishes.
- 4
Review the results
Check the predicted conversion lift and the blocked share. If the numbers look right, continue. If not, edit the configuration and Dry Run again — repeat until you're happy.
- 5
Start (go live)
Click Start to promote the draft to a live workflow. It begins running on its schedule and applying its action to real traffic.
- 6
Monitor
Watch the live workflow on the dashboard. Run results keep updating on each scheduled run so you can confirm it behaves as expected.
- 7
Pause or edit
Pause a live workflow any time to stop it affecting traffic, or edit its configuration and run another Dry Run before resuming.
Continue reading