First-party by construction, not as an option.

The term has been stretched to cover a lot of very different things. It is worth being precise, because the differences change what you actually get.

In web measurement, the meaningful distinction is where the browser sends the data. A third-party setup loads a script from a vendor's domain and posts visitor data to that same vendor domain. A first-party setup serves collection under the domain being measured, so from the browser's point of view the request is to the site the visitor is already on.

That is a narrow technical difference with wide consequences, because almost every mechanism that interferes with web measurement — browser tracking prevention, extension blocklists, third-party cookie policy — operates on the domain the request is going to.

Where the term gets abused is in products that keep third-party collection and describe themselves as first-party because they do not sell the data on, or because they set a cookie on your domain while still posting to theirs. Both are meaningful commitments. Neither changes the failure modes below.

The third-party model was the default for two decades and the environment it assumed no longer exists. Four things have changed underneath it.

• Domain-level blocking. Extension blocklists and browser tracking-prevention features match on the destination domain. A request to a well-known analytics host is trivially identifiable and is dropped before it leaves the browser. The visitor is never counted, so the loss is invisible in your own reporting.
• Third-party cookie policy. Browsers have spent years restricting cookies set on a domain other than the one being visited, which degrades the ability of third-party collection to recognise a returning visitor at all.
• Storage partitioning and lifetime caps. Even where storage is permitted, several browsers cap how long script-set storage survives. Multi-session paths get truncated into what looks like a series of new visitors.
• The vendor in the middle. Your visitor data sits on infrastructure you do not control, subject to a retention policy you did not write, and — depending on the vendor — as one input into a cross-site identity graph you have no visibility into.

The first three are measurement problems. The fourth is a governance problem, and it is the one most likely to be raised by someone with a legal remit rather than a marketing one.

Wardly is installed to run under your own setup. There is no Wardly-domain script tag to paste, because we do not offer one. Collection is wired into the site during deployment, and we verify it against your live traffic before anything is reported on.

The consequence for the browser is that there is no third-party request in the measurement path. Nothing is being sent to an ad-tech domain, so there is nothing for a blocklist to match by domain, and none of the third-party cookie restrictions apply — because there is no third party.

The consequence for you is that the measurement layer is not sitting on a vendor's advertising infrastructure, and your visitor data is not an input into anyone's cross-site graph.

How this is wired specifically — what is served from where, and how it fits your hosting — depends on how your site is built and served, and is set out in the written scope after the scoping call. We would rather write that down against your actual infrastructure than publish a generic diagram that turns out not to describe your deployment.

The honest answer is that it depends on your audience, and anyone giving you a number before looking at your traffic is making it up. The direction is predictable; the size is not.

What changes reliably: sessions that were previously dropped by domain-level blocking are now recorded, so counts go up rather than down. Returning-visitor recognition improves, because it no longer depends on storage that browsers actively restrict. Multi-session paths hold together over longer windows, which matters most for businesses with a long consideration cycle.

The effect is uneven across your channels, and that is the part worth preparing for. Audiences that skew technical, privacy-aware, or desktop-with-extensions were the most under-counted before, so those sources will appear to grow the most. That is not growth. It is the removal of a bias that was quietly making some of your channels look worse than they were, and it means your before-and-after comparison needs care.

First-party collection removes one class of loss. It leaves several others completely untouched, and a vendor that lets you believe otherwise is setting you up to stop investigating real gaps.

• Consent. Where consent is required and declined, you do not collect. This is a legal constraint and it is indifferent to your architecture. In consent-heavy markets your data is a biased sample, and reporting that presents it as a census is wrong.
• Cross-device paths. Identity still lives in browser storage. Someone who researches on a phone and buys on a laptop is two visitors, and no collection architecture fixes that on its own.
• Events nobody instrumented. Conversions that complete on a third-party payment page, inside an embedded widget, or in an iframe from a scheduling vendor are invisible unless someone deliberately wires them up. This is usually the single largest category of missing data, and it is manual work to find.
• Events lost on unload. A conversion fired immediately before a redirect can be cancelled by the navigation. It is a well-understood problem with a well-understood fix, and it is missing from a surprising number of otherwise careful implementations — where it shows up as a small, consistent undercount on the most important event you have.

We treat the last two as part of deployment rather than as your problem to discover later. That is most of why deployment is a service rather than a download.

Offering a vendor-domain tag alongside the deployed version would be commercially easier. It would let us sell to people who are not ready for an engagement, and it would shorten the path from interest to installed.

We do not, because the two are not the same product at different price points. A tag-based install has the failure modes described above, and a business running one would be reading the same claims on this site while getting materially worse data. The result would be a product whose marketing is true of some customers and not others, which is a slow way of becoming untrustworthy.

There is one way to install Wardly and we do it. That is a constraint on how fast we can grow, and it is the right trade.