The product analytics decision record: why the event schema you configured determines your retroactive analysis failure mode and your data subject consent gap

A 24-person SaaS company that built project management tooling for design teams had added Mixpanel in its eighth month, shortly after reaching 200 monthly active users. The instrumentation had been done by the engineer who had built the product's onboarding flow. She had added twelve events covering the key steps: account_created, profile_completed, first_project_created, team_member_invited, template_selected, first_task_assigned, collaboration_started, first_export, first_comment, first_integration_connected, workspace_configured, onboarding_completed. Each event carried a handful of properties: user_id, timestamp, plan, referring_domain. The instrumentation had taken three days and the engineer had kept a list of the event names in a Notion page titled "Analytics Events."

Over the following twenty-two months the product grew and the engineering team grew with it. Eight additional engineers joined and each contributed to the product's instrumentation over time. The Notion page was consulted occasionally but not consistently — some engineers found it, others did not know it existed, and several added events with names that seemed logical given their own understanding of the product. The original engineer left the company in month eighteen. Her Notion page remained but was not actively maintained by anyone after she left. By month thirty, the Mixpanel event taxonomy contained 347 distinct event names.

The company's Series A investor, conducting due diligence in month thirty, asked a standard cohort question: what was the 90-day retention rate for users who completed onboarding, broken down by the activation milestone they hit first? The investor's portfolio analytics team ran the query against the Mixpanel export and came back with a problem. There was no single "onboarding_completed" event. They found "onboarding_completed", "onboarding_complete", "onboarding_done", "onboarding_step_6_done", "setup_finished", "setup_complete", "user_activated", "activation_complete", and "profile_setup_done" — all of which appeared to correspond to some version of the same user lifecycle state, but with inconsistent triggering conditions, inconsistent property schemas, and significant overlap in timing for individual users who appeared in multiple event streams. Some events fired client-side, some server-side, some both. Some had a user_id property, some had an account_id property pointing to the same underlying identifier, and some had both with inconsistent values for the same user session.

The due diligence team escalated to the company's head of product. She assigned the problem to the two engineers who had been at the company the longest. The normalization work required six weeks: mapping each of the 347 event names to a canonical event taxonomy, identifying which events were duplicates of other events versus genuinely distinct user actions, rebuilding the onboarding funnel definition from a combination of server-side logs and the Mixpanel data, and constructing a cohort analysis that was defensible to the investor's team. The six weeks produced an answer to the original question. It also surfaced three additional problems: 180 of the 347 event names had not been queried in the prior six months and appeared to be legacy instrumentation still firing; 23 events contained email addresses in event properties, creating GDPR exposure that had not been identified in any prior compliance review; and the activation milestone that produced the highest 90-day retention was connected to a feature the product team had been considering cutting because the analytics dashboard had shown low engagement — the low engagement signal was an artifact of the naming inconsistency, not the actual usage pattern.

The normalization work had cost six weeks of two engineers' time. The due diligence timeline had been extended and the investor's confidence in the company's data discipline had been affected. The founding analytics instrumentation had not produced any of the artifacts that would have prevented the accumulation: not a naming convention, not a required property schema, not a process for proposing new event names before they were shipped, not a review cadence that would have caught the divergence before it reached 347 events. The engineer who built the original instrumentation had known the naming convention from her own mental model; she had not written it down because at eight months and 200 MAU the team was small enough that shared context substituted for documentation.

A 32-person SaaS company that built revenue intelligence tooling for enterprise sales teams had integrated Amplitude in its first year and had accepted the default 10% sampling rate when Amplitude recommended it to control event volume costs as the company scaled. The product manager who made the integration decision noted the sampling rate in an internal Slack message and moved on. The sampling configuration was not recorded in any decision document. No one had discussed the implications of 10% sampling for a product whose feature surface included several low-traffic but high-value capabilities used exclusively by enterprise administrators.

