First-party tracking
First-party tracking loads scripts and sends events through your own domain, so browsers and blockers treat it as part of your site, not a third party.
What is first-party tracking?
First-party tracking means the requests that load tracking scripts and send events go to a domain you own, such as t.yoursite.com or a path on yoursite.com, instead of directly to a vendor's domain like connect.facebook.net or googletagmanager.com.
The term also covers first-party cookies: cookies set by your own domain. Browsers treat these more favorably than third-party cookies, which most major browsers restrict or block by default.
Why it matters
Ad blockers and privacy extensions work largely from lists of known third-party tracking domains. When a pixel loads from a vendor domain on that list, the request is blocked and the event is never recorded.
Browsers also treat third-party contexts with suspicion. Safari's Intelligent Tracking Prevention and Firefox's Enhanced Tracking Protection both restrict third-party cookies and some tracking techniques. Routing through your own domain reduces how often tracking is caught by these rules, though it doesn't make tracking immune to them.
How first-party tracking is usually set up
The common pattern is a proxy: a subdomain or path on your site that forwards requests to the vendor and returns the response. Google offers this for its tags as Google Tag Gateway, and analytics tools like PostHog document reverse proxy setups.
A proxy only changes where the request goes. It doesn't change what data is collected or whether the visitor consented, so the same consent rules still apply.
How TracerKit handles it
TracerKit's first-party proxy serves third-party scripts through your own domain, so pixels load as first-party requests. It's separate from server-side forwarding: the proxy changes how scripts load, while server-side forwarding sends conversions directly from TracerKit to the platforms.
See how TracerKit handles this: First-party proxy
Take a look →