Field notes / Startup & Product
Front-end events are an API contract
Make event ownership, identity, schemas, and validation visible across UI and data systems.
An event name is an API contract. If the front end sends booking_requested, the data team needs to know whether that means a button click, an accepted server request, or a durable booking. Those are different facts, even if they happen close together.
Consider a synthetic event for a booking attempt. Its purpose is to understand attempted requests, not confirmed revenue. Naming that purpose first prevents a convenient UI signal from becoming an accidental business metric.
Specify meaning before adding properties
1 { 2 "name": "booking_requested", 3 "version": 1, 4 "eventId": "example-attempt-01", 5 "occurredAt": "2026-10-18T12:00:00Z", 6 "userId": null, 7 "consent": "analytics-permitted", 8 "owner": "booking-team" 9 }
This is fictional fixture data. A real contract must define allowed values, retention, consent behavior, and where identity comes from. Do not put free-text form contents into analytics merely because the UI has access to them.
From click to trusted event
A versioned event moves through validation, consent checks, delivery, and deduplication before becoming a durable consumer result.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Sequence: UI to Collector: versioned event and event id; Collector to Schema: validate shape and consent; Schema to Collector: accept or explicit rejection; Collector to Consumer: deliver validated event; Consumer to Store: deduplicate and persist; Store to Consumer: durable result. A versioned event moves through validation, consent checks, delivery, and deduplication before becoming a durable consumer result.
A stable event ID belongs to one occurrence and survives retries of that occurrence. A later user attempt gets a different ID. The collector can then distinguish repeated delivery from repeated behavior instead of guessing from timestamps.
Make disagreements diagnosable
Suppose four deliveries contain three distinct event IDs and represent two people. A delivery count of four, an event count of three, and a people count of two can all be correct. None establishes how many bookings completed. That requires an authoritative completion event or a reconciled transactional source.
The event contract card
An event contract names identity, meaning, version, time, permission, and ownership; the values shown are synthetic.
Illustrative framework · Graphic by Nick JensenRead the diagram as text
Identity: eventId: stable for one occurrence userId: nullable, no guessed identity; Meaning: name: booking_requested version: 1, owner: booking team; Time and permission: occurredAt: source event time consent: explicit permitted purpose An event contract names identity, meaning, version, time, permission, and ownership; the values shown are synthetic.
Record both occurrence and ingestion time when needed, and define which one controls a report's window. Late arrival should produce a documented adjustment policy, not an unexplained disagreement between dashboards. Define anonymous-to-known identity handling explicitly; inventing a user ID to fill a null field changes the denominator.
Review consumers before evolving the schema
Adding a field is not universally safe. A strict JSON Schema consumer can reject unknown properties through additionalProperties: false; the object validation documentation explains that constraint. Exercise old and new consumers with representative fixtures before changing the producer.
For a release, ask for a sample payload, a validation result, a deduplication example, a consent-denied case, and the metric owner who accepted the semantics. A browser assertion that the event function was called proves little about those downstream requirements.
The cost of this discipline is coordination. Keep the contract small, version meaning changes, and publish a migration path for consumers. Continue with the data intelligence guide and API compatibility guide. If your team needs a bridge between product events and reliable data, discuss fractional leadership.
From the idea to the work
Make the workflow useful in a real product.
Bring a product idea, an internal tool, or an AI-assisted workflow that needs a working implementation.