Analytics Tracking Plan Template (Privacy-First, JSON Schema, GPC)

Analytics Tracking Plan: [Product name]

Privacy-first tracking plan for product analytics events. It covers measurement goals, event naming (object and action), the event catalogue, a property dictionary, event schemas written in JSON Schema 2020-12 with versioning through self-describing schemas (the Snowplow Iglu pattern is used as an example), the identity model, consent and Global Privacy Control (GPC) gating for each event, personal data rules, a platform coverage matrix, QA and validation, and the change process. The default is aggregate, cookieless measurement that needs no personal data; anything more is opt-in. Consent rules refer to the ePrivacy Directive 2002/58/EC Article 5(3) and GDPR Articles 6 and 7. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and measurement principles
2. Measurement tiers and lawful basis
3. Naming conventions
4. Event catalogue
5. Property dictionary
6. Event schemas and versioning
7. Identity model
8. Consent and GPC gating
9. Personal data rules
10. Collection architecture and platform coverage
11. QA and validation
12. Change process and governance
13. Retention, access and downstream use
14. Glossary and references
15. Standard and licence note

1. Purpose, scope and measurement principles

1.1 Purpose

This plan defines every analytics event that [Product name] sends, why it exists, what it contains, when it may be sent and how its quality is checked. It is the single source of truth for product managers, engineers, analysts and privacy reviewers. An event that is not in this plan must not be sent.

1.2 Principles

1. Question first. Each event answers at least one measurement question (section 1.3).
2. Aggregate by default. Prefer counts and distributions over per-person histories. Most funnels can be measured as step counts per day.
3. No personal data required. No event requires a name, email, phone number, address, precise location, free text or a persistent device identifier.
4. Cookieless by default. Tier A events store nothing on the device. Cookieless is not the same as consent-free: a client-side event is sent because our code instructs the device to send it, which is access under ePrivacy Article 5(3) (section 2.3).
5. Consent and GPC respected. Client-side events fire only after consent unless a documented exemption applies in the market; Tier B and C events always need consent; nothing but server-side Tier A fires when GPC is on.
6. First-party only. Events go to the organisation's own collection endpoint. No third-party tags, pixels or SDKs that send data to advertising networks.
7. Schemas are contracts. Every event has a versioned schema and is validated at collection; invalid events are quarantined, not silently dropped.

1.3 Measurement questions

1.4 Out of scope

• Advertising, retargeting and audience building for third parties.
• Cross-site or cross-app tracking, device fingerprinting and identity graphs.
• Session replay and keystroke capture.
• Anything not linked to a measurement question.

2. Measurement tiers and lawful basis

2.1 Tiers

Example: Corvid Commerce uses Tier A for all funnel and error events, Tier B only for the checkout experiment, and no Tier C events.

2.2 Lawful basis (EU and UK)

• Where an event involves storing information on the user's device or gaining access to information already there, Article 5(3) of the ePrivacy Directive (as implemented nationally) applies: consent is needed unless the storage or access is solely to carry out the transmission of a communication, or is strictly necessary to provide a service the user explicitly requested. Analytics is generally not strictly necessary for the service itself.
• Where an event processes personal data, the GDPR applies: choose a lawful basis under Article 6 (for analytics beyond strict necessity this is usually consent, which must meet Article 7 conditions: demonstrable, freely given, as easy to withdraw as to give).
• Record the lawful basis and purposes in the Record of Processing Activities (compliance/gdpr-ropa). Tier B and C events normally need a DPIA screening (compliance/dpia).
• Other jurisdictions: several US state privacy laws require businesses to honour opt-out preference signals such as GPC (for California, see the CCPA regulations, Cal. Code Regs. tit. 11, section 7025). Under the amendments effective 2026-01-01, a California business must display on its site whether it processed the signal as a valid opt-out (section 7025(c)(6)); check the current text at cppa.ca.gov. Check the current text for each market.

2.3 Cookieless is not automatically consent-free

The EDPB Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive (version 2.0, adopted 7 October 2024) explain that "gaining access" covers any case where an entity instructs the terminal to send back information: cookies, but equally JavaScript that tells the browser to send requests with the targeted information, app code that calls an API endpoint, tracking pixels and URL tracking. A client-side analytics event without cookies or identifiers is therefore still within Article 5(3). The guidelines do not analyse the exemptions themselves.

Apply this to the tiers:

• Server-side Tier A events (Corvid Commerce: EVT-003, EVT-005, EVT-008) are recorded by the server while it handles a request the user made, such as adding an item or placing an order. No extra instruction is sent to the device, so they carry the lowest risk and need no consent under Article 5(3). The GDPR still applies if the record could relate to a person.
• Client-side Tier A events (EVT-001, EVT-002, EVT-004, EVT-006, EVT-007) need consent unless an exemption applies. The strictly-necessary exemption rarely covers analytics. Some supervisory authorities accept audience measurement without consent under strict national conditions (for example the conditions published by the French CNIL: first-party, aggregate statistics only, no cross-site tracking, limited retention, and information with a right to object). Such exemptions are national: list the markets where you rely on one, cite the national source, and gate the events behind analytics consent everywhere else.
• Tier B and C events always need consent.

