Measurement architecture · from request to report
SealMetrics separates collection, processing, attribution and activation. Each stage has a defined input, a visible output and a boundary your technical team can inspect.
First-party option · aggregate events · full-resolution processing · Dublin hosted
Where conventional measurement breaks
Consent rejection, blocked requests, browser restrictions and sampling can remove or reshape evidence before an analyst sees a chart. A polished interface cannot recover an event that never entered the pipeline.
Illustrative diagnostic · actual loss depends on the current stack, audience and configuration
The architecture
SealMetrics keeps collection and interpretation separate. That makes it possible to identify whether a disagreement comes from missing events, a commercial definition or the attribution model.
A lightweight event contract records pageviews and commercial actions without analytics cookies, persistent visitor IDs or fingerprinting.
The processing layer validates eligible events and keeps aggregate acquisition context such as referrer, UTM and landing page.
Recorded outcomes are connected to channel and campaign using a declared last-click model on the complete eligible dataset.
Reports, BigQuery, REST and MCP expose the defined metrics. LENS answers against that layer instead of inventing another dataset.
What enters · what does not
The architecture is easier to review when the collected fields and the prohibited fields are stated directly.
| Signal | Used for | Stored as | Boundary |
|---|---|---|---|
| Page path | Content and funnel reporting | Aggregate dimension | No visitor profile |
| Referrer + UTM | Acquisition context | Aggregate dimension | No cross-visit stitching |
| Commercial event | Conversion and revenue totals | Defined metric | No payment details |
| Country + device class | Operational breakdown | Coarse aggregate | No IP address stored |
| Persistent identifier | Not collected | — | Prohibited by design |
| Browser fingerprint | Not generated | — | Prohibited by design |
Implementation sequence
Keep the existing stack live while SealMetrics collects the same period. The change decision comes after both systems have been reconciled against backend outcomes.
Deploy the script directly or through the current tag-management workflow.
Confirm traffic, channel context and commercial events are arriving.
Review the difference by channel and explain each collection boundary.
Align purchases and 5–10 microconversions with backend definitions.
Document the baseline and let marketing, finance and the agency use it.
A controlled comparison
Run the two pipelines together. SealMetrics should earn its place by explaining the gap and reconciling more closely with the store, CRM or booking engine.
Technical questions
Answers for CTO, DPO and analytics teams evaluating the collection boundary.
SealMetrics records aggregate events and their declared acquisition context. It does not create a persistent visitor identifier, use fingerprinting or reconstruct a cross-visit profile.
The collection endpoint can run in first-party mode on your own subdomain. This reduces the loss caused by lists that block known third-party analytics domains.
The initial script can be installed in minutes. A useful comparison starts on day one; event calibration and revenue reconciliation normally continue through the first week.
No. Run both systems side by side, define the same commercial events and compare each reported total with the revenue recorded by your backend.
The visitor data path is hosted in Dublin, Ireland. SealMetrics is designed without analytics cookies, persistent visitor IDs or fingerprinting.
No. Eligible events are retained at full resolution. Reports state the model being applied instead of presenting sampled or modeled data as direct observation.
Validate with your own traffic
Install beside the current stack, define one commercial period and compare both totals with the backend.
