A reliable product analytics pipeline with Amplitude

The scenario

Consider a web product where people sign up, create a workspace, invite a colleague, and finish a first project. The team wants an activation funnel, but browser clicks and backend actions are currently mixed together. This scenario would establish a small, auditable event pipeline before building more dashboards.

Give each event a business meaning

The event contract would describe completed domain actions rather than component names. Workspace Created would mean the backend committed a workspace; Create Button Clicked would describe interface behaviour. Using different events prevents failed requests from appearing as successful activation.

Each contract would define required properties, permitted values, an owner, and a schema version. A TypeScript type helps application authors, while runtime validation protects the ingestion boundary. Raw request bodies, tokens, and free-form user content would be excluded from the event schema.

{
  "event_id": "evt_example_01",
  "event_type": "Workspace Created",
  "account_id": "acct_example_01",
  "schema_version": 1,
  "properties": { "entry_point": "onboarding" }
}

Separate committing an action from delivering analytics

The backend could write an outbox row in the same database transaction as the workspace. A worker would send eligible events and record delivery status. An analytics outage would then delay reporting without blocking workspace creation.

An Amplitude HTTP V2 adapter would map the internal event to the vendor payload and use the original event time in milliseconds. It would preserve insert_id and device identity across retries. Amplitude’s documented deduplication window is bounded, so the outbox would also retain its own delivery bookkeeping.

Build the first funnel from verified journeys

A first dashboard would connect sign-up, workspace creation, invitation, and first project completion using agreed definitions. Cohorts would distinguish new and existing accounts. The team would record the intended time window and whether the funnel is measured by user or by account.

Quality checks would cover duplicate delivery, missing required properties, and event changes across application versions. A documented event deprecation process would keep old and new releases interpretable. Only after these checks would the funnel be useful for evaluating an onboarding change.

What to validate

• A rolled-back transaction produces no completed-action event.
• Retries preserve event identity and original timestamps.
• Account and user funnels use the intended identity model.
• A synthetic onboarding journey produces the expected sequence.

The tradeoff

An outbox adds a worker and operational state. Browser-only interface events may not need it. Use stronger delivery guarantees for business events where missing or duplicate data would change a product decision.