How ClickGuardIQ works

Collect useful evidence without blocking the page.

The planned tracking SDK is asynchronous, versioned, consent-aware, and performance-budgeted, with resilient validation and ingestion behind it.

Review the methodology Follow the five stages

Sanitized ClickGuardIQ Tracking Health workspace showing its current diagnostics state. — **Tracking Health**Current beta interface captured without implying that a customer property has been tested.

A reproducible operating method

Tracking and Data Collection 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

Which website activity can be collected, under which privacy state, and when can the system treat a transmitted event as durably accepted evidence? This page is written for website owners, developers, analytics teams, privacy owners, agencies, and operators responsible for trustworthy website measurement. Its owner is the consent-aware browser collection, validation, delivery, and acceptance boundary, so adjacent product surfaces can reference the result without silently changing its meaning or authority.

The supported decision is whether an event was eligible to collect, valid to transmit, accepted by the intended ingestion boundary, and available for a named downstream purpose. 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 consent-aware browser collection, validation, delivery, and acceptance boundary
Audience: website owners, developers, analytics teams, privacy owners, agencies, and operators responsible for trustworthy website measurement
Supported decision: an event was eligible to collect, valid to transmit, accepted by the intended ingestion boundary, and available for a named downstream purpose

Inputs retain their original meaning

Inputs include the installed SDK version and configuration, verified website boundary, consent and Do Not Track state, eligible automatic observations, approved custom events, identifiers, timestamps, delivery attempts, ingestion validation, and tracking diagnostics. 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.

Each event should retain schema and SDK version, event identity, website scope, source type, event and receipt time, consent state, permitted fields, delivery attempt, validation result, deduplication key, and downstream availability where implemented. 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

Browser observation, local queueing, transmission, HTTP response, ingestion validation, durable acknowledgement, downstream processing, metric availability, and analytical freshness are separate states. 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 tracking and data collection method must preserve.

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

Load without blocking the page

Use an asynchronous versioned loader, bounded initialization, safe failure behavior, and performance budgets so measurement does not become a critical rendering dependency.

Enforce the website boundary

Bind configuration and anonymous identity to the verified property by default; require explicit governed ownership and compatible consent before broader identity use.

Respect privacy state before capture

Apply consent, Do Not Track, masking, field exclusion, sampling, and permitted-purpose rules before sensitive or optional observations enter a delivery batch.

Validate a strict event contract

Require supported schema version, event type, identity, timestamps, field shapes, sizes, and enumerations while rejecting malformed or disallowed payloads visibly.

Deliver with bounded resilience

Batch, retry, back off, deduplicate, and expose queue or delivery diagnostics without claiming that a browser response equals durable downstream acceptance.

Explain tracking health

Distinguish absent installation, disabled collection, consent exclusion, validation rejection, delivery failure, provider delay, incomplete coverage, and analytical freshness.

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.

The script loads but no events appear

Check website configuration, consent, SDK readiness, event eligibility, queue state, network delivery, validation, durable acceptance, processing, and reporting freshness in sequence.

A retry appears to duplicate activity

Compare stable event identity, attempt history, receipt records, deduplication result, processing version, and metric grain before treating two deliveries as two occurrences.

Consent changes during a session

Record the applicable state and time, stop or narrow later capture as required, retain permitted history under policy, and avoid retroactive inference about excluded activity.

A custom event contains an unexpected field

Reject, remove, mask, or quarantine it according to the contract; expose the reason and affected scope rather than accepting arbitrary customer data silently.

The controlled sequence

Five stages of tracking and data collection.

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
Establish scope and privacy
Resolve verified website, configuration and SDK versions, environment, consent, Do Not Track, allowed event types, fields, masking, sampling, and purpose.
A present script tag does not prove initialization, consent, capture, delivery, acceptance, or complete coverage.
02
Observe eligible activity
Create website-scoped events from permitted automatic observations or approved explicit calls with stable identity, source, event time, and schema metadata.
03
Validate and prepare delivery
Enforce field, type, size, version, identifier, timestamp, privacy, and batch rules before placing valid events into the bounded queue.
04
Transmit and acknowledge
Send batches with attempt history, timeout, retry, backoff, and deduplication while distinguishing network response from durable server acceptance.
05
Process and diagnose availability
Track validation, durable acknowledgement where configured, processing, enrichment, metric inclusion, delay, failures, exclusions, and current reporting freshness.

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.

