ClickGuardIQ platform

Understand the visitor behind each measured journey.

Explore website-scoped visitors with acquisition, activity, conversion, identity, risk, recording, protection, and history context.

Review visitor-data fit Review the workflow

Sanitized ClickGuardIQ Visitor Intelligence screen with website-selection guidance. — **Visitor Intelligence**Current beta interface captured without customer identities, traffic, or performance claims.

A clearly owned job

Visitor Intelligence has one defined place in the operating model.

The page explains what this surface measures, the decision it can support, and the boundary it does not cross.

The job this surface owns

Visitor Intelligence is designed for analysts, investigators, growth teams, and lead operators who need a website-scoped view of a measured journey. Its primary record is a property-scoped visitor identity with attributable acquisition, activity, session, conversion, lead, recording, risk, and protection history. That focus matters because a useful operating surface should answer a specific question before it asks a team to act. Here, the question is whether a measured journey has enough context for investigation, qualification, audience-safe follow-up, or a link to another governed record. The answer stays attached to the evidence and scope that produced it.

Visitor identity is scoped to a website by default, and anonymous identifiers are not assumed to represent the same person across unrelated properties or clients. That scope travels with summaries, filters, exports, and follow-up links so a number is not separated from the population it describes. When the required evidence is absent, the interface should say that the answer is unavailable or incomplete instead of replacing it with an estimate that looks authoritative.

Primary record: a property-scoped visitor identity with attributable acquisition, activity, session, conversion, lead, recording, risk, and protection history
Decision supported: a measured journey has enough context for investigation, qualification, audience-safe follow-up, or a link to another governed record
Designed for: analysts, investigators, growth teams, and lead operators who need a website-scoped view of a measured journey

A deliberate evidence boundary

Visitor Intelligence organizes measured evidence; it does not claim to reveal a person’s real-world identity or turn behavioral interest into consent, qualification, or fraud confirmation. ClickGuardIQ preserves this distinction because a high-risk signal, an unusual pattern, a tracking defect, and confirmed invalid activity are not interchangeable findings. Each can change what an investigator checks next, but none should silently inherit the certainty of another.

The visitor timeline distinguishes observed events, calculated signals, customer or CRM updates, identity changes, and provider responses rather than flattening them into one story. The operating record keeps source observations, calculated signals, human notes, decisions, provider responses, and verified outcomes attributable. Corrections create a history rather than rewriting the earlier state, which keeps later reporting and review understandable.

How it fits daily work

Acquisition events, live activity, processed sessions, recordings, conversions, CRM updates, and risk calculations can become available at different times. This prevents a recent partial stream from being compared casually with a completed historical period. It also gives an operator a direct route to the underlying visitor, session, incident, conversion, lead, campaign, integration, or delivery record when more detail is justified.

Sensitive attributes, recordings, lead fields, exports, identity merges, and cross-client access require purpose-based controls and an attributable operator action. Access is therefore part of the product model, not an afterthought. Sensitive evidence, exports, provider actions, and administrative changes should remain limited to the appropriate website, client, role, and purpose, with an audit trail that explains who did what and when.

Feature detail

What Visitor Intelligence is designed to help teams do.

Each capability keeps its underlying scope and limitations visible so convenience does not come at the expense of explainability.

Keep identity property-scoped

Represent anonymous and known states within the selected website, retain approved merge and split history, and avoid silent cross-client identity assumptions.

Read a typed timeline

Separate page activity, acquisition, calculated risk, conversions, lead updates, recordings, investigation notes, and provider actions by source and meaning.

Compare acquisition context

Connect source, campaign, keyword, referrer, landing page, device, network, and location context without claiming that one attribute identifies invalid traffic.

Open session evidence

Move from a visitor to eligible sessions, live events, or privacy-controlled recordings while preserving the exact reason for review.

Learn more →

Track conversion and lead context

Link occurrences and lead states without treating a conversion, qualification, CRM stage, priority, intent score, and risk score as equivalent outcomes.

Learn more →

Use stable saved views

Retain filters, columns, sort, property, period, and a query snapshot so a large investigation does not shift invisibly while the dataset changes.

Working situations

Use it when the next question needs evidence, not a guess.

These workflows describe practical investigation and operating needs; they are not promises of a particular savings, detection rate, or commercial result.

Investigate repeated suspicious activity

Review the eligible journeys, devices, networks, acquisition records, reasons, confidence, and known identity changes before deciding whether repetition is meaningful.

Explain a high-value conversion

Trace the conversion occurrence to its measured journey, attribution context, qualification, and known evidence gaps without converting risk directly into revenue quality.

Review a submitted lead

Connect the lead to prior sessions, acquisition, form journey, consented evidence, CRM state, and risk context while keeping sales priority separate.

Find a recording for a reason

Open an eligible recording because a specific tracking, experience, conversion, or risk question warrants it—not because all visitor behavior should be watched.

A governed sequence

From a property-scoped visitor identity with attributable acquisition, activity, session, conversion, lead, recording, risk, and protection history to a defensible next step.

The workflow keeps observation, calculation, review, action, and verification separate so uncertainty and responsibility remain visible.

01
Create the scoped visitor
Associate eligible events with a property-level anonymous identifier and preserve source, consent, timestamp, and identity confidence.
A browser or device identifier is not proof of a natural person.
02
Build typed sessions and events
Group compatible activity while retaining raw event provenance, sessionization rules, late arrival, validation state, and exclusions.
03
Attach calculated context
Link versioned risk, traffic-quality, intent, or qualification outputs to the eligible evidence and calculation time that produced them.
04
Investigate without rewriting
Add notes, assignments, decisions, approved identity changes, and links to incidents while preserving the measured timeline as evidence.
05
Continue to the right workflow
Move to a session, conversion, lead, incident, report, or protection record with the same property and evidence scope intact.