At 30,000 monthly active users, the product had a clearly stratified usage distribution. The core workflow — pipeline view, deal management, and activity logging — was used daily by nearly every user. The reporting module was used weekly by 12% of users. The integration configuration panel was used monthly by 4% of users, typically the same enterprise administrators who owned the CRM connection for their teams. The forecast modeling feature was used by 2% of users, all of them VP-level stakeholders with direct board reporting responsibility. At 10% sampling, the core workflow generated more than enough events for analysis. The reporting module generated approximately 360 events per user per month at 12% penetration — at 10% sampling, roughly 1,080 events per month, enough for basic usage pattern analysis but not enough for cohort-level behavioral sequence analysis. The integration configuration panel generated fewer than 50 events per user per month at 4% penetration — at 10% sampling, 60 events per month total across all users, a volume that cannot support any analysis with statistical validity. The forecast modeling feature generated 12 events per user per month at 2% penetration — at 10% sampling, fewer than 10 events per month total, analytically equivalent to noise.

The product team made three feature prioritization decisions in a six-month window that drew on Amplitude data for the integration configuration panel and the forecast modeling feature. The integration configuration panel's "advanced mapping" sub-feature showed near-zero engagement in Amplitude — the product team interpreted this as user disinterest and recommended the feature for removal in the next roadmap cycle. The forecast modeling feature's "scenario comparison" view showed similarly low engagement and was marked as a candidate for consolidation with the simpler forecast view. A third feature, the "bulk activity import" tool used by enterprise administrators during onboarding of large sales teams, showed low completion rates in the Amplitude funnel analysis — the product team added engineering capacity to simplify the flow, which was the correct directional call, but the funnel completion rates used to prioritize the work were based on a sample size of fewer than 30 events per month.

The decisions were surfaced through an unrelated route eight months later. A customer success manager preparing for a quarterly business review with the company's highest-paying enterprise customer pulled that account's usage data from the raw database rather than from the analytics dashboard. The raw database showed that three enterprise administrators at the customer account had used the "advanced mapping" sub-feature 47 times in the prior quarter and had submitted 12 support tickets about mapping limitations. The Amplitude data for those users showed 4 events for the feature — a 10% sample of their actual usage. The product team checked the other two decisions. The "scenario comparison" view had been regularly used by VP-level stakeholders at 8 of the company's 11 enterprise accounts; the Amplitude sample had captured between 0 and 3 events per user per month for those stakeholders, which had appeared in the dashboard as effectively zero usage. The "bulk activity import" completion rate issue was real, but the sample size had been too small to distinguish between a design problem and normal variance in enterprise onboarding timelines.

The company had not removed the "advanced mapping" feature yet — the roadmap cycle had been delayed by a different priority. They reversed the "scenario comparison" consolidation decision. The cost of the discovery was two roadmap cycles of misdirected prioritization. The cost of the sampling configuration decision — made once, in year one, by a product manager with no context on the statistical implications for a product with a highly stratified usage distribution — had been invisible in the analytics dashboard because Amplitude's sampling implementation displayed rounded numbers without any indication of the sample size behind each metric or the statistical validity of the analysis drawn from it.

A 38-person SaaS company that built customer support tooling for e-commerce brands had implemented a cookie consent banner in its second year, following a legal review triggered by an enterprise customer's data processing addendum requirements. The consent banner had been implemented using a third-party consent management platform that displayed a modal on first visit, stored the user's consent choice in a cookie, and provided a "Privacy Settings" link in the footer for users who wanted to change their choices. The product manager who led the compliance sprint had reviewed the banner implementation with the company's outside counsel and marked the item as complete in the compliance documentation.

