Data and Tracking Model

How SGEN captures, governs, and surfaces site data — the shared model behind every per-area data behavior.

SGEN's data-and-tracking model defines how site data is captured (Form submissions, Analytics events, Call records, custom events), how that data is governed (consent, retention, audit), and how it is surfaced back to operators (per-module record lists, exports, downstream integrations). This page is the shared definition of the model — what gets captured, what runs underneath, and where each per-area Reference picks up the per-module specifics.

This page sits alongside Environments and Site States, Publishing Model, and Roles and Access. The four together describe SGEN's complete operating model: where things live (environments + states), what operations run on them (publishing), who can run them (roles), and what the platform captures and surfaces from them (this page).

What is this for?

Read this page when you want the shared model behind data capture and tracking in SGEN. It defines the capture surfaces the platform exposes by default, names the governance disciplines that run underneath every captured record, and explains where the per-area Reference pages pick up with module-specific behavior. It is the vocabulary anchor for every Guide that mentions site data, tracking, or consent.

The page is a Reference definition. It does not walk you through configuring a specific Form, enabling a specific Analytics integration, or setting consent banner copy — those procedures live in per-area Guides. It also does not enumerate per-customer data export pipelines; that detail lives in the customer agreement.

Good use cases

• You are scoping a site rollout and need to know what the platform captures by default vs. what requires explicit configuration.
• You are working through a privacy or compliance review and need the consent and retention posture in operator language.
• You are designing reporting on top of SGEN data and need to know which capture surface holds which type of record.
• You are preparing an integration hand-off and need to confirm where exports come from and what they include.
• You are explaining to a stakeholder how SGEN handles tracking without giving up control to a third-party plugin chain.
• You hit a "where did this submission go?" or "is this visitor counted twice?" question and want the structural model behind it.

What NOT to use this for

• Step-by-step procedures for configuring a specific Form or Analytics view — open the relevant Guide.
• Per-customer data-pipeline detail — internal-only or customer agreement.
• API-tier integration setup — open Developer Reference if available.
• Per-release shipped behavior change — open What's New or Changelog.

How this connects to other features

• Environments and Site States — the where-and-state coordinates that captured records belong to.
• Publishing Model — the audit posture that data captures share with content publishing.
• Roles and Access — who can see captured data, who can export it, who can configure the capture.
• Shared Concepts Index — sibling concept pages.
• SG-Admin Overview — the per-site administrative surface where capture configuration lives.
• Tracking Consent — the consent banner and policy surface that gates tracking-class capture.

Definition

The data-and-tracking model in SGEN is the set of capture surfaces, governance disciplines, and surfacing mechanisms that the platform runs to handle site data end-to-end. It covers what gets captured (form submissions, analytics events, call engagements, custom events, discussion threads), what discipline applies to what is captured (consent gating, retention rules, audit trail, export model), and how operators see the captured data (per-module record lists, exports, downstream integrations).

The defining property is platform-managed. Capture, governance, and surfacing are first-class platform behaviors — operators do not assemble them from a chain of vendor plugins, third-party tags, and external data warehouses to see a Form submission or a tracked event.

Purpose

The purpose of this page is to give operators a stable, shared model of data and tracking so that every Guide and every per-area Reference can use the same vocabulary. Without that shared model, "tracking" gets confused with "analytics", "consent" gets treated as a banner-only concern rather than a gating discipline, and operators end up surprised when retention or export behavior does not match what a third-party tool would have done.

Scope

This page covers the data-and-tracking model at the shared-concept level — the structure rather than the procedure.

The page covers:

• The capture surfaces the platform exposes by default.
• The governance discipline (consent, retention, audit, export) that runs underneath.
• The surfacing mechanisms operators use to read captured data.
• The boundary against per-area module behavior.
• The relationship to consent and to per-record permissions.

• Per-area capture mechanics (Form field configuration, Analytics view setup, Phone Tap pixel placement) — open the relevant area Reference.
• Per-customer pipeline or warehouse setup — internal-only or customer agreement.
• API-tier export endpoints — open Developer Reference if available.
• Per-release shipped behavior change — open What's New or Changelog.

Capture surfaces

SGEN exposes a small set of platform-managed capture surfaces. Each surface writes structured records into the per-site record store, where they become first-class records — administered through the admin, covered by backups, and reachable through the same audit and export disciplines that govern content records.

Form submissions

Form submissions arrive through Forms configured in the admin. Each submission becomes a record with the submission payload, the originating Form identity, the timestamp, and the visitor context (subject to consent posture). Submissions are visible per-Form in the admin and can be exported on demand.

