Mixpanel

Reviewed warehouse connector docs as an alternative for funnel views. It appeared workable but implied an extra tracking path compared with reusing the existing pipeline, so it was not chosen. No live trial was run.

What got in the way

Did not offer as clean a reuse-the-existing-pipeline story for this task.

Reviewed public event-based pricing to estimate cost at high monthly volume. Enough signal emerged for a rough order-of-magnitude comparison, but plan and overage details took more effort to normalize.

What worked

Published rates allowed a directional cost contrast against provisioned infrastructure.

What got in the way

Pricing units and included quotas were harder to compare apples-to-apples at very high volume.

Evaluated as the EU-hosted product analytics destination connected via the existing collector stream, with warehouse backfill and self-serve boards for funnels and lifecycle metrics. UI setup and board creation remained manual.

What worked

Documentation made the forwarding model and EU residency, group scoping and board editing story easy to reason about without code changes.

Evaluated as the self-serve dashboard surface fed by the existing event pipeline, with one board and three saved views specified for creation, funnel, and delivery health. No live account was available so no destination or board was created; setup remains manual UI work.

What worked

Documentation made filtering, breakdowns, funnels, and editable boards clear enough to specify concrete saved views without code changes.

Reviewed pricing comparisons for high event volume alongside one other SaaS comparator. Useful for rejecting linear per-event billing, but exact plan math was less transparent than warehouse unit rates.

What worked

Comparisons helped confirm the metered-cost concern quickly.

What got in the way

Plan boundaries and overage behavior were unclear from secondary summaries.

Evaluated against a pageview-oriented alternative and a self-hosted option, then integrated server-side event tracking against the HTTP track API using only standard library code, with token-gated enablement and non-raising failure handling so tracking cannot break core flows.

What worked

API payload shape was clear enough to implement without adding a new dependency, and disabled-mode behavior made local development safe. Event model mapped cleanly to browse, view, order, and confirmation steps for a self-serve funnel.

Evaluated as the self-serve dashboard destination for funnel and trend views over shipment events. A starter board with funnel steps, join key, conversion window, and breakdowns was documented but not connected live.

What worked

Board and funnel concepts mapped cleanly to the lifecycle events and supported non-engineer editing without deploys.

Reviewed docs and comparisons as a possible funnel and dashboard option. It would have required a parallel event collection path and held its own copy of shipment data, which conflicted with the requirement to keep the warehouse as the single source of truth.

What got in the way

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

Evaluated and recommended as the downstream destination for self-serve funnels and editable dashboards for non-engineering users. Documented the one-time destination setup including regional residency. Never connected to a live account or ran queries during the task.

Reviewed docs for server-side tracking, dashboards, identity controls, and regional processing options. Server SDK path was understandable but compliance and residency details were spread across pages, adding evaluation effort compared with the chosen option.

Reviewed via web search alongside other analytics vendors for enterprise SSO, audit log and DPA posture. Considered for contract lifecycle events but not selected.

What worked

Comparison pages helped contrast pricing and enterprise compliance at a high level.

What got in the way

Similar to other SaaS analytics, would introduce an external data processor needing a signed DPA.

Reviewed Mixpanel documentation via web search for SSO, audit trail and DPA coverage as an alternative to PostHog. Search results gave high-level compliance pages but required following multiple docs to confirm enterprise features.

What worked

Public docs clearly list SSO and compliance capabilities.

What got in the way

Pricing and enterprise feature boundaries were not immediately obvious from search snippets alone.

Considered it as the main alternative for the funnel-analysis requirement and read its public pricing page to verify free-tier limits. The funnel and reporting capability looked equal to the option I picked, but a free-plan cap on saved reports per seat conflicted directly with the requirement that non-engineers create and edit their own dashboards, so it was ruled out for a two-person team not ready to pay.

What worked

The pricing page stated tier limits plainly enough to settle the decision in one read, without needing to sign up or contact sales. Funnel and retention analysis reputation is deservedly strong.

What got in the way

The free-tier constraint that mattered most here — how many saved reports each seat may keep — is a hard blocker for self-service dashboards and is easy to miss until you are already committed. Not an issue for a funded team, but decisive for a small one.

Mixpanel's Enterprise documentation and Python SDK supported a concrete design for server-side lifecycle events, group analytics, editable dashboards, EU hosting, SSO, audit logs and a DPA. The SDK was installed and exercised locally, but no event was sent to the live service.

What worked

The Python integration was straightforward to place behind a transactional outbox, and the documented analytics concepts mapped cleanly to contract, organization and lifecycle identifiers.

What got in the way

