Install the Probecast Pixel: a practical setup guide — and what to expect in your first 30 days

Filis10 min read
Install the Probecast Pixel: a practical setup guide — and what to expect in your first 30 days

Install the Probecast Pixel: a practical setup guide — and what to expect in your first 30 days

Analytics tools love to make a simple thing feel complicated. The Probecast Pixel is one script tag. Paste it once, and you get first-party, unsampled visitor data sitting right next to your uptime and revenue — no Google account, no cookie wall, no data warehouse.

But there are a few things worth knowing so you install it correctly the first time, avoid the traps that silently swallow data, and read the numbers with the right expectations. Early on, an analytics pixel always looks a little strange — the trends aren't wrong, they're just young. This guide walks through all of it.


What the pixel actually is

The Probecast Pixel is a tiny, asynchronous script served from Probecast. When it runs on your page it does three things:

  • Records a pageview (and follows client-side navigation in single-page apps automatically).
  • Assigns each visitor an opaque, rotating ID — no cookie by default.
  • Sends everything to a first-party collect endpoint, and never blocks or breaks your page if a request fails.

Why use it instead of (or alongside) Google Analytics?

  • First-party and unsampled. You see every visit, not a statistical sample. Because the request goes to a Probecast endpoint rather than google-analytics.com, far fewer ad blockers eat your data.
  • Cookieless by default. It uses a rotating session identifier until you decide to ask for consent. That makes the baseline install friendly to strict privacy regimes.
  • Revenue-aware. Probecast already knows your Stripe revenue. The pixel connects acquisition to money — so a traffic spike, a conversion, and a payment live on the same screen.

One rule: each product uses one growth source — Google Analytics or the pixel, never both. You pick it per product and can switch anytime.


Step 1 — get your snippet

In Probecast, open the product you want to track → GrowthGrowth source → choose Probecast pixel. You'll get a snippet that looks like this:

<script async src="https://api.probecast.io/p.js" data-key="pk_your_public_key"></script>

Always copy the exact src and data-key from your dashboard — the public key is unique per product. The example above is just the shape.

The key (pk_…) is a public identifier — it's safe to ship in your HTML, exactly like a GA measurement ID. It only says "attribute these events to this product."


Step 2 — install it (by stack)

The golden rule for every stack: load it once, site-wide, in the <head>, on every page. You do not need to add it per route — the pixel tracks SPA navigation on its own.

Plain HTML

Drop it into the <head> of your template:

<head>
  <!-- … -->
  <script async src="https://api.probecast.io/p.js" data-key="pk_your_public_key"></script>
</head>

Next.js (App Router)

Use next/script. Put it in your root app/layout.tsx so it loads everywhere:

import Script from 'next/script';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        <Script
          src="https://api.probecast.io/p.js"
          data-key="pk_your_public_key"
          strategy="afterInteractive"
        />
      </body>
    </html>
  );
}

If your site uses a Content-Security-Policy with a nonce, pass the same nonce to the <Script> tag — otherwise the browser will refuse to run it (more on CSP below).

React (Vite / Create React App)

Don't mount it as a component — put it in the static index.html <head> so it loads before your app hydrates:

<!-- index.html -->
<head>
  <script async src="https://api.probecast.io/p.js" data-key="pk_your_public_key"></script>
</head>

Vue / Nuxt

Nuxt: add it in nuxt.config.ts under app.head.script:

export default defineNuxtConfig({
  app: { head: { script: [
    { src: 'https://api.probecast.io/p.js', async: true, 'data-key': 'pk_your_public_key' },
  ] } },
});

Plain Vue: same as the React/Vite approach — put the tag in index.html.

WordPress

