The tracking snippet is a small async script — a few kilobytes served from an edge-cached first-party path — that identifies the organisation behind each session. Correctly installed, you should never notice it. Incorrectly installed, you will spend a week debugging why identified companies are missing before you find out the loader was inside a lazy-loaded partial. This guide gets you past that week.
Three principles before you paste anything
- The loader belongs in the site-wide HTML head. Not the footer, not a specific page template, not a component that only renders on marketing pages. In the head, on every page.
- The loader is async by default. Do not add a defer/async override that changes when it executes; the shipped attributes are the ones we tested.
- Install once, exactly. Two copies of the loader on the same page do not double your data — they double the requests and confuse debugging.
WordPress
The cleanest install on WordPress avoids theme edits. Use a header-scripts plugin (any of the well-known ones will do), paste the loader into the "scripts in head" field, save, and clear any page-cache. If you do not want a plugin, add a small mu-plugin file that hooks into wp_head with priority 5 so the loader lands before analytics tags. Do not paste it into a page or post body — WordPress will sanitise the script tag out.
One WordPress-specific check: if you run a full-page cache (LiteSpeed, WP Rocket, W3 Total Cache), purge the cache after installing. Cached HTML that predates the install will not contain the loader.
Shopify
Shopify puts the theme HTML in theme.liquid. In your Shopify admin, open Online Store → Themes → Actions → Edit code → theme.liquid, and paste the loader immediately before the closing </head> tag. Save. That is all — no app required, no checkout script (checkout is out of scope for company-level identification anyway).
Duplicate a theme first
Before editing theme.liquid, use Actions → Duplicate. If anything goes wrong you can revert in one click. This is a five-second habit that has saved every Shopify team it was ever suggested to.
Webflow
Webflow → Site Settings → Custom Code → Head Code. Paste the loader. Save. Publish the site. The head code applies globally to all pages, which is exactly what you want. Do not paste the loader into a page-level embed — you will only track that one page.
Google Tag Manager
GTM works, with two caveats. First, use a Custom HTML tag with the trigger set to "All Pages" so the loader runs on every pageview. Second, put the tag priority high enough that it fires before other analytics tags that might slow the initial payload. GTM users often layer four or five tags on the head; the loader is small, but tag firing order matters if you want first-request identification.
Consent-mode caveat: if you run GTM behind a consent banner that only fires analytics tags after opt-in, do not put company-level identification behind the same gate — it does not use cookies or store data on the visitor’s device, so it does not require the same consent surface. Configure the tag to fire immediately, alongside your strictly-necessary tags.
Plain HTML / bespoke stacks
For a hand-rolled site or a framework we did not name, paste the loader inside the <head> element of your base template — the file that renders on every page. Rebuild and redeploy. For static site generators, the loader belongs in the site-wide layout file (in Next.js, that is a <Script> in the app-level layout with strategy="afterInteractive"; in Astro, the <BaseHead> component; in 11ty, the base template partial). If you added it as a component-level script, only pages including that component will report.
Single-page applications — the one gotcha
In an SPA, the initial pageview is captured by the loader when the page first loads. Subsequent client-side navigations are not automatic pageviews from the browser’s point of view. Our loader listens for the History API by default, so back/forward and pushState-based navigations register as new pageviews without any code from you. If your SPA uses a non-standard router that bypasses the History API (rare, but not unheard of), call the small documented pageview function on route change — three lines, referenced in the docs.
Verify installation in two minutes
Verification is not optional. Do it before you close the tab that installed the loader; catching a broken install five minutes after paste is trivial, catching it five days later is not.
- Open your site in a private/incognito window (so no cached assets confuse you).
- Open DevTools → Network tab, filter by "l5e" or the loader path.
- Reload the page. You should see one request to the loader, then one small identify beacon. Both should be status 200. The loader response headers should include a cache-control with s-maxage and stale-while-revalidate.
- Navigate to a second page. You should see one more identify beacon fire, no re-download of the loader (it will 304).
- Return to the lead.box dashboard, open the live visitor feed, and confirm your test visit appears. If it does, the install is done.
Common mistakes — the table to check first
| Symptom | Likely cause | Fix |
|---|---|---|
| No live visits at all | Loader missing from head, or on wrong template | Move loader into the site-wide head template |
| Live visits only from one section | Loader in a page-level embed, not global | Move to global head / theme header |
| Loader loads but no identify beacon | Consent banner blocking third-party scripts too aggressively | Configure banner to allow strictly-necessary; loader does not need consent |
| Double beacons per pageview | Loader installed twice (theme + plugin/tag) | Remove one |
| Slow first paint after install | Loader placed before critical CSS | Confirm async attribute is present; place after preload of critical CSS |
| SPA reports only the first page | Custom router bypasses History API | Call documented pageview() on route change |
| Stale HTML served without loader | Full-page cache not purged after install | Purge cache; verify in incognito |
Performance note — edge-cached loader
The loader is served from a first-party path proxied to our edge cache with s-maxage=300 and stale-while-revalidate. In practice this means the loader is fetched once per five minutes per edge PoP, then served from cache to every subsequent visitor. Byte weight and blocking impact are small enough that we do not recommend layering additional loading logic on top of it.
When to ask for help
If you have walked the verification steps and something still is not right, we would rather hear from you at the ten-minute mark than at the ten-day mark. Bring three things: the site URL, a screenshot of the DevTools Network tab filtered by the loader path, and the name of the platform you installed on. That is enough to diagnose almost every install issue on the first reply.
Published by
lead.box Team
More articles
See lead.box on your own traffic
Start free — no card, no sales call required. Or book a 20-minute walk-through if you want the guided tour.