The consent implementation had three gaps that were not visible in any compliance review conducted in the twenty-two months following deployment. The first gap was pre-consent event capture: the company's analytics SDK — Segment — was initialized on page load and began capturing events before the consent modal was dismissed. Events fired during the window between page load and consent modal interaction — which could be several minutes for users who navigated away to read the privacy policy before choosing — were captured without a valid consent signal. The consent management platform's JavaScript loaded asynchronously after the analytics SDK, creating a race condition that was not documented in the implementation and was not visible from the consent dashboard. The second gap was autocapture scope: Segment's autocapture feature, left enabled as the default when the SDK was installed, automatically captured click events and form interaction events across the product's UI. This included the contact support form used by end-customers of the support tooling's clients — a form that collected name, email, and phone number. The form field values were being captured as event properties in the Segment event stream. The engineering team that implemented the Segment integration had not reviewed the autocapture scope against the product's UI surface; they had accepted the default configuration because it was documented as "automatic instrumentation with no code changes required." The third gap was retroactive consent: the "Privacy Settings" opt-out toggle controlled whether Segment would capture future events for the user. It did not delete historical events captured before the opt-out. No retroactive deletion API call was made when a user opted out. The opt-out record was stored in the consent management platform and in a compliance log, but Segment's user data for opted-out users remained in the Segment workspace.

Twenty-two months after the consent implementation, the company was acquired by a larger enterprise software vendor. The acquirer's DPO conducted a standard pre-close data protection review. The review included an examination of the analytics configuration. The DPO's team identified all three gaps within a three-day technical audit. They identified the pre-consent event capture through a browser HAR trace that showed Segment network requests firing within 800 milliseconds of page load, before the consent modal had rendered — the modal appeared at approximately 1,400 milliseconds based on the asynchronous consent platform initialization. They identified the autocapture form field capture by examining the Segment event stream for form interaction events and finding phone number strings in the event property payloads. They identified the retroactive deletion gap by creating a test user, recording 50 events, opting out, and querying the Segment workspace — all 50 events remained.

The DPO's assessment was that the company had been capturing analytics data without a valid legal basis for twenty-two months for a fraction of users whose page interaction fell within the pre-consent window, had been capturing sensitive personal data — phone numbers — through autocapture for the same twenty-two months, and had been retaining analytics data for opted-out users in violation of the consent model represented in the privacy policy. The remediation required five weeks: re-architecting the analytics initialization to fire only after a confirmed consent signal, configuring autocapture exclusion rules to exclude all form fields, building a per-user deletion job that submitted a Segment deletion API request for each user in the opted-out consent log, and running a retroactive analysis of the pre-consent event capture window to estimate the total affected event records and personal data categories included. The retroactive analysis could not determine the exact number of affected records because the pre-consent window was not logged — the consent timestamp was stored but not the analytics event timestamps for the period before consent. The DPO prepared a disclosure to the acquirer's legal team documenting the gap, the remediation, and the limitations of the retroactive analysis. The acquisition closed on schedule but with an escrow holdback tied to the completion of the retroactive deletion job.

Structural properties set by the product analytics decision

Three structural properties are determined when a founding team establishes its product analytics instrumentation: how consistently the event schema represents the product model across engineers who add events independently over time, how valid the behavioral analysis is for features whose traffic distribution makes them statistically sensitive to the sampling configuration, and how completely the consent implementation aligns the data capture surface with the legal basis the company represents to users and enterprise customers. None are labeled as decisions at the time of instrumentation — they are properties that emerge from choices the founding engineers make about naming conventions, sampling defaults, and consent initialization order, and they are invisible until a retroactive analysis exposes the schema divergence, until feature-cut decisions are made from statistically invalid data, or until a compliance audit examines the analytics configuration against the consent model the company has represented in its privacy policy.

