Funnels and webhooks have always been fully self-serve on Mitr — no sales call, no support ticket, just a dashboard form. The one friction left was the blank page: to build a funnel you had to already know which steps mattered and which app each one lived on; to add a webhook you had to already know which event names to filter to. Today both start from a template instead.
Funnels: six starting points
New funnel now opens a template picker before the editor. Pick one and it pre-fills step labels, a plausible event name, and — this is the part that’s actually hard to get right by hand — which of your connected apps each step probably belongs to, resolved against your real, already-registered apps, not a guess.
| Template | Steps |
|---|---|
| SaaS signup → activation | Landing page view → Signup completed → Activation event → Upgraded/purchased |
| E-commerce checkout | Product viewed → Added to cart → Checkout started → Purchase completed |
| Lead gen | Landing page view → Form submitted → Demo booked |
| Mobile onboarding | First open → Signup completed → Key action |
| Free tool → paid customer | Free tool used → Email captured → Signup completed → Purchase completed |
| Email campaign | Email opened → Email clicked → Landed on site → Signup completed → Purchase completed |
Every field stays editable — a template gets you to a sensible starting point faster, it doesn’t lock you in. Full reference at /docs/funnels.
The Email campaign template is listed but not selectable yet. It needs a recipient-identity feature that isn’t shipped — following one person from an email open through to a purchase requires the sender to tell Mitr who the recipient is, hashed client-side before it ever reaches us, the same way identify() already works, so we still never see the raw email address. Rather than ship a template that quietly produces an empty funnel, it stays visible-but-disabled until that lands.
Webhooks: four event bundles, and two we deliberately left out
Add webhook gets the same treatment — pick a bundle of event names instead of typing them from scratch, then adjust as needed. Your destination URL is always yours to paste; a template only pre-fills which events to filter to.
| Template | Event names |
|---|---|
| New signups | signup_completed |
| Revenue events | purchase_completed, subscription_started, refund_issued |
| Churn & cancellations | subscription_cancelled, refund_issued |
| Email opens | email_open |
We’d originally sketched two more — “Traffic anomalies” and “Quota & billing” alerts as webhook templates. Before shipping them we checked how webhook delivery actually triggers in the backend: only off a real, tracked event. Traffic and quota alerts don’t work that way — they go through a separate, one-shot notification path that never touches the event pipeline. A webhook template built on those event names would have looked like it worked and delivered nothing, forever. We dropped both rather than ship something that fails silently. Full reference at /docs/webhooks.
Why this is worth calling out
Templates are a small feature on their own, but they’re built entirely on infrastructure that already shipped — funnels have supported cross-app steps since the funnels launch, and webhooks have had signed, retried delivery from day one. Nothing about the underlying event pipeline, privacy model, or ingestion changed to ship this. That’s deliberate: the fastest way to add a feature safely is to not touch the parts that already work.
If you’re already on Mitr, try both from your dashboard — Funnels → New funnel, or Settings → Webhooks → Add webhook. If you’re not yet, start free — 10,000 events/month, no credit card required, and both of these are there from your first funnel or endpoint.