Product Analytics and Privacy-Aware Measurement

Draft 0.1 — 2 August 2026
Analytics can support product and operating decisions. It does not automatically establish causality, legal compliance, user intent, or the truth of a business claim.

Objective

ANUKA products need measurement that is useful enough to guide improvement and restrained enough to preserve participant trust.

The governing rule is:

Collect the smallest reliable evidence needed for a declared product decision, and do not convert operational visibility into generalized surveillance.

Measurement layers

Operational telemetry

Used to operate and secure the service.

Examples:

• request success;
• latency;
• queue depth;
• job status;
• authentication failures;
• provider errors;
• security signals.

Product analytics

Used to understand product adoption and user journeys.

Examples:

• activation;
• feature use;
• completion;
• retention;
• funnel transitions;
• support burden.

Experiment data

Used for registered product experiments and rollout decisions.

Business evidence

Used to support financial, traction, quality, sponsorship, or diligence claims.

Public network metrics

Aggregated and intentionally published information about ANUKA products or network activity.

These layers have different purposes, access, retention, and publication rules.

Measurement plan

Every material analytics implementation has a plan containing:

• product decisions supported;
• user journeys;
• metrics;
• source events;
• identity and deduplication model;
• consent and notice behavior;
• data classes;
• processors;
• retention;
• access roles;
• publication rules;
• experiment use;
• known limitations;
• owner and review date.

“Collect everything; decide later” is not a valid plan.

Event taxonomy

Canonical product events should use:

• stable event type;
• schema version;
• product and environment;
• event ID;
• occurred time;
• actor or subject reference only when needed;
• session, account, organization, or project scope;
• capability and journey;
• result;
• source;
• consent state where relevant;
• trace or correlation reference;
• privacy class;
• provenance.

Event naming

Prefer domain outcomes:

• project.created;
• consent.request.approved;
• feedback.submitted;
• opportunity.assignment.accepted;
• contribution.review.completed;
• payment.refund.completed;
• data_export.completed.

Avoid presentation-specific names such as blue_button_clicked as the only canonical event.

UI interaction events may exist as local analytics details but should map to meaningful journeys.

Event quality

Every event definition states:

• exact trigger;
• required fields;
• optional fields;
• duplicate behavior;
• retry behavior;
• clock source;
• ordering assumptions;
• identity rules;
• test fixtures;
• owner;
• deprecation plan.

Identity and pseudonymity

Analytics may use different identifiers for different purposes.

Possible forms:

• no identifier;
• ephemeral session ID;
• product-scoped pseudonymous ID;
• account ID;
• organization ID;
• experiment assignment key;
• transaction or task ID.

A product-scoped analytics identifier should not become a cross-network tracking identifier without explicit purpose and authorization.

URL and content minimization

Default collection excludes:

• full URL query strings;
• page body text;
• form values;
• passwords;
• authentication tokens;
• private messages;
• unrestricted screenshots;
• full browsing history;
• unrelated tab information;
• sensitive free text.

Paths should be normalized when exact paths are unnecessary.

Consent-aware collection

The analytics layer evaluates:

• site-owner configuration;
• user consent where required;
• account or organization policy;
• browser-extension permission;
• product purpose;
• jurisdiction and contract settings;
• experiment authorization.

Denied consent must prevent the corresponding nonessential collection.

Consent is not inferred from continued site use when the product’s own policy requires explicit authorization.

Essential versus nonessential

Essential operational events

Necessary to deliver, secure, reconcile, or diagnose a user-requested service.

Nonessential product analytics

Useful for improvement but not required for the requested operation.

Optional personalization

Used to change experience based on history or preferences.

Research or secondary use

Used beyond ordinary service improvement and requiring separate review or authorization where appropriate.

Products must document their classification rather than labeling every event essential.

Metric contract

Every important metric defines:

• name;
• purpose;
• owner;
• version;
• formula;
• numerator and denominator where applicable;
• source events;
• eligibility rules;
• exclusions;
• time window;
• timezone;
• attribution;
• data freshness;
• missing data;
• bot and fraud rules;
• identity logic;
• privacy class;
• uncertainty;
• known bias;
• allowed claims.

Common metric classes

Reach

How many eligible people, organizations, or projects encountered a product capability.

Activation

Whether users reached a meaningful first outcome.

Engagement

Meaningful use over time, not raw clicks alone.

Retention

Continued return or continued value at defined intervals.

Quality

Correctness, reliability, accessibility, support, user outcome, or evidence strength in a defined context.

Economy

Charges, refunds, payouts, funded work, attribution, and verified outcomes.

Trust

Consent success, revocation, disputes, correction, incident handling, and verification freshness.

Network value

Cross-product reuse, portable evidence, completed contribution loops, and resident-product adoption.

North Star metrics

A North Star must be paired with guardrails.

Candidate ANUKA network metric:

Monthly Verified Improvement Loops

A loop counts only when:

• a real signal or opportunity existed;
• a bounded intervention occurred;
• outcome evidence was captured;
• review was completed;
• status and attribution were recorded;
• the result was not duplicated.

It does not require a positive outcome; valid negative learning may count separately.

Guardrails

Examples:

• accessibility barriers;
• privacy complaints;
• support load;
• fraud;
• refund and dispute rates;
• security incidents;
• contributor rejection or nonpayment;
• user churn;
• data-quality failure;
• SLO burn;
• concentration of opportunity or reward.

Growth that damages guardrails is not healthy product improvement.

Funnel design

Funnels should map to real journeys.

Example consent funnel:

request_received → request_viewed → items_selected → approved_or_denied → presentation_delivered → access_revoked_or_expired

Funnels must preserve denial and abandonment rather than considering only success paths.