Analytics events

Analytics captures page-level and visitor-level events for the site. The capture is platform-managed; operators do not have to install third-party JavaScript tags to get baseline analytics. The captured events surface through the per-site Analytics view in the admin.

Phone Taps

Phone Tap capture records engagement with call links on the site (clicks on tel: links and equivalent surfaces). The capture is per-engagement and surfaces through the Phone Taps record list in the admin alongside originating page context.

Events

The Events module captures custom event records the platform exposes for operator workflows — appointments, registrations, calendar-style entries. Events are first-class records with their own per-module record list and audit posture.

Discussions

Discussions capture conversation threads associated with site content (typically blog posts or community surfaces where the module is enabled). Each discussion entry is a record under the platform's audit and retention discipline.

Governance discipline

Every captured record sits under the platform's governance discipline. Operators do not configure the discipline per record; the platform applies it as part of the operating posture.

Consent gating

Tracking-class capture (Analytics, Phone Taps, downstream tracking integrations) is gated by the site's consent posture. Configuration and the consent banner live under the Tracking Consent surface in the admin. Until consent is recorded, tracking-class capture is suppressed for that visitor; non-tracking capture (Form submissions explicitly initiated by the visitor) is not gated.

Retention

Each capture surface has a retention discipline that determines how long records remain in the record store. Retention is platform-managed by default and can be tuned per customer through the customer agreement. Records past retention are removed from the record store; backup coverage during the retention window is the safeguard that protects against premature loss.

Audit

Every capture event is recorded with timestamp + originating surface + (when consent allows) visitor context. The audit trail sits in the same audit surface that publishing-related events use, so a single audit query can answer "what was captured on this Page during this window" without leaving the platform.

Export model

Captured records can be exported on demand from the per-module surface in the admin. The export model is operator-tier — Site Editor or higher can run an export, which is itself an audit event recording who exported, when, and what scope of records.

Surfacing back to operators

Captured data becomes useful when operators can read it. SGEN exposes captured data through three operator-facing surfaces, each appropriate for a different operator workflow.

Per-module record list

Each capture surface has a per-module record list in the admin — Forms have a submissions list, Analytics has a per-Page event view, Phone Taps has a tap log, Events has a per-event record list, Discussions has a thread list. The record list is the day-to-day surface for reading captured data without leaving the per-site administrative surface.

Exports

Exports take a scope of captured records and produce a downloadable artifact (typically a structured file the operator can hand off). Exports are operator-initiated, audited, and per-record-type. They are appropriate for one-shot reporting needs and for stakeholder hand-off.

Downstream integrations

For ongoing pipelines (a CRM that should receive Form submissions, an analytics warehouse that should receive Analytics events), the platform supports downstream integrations through the Integrations surface. The integration is configured once at SG-Admin and runs continuously thereafter; capture events route to the configured downstream surface as part of the same audit-tracked path.

Constraints and boundaries

Some properties of the data-and-tracking model are structural and worth naming explicitly so operators do not assume otherwise.

• Capture is platform-managed. Operators do not have to install third-party JavaScript tags to get baseline tracking. The capture surfaces ship with the platform.
• Consent is gating, not cosmetic. The consent posture suppresses tracking-class capture until the visitor has consented. Configuring the banner without engaging the consent gate would not be SGEN's posture.
• Retention is finite. Captured records do not stay forever. Operators who need permanent retention should configure a downstream integration that owns long-term storage, with audit retention preserved at SGEN's tier.
• Export is per-scope. Exports are not "everything ever captured" by default; they are a defined scope (date range, surface, filter), audited per export.
• Per-area Reference owns module specifics. This page describes the model. The per-area Reference for Forms, Analytics, Phone Taps, Events, Discussions, and Tracking Consent describes the specifics of each surface.

Examples

Example 1 — A Form submission lands and routes to a CRM

A visitor submits a Contact Form. The platform writes the submission record to the per-site record store, visible in the Form's submissions list in the admin. The downstream CRM integration (configured under Integrations) routes the submission to the CRM as part of the same audit-tracked event. The operator sees the submission in two places: the admin submission list and the CRM. The audit trail records both the capture and the downstream hand-off.

Example 2 — A visitor declines consent

A visitor opens a page on the site. The Tracking Consent banner appears. The visitor declines. Analytics, Phone Tap tracking, and downstream tracking integrations are suppressed for that visitor's session. A Form submission they explicitly initiate is still captured, because explicit-action capture is not consent-gated; tracking-class capture is.