Record the market-by-market reasoning in section 8.4 and review it when any Tier A event or property changes. If in doubt, gate client-side Tier A behind consent too.

3. Naming conventions

3.1 Event names: object and action

• Pattern: <object>_<action> in snake_case, action in the past tense: cart_item_added, checkout_started, order_completed.
• The object is a business noun from the domain glossary (cart_item, checkout, order, product), not a UI element.
• The action is a past-tense verb from a controlled list: viewed, added, removed, started, completed, selected, searched, displayed, exposed, updated, failed.
• Variation goes into properties, not names: checkout_step_completed with checkout_step = "shipping", not shipping_step_completed.
• Names are at most 40 characters, ASCII only, and never contain user data, IDs or dates.

3.2 Property names

• snake_case, singular nouns, units in the name where relevant (price_amount_minor, duration_ms). Money is sent as an integer in minor units (cents) with a separate currency, never as a binary floating-point number.
• Booleans start with is_ or has_; enumerations list every allowed value in the schema.
• Reserved envelope properties (section 5.1) are set by the collector or SDK, never by feature code.

3.3 Schema identifiers

Each event schema is identified by vendor, name, format and version, for example com.corvid.shop/cart_item_added/jsonschema/1-0-0. The vendor is the reversed domain of the organisation, optionally with a sub-namespace per product.

4. Event catalogue

Prefer server-side events (EVT-003, EVT-005, EVT-008) wherever the server already knows the fact: they are more reliable than client events, need no device access and cannot be blocked or duplicated by retries in the browser.

5. Property dictionary

5.1 Envelope properties (set by the collector or SDK)

5.2 Event properties

Classification labels follow the Data Classification Policy (data/data-classification-policy).

6. Event schemas and versioning

6.1 Schema dialect and self-describing events

Write event schemas in JSON Schema 2020-12 (meta-schema https://json-schema.org/draft/2020-12/schema) unless your collection tool requires another dialect. Make every event self-describing: the payload names the exact schema and version it claims to follow, so the collector can validate it and the warehouse can load it into the right table version.

Snowplow's Iglu registry is a well-known open implementation of this pattern (Apache-2.0): a self-describing JSON object has a schema URI of the form iglu:<vendor>/<name>/jsonschema/<version> and a data object. Note that Snowplow's documentation describes its schemas as JSON Schema draft 4 documents with an Iglu self-describing meta-schema; if you adopt Snowplow, author schemas in its format. The example below uses the same envelope idea with a vendor-neutral JSON Schema 2020-12 schema.

6.2 Example schema

Example: com.corvid.shop/cart_item_added/jsonschema/1-0-0

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://schemas.corvid.example/com.corvid.shop/cart_item_added/jsonschema/1-0-0",
  "title": "cart_item_added",
  "description": "Server confirmed that a product was added to a cart. Tier A: no identifiers.",
  "type": "object",
  "properties": {
    "product_id": { "type": "string", "pattern": "^PRD-[0-9]{6}$" },
    "quantity": { "type": "integer", "minimum": 1, "maximum": 99 },
    "price_amount_minor": { "type": "integer", "minimum": 0 },
    "currency": { "type": "string", "pattern": "^[A-Z]{3}$" }
  },
  "required": ["product_id", "quantity", "price_amount_minor", "currency"],
  "additionalProperties": false
}

Example event instance (Example, fictional data):

{
  "schema": "iglu:com.corvid.shop/cart_item_added/jsonschema/1-0-0",
  "data": {
    "product_id": "PRD-204118",
    "quantity": 2,
    "price_amount_minor": 2490,
    "currency": "EUR"
  }
}

additionalProperties: false is deliberate: an engineer cannot add a property (for example an email address) without a reviewed schema change.

Money is an integer in minor units on purpose. A "type": "number" with "multipleOf": 0.01 looks natural but fails valid prices in common validators, because binary floating point cannot represent most decimal fractions exactly (0.29 / 0.01 evaluates to 28.999999999999996 in JavaScript). If a consumer needs decimals, send a string matching ^[0-9]+\.[0-9]{2}$ instead; never rely on multipleOf with a fractional divisor. Currencies with no minor unit (for example JPY) or with three decimals (for example KWD) follow the ISO 4217 exponent of currency.

6.3 Versioning rules

Use SchemaVer, as defined by Snowplow for Iglu: MODEL-REVISION-ADDITION, starting at 1-0-0.

Rules:

