How ClickGuardIQ works

Every risk decision should lead back to evidence.

Investigations preserve the signals, reason codes, versions, operator notes, decisions, and actions required to understand what happened.

Review the methodology Follow the five stages

Sanitized ClickGuardIQ Fraud Center showing its current investigation workspace state. — **Fraud Center**Current beta interface captured without invented incidents, scores, or blocked-click totals.

A reproducible operating method

Investigation and Explainability begins with scope, provenance, and a permitted decision.

The method explains what enters the workflow, which transformation occurs, what leaves it, and which conclusion the evidence does not support.

The question this workflow owns

Can an authorized reviewer reconstruct the evidence, reasons, uncertainty, decisions, actions, and later corrections behind an incident? This page is written for fraud investigators, paid-media operators, analysts, agency reviewers, managers, auditors, and teams responsible for explaining why a traffic decision was made. Its owner is the versioned incident, evidence timeline, human review, decision rationale, and attributable case history, so adjacent product surfaces can reference the result without silently changing its meaning or authority.

The supported decision is whether an incident needs more evidence, remains unclassified, can be dismissed, meets an approved policy classification, supports a governed next action, or requires correction or reversal. That decision remains qualified by the selected property or client, eligible population, time window, filters, definitions, coverage, freshness, permissions, and evidence available when the workflow runs.

Workflow owner: the versioned incident, evidence timeline, human review, decision rationale, and attributable case history
Audience: fraud investigators, paid-media operators, analysts, agency reviewers, managers, auditors, and teams responsible for explaining why a traffic decision was made
Supported decision: an incident needs more evidence, remains unclassified, can be dismissed, meets an approved policy classification, supports a governed next action, or requires correction or reversal

Inputs retain their original meaning

Inputs include a versioned risk incident, eligible signal and assessment snapshots, linked acquisition and website evidence, visitor and session context, recordings, conversions, leads, tracking state, assignments, notes, external facts, and prior decisions. An observed event, calculated metric, inferred relationship, customer-provided field, provider-reported state, and human decision are different evidence types. The workflow records which type produced each value instead of flattening all of them into a generic fact.

Every reason, annotation, assignment, evidence link, decision, approval, request, provider response, verification, correction, and reversal retains source or actor, time, scope, version, and relationship to the incident. Source identity, event time, ingestion time, calculation time, definition or model version, eligible scope, confidence, coverage, freshness, and correction history travel with the result wherever the interface presents it.

Boundaries remain visible

The investigation record interprets and links evidence but does not mutate raw observations, manufacture unavailable context, replace provider state, or prove a commercial outcome from reviewer judgment. This distinction prevents collection from being treated as acceptance, a signal as confirmation, a recommendation as execution, an attempt as provider application, or an applied state as a verified business result.

When a required input, permission, provider capability, identity link, outcome, or correction path is missing, the method narrows the supported result or returns unavailable, incomplete, unclassified, needs-review, failed, expired, or unknown. It does not replace missing evidence with an authoritative-looking estimate.

Method capabilities

What the investigation and explainability method must preserve.

These are testable behaviors of the operating model, not claims of guaranteed detection, provider coverage, blocking, savings, revenue, or customer performance.

Open a versioned incident

Bind the owned entity, eligible population, assessment snapshot, reasons, confidence, coverage, limitations, creation source, time, and current investigation state.

Build an evidence timeline

Order source observations, calculations, visitor and session context, conversions, leads, tracking issues, external facts, notes, decisions, actions, and corrections by meaningful timestamps.

Explain reasons in context

Connect readable contributing and opposing reasons to source evidence, eligibility, freshness, entity grain, model or rule version, and known alternative explanations.

Coordinate attributable review

Retain assignments, watchers, notes, attachments or links, requests for evidence, status changes, approvals, due states, and permission checks without rewriting source data.

Record a defensible decision