Property 1: The event schema and the retroactive analysis failure mode. Product analytics event schemas are designed to answer the questions urgent at the time of instrumentation. The questions that become urgent twelve to thirty months later — cohort retention broken down by activation milestone, feature engagement correlated with churn, behavioral sequences that predict expansion — require event schemas with consistent naming conventions, consistent property schemas across all engineers who add events, and explicit canonical definitions for the product lifecycle events used in cohort modeling. Founding instrumentation rarely specifies any of these requirements because at founding the team is small enough that naming conventions are informal shared knowledge. As the team grows, engineers add events according to their own mental models of the product — individually coherent but collectively inconsistent. The divergence is not visible in the analytics dashboard, which displays event names without indicating that "onboarding_completed" and "onboarding_complete" represent the same user action instrumented by two different engineers. The failure becomes visible only when a retrospective analysis requires joining events across the diverged taxonomy, at which point normalization is the only path forward and the cost of normalization scales with the months the divergence has accumulated unchecked. The multi-tenant data isolation decision record connects at the analytics data scope layer: in multi-tenant products, analytics events must be scoped to the correct tenant context — user events, account events, and cross-account administrative events must be distinguished in the event schema to prevent cross-tenant data leakage in analytics queries; an event schema that does not specify tenant scoping creates queries that can surface behavioral data across organizational boundaries, which is both an analytics validity problem and a data isolation compliance problem simultaneously. The audit log decision record connects at the event taxonomy layer: analytics events and audit log events answer different questions — analytics events track user behavior for product understanding, audit log events track account actions for security and compliance — and conflating them in a single event stream creates a schema that serves neither purpose well; the analytics event schema decision must specify which events belong in the analytics stream, which belong in the audit log, and which belong in both with different property sets for each consumer, because the naming conventions, retention requirements, and query patterns for the two streams are incompatible when merged.

Property 2: The sampling model and the statistical validity surface. Analytics sampling is a cost-optimization decision that trades event volume for event coverage. The trade-off is benign for high-traffic features and pathological for low-traffic features that are nonetheless important to the product's business model. The failure mode is not that sampling produces wrong numbers — it produces numbers that appear correct because they fall within the normal range of the metric being measured, but which are drawn from a sample size too small to be statistically meaningful. A product manager looking at a feature with 60 events per month at 10% sampling does not see a statistical validity warning; they see a usage number that looks like low engagement. The structural property set by the sampling configuration is the threshold below which the product team's analysis of a given feature is producing conclusions the data cannot support — a threshold invisible in the analytics dashboard without supplementary context about the sample size behind each metric. The founding sampling configuration appropriate at 1,000 MAU becomes inappropriate for some features at 10,000 MAU and for more features at 50,000 MAU as the usage distribution stratifies by feature surface. The decision record must specify the sampling rate, the statistical validity threshold, and the mechanism by which the product team is informed when a feature falls below the validity threshold — because a feature below the threshold analyzed without that context is analytically equivalent to a feature above it only if the analyst has no way to distinguish between them. The database backup verification decision record connects at the raw data access layer: raw event data in the primary database before sampling is the authoritative source for any analysis that falls below the validity threshold in the analytics platform; the backup retention policy for raw event data determines how far back a validity-threshold analysis can reach into the primary database for supplementary data; if the raw event data is retained for 90 days but the analytics analysis window is 12 months, the supplementary access path is available only for recent data and the analytics platform's sampled data must be used for older periods regardless of its statistical validity for the feature in question.

Property 3: The consent scope and the data subject rights gap. Analytics consent implementations are designed against the compliance surface visible at the time of implementation: the cookie consent banner satisfies the visible regulatory requirement, the opt-out toggle satisfies the visible user control requirement, the privacy policy update satisfies the visible disclosure requirement. The compliance surface not visible at implementation time is the analytics SDK's initialization order relative to the consent signal, the autocapture scope relative to the product's personal data surface, and the effect of opt-out on historical data. These properties are set by technical implementation decisions that sit beneath the compliance-facing layer — which JavaScript loads first, whether autocapture is enabled by default, whether the opt-out handler calls a retroactive deletion API. Each creates a distinct data subject rights gap: pre-consent capture is capture without legal basis; autocapture of personal data is capture the user did not specifically consent to; and the absence of retroactive deletion on opt-out is retention without consent. The gap is structurally similar to the gaps in the export scope and erasure coverage described in the customer data portability decision record: the compliance layer says the data is handled correctly, and the technical implementation layer says it is handled differently from what the compliance layer represents. The founding analytics consent decision must specify the analytics initialization architecture, the autocapture configuration including explicit field exclusions for personal data surfaces, and the retroactive deletion protocol for historical analytics data when a user opts out or submits an erasure request. The compliance automation decision record connects at the consent enforcement layer: automated consent signal propagation — from the consent management platform to the analytics SDK, from the erasure request intake to the analytics platform deletion API — is more reliable than manual propagation because it closes the gap between the compliance record and the technical enforcement before a DPA audit surfaces it; the automation design must specify the latency between a consent change and the analytics capture behavior change, because a 15-second propagation delay produces a different compliance posture than a 2-second delay when the consent signal is the result of a user explicitly opting out mid-session.

