Between a first-party and a third-party URL, a browser differentiates various degrees of "first-party-ness". Generally, the more first-party a URL is, the more trust the browser places in communication with that URL. To judge the first-party-ness of a URL, the browser always compares it against the main document, the URL the user has either clicked on or manually typed into the address bar. Understanding this trust model matters because it directly determines how your Seers.ai server-side endpoint should be configured and what browser protections it will benefit from.
First-party and Same-origin: What They Mean
Browsers measure "how first-party" a URL is by comparing it against the main document, the URL that the visitor navigated to, either by clicking a link or typing it into the address bar. The further a request destination is from that main document URL, the less trust the browser extends to it.
Two terms describe the two most relevant levels of trust in this context:
First-party
A URL is considered first-party if it contains the URL of the main document within it. For example, www.seers.ai is a first-party URL to seers.ai, because www.seers.ai contains seers.ai. Any URL that includes the main document's domain qualifies as first-party, regardless of what subdomain precedes it or what path follows.
So https://sgtm.seers.ai/collect is first-party to a visitor on https://seers.ai, and so is https://docs.seers.ai, both of which contain seers.ai.
Same-origin
Same-origin is more specific than first-party. It requires that the destination URL match the main document on all three of the following simultaneously:
- Protocol, both must use the same scheme (e.g., both https)
- Subdomain, both must share the same subdomain, including no subdomain at all
- Domain, both must share the same root domain (e.g., seers.ai)
Because of this stricter matching, same-origin is a narrower category than first-party. For instance, https://seers.ai/collect is same-origin to https://seers.ai, the protocol, subdomain (none on either), and the domain all match. But https://www.seers.ai/ is not the same origin as https://seers.ai, because the subdomain differs (www vs. none), even though it is still first-party.
In short, same-origin domains are always first-party, but not all first-party domains are same-origin.
Anatomy of a URL
Still sounds abstract? The diagram below breaks down each component of a URL and shows exactly which parts the browser uses when making its first-party and same-origin determination.
URL Examples Relative to https://seers.ai
To better understand the difference between first-party and same-origin, here are a few example URLs assessed relative to a main website hosted at https://seers.ai/.
| EXAMPLE URL | FIRST-PARTY? | SAME-ORIGIN? |
|---|---|---|
| https://www.google.com/gtm.js | ✕ No | ✕ No |
| https://sgtm.seers.ai/gtm.js | ✓ Yes | ✕ No |
| https://seers.ai/collect/gtm.js | ✓ Yes | ✓ Yes |
| http://seers.ai/collect/gtm.js | ✓ Yes | ✕ No |
Walking through each row:
- https://www.google.com/gtm.js, the domain is google.com, which does not contain seers.ai at all. The browser classifies this as a fully third-party request, neither first-party nor same-origin.
- https://sgtm.seers.ai/gtm.js, this URL contains seers.ai, so it qualifies as first-party. However, the subdomain sgtm differs from the main document (which has no subdomain), so the same-origin check fails. This is the profile of a subdomain endpoint.
- https://seers.ai/collect/gtm.js, protocol (https), subdomain (none on both), and domain (seers.ai) all match the main document exactly. Both first-party and same-origin conditions are met. This is the profile of a same-origin endpoint and receives the highest level of browser trust.
- http://seers.ai/collect/gtm.js, the domain matches seers.ai, so the URL is still first-party. However, the protocol is http while the main document uses https, one of the three same-origin components does not match, so same-origin status is not granted.
Why this matters for cookie behaviour Browsers apply stricter cookie restrictions to subdomain endpoints than to same-origin ones. In particular, Safari's Intelligent Tracking Prevention (ITP) may limit the lifespan of cookies set from a subdomain endpoint, even when that subdomain belongs to the same registrable domain. A same-origin endpoint avoids this restriction entirely, which is why it is the recommended configuration for Seers.ai SST when longer-lived first-party cookies are required. |
Which Endpoint Type Should You Use?
Both endpoint types are fully supported by Seers.ai Server-Side Tagging. The right choice depends on your technical setup and the level of browser trust you need:
- Subdomain endpoint (e.g., https://sgtm.seers.ai), easier to configure via a CNAME DNS record and requires no changes to your web server or reverse proxy. It still qualifies as first-party, which is sufficient to bypass most ad blockers. Suitable for most standard deployments.
- Same-origin endpoint (e.g., https://seers.ai/collect) requires routing a specific path on your existing domain to the Seers.ai container, typically via a reverse proxy or CDN path rule. In return, you get the highest level of browser trust, full same-origin cookie access, and immunity to any ITP subdomain restrictions. Recommended when attribution window accuracy is a priority.
Seers Recommendation If your infrastructure supports it, configuring a same-origin endpoint gives you the strongest possible data quality and cookie durability. If a subdomain endpoint is simpler to deploy given your current setup, it still delivers significant improvements over client-side tagging, particularly for ad blocker bypass and consent-gated event forwarding. |