Two easy options:

  • Without a plugin: Appearance → Theme File Editor → header.php, and paste the snippet just before </head>. (Better: do this in a child theme so an update doesn't overwrite it.)
  • With a plugin: any "insert headers and footers" plugin — paste the snippet into the header box.

Shopify

Online Store → Themes → Edit codelayout/theme.liquid, and paste the snippet inside <head>.

Webflow / Framer / Squarespace / Wix

These all have a site-wide custom code / header embed field (Project settings → Custom code → Head). Paste the snippet there so it loads on every page.

Google Tag Manager

Create a new Custom HTML tag, paste the snippet, and set the trigger to All Pages. The pixel is built to find itself even when a tag manager injects it dynamically, so it works fine through GTM — just make sure your CSP (below) allows it.


Step 3 — the three things people get wrong

These are the traps that make a correctly-pasted pixel look "broken." Check them first.

1. Content-Security-Policy

If your site sends a Content-Security-Policy header, the browser will silently block the pixel unless you allow it. You need two directives:

script-src  … https://api.probecast.io ;
connect-src … https://api.probecast.io ;
  • script-src lets the browser load p.js.
  • connect-src lets it send events to the collect endpoint.

Miss either one and you'll see a CSP violation in the browser console and zero data. (If your CSP uses a nonce, remember to put that nonce on the script tag, as noted for Next.js above.) Use the host shown in your snippet.

2. It must be in the <head>, on every page

Put it in the shared layout/template, not a single landing page. A visit to a page without the tag simply isn't recorded — and gaps in coverage look like a traffic drop that never happened.

3. One source per product

If you had Google Analytics selected for a product and switch to the pixel, you're now reading pixel data — the two are never mixed. Don't try to run both for the same product expecting a merged view; pick the one you trust.

A note on ad blockers: because the pixel is first-party it survives far better than GA, but no client-side analytics is 100% blocker-proof. If you want the strongest coverage, serve the script from your own domain via a reverse proxy — that's optional and most teams don't need it.


Step 4 — turn on the good stuff (optional but worth it)

The base snippet already tracks pageviews. Two small additions unlock the parts that make Probecast different.

Consent → durable, cross-session attribution

By default the pixel is cookieless and forgets visitors between sessions. When a user accepts cookies, call:

probecast.consent('granted');

…from your cookie banner. That promotes their ID to a first-party cookie so returning visits are recognised. On rejection, call probecast.consent('denied') — it wipes the persistent ID and falls back to the rotating one. (There's deliberately no "zombie cookie" respawn — declined means declined.)

Conversions → tie traffic to signups and revenue

Fire an event at the moment that matters:

probecast.event('signup');     // or 'trial_started', 'purchase', …
probecast.identify();          // optional: marks this visitor as a known user for stronger attribution

This is what lets Probecast draw the line from "a visitor arrived from this campaign" to "…and became this paying customer."


What to expect: the first minutes, the first days, and the steady state

This is where expectations matter most. An analytics pixel isn't wrong on day one — it's just young. Here's the honest timeline.

Minute 1 — realtime lights up

As soon as the tag runs on a live page, the LIVE widget on your Wallboard and the Growth card on your Main View start showing "live now." If you open your own site in another tab, you should see the count tick up within about a minute. This is your install smoke-test — if LIVE moves, the pixel is wired correctly.

First hour — pageviews accrue

Realtime is sampled every minute and rolled up hourly. Totals begin filling in, but don't read too much into the shape yet — an hour of data is an hour of data.

Days 1–3 — the trend line appears

Your 30-day traffic sparkline (on the Growth cards and behind the LIVE number on the Wallboard) needs at least two days of history before it draws a line. So expect it to be blank on day one and to start sketching a curve from day two or three.

New vs. Returning will look lopsided at first — early on, almost every visitor is "new," because nobody has come back yet. The returning curve only becomes meaningful once people start making repeat visits, which takes… people making repeat visits. Give it a week.

Day 7–30 — the numbers settle

Conversion rate, channels, geo, and devices stabilise as volume grows. One thing to know: Probecast counts in UTC calendar days, not a rolling 24-hour window. So a day's number is "midnight-to-midnight UTC," which can look slightly different from tools that use a rolling window — especially if your audience is concentrated in one timezone. It's consistent, just calendar-based.

The 30-day totals are only fully populated after you've been collecting for 30 days. Before that, "last 30 days" literally means "every day since you installed."

Steady state — the definitive view

After the first month you have a stable, unsampled baseline: real daily traffic, real new-vs-returning behaviour, real conversion by channel, and — with event() firing — real revenue attribution. From here, week-over-week comparisons are trustworthy.


Where to read the data (and how to get value from it)

Three places, increasing in depth:

  1. Wallboard → LIVE widget. Glanceable: who's on the site right now, with the 30-day traffic trend drawn behind the number. Perfect for a wall screen.
  2. Main View → Growth strip. One card per product: live visitors, conversion (or engagement) rate, 30-day total, and the trend sparkline. Your at-a-glance acquisition health across every product.
  3. Revenue / Growth page. The full picture: daily sessions, new vs. returning, channels, geography, devices, top pages, campaigns, the acquisition funnel, and revenue split by traffic share.

The reason all of this lives inside Probecast — rather than in a separate analytics tab you never open — is correlation:

  • Traffic dips next to incidents. When an API you depend on goes down, watch what your traffic and conversions do. That's the real cost of downtime, in one view.
  • Conversion by channel. See which sources bring visitors who actually pay, not just visitors who bounce.
  • Campaigns that move money. Tag conversions with event() and you can tell which campaign produced revenue, not just clicks.
  • Revenue next to uptime. The whole point: your money and your reliability, on the same screen, so you can see how one affects the other.

Quick checklist

  • [ ] Picked Probecast pixel as the growth source for the product
  • [ ] Pasted the exact snippet (with your pk_ key) into the site-wide <head>
  • [ ] Allowed the pixel host in script-src and connect-src if you run a CSP (and added the nonce if you use one)
  • [ ] Opened your live site and confirmed the LIVE widget ticks up within a minute
  • [ ] (Optional) Wired probecast.consent('granted') into your cookie banner
  • [ ] (Optional) Added probecast.event('signup') at your conversion moment
  • [ ] Came back in a few days to watch the trend line and New-vs-Returning fill in

Install takes two minutes. The patience is in the reading — give it a week before you judge the trends, and a month before you call them definitive. After that, you've got a first-party, revenue-connected view of your traffic that most teams pay three tools to approximate.

30-day free trial

Never miss an API outage again.

Monitor 1,000+ APIs from 4 global regions. Get alerted on Slack, email or webhooks before your users notice. Free for 30 days on Indie.

Start free trial
Share:

Comments

Sign in to join the conversation and leave a comment.

Sign In to Comment