中文
devexamples
← Workflows

阅读中文版本

Product Analytics Event Schema Workflow

Define a tracking plan for events and properties, enforce it in code review, validate incoming events, and keep naming consistent over time.

intermediate~90 minanalyticsdata-qualityproduct

Objective

Ensure analytics events are consistent and well-defined so product decisions rest on trustworthy data.

Environment

  • A tracking plan document or registry
  • An analytics backend with validation

Steps

1. Define events, properties, and naming conventions

Define events, properties, and naming conventions in a tracking plan.

Expected state: There is one reference for every event.

2. Require the plan to be updated

Require the plan to be updated and reviewed with code changes.

Expected state: Instrumentation does not drift.

3. Validate incoming events against the schema

Validate incoming events against the schema and quarantine bad ones.

Expected state: Data quality is enforced at ingestion.

4. Review event usage periodically and remove

Review event usage periodically and remove dead events.

Expected state: The schema stays meaningful.

Decision points

Validate at ingestion or only at send?

  • Both
  • Send only

Both; client validation is bypassable and does not protect the warehouse.

Rename events for consistency?

  • Yes, with migration
  • Keep historic names

Rename with a migration window and aliases so historic dashboards do not break.

Expected outcome

A tracking plan enforced in review and at ingestion, producing consistent events and no dead instrumentation.

Verification

Confirm ingestion quarantines schema-invalid events and that the plan lists every event the app sends with matching properties.

Cleanup

Deprecate unused events and update the plan version.

Overview

Ensure analytics events are consistent and well-defined so product decisions rest on trustworthy data. Confirm ingestion quarantines schema-invalid events and that the plan lists every event the app sends with matching properties.

Steps

  1. Define events, properties, and naming conventions in a tracking plan. Expected state: There is one reference for every event.
  2. Require the plan to be updated and reviewed with code changes. Expected state: Instrumentation does not drift.
  3. Validate incoming events against the schema and quarantine bad ones. Expected state: Data quality is enforced at ingestion.
  4. Review event usage periodically and remove dead events. Expected state: The schema stays meaningful.
track('checkout_completed', {
  order_id: string,
  value_cents: number,
  currency: 'USD' | 'EUR',
  // validated against the tracking plan
});

Verification

  • A tracking plan enforced in review and at ingestion, producing consistent events and no dead instrumentation.

Decision points

  • Validate at ingestion or only at send? Options: Both; Send only. Recommended: Both; client validation is bypassable and does not protect the warehouse.
  • Rename events for consistency? Options: Yes, with migration; Keep historic names. Recommended: Rename with a migration window and aliases so historic dashboards do not break.