Install the pixel

The pixel is how Bryn sees your website traffic. Without it, Bryn cannot identify anyone. Install it site-wide: identification improves with coverage, and a single-page install misses most of the visitors Bryn could have named for you.

One snippet does two jobs: it reports visits to Bryn, and it receives the payload that lets your site personalize for identified visitors.

Before you start

Your pixel ref: shown on the Pixel step of onboarding, and in your Bryn dashboard.
Edit access to your site's <head> template or your tag manager. No access? Skip to hand it off.

Install it

Pick your platform:

No code changes on your site. Bryn ships an official GTM tag template.

1
Import the template
In GTM, go to Templates, then Search Gallery, and search for Bryn Pixel (published from the civicteam/bryn-google-tag-manager repository).
2
Create the tag
Add a new tag using the template and paste your pixel ref into the Pixel ref field. Use the copy button in the Bryn dashboard so no stray characters come along.
3
Trigger on all pages
Set the trigger to All Pages, then publish the container.

Paste this into your site-wide <head> template, replacing YOUR_PIXEL_REF with your pixel ref:

<script>
(function () {
  window.__brynPixel = { ref: "YOUR_PIXEL_REF" };
  var s = document.createElement('script');
  s.src = "https://bryn.civic.com/pixel/pixel.js";
  s.async = true;
  s.setAttribute('data-bryn-pixel-ref', "YOUR_PIXEL_REF");
  document.head.appendChild(s);
})();
</script>

Put it in the shared layout or header template, not on a single page, so every page reports.

Options. Two attributes on the script tag tune the pixel: data-bryn-personalize="off" reports visits and skips the personalization leg entirely (no polling, no bryn:updated or bryn:personalize, no PostHog write), and data-bryn-debug="true" logs each delivery step to console.debug. Tag managers set the same options on the config global instead:

window.__brynPixel = { ref: "YOUR_PIXEL_REF", personalize: false, debug: true };

__brynPixel also accepts endpoint for a custom collection origin. A CSP nonce on your script tag is forwarded to the bundle it loads, so strict-CSP sites work with a nonced tag. The pixel initializes once per pixel ref: a tag-manager install alongside a leftover manual snippet reports each visit once.

Hand it off

Not the person who edits the website? Send your developer this page link and your pixel ref, with one line: "Please add this script tag to our site-wide head template so it loads on every page." The verification step below tells them (and you) that it worked.

Verify it's working

Open your site in a normal browser tab, click around, then check Activity in the Bryn dashboard. Your visit arrives within moments of the pixel going live.

note

You may not see yourself identified, and that is normal. The pixel reports every visit, but Bryn only resolves identities for business traffic it can match. Seeing the visit in Activity means the pixel works, even while your own visit stays anonymous.

Check it in the browser

Open the console on any page with the pixel and read window.__brynPixelDiagnostics:

{
  publish: { state: "sent-beacon" },   // sent-beacon | sent-fetch | failed | unavailable
  serve: {
    lastOutcome: "ok",
    consecutiveFailures: 0,
    loopState: "polling",              // polling | paused | stopped
    stopReason: undefined              // set when stopped, e.g. "suppressed", "collection-only", "idle-ceiling"
  }
}

publish.state confirms the visit left the browser. serve describes the personalization leg: it polls for the payload, pauses while the tab is in the background, and stops 30 minutes after the last payload change once the visitor is resolved. Every change fires a bryn:delivery event with the same snapshot in event.detail, so a status chip or a QA script can follow it live.

For your IT and security team

What the pixel does, in one screen:

Sends: five fields on each page view: url, referrer, ts, plus firstUrl and firstReferrer, the first page and referrer of the browser session. The pixel keeps that first touch in sessionStorage under bryn:first-touch, so it clears when the tab closes.
Returns: only the visitor fields your workspace chooses under Integrations, then Pixel, then Returned fields. Bryn filters them on its servers, so a field that's turned off never reaches the browser. Anything returned, scores included, is readable by the visitor in their own browser.
Writes to your PostHog: when PostHog runs on your page and PostHog sync is on (the default), the pixel writes the returned fields onto the visitor's PostHog person, under a single bryn property. It never changes who PostHog thinks the visitor is. Turn it off under Integrations, then Pixel, then Setup.
Never touches: form fields, keystrokes, cookies from other tools.
Origin allowlist: Bryn only accepts events from domains on your workspace's allowlist, and rejects everything else.
Personalization writes are inert by default: the return leg only sets text content and the standard hidden attribute on elements you mark, which keeps it XSS-safe. If you never add markers, it changes nothing. data-bryn-personalize="off" turns the return leg off altogether.
Polite polling: the return leg pauses in background tabs and stops after 30 idle minutes once the visitor is resolved.
CSP: a nonce on the script tag carries through to the loaded bundle.
Erasure: deletion requests propagate through Bryn's stores. See How Bryn works for the identification model.

Going further

React to identified visitors on the page: Personalization recipes
Choose which fields, enrichment and scores the pixel returns: Choose what comes back
Name the behaviour the pixel observes: Map your signals
Send events from your backend too: Server-side events & signing
Manage the origin allowlist programmatically: Pixel Origins in the API reference

Before you start​

Install it​

Hand it off​

Verify it's working​

Check it in the browser​

For your IT and security team​

Going further​