First-party tracking domain

By default the PixelFox tag loads from and sends events to PixelFox' own hostname. Ad blockers and browser privacy lists target exactly such third-party tracking hosts. A first-party tracking domain moves both onto your domain - t.yourstore.com - so tracking requests are indistinguishable from your site's own traffic.

Setup

The fastest path is during onboarding: the Install step has an optional "Serve from your own domain" section that shows your exact CNAME record and saves the hostname in one place - the install snippet on the same screen switches to your domain the moment you save. For an existing site, use Settings → Site → First-party domain instead; the steps are identical:

1. In your DNS, add a CNAME record:

   Type	Name	Value
   CNAME	t	connect.pixelfox.app

   (Any subdomain works - t., track., data. - as long as it's on the same registrable domain as your storefront. Keep it DNS-only if your DNS provider offers proxying.)

2. Enter t.yourstore.com in the first-party domain field (onboarding install step, or Settings → Site → First-party tracking domain) and save.

3. The TLS certificate is issued automatically on the first request - no upload, no renewal. If you configured this after installing, re-paste the updated snippet from Settings → Website setup on your site.

Verifying the setup

Settings → First-party Domain checks the hostname automatically whenever you open the tab (and on demand via Check again):

• DNS record - the CNAME resolves to the ingest host (flattened A records, as Cloudflare creates, are detected too). If the record points elsewhere, the check shows exactly what it currently resolves to.
• HTTPS / certificate - the hostname answers over TLS with the PixelFox API. A fresh record can sit at "DNS OK · certificate pending" for a minute: the certificate is issued on the very first request.

The badge turns Active when both pass - from then on the snippet shown in the tab serves the script from your domain.

What changes

• Script and events are first-party - t.yourstore.com/signals.min.js and t.yourstore.com/v1/ingest don't appear on third-party blocklists.
• Same-site cookies - the tag's identifiers live under your registrable domain.
• Nothing else: keys, dashboards, destinations and the event contract are identical.

Cookie life extension

Safari and Firefox cap cookies written by JavaScript at about 7 days, which silently truncates any attribution window longer than a week. On a first-party tracking domain, PixelFox refreshes the vendor identifiers over HTTP instead: every event batch answered from t.yourstore.com re-sets _fbp, _fbc and _ga with a 2-year lifetime on your registrable domain.

• Works automatically once the first-party domain is configured; no extra setting.
• _fbc is reconstructed from a landing fbclid when the cookie is missing, so paid clicks keep their click id for the whole window.
• On the shared ingest hostname nothing is set: a third-party cookie would be pointless, and browsers increasingly refuse it anyway.

Notes

• One tracking domain per site, and a hostname can belong to only one site.
• The certificate is only issued for hostnames saved in a site's settings - pointing DNS at PixelFox without saving the domain does nothing.
• If you later clear the field, the standard hostname keeps working; certificates for the old name simply lapse.