Observed, modeled, and estimated
We treat these as three different things, and we don't blur them:
- Observed — directly measured from data collected by the site tracker or an explicit event you send us (a pageview, a form submission, a tracked conversion).
- Modeled — calculated from observed data using a defined, versioned rule set. Lead scores and lifecycle stage are modeled: every score change traces back to a specific rule and event, never a black box.
- Estimated — a derived approximation based on assumptions that can't be fully verified from data alone (for example, attribution weighting across multiple touchpoints, or AI-visibility signals scraped from third-party search results). We label these as estimates, not facts.
How scoring and lifecycle stage actually work
Lead scoring runs on a versioned rule set per workspace, not a single hardcoded formula. Each rule matches a specific trigger — a named event your site fires, a form submission, or a scheduled inactivity decay — and every resulting score change is written as its own event record, so "why is this lead scored the way it is" is always traceable to a specific rule and a specific action, not asserted after the fact.
Lifecycle stage (New → Engaged → MQL → SQL → Opportunity → Customer, with Lost reachable from any stage) is written through one single code path in the product, which is what makes two guarantees possible: an automated score-driven change can only move a lead forward (or sideways into Lost) — it can never silently move a lead backward — and moving a lead to Customer twice never double-counts a conversion.
Data freshness, by module
Freshness varies by module because the underlying work varies — a page crawl and a real-time pageview are not the same kind of data. We'd rather tell you the real cadence than imply everything is "real-time":
| Module | How it updates |
|---|---|
| Visitor / event tracking | Near real-time as your site sends events. |
| Tracking health scans | Advances as you use the scan in the app; a backstop job also runs every few minutes to finish any scan left mid-crawl. |
| SEO crawling | Advances in bounded slices every few minutes, plus a fresh crawl queued automatically on each project's own daily/weekly schedule. |
| Competitor monitoring | Runs on a scheduled job, not continuously. |
| Marketing health / campaign readiness | Recalculated by a scheduled worker, not on every page view. |
| Lead score decay | Applied by a scheduled job for inactivity, not instantly. |
Tracking methodology
The site tracker records pageviews, sessions, and events you configure, along with campaign/UTM context where present in the URL. Consent is checked before marketing-attribution data (like linking an anonymous visitor to a lead) is recorded — if a site's privacy settings require consent and none has been given, that linkage is skipped. This is not a toggle we treat as decorative: it's enforced in the code path that creates leads from anonymous activity, and we verified it behaves that way during this phase's testing.
Ad-platform and e-commerce integrations shown elsewhere on this site reflect what our tracking pipeline can detect or work alongside today — some at the level of "we recognize this platform's pixel/tag on your page," which is a lighter claim than a full two-way data sync. If you need a specific integration confirmed for your stack, ask us directly rather than assuming from a logo.
Privacy
Per-site privacy controls exist and are enforced, not aspirational: whether marketing consent is required before attribution linking, how IP addresses are handled (full, truncated, hashed, or not stored), how long data is retained, and whether geographic data is collected. We do not currently hold formal third-party certifications (SOC 2, ISO 27001, GDPR certification, HIPAA, or similar) — if and when we do, this page will say so with evidence, not before.
Security
Controls we can state plainly because they're implemented and were exercised during this phase's own testing: CSRF tokens on state-changing forms, prepared statements throughout (no raw SQL string interpolation of user input), rate limiting on public endpoints and login, passwords hashed with PHP's current default algorithm (never stored in plain text or reversible form), two-factor email verification on admin login, and session regeneration on privilege changes. We don't describe this as "unhackable" or "military-grade" — no real system is, and claiming otherwise would undercut the honesty this whole page is about.
Limitations, honestly
- Attribution is model-dependent — it reflects a chosen weighting approach, not an unarguable causal fact.
- A lead or lifecycle score is only as good as the data behind it; low-traffic accounts will see noisier signal.
- Scans and crawls run on a schedule, not instantly — what you see reflects the most recent completed run, not this exact second.
- Consent settings that restrict tracking (correctly) reduce how much attribution data we can link — this is privacy working as intended, not a bug, but it does mean some requests won't have a fully linked history.
- Third-party visibility (search results, AI-generated answers, competitor pages) depends on what's publicly accessible at scan time — it is a snapshot, not a guarantee of completeness.