Beginner question: What's a good first step after installing an attribution pixel?

Good call on verifying the pixel fire first. I'd open the browser dev tools, go to the Network tab, and look for the pixel request. That's a solid first step.

I'd hold off on test conversions until you know the base tracking is solid. Bad baseline data can really mess up your reports later. Maybe check a couple different page types, like your homepage and a pricing page, just to be sure it's loading everywhere it should.

Out of curiosity, are you using any tag manager, or is the pixel code hardcoded?

Totally agreed on the network tab check. That's the bare minimum.

But I'd add that looking for the request alone can be misleading, especially with some of these newer platform pixels. They often load asynchronously and the initial request might just be a loader script. The real test is whether it's setting the correct cookies or local storage entries afterward. You need to check the Application tab in dev tools too, otherwise you might see a 200 OK and think you're golden when the tracking ID hasn't actually been set.

> are you using any tag manager
This is the critical question. If they are, the verification step has to include the tag manager's preview/debug mode. The pixel might fire perfectly from the tag manager container, but if the container itself isn't loading on certain pages (like a checkout flow with stricter CSP), you're still dead in the water.

Hold on. You're worried about collecting bad data from day one, but you're already thinking about test conversion events? That's the exact mindset that leads to months of corrupted datasets and useless marketing dashboards.

Your first step isn't technical verification. It's scoping what "bad data" even means for your business. Before you even open dev tools, write down the three key user journeys you actually care about attributing. Do you need session tracking across subdomains? Does your signup flow happen on a different path? The pixel can fire perfectly on every page load but still give you a completely false picture if you haven't locked down the *logic* of what you're stitching together.

Verifying the network request is kindergarten stuff. The real failure point is assuming the platform's default session logic matches your funnel. I've seen teams waste six figures on bloated contracts because they chased perfect pixel fires while their attribution model was fundamentally wrong for their product.

Hey, great question. That initial "is it working?" anxiety is totally normal. I'd actually split your first step into two quick checks.

First, yes, absolutely open the browser's Network tab and look for the pixel request on a page load. But like some others mentioned, don't just look for a 200 OK. Filter for the platform name (e.g., "northbeam") and check the *payload* of the request. It should contain some kind of identifiable session or user ID from the pixel's initialization. If it's just a blank request or a static file load, the script might be on the page but not actually tracking.

Second, and this is the part I messed up once, go incognito. Clear your local storage and cookies first, then load your site in a private window. Watch the Network tab *and* the Application tab for cookies/local storage. The pixel should drop a fresh tracking cookie on that very first anonymous visit. If it doesn't, you might have a script loading order issue or a ad blocker conflict you'd never see on your regular browser.

Hold off on the test conversion for maybe 24 hours after you confirm the basic pixel fire works. Get a small batch of real organic pageview data flowing first, then trigger a test signup or button click. That way you can see the full journey from a fresh anonymous session to a conversion in their dashboard, which tests the stitching logic too. Jumping straight to a test event sometimes masks problems with the initial visitor identification.

Confirm the pixel fires, but look at the payload. A 200 status is meaningless if the request doesn't contain your unique visitor identifier. Open the network tab, filter for the platform, and inspect the query parameters.

Ignore conversion events for now. If your base session tracking is wrong, your attribution model will be garbage. You can't fix bad data upstream.

Are you using a tag manager? If yes, your first check is the tag manager's debug console, not the browser network tab. The container load failure is the most common point of breakage.

Good call being worried about bad data from day one. That's smart.

Everyone's saying check the network tab, which is right. But the first thing I do is even simpler: open a page in two different browsers where you aren't logged in. Does the pixel fire in both? Sometimes cookies or cached scripts make it look like it's working only for you.

Hold off on test conversions for sure. If the visitor ID is wrong on page load, every "conversion" after will be tied to the wrong session. Then your reports are just fiction.

> are you using any tag manager
This really is the key follow-up. The verification path is totally different.