What the founding session records and what it omits

The founding session that establishes product analytics — typically a one-week sprint in the product's first months, triggered by the need to understand onboarding funnel performance or to answer an investor question about monthly active users — records the integration: the SDK installed, the events defined, the dashboard configured, the Slack alert set up for the daily active user count. If the team has thought about compliance, it records the consent banner and the privacy policy update. What the founding session does not record is the naming convention that future engineers should use when adding events, the property schema every event should carry for consistent analysis, the funnel and lifecycle event canonical definitions needed for cohort modeling, the sampling policy and its statistical validity thresholds, the autocapture configuration and its personal data scope, or the retroactive deletion protocol for users who opt out or submit erasure requests.

These omissions are structurally similar across the decision record series: benign at founding, when they are covered by the founding team's shared context. The naming convention omission is not a problem when the product has twelve events added by one engineer. The sampling policy omission is not a problem when the product has 800 monthly active users and 10% sampling produces more events per feature than the team needs for analysis. The consent architecture omission is not a problem when the enterprise customer base is small enough that no DPO has examined the analytics configuration closely.

The failure modes develop along three distinct timelines. The event schema failure develops from team growth — a continuous process that adds one new engineer at a time, each adding events according to their own naming conventions, until the cumulative divergence produces a taxonomy that cannot be queried retroactively without normalization work measured in weeks. The sampling failure develops from MAU growth — the same sampling rate appropriate at 1,000 MAU produces invalid analysis for an increasing fraction of the product surface as MAU grows and the usage distribution stratifies, but the dashboard displays the same kind of numbers at every scale and does not indicate when the statistical validity threshold has been crossed. The consent gap develops from technical implementation choices made once at integration time and not revisited — the initialization order, the autocapture configuration, and the retroactive deletion protocol are set by the engineer who installs the SDK and are not examined by subsequent compliance reviews, which typically examine the consent banner copy and the privacy policy rather than the SDK initialization sequence in the browser.

The product analytics ADR closes these gaps by specifying the naming convention before the second engineer adds their first event, documenting the sampling policy against the product's usage distribution and minimum validity thresholds, and specifying the analytics consent architecture as an engineering requirement rather than a compliance surface. The decisions never written down in the product analytics domain are not the decisions about which analytics platform to use or which events to track — those are visible in the codebase and the dashboard. They are the naming convention the founding engineer carried in their head, the sampling rate whose implications for low-traffic features were never analyzed, and the three-line initialization order in the analytics SDK configuration that determines whether events fire before or after consent. The new CTO onboarding problem in the product analytics domain is specific: the incoming technical leader finds the analytics dashboard with 347 events and a healthy active user count, but cannot determine which events are canonical versus legacy, which features are being analyzed with statistically invalid sample sizes, or whether the consent implementation produces analytics data that matches what the privacy policy represents to users. The product analytics ADR makes those decisions explicit, traceable, and auditable against the current event taxonomy, sampling configuration, and consent implementation. The WhyChose extractor finds the product analytics discussions in your AI session history — the conversation where the event schema was first sketched, where the sampling rate was mentioned in passing, where someone asked whether the consent banner was blocking the analytics events and the answer was "I think so," and where the autocapture scope was accepted as a default without examining what the product's forms collected — and surfaces those parameters so you can assess which assumptions still hold against the current event taxonomy, MAU distribution, and consent configuration.

The product analytics ADR: five sections