Browser SDKavailable

Versioned collection package

A typed asynchronous loader, strict event contract, consent and Do Not Track enforcement, safe observations, bounded delivery, and diagnostics exist in the product codebase.

Tracking Healthbeta

Sanitized beta interface

The current capture shows the diagnostics surface without asserting that a customer website is installed, healthy, complete, or currently sending data.

Durable ingestionexternal

Server configuration dependency

Token and origin enforcement, durable stream acknowledgement, processing, enrichment, and analytics freshness remain server-side and environment-dependent.

Browser coveragelimited

Policy and environment limited

Consent, blockers, browser restrictions, page lifecycle, sampling, network failure, SDK support, and excluded fields can limit observable activity.

Method quality review

Compare tracking and data collection by reproducibility, not presentation alone.

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

Compare tracking and data collection by reproducibility, not presentation alone.
Comparison	Script-present assumption	Collection-to-availability contract
Installation	Treats a tag found in markup as proof that measurement works.	Separates tag presence, loading, initialization, configuration, consent, capture, queueing, transmission, acceptance, processing, and freshness.
Privacy	Collects broadly and attempts to filter sensitive fields later.	Applies consent, Do Not Track, purpose, masking, exclusion, sampling, and field policy before or at the collection boundary.
Validation	Accepts arbitrary names and payload fields as usable analytics facts.	Uses versioned event types, schemas, identifiers, limits, permitted fields, rejection reasons, and compatibility rules.
Retries	Counts repeated delivery as repeated visitor behavior.	Retains stable event identity, attempt history, deduplication outcome, receipt time, and source occurrence separately.
Health	Shows either connected or disconnected without the failure stage.	Explains configuration, privacy, capture, queue, network, validation, durability, processing, coverage, delay, and reporting state.

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

Collection reporting uses eligible pages, sessions, devices, consent states, event types, SDK versions, delivery windows, validation outcomes, deduplication, delay, and known exclusions rather than a single unqualified coverage percentage. 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

Configuration, schema, consent interpretation, website ownership, identity scope, or ingestion defects are corrected prospectively with version history; source events are not silently rewritten to hide the earlier collection state. 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.

Tracking and Data Collection 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 the tracking script block page rendering?

It is designed to load asynchronously with bounded work and safe failure behavior. Actual performance depends on the deployed version, configuration, page environment, event volume, browser, network, and any customer code around it, so the target property should still be measured.

Does an HTTP success response prove the event is stored?

Not by itself. Network response, ingestion validation, durable acknowledgement, processing, enrichment, metric inclusion, and reporting freshness are distinct. The configured environment must expose the strongest state it can actually verify.

How are retries prevented from inflating activity?

A stable event identity and deduplication contract should link repeated delivery attempts to one source occurrence. Attempt, receipt, validation, durable acceptance, processing, and metric inclusion remain separately inspectable.

What happens when consent is unavailable or denied?

Collection follows the configured consent and permitted-purpose boundary. Optional events or fields may be withheld, capture may be narrowed or stopped, and the resulting coverage limitation should remain visible in diagnostics and downstream interpretation.

Can the SDK collect any custom field?

No. Custom events and properties should conform to approved versioned contracts, type and size limits, privacy and masking policy, permitted purpose, and website scope. Unexpected or prohibited fields should be rejected or removed visibly.

Does tracking coverage prove traffic quality?

No. Collection produces eligible source evidence. Attribution, identity, metrics, risk, classification, investigation, provider action, and outcome verification are later stages with their own requirements and limitations.

Review the workflow against your operating reality

Validate the website, privacy, event, and ingestion boundary before relying on downstream metrics.

Share the property, framework, tag deployment, consent mode, event needs, field policy, expected volume, ingestion environment, and health requirements. The review will separate current SDK support from server and deployment dependencies.

Review the methodology Review the complete method