Tracking Consent
| Field | Value ||---|---|| Audience | public || Page type | reference || Area | sg-admin || Updated | 2026-05-14 |The SG-Admin Tracking Consent module — visitor consent capture, retention, integration gating.
The Tracking Consent module in the admin is the per-site surface for visitor consent capture and consent-aware behavior. The platform surfaces a configurable consent banner on the public site; visitor responses (accept / reject / partial) are recorded; tracking integrations gate behavior on the recorded consent state. This page is the Reference definition.
What is this for?
Read this page when you want the structural definition of consent handling — what gets captured, how integrations gate on consent, and how consent records are retained.
Good use cases
- You are scoping a new site's compliance posture.
- You are explaining to a stakeholder how SGEN handles tracking consent.
- You hit a "is the consent banner configurable?" question.
What NOT to use this for
- Step-by-step procedures — open the relevant Guide.
- Legal compliance counsel — out of scope; consult legal.
- Per-release shipped change — open What's New or Changelog.
How this connects to other features
- SG-Admin Overview — parent surface.
- Google Analytics 4 — example tracking integration that gates on consent.
- Discussions — visitor identity fields collected with comments interact with the consent posture.
- Phone Taps — call-signal recording is consent-gated where the posture requires it.
Before you start
You need the following before configuring Tracking Consent on a live site:
- A clear answer to "which measurement categories does the site use?" — typically some combination of necessary, analytics, marketing, and personalisation.
- The default posture you want to apply when a visitor has not yet decided — opt-out (track until refused) or opt-in (do not track until accepted). Pick one and apply it consistently.
- The visitor-facing wording for the prompt. Wording is content; the surface is governance. Keep them aligned.
- The retention window you intend to apply to the consent log.
- Confirmation from counsel where the site serves a jurisdiction with explicit consent rules. The platform exposes the surface; the legal interpretation is the site owner's.
Where to find it
Tracking Consent lives in the admin under the privacy / compliance group, alongside Discussions and Phone Taps. The grouping is intentional — these modules sit at the trust and interaction edge of the platform.
Site · SG-Admin · Privacy / Compliance group
Modules in this group
Steps
The steps below cover a typical first-time configuration of Tracking Consent for a site that has decided to run measurement.
1. Decide the consent posture
Open Tracking Consent in the admin. Choose the default posture for the site:
- Opt-in. No measurement runs until the visitor explicitly accepts. The default in jurisdictions that require explicit consent.
- Opt-out. Measurement runs until the visitor refuses. Acceptable where local rules allow soft consent or where the categories are narrow.
The posture decides the visitor's experience on first visit. It also decides what the prompt has to ask.
2. Configure the categories the site offers
Decide the measurement categories the site will surface to the visitor. Common categories include:
- Necessary. Records required for the site to work at all (session, security). Not optional under most consent models.
- Analytics. Measurement of how visitors use the site. Usually optional.
- Marketing. Advertising-related tracking, retargeting tags, conversion measurement for ad platforms. Usually optional.
- Personalisation. Content adapted to a known visitor. Optional where used.
A visitor decision applies to each category separately; the platform retains the per-category state, not a single yes/no.
3. Set the prompt wording and position
Set the visitor-facing prompt text. The wording is content; treat it the same way as other public copy — clear, plain, no jargon. State what each category does in one sentence; do not pad with legal abstractions.
Set the prompt position (footer banner, modal, sidebar) according to the site's design.
4. Confirm log retention and the review surface
Set the log retention window. The platform keeps a per-decision record so the site can answer "did this visitor consent at the time we measured them?" later. The retention window decides how long these records are kept.
Confirm that the log surface is reachable from Tracking Consent. Operators reviewing a compliance question open the log here.
What success looks like
A site whose Tracking Consent posture is configured and live behaves as follows:
- A first-time visitor sees the consent prompt before any optional measurement starts (under opt-in posture) or sees the prompt and can refuse before further measurement (under opt-out posture).
- A returning visitor's prior decision is remembered; the prompt does not re-appear unless the visitor clears their decision.
- Connected measurement (analytics, advertising tags, phone taps where consent-gated) respects the per-category state. A visitor who has accepted Analytics but not Marketing is measured by analytics and not by marketing tags.
- The consent log shows decisions for visitors who have responded, with the timestamp and the per-category state at the time of decision.
- A compliance review can answer the "what did this visitor agree to and when?" question from the log alone.
Site · SG-Admin · Tracking Consent · Logs
Recent decisions
| Time | Visitor (hash) | Necessary | Analytics | Marketing |
|---|---|---|---|---|
| 14:02 | v_8c4f... | Accepted | Accepted | Refused |
| 13:58 | v_a91d... | Accepted | Accepted | Accepted |
| 13:41 | v_3e02... | Accepted | Refused | Refused |
What to do if it does not work
- The consent prompt does not appear for a new visitor. The default posture may be set to opt-out with no prompt. Check the posture in Tracking Consent and confirm the prompt is enabled for first-time visitors.
- The prompt appears every visit, even after the visitor has answered. The decision is not being remembered. Most often this is a browser-side state problem (the visitor is in private mode, or has cleared site storage). Confirm in another browser session that the decision persists.
- Analytics is collecting data from visitors who refused. The analytics integration is not reading the consent state. Open the Analytics integration Reference and confirm the integration is set to respect the consent posture from this area.
- The log shows no entries for a day where visitors clearly used the site. The prompt may not be wired to write to the log. Re-confirm in Tracking Consent that logging is enabled.
- A compliance review needs a decision older than the log retention window. The log only retains decisions for the configured window. Decisions older than the window are not recoverable; set the retention window to match the longest review horizon the site needs.
Definition
Tracking Consent administers the per-site consent banner, the consent-record store, and the integration-gating rules. The banner surfaces on first visit per session (or per the configured policy); the visitor's response records as a session-scoped consent state; tracking integrations check the state before firing their trackers.
The defining property is consent-gated tracking. Tracking integrations do not fire blindly; they check consent first.
Purpose
Define the Tracking Consent module as a Reference layer.
Scope
Covers consent banner config, consent-record retention, integration gating. Does not cover legal compliance work (out of scope) or per-step setup (Guides).
Consent banner
Surface
Default surface is a footer banner appearing on first visit per session. Position, copy, and accept/reject options configurable.
Response model
Accept (all categories) / reject (no tracking) / partial (per-category opt-in where the configuration supports it).
Persistence
The visitor's response persists for the configured retention window so the banner does not re-prompt every visit.
Site · SG-Admin · Tracking Consent
Banner configuration
Settings
Preview
Integration gating
Tracking integrations (GA4 and others) check the consent-record state before firing trackers:
- Accepted: trackers fire normally.
- Rejected: trackers do not fire; data is not captured.
- Partial: per-category gating where supported (e.g., analytics OK, advertising not).
Constraints and boundaries
Tracking Consent is a Reference area for consent capture and gating.
Do not use for: legal compliance work (consult legal), per-step setup (Guides).
Public boundary
This page is intentionally public-safe.
Examples
Example 1 — Operator configures banner copy for a region
Operator updates banner copy to match local language and regulatory requirements. The banner re-renders on the public site.
Example 2 — Operator reviews consent-rate trend
Operator opens the consent-record summary, reviews accept-rate trend over the last 28 days. Drops indicate banner copy or visibility may need tuning.
Example 3 — Visitor rejects tracking
A visitor clicks Reject; no tracking integrations fire for the session; their behavior is not captured by GA4 or others.
Documentation guidance
Use this page as the structural definition for Tracking Consent.
Reading order
Open this page when scoping compliance posture.
Related reading
- SG-Admin Overview — parent surface.
- Google Analytics 4 — example consent-gated integration.
Vocabulary cross-reference
- Consent banner is the surface that captures visitor response.
- Consent record is the persisted response per visitor session.
- Consent state is one of accept / reject / partial.
- Integration gating is the check that integrations run before firing.
Maintenance discipline
When Tracking Consent changes across releases (new banner option, new gating rule, new retention model), update this Reference.
When the platform adds a new consent category, update the prompt-wording section and the Examples to reflect the addition.
When a connected integration changes how it reads the consent state, update the corresponding callout in "how this connects to other features".
When regulation in a region the site serves shifts the recommended default posture, raise the change with the operator. The platform exposes both postures; the choice is the site owner's.
Governance scope
Tracking Consent is one of three modules that sit at the trust, interaction, and attribution edge of the platform: Discussions, Phone Taps, and Tracking Consent. They are grouped because they touch the visitor's identity, the visitor's behavior, and the visitor's permission. The grouping preserves category separation; each module governs a distinct meaning that documentation must not collapse together.
- Consent is not traffic. A consent decision is about the visitor's permission for measurement to occur. It is not a measurement event. Counting decisions is governance work, not analytics work.
- A phone tap is not a form submission. A call-signal record is attribution-adjacent behavior. A form submission is a content surface (My Forms) interaction. Treating them as the same event loses the operational meaning of each.
- A discussion body is not another page type. Comment moderation is its own interaction surface (Discussions). A page is content. A discussion is conversation.
Where Tracking Consent feeds analytics or attribution downstream, the documentation preserves one clear meaning for what consent itself governs versus what downstream reporting later interprets.
What this area is not responsible for
This is a privacy-sensitive surface. Boundary clarity prevents the area from absorbing responsibilities that belong elsewhere.
- Legal compliance writing. Counsel writes the legal language. The platform surface exposes the configuration the legal language requires.
- Per-region detection. The platform does not detect the visitor's jurisdiction and rewrite the prompt automatically. The site owner chooses one posture; if the site needs different postures per region, the site owner configures that at the routing layer.
- Tag implementation. Tracking Consent records the decision. Tags (analytics, ad pixels, third-party scripts) read the decision and decide whether to run. A tag that ignores the decision is a tag-side problem.
- Visitor identity resolution. The consent log records decisions against a session-level identifier. The platform does not stitch decisions to a long-lived personal identity; that boundary is deliberate.
Privacy-sensitive notes
Operators handling Tracking Consent are handling visitor permission data. Two practical habits keep that handling safe.
Treat the log as evidence
The consent log is the answer to "did this visitor consent?" Treat it as evidence. Do not edit log entries. If the log surface allows export, use export for sharing with compliance; do not screenshot or paraphrase decisions when the original is available.
Treat changes to posture as a release event
Switching the default posture or adding a new category changes the behavior the visitor sees. Treat the change like a release — announce it internally, record the change date, and re-check that connected integrations still read the posture correctly after the change.
Site · SG-Admin · Tracking Consent · Posture change
Change log (last 90 days)
| Date | Operator | Change | Reason |
|---|---|---|---|
| 2026-05-12 | L. Operator | Added Marketing category | New retargeting campaign starts 2026-05-15 |
| 2026-03-04 | L. Operator | Retention 12 mo → 24 mo | Compliance review horizon |
| 2026-01-22 | L. Operator | Posture opt-out → opt-in | New region in audience |
Avoid mixing categories
Categories exist because visitors decide differently about each one. A visitor who accepts Analytics but refuses Marketing has made a specific decision; a tag that runs because "the visitor accepted something" violates the decision. When adding a new tag or integration, name the category it belongs to; if it does not match an existing category cleanly, add the category rather than placing the tag under the closest match.
Cross-cutting reference: the privacy/compliance group
Tracking Consent does not stand alone. It governs the permission posture for measurement that flows from other modules. The table below summarises the per-module relationship.
| Module | What it governs | Consent dependency |
|---|---|---|
| Discussions | Comment moderation, visitor-generated content | Identity fields collected with a comment may need consent under the configured posture. |
| Phone Taps | Call-tap session signals, attribution-adjacent | Recording the call signal is consent-gated where the posture requires it. |
| Tracking Consent | Consent posture, prompt, decision log | The source of truth other modules read. |
The relationship runs in one direction: Tracking Consent declares the posture; other modules read it. A module that ignores the posture is a module-side problem, not a Tracking Consent problem.
## Related reading| Topic |
|---|
| SG-Admin |
| Google Analytics 4 |