Section 1: Event schema specification and naming convention. Specify the naming convention for event names and property names before the analytics SDK is installed, not after the first inconsistency is discovered: the pattern for event names (verb plus object in snake_case: "feature_viewed", "export_completed", "plan_upgraded"), the case convention for property names, the list of required properties that every event must carry regardless of type (user_id, account_id, session_id, timestamp, platform, product_area), and the list of canonical lifecycle events with their exact trigger conditions — the onboarding funnel events, the activation event, the retention signal events, and the expansion events, defined as ordered lists with explicit trigger conditions rather than informal descriptions. Specify the event proposal process: a pull request or shared document review that checks new event names against existing names before they are shipped, with explicit criteria for when a new event name is appropriate versus when an existing event name with an additional property is the correct instrumentation choice; this review must happen before deployment, not as a retroactive audit after the event name is live in production and has begun accumulating data that cannot be renamed without breaking existing dashboard queries. Specify the schema review cadence: a quarterly review of the event taxonomy that identifies duplicate event names (same user action, multiple event names), deprecated events (events that fired in the prior three months but were not queried in that period), and property schema inconsistencies (the same logical property carrying different names across different events); the quarterly review produces a changelog of schema decisions that makes the taxonomy's evolution traceable for engineers who join the team after the divergence has begun. Connect this section to the audit log decision record: analytics events and audit log events are distinct schemas serving distinct consumers — analytics events must carry the user behavior context required for product analysis, while audit events must carry the account action context required for security and compliance audit; conflating them in a single event stream or sharing naming conventions across both produces schemas that serve neither purpose well, and the analytics decision record must specify which events belong only in the analytics stream, which belong only in the audit log, and which belong in both with different property sets for each consumer.

Section 2: Analytics platform selection and sampling policy. Specify the analytics platform against the product's analysis requirements: the query patterns the product team expects to run (cohort analysis, funnel analysis, retention modeling, behavioral sequence analysis), the minimum event retention period required (12 months for annual cohort comparisons, 24 months for year-over-year retention), and the platform's data model constraints that affect those requirements (sampling behavior, event property limits, query performance at expected event volume). Specify the sampling policy: the sampling rate, the rationale for the rate given the expected MAU at the time of the decision, and the statistical validity threshold — the minimum event volume per month for a feature to support valid analysis at the chosen sampling rate, expressed as a formula so the threshold can be recalculated as MAU grows. Specify the validity monitoring requirement: a quarterly review of the product's usage distribution at the feature level against the validity threshold, with a protocol for the product team when a feature falls below the threshold — either explicitly acknowledging the statistical limitation in any analysis that draws on that feature's data, or supplementing with raw database queries that bypass sampling. Specify the MAU trigger: the MAU level at which the sampling policy must be reviewed given the product's feature penetration distribution, to prevent the sampling configuration from becoming a silent validity problem as the user base grows without any systematic check that the original sampling rate still produces valid analysis for the product's full feature surface. Connect this section to the database backup verification decision record: the raw event data in the primary application database before sampling is the authoritative supplement for features below the sampling validity threshold; the backup retention policy for raw event data determines the historical window available for supplementary analysis; if the analytics platform's event retention is 24 months but the primary database backup retention is 90 days, the supplementary analysis window for sub-threshold features is 90 days not 24 months, and this constraint must be documented so that the product team does not attempt to backfill an analysis from a database backup that no longer exists.

Section 3: Consent architecture, initialization order, and autocapture scope. Specify the analytics consent architecture as an engineering requirement, not as a compliance-layer description: whether the analytics SDK is initialized before or after a confirmed consent signal — the decision record must specify consent-gated initialization as the architectural requirement, not as a preference — the consent signal format (a consent management platform callback, a localStorage flag, a server-side consent record) and the latency between a consent change and the analytics capture behavior change, and the fallback behavior when the consent signal is unavailable. Specify the autocapture configuration: whether autocapture is enabled, which event types are autocaptured, and the exclusion list for personal data surfaces — form fields that collect personal data must be explicitly excluded from autocapture by field name, class, or selector, and the exclusion list must be reviewed and updated whenever a new form is added to the product's UI surface; the autocapture exclusion list review must be a required step in the deployment checklist for any feature that includes a user-facing form. Specify the historical data handling for consent changes: when a user opts out, whether historical analytics events are deleted via the platform's deletion API, anonymized, or retained with a documented legal basis; if deletion is the specified behavior, the deletion API call must be part of the opt-out handler with a defined execution latency, not a deferred action; and the deletion latency — how long between the API call and the data being removed from all platform storage including archives — must be documented in the consent policy so the privacy disclosures are accurate about when a consent change takes full effect. Connect this section to the compliance automation decision record: the consent signal propagation from the consent management platform to the analytics SDK should be automated with a defined latency SLA rather than implemented as a manual configuration that requires a developer to update the analytics initialization code when the consent management platform changes; automated propagation reduces the risk of a consent model change in the CMP not reflected in the analytics initialization because the developer who made the CMP change did not know about the analytics initialization dependency.