Capture decision type, policy, rationale, reviewer or automation authority, evidence snapshot, uncertainty, limitations, expiry, next action, and required verification.

Audit later changes

Show recalculation, identity correction, new evidence, decision correction, provider result, verification, outcome review, expiry, and reversal as linked historical states.

Questions operators encounter

Apply the method when evidence and system states disagree.

Each scenario illustrates how the workflow should retain uncertainty, chronology, ownership, and a responsible next step.

Two signal families disagree

Inspect source quality, grain, eligibility, timing, freshness, coverage, contribution, opposing evidence, and alternative explanations before leaving the incident unclassified or deciding.

A reviewer cannot reproduce a dashboard total

Open the metric definition, filters, population, incident scope, assessment version, event and calculation times, exclusions, corrections, and current versus historical viewpoint.

A conversion follows suspicious activity

Keep conversion occurrence, attribution, quality, value, risk, reviewer decision, provider action, and later outcome independent while linking their evidence histories.

A prior decision needs reversal

Record the new evidence or policy reason, affected scope, approving authority, linked action and provider states, reversal request, verification, and remaining downstream review.

The controlled sequence

Five stages of investigation and explainability.

Stages are linked but not interchangeable. Every handoff carries the evidence snapshot, status, actor, time, limitation, and correction route needed by the next stage.

01
Create the incident snapshot
Link entity, eligible evidence, assessment version, reasons, confidence, coverage, limitations, source, affected scope, and creation time.
Incident creation records a reviewable condition; it is not automatic confirmation of invalid traffic or fraud.
02
Prioritize by governed context
Use evidence readiness, affected workflow, urgency, potential collateral scope, policy, and permitted next step rather than score magnitude alone.
03
Review the evidence timeline
Inspect linked traffic, visitor, session, recording, conversion, lead, tracking, identity, and historical records; add attributable notes or requests.
04
Record the decision
Choose an approved outcome with rationale, reviewer or system authority, evidence snapshot, uncertainty, limitations, expiry, and follow-up requirement.
05
Follow action and correction
Track requests, provider states, verification, outcomes, new evidence, recalculations, corrections, expiry, and reversals without changing the earlier viewpoint.

Evidence and implementation status

Separate the documented method from current product and external readiness.

Status labels distinguish implemented interface evidence, beta behavior, provider dependencies, planned coverage, and known limitations.

Fraud Centeravailable

Sanitized investigation surface

The current product capture demonstrates page structure without invented incidents, evidence, scores, assignments, decisions, blocked clicks, or customer outcomes.

Case modelbeta

Versioned beta history

Incident, evidence, assignment, note, decision, action, verification, correction, and reversal separation is defined and requires operational validation.

External evidenceexternal

Source and permission dependent

Provider, CRM, customer, commerce, lead, conversion, and outcome context depends on connected systems, available fields, identity links, and permissions.

Customer prooflimited

No completed investigation result

The page does not present a customer case, fraud confirmation, recovered spend, blocked-click result, reviewer productivity, or audit certification.

Method quality review

Compare investigation and explainability by reproducibility, not presentation alone.

The comparison describes two operating approaches. It does not assert that every alternative service uses the weaker approach.

Compare investigation and explainability by reproducibility, not presentation alone.
Comparison	Current-score case view	Versioned evidence investigation
Starting record	Opens a mutable case around the latest label or score.	Opens a versioned incident linked to the eligible assessment snapshot, reasons, confidence, coverage, and limitations.
Evidence	Copies selected attributes into an editable narrative detached from source history.	Links immutable observations and versioned calculations with provenance, grain, scope, time, freshness, and correction state.
Explanation	Lists generic reasons without showing contribution, opposition, eligibility, or alternative causes.	Connects readable contributing and opposing reasons to eligible source evidence and known limitations.
Decision	Changes case status without recording policy, evidence snapshot, authority, rationale, or uncertainty.	Records a policy-supported outcome with actor, time, evidence, rationale, limitations, expiry, action, and follow-up.
History	Overwrites the case as models, identity, evidence, or judgments change.	Appends recalculations, corrections, later decisions, provider facts, verification, outcomes, expiry, and reversals.

