Server-Side vs. Browser-Side Tracking: The Reliability and Ethics of Bread & Butter
To score leads accurately and map a buyer's journey, your system needs data that actually arrives, collected in a way that respects modern privacy standards. Bread & Butter is built around both: server-side delivery for reliability, and consent-based identity resolution instead of surveillance.
In short: Every behaviour tool loads a script from its own domain and then sends data back to that domain from the visitor's browser. Content blockers work from lists of those domains, so both ends are exposed. The Bread & Butter WordPress plugin has neither. The JavaScript is served from your own domain, and the data is delivered to us by your server rather than by the visitor's browser. There is no Bread & Butter address anywhere in the path for a blocklist to match. On identity we take the opposite approach to legacy tools: we never guess who someone is from their IP address. We wait until they tell us.
1. Where Browser-Side Tracking Breaks Down
It helps to separate two things that usually get lumped together.
Collecting behaviour happens in the browser. Scroll depth, time spent on a section, the sequence of pages, the movement that builds a heatmap: these are browser events, and every tool in this category captures them the same way, ours included.
Sending that data somewhere is a network request, and that is what content blockers act on. uBlock Origin, Brave's shields, Safari content blocker extensions and DNS-level blockers all work from lists of known third-party analytics domains, and they refuse requests to those destinations. Depending on the list, they may stop the tool's script from loading at all, or let it run and then quietly drop the call home.
The damage is quiet. Nothing errors, nothing warns you, and your dashboard looks perfectly healthy. It is simply missing sessions, and you have no way of knowing which ones. That is how two tools watching identical traffic end up reporting materially different numbers.
2. First-Party End to End: The Reliability Angle
The Bread & Butter WordPress plugin removes both weak points rather than one.
The script is yours. The plugin serves our JavaScript from your own domain. There is no Bread & Butter URL to load, no third-party address in the page source, and nothing pointing back to us. Blocklists are built from known third-party tracker domains, and your domain is not on any of them, so there is nothing for a blocker to match against in the first place.
The delivery is server to server. The JavaScript still captures the behavioural detail in the browser, because that is the only place it exists. But instead of calling our API from the visitor's browser, the plugin stores that data on your own WordPress site, and your server delivers it to us. A content blocker lives in the visitor's browser, and a request it never sees is a request it cannot refuse.
Put together, the entire path is first-party. The visitor's browser talks only to your website, which is exactly what it was going to do anyway. This is not a workaround or a loophole, and nothing is being disguised. There is simply no third-party traffic to intercept, because none is taking place.
What customers notice: The practical result is precision. Our customers consistently report that Bread & Butter reads as more exact than the browser-based analytics and session-recording tools they have used before, and this is why: fewer sessions fall through the gaps, at either end.
A note on script tag installs. Many customers run Bread & Butter on Shopify, Webflow, Squarespace and similar platforms using our script tag. Everything else works identically there: the same scoring, the same enrichment, the same journey stitching. What the script tag cannot provide is the first-party path above, because there is no server of yours involved. If complete tracking matters to you and your site runs on WordPress, the plugin is the stronger install for that reason alone.
3. Consent-Based Intelligence: The Ethical Angle
Reliable delivery is about the behavioural journey. Knowing who the person is runs on a completely different principle, and the line we draw is deliberate.
Many legacy B2B visitor identification tools use IP-to-company mapping to guess who is on your website, buying third-party data to deanonymize people who never gave them permission. In an era of remote work and VPNs, that delivers poor data as well as poor ethics, frequently identifying an ISP's headquarters rather than an actual buyer.
Bread & Butter waits to be told.
- The hand raise: We track the anonymous behavioural journey from the very first visit, but identity resolution stays inactive until the visitor does something deliberate, such as submitting a form on your site.
- Permission to be known: By giving you their email address, the visitor provides consent. Only at that moment do we connect their history to a verified identity and trigger Deep Profile Enrichment.
The result is a rare combination: we see the journey more completely than browser-dependent tools, and we know less about people who never asked to be known. Reliability and restraint are usually traded off against each other. Here they are separate mechanisms, so you get both.
That restraint is also why the journey holds up over time. It is anchored to a verified identity rather than to a cookie, which is covered in why we can track a lead's full journey when cookie-based tools lose the trail.
Why This Matters for Focused Score
An intelligence model is only as good as the behaviour it can see. If a prospect's most revealing session never reached us, that session cannot influence their score, and the model reasons from a partial picture without knowing it is doing so.
More complete delivery means Focused Score is working from more of what actually happened. That is the difference between a score your sales team acts on and one they second-guess.