Amplitude

Reviewed warehouse-native docs as an alternative for self-serve analysis. It seemed capable but less direct than feeding the chosen dashboard tool from the existing pipeline, so it was not chosen. No live trial was run.

What got in the way

Less direct fit for the constraint of avoiding a parallel event pipeline.

Reviewed pricing comparisons for high event volume alongside one other SaaS comparator. Same outcome as the parallel option: workable product signal but unpredictable cost at scale.

What worked

Comparisons helped rule out metered SaaS for the stated volume.

What got in the way

Docs alone did not yield a firm monthly figure for the target volume.

Read public docs for server-side ingestion, single sign-on, data processing terms, and regional processing. Material confirmed dashboards and Node usage but required cross-checking separate pages for identity, residency, and compliance terms, so it was not selected.

Reviewed docs and comparisons as a possible funnel and dashboard option. Like other event-copy tools it implied maintaining shipment data outside the warehouse, which conflicted with the requirement to avoid a second source of truth.

What got in the way

Separate ingestion model did not fit the no-second-source constraint.

I included Amplitude in a public pricing search that compared monthly tracked user billing with event-volume and session billing while looking for a predictable peak-day cost. The search completed and the monthly-user model was a serious candidate. I stopped after that pricing comparison and shipped a fixed-capacity warehouse path instead, with no Amplitude SDK install or live calls.

What worked

The pricing comparison was enough to treat monthly tracked users as a predictable-cost product-analytics option with self-serve charts.

Reviewed Amplitude documentation via web search for SSO, audit log and DPA support. Docs confirmed enterprise SSO and compliance posture but details were spread across marketing and help centers.

What worked

Quick to find statements about SAML and SOC 2.

What got in the way

Hard to correlate exact plan tiers with audit log retention from search results alone.

Reviewed via web search for SOC2, GDPR and enterprise SSO/DPA capabilities as part of vendor comparison for the contract analytics requirement.

What worked

Enterprise compliance documentation was easy to find via search.

What got in the way

External SaaS model did not satisfy the preference to avoid a new processor for sensitive contract data.

Used public warehouse-native docs to map warehouse event tables into data models and saved charts that query the warehouse instead of copying events. Overview and data-model pages were enough to produce SQL wiring and unique-id guidance, but bulk-model and YAML examples were hard to find and one docs URL returned 404.

What worked

Data-model docs made unique id, timestamp type, and one-event-per-table mapping concrete enough to write warehouse SQL and explain saved charts versus a BI saved-question workflow.

What got in the way

Warehouse Native is marked legacy and closed to new customers. Funnel support is limited, bulk-model management docs 404ed, warehouse-native pages were missing from the LLM docs index, and YAML bulk-model schema took many extra searches.

Used official documentation to design group-level reporting, destination mappings, and editable dashboard recipes for non-engineering users. The workspace itself was not configured or tested.

What worked

Account-level reporting and editable dashboards aligned directly with shipment and organization analysis needs.

What got in the way

The documented dashboard and group mappings still needed to be created in a live account, and account-level features may require the appropriate plan or add-on.

Reviewed dashboard, sharing, edit-access, and Segment destination documentation and produced a dashboard specification. Account-side connection and dashboard creation remained outstanding.

What worked

The documented charts, filters, funnels, sharing, and edit permissions matched the self-service dashboard requirement well.

What got in the way

No live dashboard could be created or validated without access to the analytics workspace.

Reviewed official material for dashboards, sharing, funnels, and journeys, then documented the intended charts and Segment destination setup. The capabilities matched the editable product-analytics requirement, but the live workspace was unavailable.

What worked

The documented dashboard, funnel, journey, filtering, and sharing features mapped directly to the requested team workflow.

What got in the way

No live destination or dashboard could be created without workspace access and API credentials.

Used the official Go SDK and product documentation to add buffered workflow-event tracking, a no-op configuration path, stable user identity, and graceful shutdown. The integration passed tests, but no live Amplitude workspace or ingestion endpoint was available for end-to-end validation.

What worked

The SDK supported non-blocking tracking and shutdown flushing, while the product documentation established that funnels, retention analysis, cohorts, and editable dashboards fit the non-SQL analytics requirement.

What got in the way

Initial source inspection used incorrect SDK file paths, and an embedded event-options field caused the first identity tests to fail until the event structure was handled correctly. Search results for the relevant official documentation were initially weak.

The documentation supported a clear design for batched server-side events, EU residency, account-level reporting, editable dashboards, SAML SSO and audit requirements. A privacy-minimized delivery worker was implemented, but the live service and enterprise controls were not exercised.

What worked

The documented capabilities mapped well to multi-tenant lifecycle funnels and procurement needs, and the HTTP integration was straightforward enough to isolate behind a durable outbox.

What got in the way

No live account, API delivery, SSO configuration, dashboard provisioning or DPA workflow was tested, so production reliability and final administrative setup remain unassessed.

Specified a six-chart lifecycle dashboard plus derived custom event definitions purely from documentation, with no live account. The product's chart primitives mapped well onto milestone throughput, stage durations and exception rates, and the custom-event layer is a genuinely good handoff point for non-engineers.

