BleedWatch
Available from Community

The cookieless marketing stack I bet on.

No Google Analytics. No Hotjar. No FullStory. Why a security product can't credibly run the same tracking stack it warns customers about — and what I built instead.

Founder byline - 2026-03-28

The contradiction nobody on the buy side talks about

A B2B security vendor sells you on the premise that they're going to help you understand what data your team is leaking. Then they ask you to load their marketing site, which loads Google Analytics, which loads Tag Manager, which loads a Hotjar session replay, which fingerprints your browser, which builds a behavioral profile that gets stored on US infrastructure under a CCPA carve-out that probably doesn't apply to your tenants in Frankfurt.

Every B2B security vendor does this. Most CISOs ignore it because everyone does it. It's still embarrassing.

When I built BleedWatch's marketing site, I sat with this for a few hours and decided I couldn't credibly run that stack on a product whose pitch is "we'll show you what's leaking." The stack I ended up with is different. This article is the field notes from the decision.

The stack, named

Web analytics: Umami, self-hosted. Runs on analytics.bleedwatch.com, on our own Hetzner box in Falkenstein. Cookie-free by design. Tracks page views and named events (form submissions, CTA clicks). Zero PII storage. No cross-site fingerprinting. The total disk footprint of the analytics database after six months of traffic is under 600MB.

Error monitoring: nothing third-party. Errors land in our own log pipeline through Caddy + Vector + a small Postgres tail. Sentry is a fine product. I don't run it because the cost of having every uncaught client-side stack trace travel to a US-hosted SaaS is higher than the cost of building a smaller equivalent in-house.

Session replay: nothing. Hotjar, FullStory, LogRocket — all unshipped. The product team makes UX decisions from explicit interviews + named-event analytics + the periodic "watch a CISO try the trial" video call. Replay watching is a productivity trap, IMO.

A/B testing: nothing yet. This is a real gap. I'll need an experimentation framework eventually. When I add one, it will be either self-hosted GrowthBook or a hand-rolled feature flag table in our own DB. Optimizely / VWO are not on the shortlist because they ship third-party JS into customer-facing pages.

Marketing automation: Resend + Postgres. Transactional + newsletter sends through Resend (EU data residency, signed DPA, low surface area). Subscriber lists in our own Postgres. No HubSpot, no Marketo, no Customer.io. The single weakness is I don't have an SMTP-warmed sender reputation; I solve it with content cadence and a clean list.

Sales tooling: Cal.com self-hosted. Booking links on bleedwatch.com/book. EU data residency. The integration into Postgres is a webhook + small worker.

That's it. Six tools. Three of them are open-source self-hosted on our own infra. Two of them (Resend, Cal.com) are EU-based with signed DPAs and minimal data scope. The sixth is "nothing" which is sometimes a valid stack choice.

The reasons I went this direction

Customer credibility. When a CISO procurement officer asks me what subprocessors handle their account data, the list is short and defensible. Listing Google Analytics + Hotjar + Segment + Mixpanel on a security vendor's subprocessor page is a slow embarrassment that compounds across sales cycles.

Operational simplicity. Six tools is a small surface to maintain. Twenty tools is a full-time integration job. I don't have a marketing engineer, and I don't want to be one full-time.

Cost discipline. The total monthly cost of the stack is under €80. The equivalent commercial stack would land between €1,200 and €4,000/month at our traffic level. The savings compound across runway.

Pattern recognition for the product. Building security software has trained me to notice the stack you're loading. I notice when other vendors load cookie.cookielaw.org, when their Cookies tab unfolds to 47 entries, when their "EU compliant" checkbox is a fig leaf. Customers notice too. They just don't always say it.

What I lost

Detailed funnel analysis. I can't watch a visitor drop off at the third step of the signup form because I don't have session replay. I solve this with explicit form analytics (named events at each step) and the trial conversion rate is good enough that I haven't yet felt the loss acutely.

Attribution. I have no UTM-to-revenue attribution flow. I roughly track which campaigns send traffic via referrer + custom event params. For a product where the typical sales cycle is 60-90 days and most customers come through founder-network word-of-mouth, this is fine. It would not be fine for a B2C app spending €40k/month on Meta ads.

Vendor-side AI insights. I don't have the "Vercel Analytics shows your Core Web Vitals dropping in the Brazil region" kind of automated insight surface. I look at logs.

These are real trade-offs. They are mine. If you're building a marketing site for a product whose pitch is not "we'll show you what's leaking," you should probably make different ones.

What the trust page says about this

Our /trust page lists Umami as our only analytics provider, EU-hosted, on our own infrastructure, with no cookies and no PII collection. The subprocessor register at /trust/sub-processors reflects this. The relevant CISO procurement question — "who else gets to see this data?" — has a one-word answer: nobody.

The day we add a third-party analytics tool, that page gets updated within 30 days per our DPA. Subscribers to the sub-processor change feed (RSS at /trust/sub-processors.xml) get notified. That commitment is the entire reason the stack stays simple.

The recommendation, if you're shipping a B2B security product

Three principles, in priority order:

  1. Whatever you load on your marketing site, you're saying it's okay to load. Pick assets you'd be comfortable defending in front of your toughest CISO. The bar is not "industry standard." The bar is "would I tell a customer it's fine for their team to load this."

  2. The fewer tools, the easier the trust page. Every new vendor compounds the work of staying procurement-credible. Default to "don't add it" unless the value is unambiguous.

  3. Self-host the analytics if you can. Umami runs on one small box. It's not hard. The control it gives you over your own narrative is worth the operational delta.

If you've made similar choices and want to compare notes, [email protected].

The detection described in this article is available from Community tier upward.

Start scanning what attackers see.

Free tier, 3 assets, no credit card. Or jump straight to Shield with a 14-day trial.