Straight answers on pixel performance, privacy, Safari, data retention, test orders, and consent banners.
Answers to the questions we hear most, in plain terms — no legalese, no marketing gloss.
No. The pixel loads with a plain async script tag, so it never blocks page rendering. The whole script is wrapped in a try/catch, so it can never throw an error on your page — a pixel failure stays inside the pixel. Events are sent with navigator.sendBeacon (falling back to a keep-alive fetch), which doesn't hold up navigation either. The script response itself is cached for an hour, so repeat visits don't re-fetch it.
No raw personal data is transmitted or stored by the pixel. Lead and declared-form helpers may read an email inside the browser long enough to hash it with Web Crypto, then discard the raw value. The event carries only that digest plus nod_vid, a random anonymous id. Names, phone numbers, form values, arbitrary query parameters, URL userinfo, and fragments are removed before transport and scrubbed again at the collect endpoint.
On the server side, we don't store your visitors' raw IP addresses at all. We hash the IP with a secret pepper before it ever touches the database, so the stored value can't be reversed back into an IP, and it can't be matched across other workspaces either.
Safari's tracking prevention is real, and we don't pretend otherwise. After analytics consent is granted, the pixel captures the current landing immediately, so a click id like fbclid does not wait on another page. The visitor id (nod_vid) is stored in both a cookie and localStorage with the same explicit expiry. If localStorage throws or comes back empty, the script falls back to the cookie mirror instead of losing the visitor immediately.
Serving the pixel from your own subdomain (see how the nod. pixel works) can avoid simple blocklists that target the shared third-party hostname. It does not bypass consent or every blocker.
None of this makes Safari's cookie limits disappear — it just means a dropped storage read doesn't quietly stop tracking a visitor.
The observable Journey horizon defaults to 90 days and can be configured from 1 to 365 days. Raw pixel events retain only that horizon plus the larger of seven days or the workspace's configured correction/order-delay buffer. The extra buffer supports late correction and is service-role-only; it never widens Journey or attribution credit. The retention job reports the active horizon, buffer, oldest event, purge lag, and last purge time.
Test orders (orders marked test: true in Shopify) are never counted. They don't create a conversion row and never trigger a Meta CAPI purchase — for live webhooks and for the automatic backfill on connect.
Point-of-sale (in-person) orders are handled differently: they ARE recorded as a conversion, since the sale is real, but they do not send a Meta CAPI purchase event, since a CAPI purchase always represents a website action and an in-store sale isn't one.
Each nod. account is one workspace, and one workspace is one brand. There is no multi-workspace plan to buy and no account switcher: a workspace holds a single brand identity, and its campaigns, creatives, reviewers and attribution all live inside it.
Connecting more than one Meta ad account does not need a second workspace. You add each ad account as a data source inside the same workspace, and one of them stays the default that nod. reads when you don't pick a specific account. Your store, CRM and calendar tools connect into that same workspace too.
If you genuinely run separate brands, you set them up as separate accounts, each with its own workspace.
That's a legal question for your own counsel, not something we can answer for you. Technically, the pixel stays dormant until analytics consent is explicitly granted. Generic CMPs and Cookiebot provide an initial snapshot plus live updates; Shopify uses its Customer Privacy API directly. See Consent and cookie banners (CMPs) for the exact contract.