Although it’s not the most optimal setup (more on that later), the most common integration is through Google Tag Manager. In this case, you’ll need to place both scripts as Custom HTML tags for:
- Initialization pixel
- Conversion pixel
When to Fire the Pixel
When configuring the trigger for this tag, you have five options, ordered by when they fire. The earlier the pixel is placed, the better it can track traffic. We recommend using the Initialization trigger.
- Consent Initialization: Designed to help ensure that consent settings are honored before any other triggers fire. The Consent Initialization trigger is used for tags that set or update the user consent state for your site, such as a Consent Management Platform tag or tags that set consent defaults. Each web container includes a Consent Initialization – All Pages trigger by default. The Consent Initialization trigger is not used for tags that should fire early on a site. For those cases, use an Initialization trigger. Learn more about consent settings.
- Initialization: Designed to fire before all other triggers except Consent Initialization triggers. Each web container includes an Initialization – All Pages trigger by default. Select this trigger to fire any tags that should fire before other triggers.
- Page View: Fires immediately when the web browser begins to load a page. Use this option if you only need data generated from page impressions.
- DOM Ready: Fires after the browser has finished constructing the full page in HTML and the Document Object Model (DOM) is ready to be parsed. Pageview-based tags that interact with the DOM to populate variables should use this trigger type to ensure that the correct values are available to Tag Manager.
- Window Loaded: Fires after the page has fully loaded, including any embedded resources such as images and scripts.
Where to Place the Pixel
The initialization pixel must be fired on every page.
Conversion pixel should be fired only on the page that marks the conversion (whether it’s pending or approved), as it creates the conversion once triggered.
The only exception is when the Update pixel is used — it fires only when triggered by a Data Layer containing the pcid. However, we still recommend firing the Update pixel on the conversion page as well.
Reasons not to use Google Tag Manager for pixel tracking
The main issue is that some ad blockers block the entire GTM container. The table below shows when the container is blocked (❌) and when it is not (✅).
| Blocker | Server Side GTM | Standard GTM |
|---|---|---|
| Adblock | ✅ | ✅ |
| Adblock Plus | ❌ | ❌ |
| uBlock Origin | ❌ | ❌ |
| Ghostery | ❌ | ❌ |
| VPN in corporates | ✅ ? | ❌ ? |
| Safari ITP | ✅ | ❌ |
Thus, it’s better to either insert the pixel directly into the website code, or—if you have the resources—use Server-Side GTM. If you implement it directly in HTML, place it as high as possible in the <head> section of the page.
Cookie parameter
Cookie parameter enables persistent cookie storage (recommended if cookies are allowed).
- Fire the tracking pixel with cookie=1 → value saved in cookies.
- Fire the tracking pixel with cookie=2 → value saved in localStorage.
- Fire the tracking pixel with cookie=0 → value saved in sessionStorage.
⚠️ Beware: If your homepage runs on the main domain and the purchase process on a subdomain, localStorage and sessionStorage will not be shared. They only work within the exact same origin (protocol + domain + port). Only cookies can be used across domain and subdomains.
- In such cases, where you do not want to fire the pixel before cookie consent, you need to store and forward local/session parameters yourself. For example, by passing them via URL parameters or syncing them through your backend API.