Reproducibility and audit standard

Another authorized reviewer should be able to reach the same scoped record.

A useful methodology is inspectable before adoption, reproducible during operation, and correctable after new evidence arrives.

Measurement contract

Investigation reporting separates incident occurrence, affected eligible population, severity or priority, evidence readiness, decision status, reviewer activity, age, action state, verification, and outcome maturity. Every summary, comparison, export, alert, and investigation link should preserve the population definition, numerator and denominator where relevant, inclusion and exclusion rules, selected period, timezone, freshness, coverage, and known collection gaps.

The contract also distinguishes event time from receipt, calculation, report, action, provider response, and verification time. This prevents late arrival, retry, deduplication, backfill, reprocessing, or timezone changes from silently altering the apparent sequence.

No metric without its population and definition
No status without its source and timestamp
No comparison without compatible scope and maturity

Version and correction contract

New evidence or a discovered error appends a correction or later decision with rationale and affected scope; it does not erase the incident snapshot or operator context available when the earlier decision was recorded. Raw source observations remain immutable; derived assessments, annotations, identity decisions, policy decisions, provider results, and outcome checks receive attributable versions or history entries.

A recalculation answers what the current definition would conclude from eligible retained evidence. It does not erase what the earlier version reported at the time. Corrections link the prior state, reason, actor or source, affected scope, new state, and any downstream records that require review.

Evaluation contract

Before beta activation, the organization should name the websites or clients, providers, event sources, consent mode, identity rules, permissions, review owners, policy thresholds, supported actions, expected provider states, verification checks, reversal route, and outcome window required by this workflow.

Evaluation should test data readiness, traceability, reason readability, reproducibility, permission enforcement, failure handling, and correction behavior before it evaluates operational or commercial outcomes. This page supplies no invented testimonial, customer logo, benchmark, detection rate, savings total, conversion lift, revenue result, or provider proof.

Investigation and Explainability questions

Clarify the method, its limitations, and the next responsible check.

Answers describe the intended and current beta boundary without presenting planned or external behavior as already verified.

Does creating an incident confirm fraud?

No. An incident creates a governed record for eligible evidence, risk context, reasons, uncertainty, review, and later decisions. It may remain unclassified, need more evidence, be dismissed, or reach a policy-supported conclusion.

What makes an explanation useful to an investigator?

It names the entity and scope, eligible evidence, contributing and opposing reasons, source provenance, model or rule version, confidence, coverage, freshness, missing inputs, alternative explanations, limitations, and the permitted next step.

Can investigators edit raw evidence?

They should not rewrite immutable source observations. They can add attributable notes, links, assignments, decisions, corrections, and requests for evidence. A source-data correction should retain the prior value, reason, actor or system, time, scope, and downstream impact.

How are historical and current viewpoints shown?

The incident retains the assessment and evidence snapshot used at the time. New evidence or a newer definition can create a current recalculation, but it is labelled separately and does not replace the original decision context.

Can an investigation automatically apply provider protection?

Only through a separate supported policy and action workflow with capability, permissions, scope, approval or governed automation, request, provider response, verification, failure, expiry, and reversal. A reviewer decision is not provider application.

Does ClickGuardIQ publish successful customer investigations?

Not on this page. It contains no invented case study, testimonial, outcome statistic, fraud finding, recovered spend, or provider result. Product captures are sanitized interface evidence only.

Review the workflow against your operating reality

Define the evidence, review, decision, and correction record your team must defend.

Share incident sources, decision grains, evidence types, review roles, policies, permissions, action handoffs, audit requirements, and correction scenarios. The review will identify the supported investigation boundary.

Review the methodology Review the complete method