Example 3 — Auditing a quarter's Form submissions

A reviewer needs Form submission counts for the prior quarter. The operator opens the admin Forms, filters the submission list by date range, and runs Export. The downloaded artifact is a structured file with the submissions in scope. The audit trail records the export with the operator identity, the scope filter, and the timestamp.

Example 4 — A retention concern

A compliance officer asks how long Form submissions are retained. The operator opens the Tracking Consent or Forms Reference page, finds the platform's default retention discipline, and (for the customer's specific window) cross-references the customer agreement. If the default is shorter than required, the path forward is a per-customer retention adjustment through the agreement, not a per-record overrides table inside the admin.

Example 5 — Phone Tap analytics for a campaign

A marketing operator wants to know how many Phone Taps the campaign Landing Page generated. They open Phone Taps in the admin, filter by originating page, and read the count. For deeper analysis, they Export the scope and hand off the file. The campaign report is built from platform-tier data without setting up a third-party call-tracking pixel.

Example 6 — Discussions moderated post-publish

A blog post receives Discussions. A Site Editor reviews the thread list, removes a spam entry, and the action is recorded as an audit event. The thread continues to capture new entries; the moderation event is preserved separately, so a stakeholder can see both the captured records and the moderation history.

Documentation guidance

This page is the shared definition of data and tracking. Use it as the vocabulary anchor when other Guides reference "capture", "tracking", "consent", "retention", "export", or any specific capture surface (Forms, Analytics, Phone Taps, Events, Discussions). Per-area Reference pages describe the per-module specifics on top of this shared model.

For step-by-step configuration of a specific Form, Analytics view, or Tracking Consent banner, open the relevant area Guide. For the audit posture this model shares with content publishing, open Publishing Model. For who can see and export captured data, open Roles and Access.

Reading order

Read this page after Environments and Site States, Publishing Model, and Roles and Access. Those three set up the operating model; this page extends it to the data layer. After this page, the per-area Reference for Forms, Analytics, Phone Taps, Events, and Tracking Consent give the per-module specifics.

Related reading

• Environments and Site States — coordinates that captured records belong to.
• Publishing Model — the audit posture this model shares.
• Roles and Access — who can see and export captured data.
• Shared Concepts Index — sibling concept pages.
• SG-Admin Overview — per-site surface where capture configuration lives.
• Tracking Consent — consent banner and policy surface.

Vocabulary cross-reference

• Capture surface — a platform-managed entry point that writes structured records to the per-site record store (Forms, Analytics, Phone Taps, Events, Discussions).
• Tracking-class capture — capture that is gated by visitor consent (Analytics, Phone Taps, downstream tracking integrations).
• Explicit-action capture — capture initiated by the visitor's deliberate action (Form submit, comment post); not consent-gated.
• Consent gating — the discipline that suppresses tracking-class capture until visitor consent is recorded.
• Retention window — the platform-managed period a captured record stays in the record store before removal.
• Audit signature — the platform-recorded fields per capture or export event (timestamp, surface, scope, operator if applicable).
• Per-module record list — the admin surface where captured records of one type are visible.
• Export — an on-demand operator-initiated transfer of captured records out of the platform; itself audited.
• Downstream integration — a configured continuous hand-off to an external system (CRM, analytics warehouse).
• Tracking Consent — the per-site surface that configures the banner copy and the consent-gating policy.
• Visitor context — the request-side metadata recorded with capture events (subject to consent).
• Operator-tier export — exports run from the admin by an operator with at least Site Editor authority; recorded in the audit trail.
• Long-term storage — durable retention beyond the platform's per-surface window; owned by the downstream integration when permanent retention is required.
• Capture event — a single record-write into the per-site record store originating from one of the capture surfaces.
• Hand-off — the moment a captured record routes to a downstream integration; itself recorded in the audit trail.
• Per-customer retention adjustment — a tuned retention window negotiated through the customer agreement; applies across the relevant surfaces for that customer.
• Spam moderation — the operator-initiated removal of an unwanted Discussions or capture entry; recorded as a moderation audit event distinct from the original capture.
• Scope filter — the criteria (date range, surface, status) applied to an export to narrow which records are included.
• Banner copy — the text the visitor sees on the consent banner; configured per-site under Tracking Consent without affecting the gating mechanism itself.
• Engagement record — a Phone Tap or equivalent click capture that does not include a payload but records intent and originating context.
• Audit query — a single query against the platform's audit surface that joins capture, export, and publishing events to answer cross-surface questions.