ZipLogger tracks product events next to the logs, traces and exceptions they happen alongside. So when a funnel drops, you are one click from the error that caused it, and from the commit that introduced it.
One SDK for logs and events · Mixpanel-compatible ingestion · No extra product to buy
Expand any error pattern in Search and ask. ZipLogger correlates the events around that error by trace id and session, and answers with the common journey into it, how many users were affected, and where they were. The regression block sits right next to it, so the path from symptom to cause to commit is one screen.
This is the join a separate analytics product cannot make. Your events and your stack traces have to be in the same system to be asked about together.
Payment failed: card_declined — Charge() 214 events · term 31d
Journey into this error
1. Viewed pricing 214
2. Started checkout 214
3. Applied coupon 198 ← 92%
4. Submitted payment 214
Affected 186 users · top: US 61, DE 24, IL 19Total events, unique users, sessions and events per user across any time range, then group by whatever matters: event name, service, environment, country, device type, browser, or release version. Top events, countries, devices and browsers come as standing panels.
Events 1,284,902 Unique users 48,201
Sessions 112,430 Events / user 26.7
Top events
page_view 812,004
checkout_started 41,882
purchase 18,209
payment_failed 214Build a funnel from any sequence of events and put it on a dashboard next to your error rates and latency. Two modes: presence counts users who did each step at all in the window, sequential counts only those who did them in order.
Because the dashboard also holds your log and metric panels, a conversion dip and the deploy that caused it are visible on the same screen.
Signup funnel sequential · 30d
visited_pricing 12,400 ████████████ 100%
started_signup 6,820 ██████▌ 55%
verified_email 5,140 ████▉ 41%
created_workspace 4,905 ████▋ 40%
first_log_received 3,260 ███ 26%The ZipLogger .NET packages register an IEventTracker alongside the logging
provider, so Track() and Identify() are injectable next to
ILogger, sharing one queue, one connection and one API key. Nothing new
to install, no second vendor script on your pages.
Anything else can POST to the events endpoint directly: a single object, a JSON array, or NDJSON: the same shapes the log endpoint accepts.
// Injected next to ILogger — same queue, same key.
public CheckoutService(ILogger<CheckoutService> log,
IEventTracker events)
events.Identify(userId, new { plan = "team" });
events.Track("checkout_started", new {
cart = cart.Id,
total = cart.Total,
});ZipLogger accepts Mixpanel-shaped payloads on three routes, so an app already instrumented with Mixpanel can send to ZipLogger by pointing the SDK at a new host and swapping the project token for a ZipLogger ingest key. Event names, properties and identity calls keep working as written. See exactly what is supported →
ZipLogger is an observability platform that also does product analytics, not a replacement for a dedicated analytics suite. Two things it deliberately does not do today:
Funnels, sessions and user histories are here; week-over-week retention cohorts are not. If retention curves are the question you buy a tool to answer, keep the tool that answers it.
User profiles are computed from the event stream rather than kept as a mutable document.
A Mixpanel $set is accepted and recorded as an event, so the properties stay
queryable, but this is not a profile store you can overwrite in place.
Analytics events are part of the same subscription as your logs, metered separately and shown in the app: 5,000 events/day on Free, 50K on Pro, 500K on Team and 2M on Business, with per-1K overage on paid plans instead of a hard stop. There is no separate analytics product to buy. See the full table →