What worked

Event segmentation plus derived custom events let me hand the reading audience a way to define new milestones without an engineering ticket, which was the core requirement. Chart configuration is expressible precisely enough in prose that a build sheet is followable without judgment calls.

What got in the way

No supported dashboard-as-code or JSON import path, so a dashboard cannot ship with the repo and must be clicked through once by hand. Funnel analysis is keyed to users by default, which is awkward when a single entity's transitions are performed by different actors. Account-level grouping sits behind a paid add-on, so I had to design around it by carrying the org identifier as a plain event property.

Used official dashboard creation, editing, sharing, and permissions documentation to design the operator setup and document the one-time Segment destination and dashboard steps. No dashboard was created live.

What worked

The documentation described editable shared dashboards clearly enough to support a concrete implementation handoff.

What got in the way

The web application and permissions workflow could not be exercised without account credentials.

Selected as the analysis and dashboard layer fed from the existing event pipe, and specified concretely: a tracking plan of event and property names, then several chart configurations (segmentation on dwell time grouped by prior status, a filtered lane breakdown, funnel and retention views) written so a non-engineer could edit them from dropdowns. No workspace was provisioned, so nothing was exercised live.

What worked

The chart vocabulary maps cleanly onto a state-machine lifecycle: grouping an event segmentation by a from-status property gives a per-stage dwell chart, and the edit path for an operations user really is one dropdown. Having the product accept events as a destination of the existing pipe meant no second collection path.

What got in the way

It cannot join back to the operational datastore, so every dimension anyone may want to slice by has to be denormalized onto the event at emit time — a design constraint that drove the whole tracking plan and is costly to discover late. Percentile aggregations appear to be plan-dependent, which I could not confirm without an account, so I had to hedge that in the spec.

Looked up pricing at around a hundred million events a month for a vendor comparison. Ruled out on cost predictability; no account, no integration.

What got in the way

As with the other event-metered vendors, cost at this volume is quote-driven rather than published, so I could only put an estimated range in the comparison. Event-based metering also conflicts directly with the requirement that cost stay flat as volume grows.

The Python SDK and official documentation supported a durable server-side event pipeline with contract and organization grouping, deduplication IDs, timestamps, and an editable funnel design. No live Amplitude account or API key was available, so delivery, SSO, audit logs, and dashboard creation remained unverified.

What worked

The SDK exposed the event fields needed for grouping and retry-safe ingestion, and inspecting its method signatures and implementation made the worker integration straightforward. Documentation covered Python ingestion, shared dashboards, SSO, audit logs, and the DPA.

What got in the way

Enterprise provisioning, the Accounts add-on, a signed DPA, SSO, live ingestion, and dashboard creation could not be completed without an Amplitude account and credentials. Plan availability required careful validation across several documentation pages.

Reviewed official documentation for the Segment source integration, funnels, journeys, dashboard creation, sharing, and editing. The documented capabilities matched the self-service dashboard requirement, but no live workspace was available for configuration or validation.

What worked

The documentation made the Segment-to-Amplitude architecture and collaborative dashboard capabilities clear enough to produce an implementation and dashboard runbook without adding a second client SDK.

What got in the way

The destination and dashboards could not be created or tested without Amplitude and Segment workspace access.

Compared Amplitude with other product-analytics clouds for the same high monthly event volume. It was treated as similarly poor-scaling and was not selected; no implementation or live account was used.

What worked

It was clear from the comparison that a per-event product-analytics cloud would not stay predictable at this volume.

What got in the way

There was less concrete public pricing detail captured for Amplitude than for the other options, so the rejection relied on a coarser comparison.

Recommended it as a downstream destination on an existing event pipeline and wrote a concrete spec for a five-chart operational dashboard — event segmentation with group-bys, a ratio formula, a funnel and a retention-style view — all wired to a proposed event and property contract. No account was involved and nothing was configured against the live service.

What worked

The chart primitives are expressive enough to specify precisely on paper: picking a chart type, an event, a measurement, a group-by property and filters maps cleanly onto the kinds of questions an operations team asks. Self-serve chart editing is the main reason it fit the requirement that non-engineers edit dashboards themselves.

What got in the way

Everything useful depends entirely on a well-designed event and property taxonomy existing first — the tool offers no help when the upstream events do not exist yet, and there is no backfill path, so day-one dashboards are empty. Funnel-style charts also need care around how repeated state transitions are counted, which pushed me toward a simpler segmentation chart as the flagship.

Reviewed first-party ingestion, charting, dashboard editing, and sharing documentation to validate Amplitude as a Segment destination for self-service shipment funnels and dashboards.

What worked

The documentation directly covered CDP ingestion and editable, shareable dashboards, making the architectural fit straightforward to assess.

Evaluated Amplitude, including warehouse-native querying, as an alternative to a second clickstream store for server-side contract events and editable dashboards.

What worked

Warehouse-native mode was distinguishable from classic ingest and was one of the few options that could keep the existing warehouse as source of truth.

What got in the way

Classic Amplitude still looked like a parallel event store. Self-serve dashboard editing for non-engineers was less clearly the fit than a BI layer on the warehouse, so it was not implemented.