Evidence and readiness

Understand the current product boundary before connecting traffic.

ClickGuardIQ is presented as a beta product. Interface evidence is sanitized, provider-dependent capabilities require validation, and unsupported proof is not substituted with generated claims.

Public captureavailable

Sanitized Visitor Intelligence

The product image shows website-selection guidance without customer identities, journeys, traffic, scores, or commercial outcomes.

Identity modelbeta

Website-scoped by default

Property boundaries and identity history are architectural requirements; production matching sources and policies require beta validation.

Sensitive evidencelimited

Purpose and permission controls

Recordings, lead fields, exports, and identity operations require appropriate consent, roles, retention, and customer policy.

External sourcesexternal

CRM and provider context

Availability and freshness depend on supported integrations, granted fields, reconciliation rules, and connection health.

A more useful comparison

Evaluate Visitor Intelligence by its operating behavior.

This table compares two operating approaches. It does not claim that every alternative product follows the same design or lacks the same controls.

Evaluate Visitor Intelligence by its operating behavior.
Comparison	Flat visitor list	Governed Visitor Intelligence
Identity	Treats cookies, devices, emails, and people as interchangeable identifiers.	Scopes identity to the property and retains anonymous, known, merge, split, and confidence history.
Timeline	Mixes source events, scores, notes, and outcomes into one undifferentiated feed.	Types every entry by source, calculation, operator, customer system, or provider response.
Risk	Displays a label without the eligible evidence or version that produced it.	Keeps reasons, coverage, confidence, limitations, and calculation state inspectable.
Recordings	Encourages broad replay as a default analytics behavior.	Uses consent, masking, sampling, retention, permissions, and reason-recommended review.
Saved review	A changing live query can alter which visitors belong to an investigation.	A saved view can retain configuration and a stable query snapshot for reproducibility.

The ClickGuardIQ operating standard

Context remains attached from first observation to final review.

Three controls make the page useful for investigation, governance, and later audit without turning one screen into an unsupported verdict engine.

Scope, eligibility, and freshness

Every important result in Visitor Intelligence should identify the website or client boundary, time range, timezone, filters, eligible population, excluded population, and last successful update. Acquisition events, live activity, processed sessions, recordings, conversions, CRM updates, and risk calculations can become available at different times. A result that cannot disclose those conditions should not be used as if it describes the whole account.

Eligibility is especially important when consent, sampling, integration coverage, event validation, identity state, or provider availability changes what ClickGuardIQ can measure. The interface should reveal those gaps at the point of use and preserve them in reports or exports. That makes an incomplete answer operationally useful without pretending it is complete.

Reasons, versions, and corrections

The visitor timeline distinguishes observed events, calculated signals, customer or CRM updates, identity changes, and provider responses rather than flattening them into one story. Calculated outputs retain their model, rule, or score version and the eligible evidence available at calculation time. A later recalculation is a new state with a reason, not a silent edit to history. Operators can therefore distinguish what the system observed from what it inferred and what a person later decided.

The same discipline applies to corrections. Identity merges, conversion reconciliation, qualification changes, incident decisions, and provider responses may alter a current view. ClickGuardIQ should keep the earlier record attributable, show the correction source, and rebuild affected summaries from governed records rather than from an unexplained overwrite.

Permissions, actions, and proof

Sensitive attributes, recordings, lead fields, exports, identity merges, and cross-client access require purpose-based controls and an attributable operator action. A recommendation is not an attempted action; an attempt is not a provider-applied change; and an applied change is not a verified outcome. Those states remain separate wherever this surface can contribute to protection, notification, export, or downstream delivery.

This page does not use invented testimonials, customer logos, benchmark statistics, or savings percentages as product proof. The product image is either a sanitized beta capture or clearly labelled conceptual artwork. Commercial evaluation should instead begin with fit, data readiness, provider capability, policy requirements, and the evidence a team needs to verify its own outcome.

Visitor Intelligence questions

Clarify the boundary before making a decision.

These answers describe the intended beta operating model and avoid claiming an integration, outcome, or automation that has not been validated.

Does Visitor Intelligence identify a real person?

Not by default. It organizes website-scoped measured evidence around anonymous or approved known identifiers. A browser, device, IP address, email hash, CRM record, or identity link has its own confidence and policy boundary and should not be presented as certainty.

Can identities be connected across websites or agency clients?

Cross-property identity is not assumed. Any supported connection would require an explicit lawful purpose, compatible customer boundary, approved source, confidence, permissions, and retained merge history. Agency client records must remain isolated by default.

What happens when two visitor records are merged incorrectly?

The intended model retains the merge source, time, confidence, operator or system, and affected records so an approved split or correction can rebuild downstream views. The earlier evidence is not silently deleted.

Is a risky visitor automatically blocked?

No. Visitor risk can support an investigation or policy recommendation, but it remains separate from confirmation and protection state. Supported actions require capability, approval policy, provider response, verification, and a reversal path.

Are session recordings visible for every visitor?

No. Recording depends on consent, configured sampling, exclusions, masking, retention, technical capture, processing, and user permission. An unavailable recording should show why; its absence should not be interpreted as safe or suspicious behavior.

Can visitor data be exported?

The intended product supports governed exports with property, period, filters, fields, purpose, creator, and generation time. Sensitive fields and available formats depend on role, policy, data state, and current beta capability.

Evidence before activation

Define the visitor evidence your team can collect and responsibly use.

Bring the property boundaries, consent posture, identity sources, investigation questions, retention needs, and sensitive-field rules. The beta review will map what is measurable and permitted.

Review visitor-data fit Review plan boundaries