• Published schema versions are immutable. Fix mistakes with a new version.
• A MODEL change creates a new table or column family downstream; keep both versions loading until all clients have upgraded.
• Every new property passes the personal data rules of section 9 before review.
• Record schema versions consumed by each data product in its Data Contract (data/data-contract).

7. Identity model

Rules:

1. No fingerprinting. Do not derive identifiers from device characteristics, IP address, fonts, canvas or similar signals.
2. No raw IP storage. The edge derives country and discards the IP address before the event is stored.
3. No cross-device linking or aliasing of anonymous and authenticated identities. If a future question needs it, run a DPIA first and add it as a Tier C change.
4. Server-side joins only by design. If a business question needs order data per session (for example revenue per experiment variant), compute it in the Checkout data product from server events under the data product's access controls, not by sending order identifiers from the client.
5. Rotation. Session keys are random 128-bit values generated per session; they are not derived from any account or device data.

8. Consent and GPC gating

8.1 Consent categories

8.2 Gating decision

The SDK and the server apply this decision before any event leaves the device or the request handler. GPC is checked before consent, so a signal always wins over an earlier choice.

8.3 Per-event gating matrix

8.4 GPC handling and assessment record

• Detection: read the Sec-GPC: 1 request header on the server and navigator.globalPrivacyControl in the browser. Treat either as a valid signal. The GPC specification is a W3C Working Draft at the time of writing; check the current status at w3.org/TR/gpc.
• Effect: GPC overrides an earlier consent for Tier B and C on that browser for as long as the signal is present. Do not show a prompt asking the user to override GPC.
• Disclosure: state in the privacy policy that GPC is honoured, and consider publishing a /.well-known/gpc.json support resource as described in the specification. For California, display on the site whether the GPC signal was processed as a valid opt-out (CCPA regulations section 7025(c)(6), as amended effective 2026-01-01; check the current text).
• Assessment record (Example): "Server-side Tier A events (EVT-003, EVT-005, EVT-008) carry no identifier, use no device storage and send no instruction to the device, so they need no consent under Article 5(3); they are outside GPC opt-out scope because nothing is sold or shared. Client-side Tier A events (EVT-001, EVT-002, EVT-004, EVT-006, EVT-007) are access under Article 5(3) (EDPB Guidelines 2/2023, version 2.0). They rely on [national audience-measurement exemption, with citation] in [markets], and are gated behind analytics consent in every other EU and EEA market and in the UK. In the US they are sent unless GPC or a refusal is present. Reviewed by [@dpo] on YYYY-MM-DD. Re-review when any Tier A event, property or market changes."

9. Personal data rules

10. Collection architecture and platform coverage

10.1 Collection flow

The flow below keeps all events first-party, validates them against the registry and quarantines failures for review.

10.2 Platform coverage matrix

11. QA and validation

11.1 Before release

11.2 In production

Production monitors follow the Data Quality Standard (data/data-quality-standard); register them as rules in the Checkout data contract (for example a completeness rule on daily event volume).

12. Change process and governance

12.1 Roles

12.2 Lifecycle

Every event moves through these states, and its current state is shown in the Status column of the event catalogue (section 4).

12.3 Change request content

A change request (pull request against the plan and registry) states: the measurement question, the event or property change, the schema diff and version bump, the tier and gating, the personal data assessment, platforms and releases, downstream models and metrics affected, and the removal date for temporary events. Target review time: [3] business days.

12.4 Deprecation

Mark an event Deprecated in the catalogue with a removal date, notify consumers of the data product, stop sending it in the next releases, and keep the schema in the registry for historical loads. Remove downstream columns only after the data retention period for the raw events has passed or the data has been migrated.

13. Retention, access and downstream use

Downstream, events feed the Checkout data product (fct_checkout_sessions) and the metrics defined in Metric Definition (data/metric-definition). Experiment analysis follows the A/B Test Plan (product/ab-test-plan). Retention follows the Data Retention and Deletion Standard (data/data-retention-deletion-standard); classification follows the Data Classification Policy (data/data-classification-policy).

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Based on JSON Schema Draft 2020-12, the self-describing schema and SchemaVer concepts published by Snowplow for Iglu (Apache-2.0, github.com/snowplow/iglu-central), the W3C Global Privacy Control Working Draft, Article 5(3) of Directive 2002/58/EC, EDPB Guidelines 2/2023 (version 2.0) and Articles 6, 7 and 9 of Regulation (EU) 2016/679, all paraphrased in original words. This is a documentation format, not legal advice. Snowplow, Segment, Amplitude and Avo are trademarks of their owners; this template is not affiliated with or endorsed by them, and no vendor text is reproduced. The text is original, written for this collection; Corvid Commerce and all example data are fictional. Check the current official versions and the consolidated legal texts before use. Template licence: MIT.