The three install paths, ranked
| Path | Example | Governance | When to use it |
|---|---|---|---|
| Native app / connector | Shopify's built-in custom-pixel system for OpenAI's pixel | Highest - sandboxed, platform-managed, least custom code to get wrong | Default choice whenever the commerce platform offers one |
| Tag-manager container tag | A server or web GTM container tag for a vendor's pixel | High - one governed inventory, but the tag's own logic is still your responsibility | Default once a site already runs a tag manager and no native connector exists |
| Manual snippet | Loading a vendor SDK directly in the page <head> | Lowest - full control, full responsibility, easiest to under-govern | Fallback only, when neither of the above exists for the platform |
None of these choices is really about which is technically easiest. It is about which leaves the smallest amount of ungoverned custom code sitting on a production site a year from now, after whoever installed it has moved to a different project.
Gate one: consent
A pixel gets wired into the same consent-management layer as every other analytics or ad tag on the estate before it ever fires - never a special case because it is new or because someone wants it live by Friday. Concretely: the tag fires only inside whatever consent category (analytics, marketing) the platform's data use maps to, and that mapping is written down, not assumed from the vendor's marketing page.
Gate two: staging
The pixel goes live on a staging or preview environment first, where its network requests can be watched without touching live customer data or live ad spend attribution. This is also where a broken pixel gets caught before it costs anything - a JavaScript error from a poorly loaded SDK, a race condition with a consent banner, a duplicate fire on a single-page-app route change.
Gate three: runtime verification
The pixel is confirmed firing correctly in a real browser session - not assumed correct because the install steps were followed. This is a large enough topic, and different enough per platform, that it gets its own guide: verifying AI conversion tracking.
When to add the server-side option
A browser pixel alone under-reports for the same reasons it always has - ad blockers, cookie restrictions, third-party script blocking - plus a newer reason specific to this category: some AI-driven purchase flows (OpenAI's Instant Checkout among them) are session-less by design, meaning there may be no browser session for a pixel to fire from at all. Where a platform offers a server-side conversions API, as OpenAI does for ChatGPT Ads, pairing it with the browser pixel closes that gap - but only where it exists. Perplexity's Buy with Pro, as of 2026-09, does not offer a merchant-facing server-side option; the honest install there is order-level tagging, not a CAPI call to a product that does not exist. See the Perplexity page for that case in full.
Consent-gating and event deduplication belong together whenever both a browser pixel and a server-side API run. Sending the same conversion twice with no shared event ID inflates every downstream number - the fix is a shared, deterministic event ID passed to both, exactly as Meta's own Conversions API guidance recommends.
The server-side layer, in more depth
For teams building or evaluating a server-side conversions pipeline more broadly - not just for one AI platform's pixel, but as house infrastructure across every ad and analytics vendor - that is a deeper discipline than one page can cover. See signals.webclat.com's CAPI practice for the install-consent-dedupe-verify framework applied across Meta, TikTok, Google, and others.
This is the same install discipline we would apply to any vendor tag - AI platforms do not get a faster, less-reviewed path just because the pixel is new. See the use case for the situation this page is written to prevent.