Section 4: Personal data handling in analytics events and DSAR scope. Specify the analytics data classification: which event properties contain personal data (user_id, session_id if stable and linked to a user record, IP address if captured, email address if captured, any autocaptured form field value), which contain organizational data, and which contain anonymous behavioral data; this classification must be included in the personal data inventory alongside the classification for the primary database and third-party integrations. Specify the analytics data DSAR scope: the analytics platform is a personal data store for any user whose events contain a personal identifier; DSAR export requests must include analytics event data for the requesting user, and the analytics platform's data export API must be documented in the DSAR response protocol alongside the primary database export. Specify the analytics erasure protocol: the platform deletion API, the trigger condition (opt-out, formal erasure request, account deletion), the expected latency for data removal from platform storage including any backup or archive storage the platform maintains, and the verification mechanism — a follow-up API call or dashboard query that confirms the user's events are no longer queryable after the deletion API's stated latency has elapsed. Specify the PII detection review cadence: a quarterly review of the analytics event stream for personal data that should not be present — email addresses in event properties other than explicitly approved locations, form field content captured through autocapture, device identifiers captured beyond what the consent policy specifies; the review must produce a remediation plan for any PII found, not a documentation update that ratifies the PII as acceptable. Connect this section to the customer data portability decision record: analytics data is personal data under GDPR and must be in scope for portability and erasure; the personal data inventory that drives the DSAR export scope must include the analytics platform alongside the primary database and third-party integrations, and the completeness fraction — the fraction of personal data stores included in the DSAR export — must account for analytics data; an analytics platform that does not provide a per-user data export API must be documented as a known gap in the export completeness fraction with a remediation plan or a documented legal basis for the gap.

Section 5: Analytics governance process, access controls, and schema maintenance cadence. Specify the analytics access control model: who can query the analytics workspace, whether product managers have direct query access or only dashboard access, whether engineers can query raw event data or only aggregated reports, and whether any external parties (investors, advisors, partners) have dashboard access and what data they can see; analytics dashboards that display user-level behavioral data must be subject to the same access control principles as the primary application — access scoped to the minimum required for the consumer's role, with explicit review when access is granted to any party outside the engineering and product teams. Specify the analytics event deprecation process: the process for marking an event deprecated (adding a deprecation marker, documenting the last-fire date, scheduling SDK-side removal), the deprecation review cadence, and the criteria for deprecation (not queried in the prior six months and not expected to be queried in the next six months given the product roadmap); deprecated events that continue to fire increase the event volume without contributing to analysis, which at sampled analytics platforms consumes sample budget and reduces the effective sample rate for events still in active use. Specify the analytics onboarding requirement: a required onboarding component for engineers who will add analytics instrumentation, covering the naming convention, the required property schema, the lifecycle event canonical definitions, and the event proposal process; analytics instrumentation added by engineers who have not been onboarded on the naming convention is the primary source of event schema divergence, and the onboarding requirement closes that gap at the point where new engineers begin contributing to the event taxonomy rather than retroactively after the divergence has accumulated to a scale that requires weeks of normalization to address. Connect this section to the access control model decision record: the analytics access control model must be consistent with the product's access control model — if the product's access control model specifies that a user in a given role cannot see data belonging to other organizations, the analytics dashboard must enforce the same constraint for any analytics access that user has; a product manager with access to a customer-level analytics segment that spans multiple organizational accounts is accessing cross-organizational behavioral data that may be personal data, and the analytics access grant must be reviewed against the product's access control model before it is provisioned.

FAQ