First-party analytics
Analytics served from your own domain into data you own, instead of shipping visitors off to someone else's tracker. Fewer blockers eat it.
See it
What it is
First-party analytics means the script and the collection endpoint sit on a domain you control (stats.yoursite.com, or /api/event) rather than on a vendor's. That is one decision, and people routinely bundle three others into it that are actually separate: where the data is stored and who can read it, whether you set a cookie or any persistent identifier, and what your legal basis for processing is. Plausible, Fathom, Umami, Matomo and a self-hosted PostHog tend to make all four choices in the privacy-friendly direction at once, which is why the terms get welded together, but proxying a third-party tool through your own domain changes only the first one.
The payoff of first-party delivery is that fewer requests get dropped: there is no third-party host for a blocklist to match, and no cross-site cookie for Safari's ITP to cap. Fewer, not none. Blocklists match on request paths and payload shapes too, so a same-origin proxy reduces loss rather than guaranteeing delivery, and some lists explicitly target the known proxy patterns.
Gotcha: delivery is not a legal status. If your own endpoint forwards the same personal data to a third party, regulators treat it exactly as if the third party collected it. Cookieless is not the same as anonymous either: hashing IP plus user agent plus a rotating server-side salt avoids storing a persistent identifier, but the raw inputs are personal data, the technique is a form of fingerprinting, and several regimes regulate reading device characteristics regardless of whether a cookie is involved. Some tools ship legal opinions arguing no consent banner is required in the EU on this basis; that is their position, not a settled fact, and it depends on your jurisdiction and what else you do with the data. Get your own advice. The engineering trade is real either way: a daily-rotating hash means no cross-device stitching, fuzzy returning-visitor counts, and sessions that reset at midnight.
Ask AI for it
Build a same-origin, cookieless analytics pipeline in my Next.js app, end to end. Delivery: serve the tracking script from my own domain with a rewrite (/js/s.js) and post events to my own route (/api/event), so fewer requests get dropped by blockers and third-party cookie rules. Collection: keep the payload to path, referrer, screen width, event name and an optional props object; validate it against an explicit schema and reject anything that does not match; set no cookies; never store or log a raw IP. Do not fingerprint visitors by default, so count events and sessions rather than deriving a unique-visitor id; if I ask for unique-user estimation later, add it behind a flag and write up the privacy review it needs, including why an IP-plus-user-agent hash is still processing personal data. Storage: persist events in a real table with an index that supports the queries, and a scheduled job that deletes rows past a stated retention limit. Queries: give me aggregate SQL for pageviews by path, top referrers, and daily event counts. Consent: implement a documented opt-out (respect a stored preference and Global Privacy Control, and drop matching requests server side). Finish with a basic report page rendering those aggregates, plus the rewrite config and the route handler with rate limiting.