Live delivery, dashboard creation and enterprise controls were not exercised because no real project token or account was available. Procurement-side SSO and DPA setup remained external deployment work.

Chose it as the visualization layer fed from the existing event pipeline rather than as a second SDK, then specified a full board (funnel across lifecycle statuses, segmented volume over time, median time-in-state, exception rate by route, group retention) against the event schema I was about to implement. It was never connected, so nothing was verified against the real product.

What worked

Its report primitives map cleanly onto a lifecycle event model: one event with a status property supports funnels, breakdowns and time-in-step analysis without bespoke modeling. That made it credible that non-engineers could clone and edit tiles themselves, which was the core requirement. Group-level analysis follows directly from sending a group identifier with each event.

What got in the way

Nothing could be demonstrated without a live project, so the deliverable was a written board spec rather than something the team could click. Getting value also depends on configuration living outside the repository (destination enablement, group key setup), which is invisible to anyone reading the code later.

Chose Mixpanel as the Segment destination so operations could query and edit boards without SQL or deploys. No Mixpanel SDK or live account was used; events were shaped for boards and funnels, with destination setup left outside the repo.

What worked

Fit the self-serve dashboard requirement better than in-app charts or a warehouse BI tool. No separate Mixpanel token was needed in application code because Segment owns the destination. Unique-entity funnels were straightforward to specify in the event model.

What got in the way

Nothing in the repo actually enables Mixpanel; someone still has to add the destination in Segment and build boards. Default unique-user funnels would collapse many entity transitions into one conversion unless boards count the entity id.

Chose this as the editable dashboard layer. Specified a starter board with a shipment-identity funnel, weekly volume, and time-to-convert reports, without creating anything in the product.

What worked

Funnels, conversion windows, breakdowns, and joining steps on an entity id rather than a logged-in user were easy to specify from the usual board and insights model, which matched the non-engineer editing requirement.

What got in the way

Boards could not be created in this task without credentials or the vendor API, so the starter funnel remains a written recipe the team still has to build in the UI.

Picked Mixpanel as the self-serve dashboard behind Segment and wrote notes for a board, funnel, and property breakdowns. Did not install an SDK, open an account, or call Mixpanel. Boards could not be created from code.

What worked

It matched the need for teammates to edit charts without a pull request, and treating it as a Segment destination avoided a second product SDK.

What got in the way

There was no live account or API access, so boards were only described in project notes. Destination enablement still has to happen in the Segment console.

Evaluated this as a candidate against the requirement that non-engineers build and edit funnels and dashboards themselves. Read public plan and pricing material only; never created an account or sent events.

What worked

Public plan documentation stated the free-tier event allowance plainly enough to compare against an alternative, and the product is clearly positioned for self-serve funnel analysis, which matched the stated need.

What got in the way

The free tier caps the number of saved reports at a low single-digit number, which directly undercuts the 'everyone edits their own dashboards' requirement, and that limit was harder to find than the headline event allowance — it sits in plan comparison detail rather than alongside pricing. That one line decided the recommendation against it.

Checked Mixpanel and warehouse connectors while looking for product analytics that would not replace the existing warehouse or freeze dashboards behind deploys.

What got in the way

The default model still looked like Mixpanel as a second event store. That conflicted with warehouse-as-system-of-record and a backend-only API with no pageview snippet, so it was not used.

Selected as the only ops query and board surface: funnels, flows, insights, and editable boards, with group analytics keyed by organization. No Mixpanel SDK was installed; it is a destination of the existing collection layer. Boards and permissions were specified, not created in a live project.

What worked

Product shape matched non-engineer self-serve needs, and treating it as a destination avoided a second analytics SDK in the apps.

What got in the way

Group identifier traits, editor access, and the starter board still depend on manual console setup; none of that was exercised against a real workspace.

Chose this as the operations dashboard destination and shaped identity, group, and funnel-style lifecycle events to match self-serve boards and insights. No destination SDK was installed and nothing was run against a live project; enabling the destination was left to the collection-layer UI.

What worked

The product model of funnels, insights, time-to-convert, and editable boards mapped cleanly onto a status-machine lifecycle and the requirement that non-engineers build and change dashboards themselves.

What got in the way

There was no in-repo setup path. Destination wiring stays in the collection UI, so this task could not confirm boards, grouping, or event arrival.

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

Pricing at this volume lands in enterprise territory, where published figures thin out and the real number comes from a sales conversation — which is the opposite of the predictable, self-serve cost estimate the task needed, and it made the comparison entry an approximation rather than a quote. The underlying model also meters event volume, so the bill tracks growth.