Retention analysis

Retention requires an explicit value event.

Avoid treating any return visit as retained value.

Possible definitions:

• contributor completes another verified contribution;
• company publishes another funded opportunity;
• product completes another verified improvement loop;
• verifier performs another holder-approved request;
• user successfully uses a critical workflow again.

Attribution

Attribution models must state their limitations.

Possible models:

• direct source;
• first touch;
• last touch;
• multi-touch;
• experiment-based incrementality;
• contract-defined attribution;
• evidence-weighted contribution attribution.

Marketing attribution is not the same as causal product impact or contributor value attribution.

Cohorts and segmentation

Segments may include:

• product lifecycle state;
• acquisition source;
• plan;
• organization size;
• supported region;
• contribution type;
• protocol version;
• product cohort;
• experiment variant.

Sensitive traits and inferred protected categories require a defined, reviewed purpose and strict access.

Segmentation must not become covert eligibility scoring.

Small cohorts and re-identification

Public or broadly shared metrics should apply:

• minimum cohort sizes;
• suppression;
• aggregation;
• rounding;
• delay;
• removal of unique dimensions;
• access control;
• disclosure review.

Exact thresholds depend on context and cannot be one universal number.

Public metrics

Each public metric declares:

• exact definition;
• source;
• aggregation;
• update frequency;
• date range;
• evidence or verification status;
• modeled versus observed status;
• corrections;
• owner;
• expiry or archive policy.

Public dashboards must not imply real-time precision when data is delayed or sampled.

Business claims

Analytics may support claims only when:

• the metric contract matches the wording;
• data quality is sufficient;
• the time window is stated;
• comparisons use appropriate baselines;
• uncertainty and limitations are not hidden;
• verification status is accurate;
• claims are reviewed before publication.

“Customers save 40%” cannot be inferred from one selected cohort without appropriate qualification.

Analytics processors

For every provider record:

• provider identity;
• purpose;
• data fields;
• region;
• retention;
• subprocessor considerations;
• access;
• export and deletion;
• security posture;
• contract owner;
• fallback or migration plan.

Vendor dashboards are projections, not canonical product records.

Data retention

Default directions:

• raw event data: short period needed for quality and debugging;
• aggregate product metrics: longer where useful;
• experiment exposure and decision evidence: retained with the experiment record;
• financial and contractual evidence: retained according to obligations;
• public metrics: archived with definitions;
• sensitive user-level analytics: minimized and shorter.

Retention must be enforceable, not aspirational prose.

Access control

Analytics roles distinguish:

• instrumentation developer;
• product analyst;
• experiment analyst;
• support investigator;
• security investigator;
• finance analyst;
• product owner;
• public viewer.

Access is purpose-bound and logged for sensitive datasets.

Analytics environments

Separate:

• local and synthetic testing;
• sandbox;
• staging;
• production;
• controlled research datasets.

Test accounts and automated traffic must be identifiable and excluded where appropriate.

Data quality monitoring

Monitor:

• schema validity;
• event volume changes;
• missing fields;
• duplicate rate;
• delayed events;
• invalid timestamps;
• identity conflicts;
• consent mismatch;
• variant imbalance;
• pipeline freshness;
• provider discrepancy;
• metric revisions.

A broken analytics pipeline can be a launch blocker when decisions depend on it.

Corrections

When metric defects are found:

• stop unsupported claims;
• identify affected reports and decisions;
• correct the pipeline;
• backfill only when reproducible;
• version changed definitions;
• publish corrections when public claims were affected;
• preserve the historical record;
• re-evaluate experiments or rewards where material.

AI and analytics

Agents may:

• query authorized aggregates;
• detect data-quality anomalies;
• draft interpretations;
• compare metric definitions;
• summarize experiment results;
• propose questions.

Agents must not:

• broaden data access;
• infer sensitive traits without authorization;
• expose small cohorts;
• fabricate causal explanations;
• publish claims without review;
• use private analytics for unrelated model training;
• create universal scores.

Participant transparency

Where practical, participants should be able to understand:

• what product analytics are active;
• which identifiers are used;
• whether data leaves the device;
• purpose;
• retention;
• processors;
• consent state;
• how to opt out or revoke optional collection;
• how to request export, correction, or deletion where applicable.

Measurement governance

Material metrics and public claims receive:

• owner;
• reviewer;
• version;
• approval;
• change history;
• challenge and correction route;
• scheduled review.

Metric definitions are governed artifacts.

Anti-patterns

• capture every click forever;
• cross-site identity by default;
• full URLs and page text without need;
• declaring all analytics essential;
• changing metric definitions silently;
• using averages that hide severe cohorts;
• public live maps that reveal individuals;
• dashboards without correction history;
• AI-generated causal stories;
• growth targets without privacy, accessibility, quality, or support guardrails;
• treating analytics provider data as canonical truth.

MVP acceptance criteria

• measurement plans state decisions and purposes;
• canonical events use versioned schemas;
• identifiers are product-scoped and minimized;
• consent state is enforced;
• metrics have contracts;
• North Star metrics include guardrails;
• public metrics have definitions and provenance;
• small cohorts receive disclosure protection;
• providers are inventoried;
• retention is enforced;
• data-quality monitoring exists;
• public-claim corrections are supported;
• AI use remains purpose-bound and reviewed.

Related documents

• 051 — Canonical Data and Event Model
• 026 — Consent and Data Request Protocol
• 035 — Value Attribution and Outcome Measurement
• 063 — Experimentation, Feature Flags, and Rollouts

Verification record

• Measurement baseline checked: 2 August 2026
• Generalized browsing surveillance: Prohibited
• Metric definition versioning: Required
• Automated causal claims: Prohibited