Pixel Tracking Launch Checklist: Test Before You Spend on Ads

Quick fix: Before you spend on ads, place a real test order from an ad-style URL with click IDs attached. Confirm that each platform receives exactly one purchase with the right value and currency, that browser and server events deduplicate, and that consent choices are respected. Most launch-day tracking problems show up in that one test.

Tracking mistakes are cheap to fix before launch and expensive afterward. Campaigns optimize toward whatever conversions the pixel reports, so a doubled purchase or a missing value trains the algorithm on bad data from day one, and you cannot correct historical data later.

Work through this checklist in order. The early items cause the most damage when wrong, and the last section is a single end-to-end test that confirms everything at once.

1. One base code per platform

The most common launch problem is the same pixel installed twice. It usually happens when tracking was added in more than one place over time: hard-coded in the theme, again in Google Tag Manager, and again by a plugin or ecommerce app.

  • List every place tags can live: theme or template files, GTM containers, CMS plugins, ecommerce apps, and platform integrations such as a store's built-in Google or Meta connection.
  • Load the site with the DevTools Network tab open and filter for each platform. Note every pixel ID, measurement ID and container ID you see.
  • For each platform, decide which installation owns it and remove the others.
  • If you intentionally run two pixel IDs for the same platform, make sure each event is sent to the right one rather than to both.

For a Google-specific walkthrough, see gtag.js and GTM duplicate tags. When reading the requests, open each one and check its Initiator column to see which script sent it.

2. Standard events with the right parameters

Use each platform's standard or recommended event names. Optimization, reporting and catalog features are built around them, and custom names usually need extra setup to be used as conversions.

Funnel stepMeta PixelGA4
Product viewViewContentview_item
Add to cartAddToCartadd_to_cart
Checkout startInitiateCheckoutbegin_checkout
PurchasePurchasepurchase
LeadLeadgenerate_lead

Then check the parameters on the events that matter most:

  • Meta Purchase requires value and currency. Catalog ads also need product IDs through content_ids or contents.
  • GA4 purchase requires transaction_id and items, and currency is required when you send value. Google says to set value to the sum of price times quantity for the items, excluding shipping and tax.
  • Values are numbers, not strings with currency symbols or thousands separators.
  • Currency is a three-letter ISO 4217 code such as USD or EUR, and it matches the currency the customer actually paid in.
  • Product IDs match the IDs in your product catalog or feed, or dynamic ads will not match products.

See fixing missing value and currency in Meta Pixel for the most frequent parameter errors.

3. Deduplication between browser and server events

If you send conversions from both the browser and your server, every platform needs a way to recognize them as the same event.

  • Meta: the pixel's eventID must match the Conversions API event_id, and the event names must match. Meta deduplicates matching events received within 48 hours.
  • Google Ads: send a unique transaction ID with each conversion. Google Ads treats a second conversion with the same transaction ID for the same conversion action as a duplicate. Google warns that hardcoded or static IDs lead to significant undercounting.
  • GA4: use a unique transaction_id on purchase to avoid duplicate purchase events, for example when a customer reloads the confirmation page.
  • TikTok and others: most conversions APIs use a shared event ID. Check each platform's deduplication documentation.

The event ID must be generated once per conversion and passed to both the browser code and the server call. A new random ID in each place defeats the purpose. Read Meta Pixel and Conversions API deduplication for the details.

Decide how tags should behave for visitors who accept, decline or ignore your consent banner, then test all three.

  • Google consent mode: a gtag('consent', 'default', ...) command must run on every page before any config or event commands, and an update must follow when the visitor chooses. Consent mode v2 includes ad_storage, analytics_storage, ad_user_data and ad_personalization.
  • Meta Pixel: if you use fbq('consent', 'revoke'), it must run before init on every page, and fbq('consent', 'grant') must run after the visitor agrees.
  • Server events must respect the same consent decision as browser events.

Test with consent accepted and confirm events flow. Then clear cookies, decline, and confirm advertising tags stop or switch to the restricted behavior you chose. Our Google Consent Mode v2 check covers the Google side step by step.

5. Click IDs and UTM parameters survive redirects

Ad platforms append click identifiers to your landing page URL: gclid from Google Ads auto-tagging, fbclid from Meta, ttclid from TikTok, plus any UTM parameters you add. If a redirect drops them, conversions lose their link to the click.

  1. Take each landing page URL and add a test parameter. Google suggests appending ?gclid=TesTER-123. Add your UTM parameters as well.
  2. Open the URL in a fresh browser window and check the address bar after the page settles. The parameters should still be present, unchanged, including capitalization.
  3. Repeat for the variations a real visitor might hit: http to https, with and without www, trailing slashes, country or language redirects, and any link shortener.
  4. If the checkout runs on a different domain, confirm your analytics setup carries the session across domains.

Google's help article Website redirects are losing click data explains server-side fixes when parameters are stripped.

6. Domain verification and account connections

  • Meta: verify your domain in Meta Business Manager, either with a DNS TXT record or by uploading an HTML file to your site's root. It proves ownership of the domain.
  • Pinterest: claim your website in your Pinterest business account.
  • Google: confirm auto-tagging is on in Google Ads, that Google Ads and GA4 are linked if you import conversions, and that each conversion action shows as active rather than unverified.

Set the account time zone and currency to match your store before launch. They are hard or impossible to change later and affect how reports line up with your backend.

7. Technical blockers

  • Content Security Policy: check the console for CSP errors on every page template, including checkout.
  • Single-page apps: confirm page views fire once per route change, not zero times or twice.
  • Payment redirects: if a payment provider sends customers off-site, confirm they return to your confirmation page, or send the purchase from your server.
  • Ad blockers: expect some browser events to be lost. A server-side event for purchases and leads covers that gap where you have a lawful basis.

How to verify: the end-to-end test

Run this once everything above is in place, using a clean browser profile.

  1. Open the platform test tools: Meta's Test events in Events Manager, GA4 DebugView, and the other platforms' test or diagnostics views.
  2. Visit a landing page with test click IDs and UTM parameters added, and accept consent.
  3. View a product, add it to the cart, start checkout and complete a real purchase with a low-priced item or a discount code. Use each payment method customers will use, including off-site ones.
  4. In the Network tab and the test tools, confirm one event per step per platform, with the correct value, currency, product IDs and event ID.
  5. Confirm the server purchase event arrived and was deduplicated with the browser event.
  6. Reload the confirmation page and confirm no second purchase is counted.
  7. Repeat the visit with consent declined and confirm the behavior matches your policy.
  8. Refund or cancel the test orders.

The Pixel Helper extension, or each platform's own helper, makes steps 4 and 6 faster, but always confirm in the platform's test tool that the events were received.

FAQ

How long after launch should I re-check tracking?

Check the platform diagnostics within the first day of spend, then compare platform conversions with backend orders after the first week. Repeat after any theme, checkout or app change.

Do I need server-side events before launch?

Not always, but they make purchase and lead counts more resilient to ad blockers and unreliable confirmation pages. If you add them, deduplication must be working on day one.

Can I run test purchases with a 100% discount?

You can, but a zero-value purchase does not test value reporting. Use a small real amount at least once so you can see the value and currency arrive correctly.

What if my numbers still do not match the backend exactly?

Some gap is normal because of consent declines, blocked browsers and attribution windows. Investigate if the gap is large, sudden, or if the platform reports more conversions than you have orders.