You're right to worry about bad data from day one. Everyone's suggestion about the network tab is good, but I'd start even simpler: can you actually see the pixel code on the page? View the page source and do a quick find for "northbeam" or the script snippet.

If it's there, then I'd follow the dev tools advice. But if you used a tag manager and just clicked "publish," the code might not even be on the site yet due to caching or approval workflows. That's a faster first check before getting into payloads and cookies.

How does Northbeam's initial verification compare to, say, a Meta pixel? Is their setup more opaque?

Good point about checking the page source first. It's a dead-simple sanity check that can save you 20 minutes of debugging in the network tab for nothing. If the snippet's not there, nothing else matters.

On your tag manager note, absolutely yes. I've seen teams publish a container, but the changes are stuck in "draft" or waiting on approval. The preview mode shows everything working, but the live site has the old version. Always double-check the published container version.

For your last question, Northbeam's pixel is a bit more opaque than Meta's during setup. Meta's helper extension gives you that instant "active on this site" confirmation. With Northbeam, you're more reliant on those dev tools checks for verification, which makes that initial page source check even more critical.

Agreed on the draft vs. published container state. I'd add that caching layers, like a Varnish or CDN config, can also hold onto an old container version for hours. You can pass all the internal checks, tag manager preview shows green, and the live site still has stale code.

The page source check is indeed step zero. If you don't see it there, you've just identified the problem domain: it's a deployment or caching issue, not a pixel configuration one. That saves the most time.

You've pinpointed a critical, often invisible failure layer. The caching layer problem extends beyond just the container script to the pixel's configuration itself. I've seen cases where the initial pixel script loads from cache, but the subsequent request for its dynamic configuration JSON is served stale from a CDN edge, causing it to fire with yesterday's tracking ID or incorrect event mappings. This creates the worst kind of bug: intermittent and user-geography dependent.

A reliable step after verifying the script is in the source is to force a cache miss. Append a unique query parameter to your site URL and check the network payload again. If the tracking parameters change, you've confirmed a caching issue. Otherwise, you can rule it out and move to cookie validation.

That's a solid point about checking the page source before anything else. It really is the fastest way to rule out deployment issues.

Your comparison between Meta and Northbeam on setup transparency is spot on, too. That lack of a helper extension does shift the verification burden onto the user. It makes me wonder if we, as a community, should be pressing vendors harder for better out-of-the-box diagnostic tools. A simple status dashboard in their UI that confirms a live connection would save so much guesswork.

That initial worry about collecting bad data is the right instinct. I'd follow the advice to check the page source first, because if the snippet isn't there, none of the fancy network tab debugging matters.

But I'm curious about something the others hinted at: if you're using a tag manager, how do you actually *know* the container you're seeing is the live, published version and not just the preview? Is there a specific header or something in the page source to look for, or do you just have to trust the platform's UI?

Trusting the platform's UI is exactly where these setups get you. Most tag managers embed a version ID in the container script's URL, like `gtm.js?id=GTM-XXXX&v=123456789`. That 'v' parameter is your published version.

But here's the kicker: you can't trust that the UI shows you the live version. I've seen the admin console display "Published: Version 42" while the script served has 'v=41' because a load balancer is pointing to an outdated origin. You have to inspect the script's *actual* response, not the page source snippet. The snippet is static, the script it pulls is dynamic.

So you're right to be suspicious. The only way to know is to check that version parameter in the network tab against what the platform *says* is live. And even then, as another post mentioned, caching layers can serve an old copy of that specific version. It's turtles all the way down.

Your instinct is the most important thing you've got right now. Everyone's dancing around the edge, but let's be blunt: if you're asking this question, you already suspect the pixel's documentation is a marketing gloss for "we start collecting immediately and you have to trust us."

Checking if it fires is kindergarten. The real first step is verifying *what* it's collecting. Open dev tools, find the pixel's network call, and look at the payload. Is it sending a user ID that looks legit, or is it some mangled session cookie? That's your source of truth, not a "pixel fired" message.

Skip the test conversion for now. If the foundational clickstream data is garbage, layering events on top just gives you polished garbage.