Full Answer

The credential set is small but each piece has a distinct job. The Pixel, with its pixel code, is the container your events land in; you create it in Events Manager and it's the same asset the browser Pixel uses, which is what lets the server and browser events share a dataset and deduplicate. The advertiser account is the ad-side identity that consumes those events for targeting and optimisation.

The access token is the sensitive part. It's a long-lived secret minted in Events Manager against a specific Pixel, and it authenticates every Events API request. Because it can write conversion data, it belongs only on your server, in an environment variable or your platform's secrets store, and never in a theme file, client-side script, or a public repository. Treat a leaked token the way you'd treat a leaked API key, revoke and regenerate it.

In a WooCommerce setup, the token and pixel code live in your server configuration, and your code attaches them to each outbound Events API call while building the event payload. If you later add catalog or Shopping features you may also generate scoped tokens through the Marketing API, but for straightforward server-side conversion tracking the pixel code plus a guarded access token is the core of what you need.