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 errors those people hit, and from the commit most likely behind them.
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: sequential counts the users who did the steps in order, presence counts each step on its own in the window (sessions by default).
Because the dashboard also holds your log and metric panels, a conversion dip and a deploy at the same moment are visible on the same screen. Seeing them together is a lead to check, not proof that the deploy caused the dip.
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 classic cohort triangle: pick the event that starts a cohort, optionally the event that counts as coming back, and daily or weekly buckets. Each row is everyone whose first cohort event fell in that period; each cell is the share who returned N periods later.
Unfinished periods render as pending rather than as churn, so this week's cohort does not look like a collapse. Identity falls back to the anonymous id, so device-level retention works before anyone signs in.
Retention cohort: signup · weekly
W0 W1 W2 W3
Aug 04 1,204 100% 42% 31% 27%
Aug 11 1,388 100% 45% 33% 28%
Aug 18 1,502 100% 44% 30% ·
Aug 25 1,610 100% 46% · ·
· = period still in progress, not churnThe 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. Two things worth knowing before you rely on it:
ZipLogger does record real sessions now — but nothing is recorded until an admin enables it for the workspace, and then only the share of sessions you choose. It is a DOM recording rather than video, so a session is a few hundred kilobytes of real text, and everything typed into a field is masked in the browser before it is sent.
What it cannot capture: cross-origin iframes, canvas and the contents of video. Images load from your own origin when a replay is watched, so an expired URL shows as broken. How session replay works →
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. Each plan includes a monthly allowance of product-event data, measured in bytes, with a daily safety ceiling; paid plans can opt into per-GB overage (off by default, under a spend cap you set) instead of a hard stop. There is no separate analytics product to buy. See the full table →