Install the site tag
One script tag that runs analytics through Mark's domain and reports when your existing lead form is submitted, so Mark can attribute it.
The site tag is a single script you paste on your site. It does two things: it starts analytics for your pages through Mark's own domain, and it listens to the lead form you already have, so the traffic source that produced an enquiry is attributed correctly.
It does not create the lead. Your form still submits to your CRM exactly as it does today — the tag only watches for the submission and reports it to Mark's analytics as an attribution event. It does not change your form either: your markup, your styling, your validation, and your thank-you page all stay exactly as they are.
Paste the snippet
Copy the snippet from your site's row on the Websites page and put it in
the <head> of every page, in the order it is given. To find that row, see
Manage websites. Mark's own line looks like this:
<script data-cookieconsent="ignore" async src="https://api.mark.lifewithdata.org/t/v1/your-site-key.js"></script>If your site uses Google Tag Manager or Cookiebot and Life With Data has your container id or Cookiebot id, the snippet also carries those blocks: Consent Mode defaults first, then the Tag Manager loader, then Cookiebot outside Tag Manager. Mark never writes the consent defaults itself; they are pasted once, here.
The snippet appears only once analytics is set to run through your own domain. Until then the Websites page says what is still needed. This sequencing matters: the tag sends events to that domain, so a snippet pasted earlier would sit on your pages doing nothing.
The key identifies your site and is safe in client-side code, the same way any analytics key is.
If your site already loads PostHog, remove that snippet when you add this one. Two copies of the analytics library on one page split a single visitor into two people, and the lead you care about ends up attached to whichever copy happened to answer first.
Tell Mark which form to capture
Life With Data configures this for you, but it is worth knowing what they need. There are two ways the tag can hear about a submission.
A form in your own markup
Most sites. Mark needs a CSS selector that matches your form element, for
example #enquiry or form.contact-form. The tag attaches one listener and
reads the form's named inputs when it is submitted.
These input names become their own property on the attribution event:
| Input name | Becomes |
|---|---|
email | The visitor's email. Required — a submission without one is ignored. |
name, or firstName and lastName | The visitor's name. A split pair is joined into one. |
phone | The visitor's phone. |
message | The enquiry text. |
personaId | The persona, if your form asks. |
anything else with a name | An answer, filed under that input's name. |
Password inputs and hidden inputs are never read. If your form has a honeypot field, tell Life With Data its name: the tag drops a submission with a filled one instead of reporting it.
A HubSpot form
If your enquiry form is a HubSpot embed, a plain listener cannot see it, so the tag listens for HubSpot's own submission event instead. Life With Data needs to know you use HubSpot, and optionally the form GUID if you have more than one HubSpot form and only one of them is your lead form.
HubSpot's email, firstname, lastname, phone, and mobilephone
properties map onto the event the same way; every other property on the
submission becomes an answer.
This works with both HubSpot embed styles. It does not work with HubSpot Forms V4, which stopped broadcasting the event the tag listens for — if your embed code mentions V4, tell Life With Data before you install.
No form yet
Leave the capture setting unset. The tag still runs analytics; it simply attaches no form listener and never reports a submission.
Cookie banners
Each site has a Cookie consent setting with two choices.
No cookie banner, track every visit is where every site starts until you give Life With Data a Cookiebot id. The tag starts full analytics on page load and does not wait for a banner to answer. If a banner does ask and the visitor declines, the tag switches to cookieless from then on.
Wait for the cookie banner's answer is what the site switches to once it has a Cookiebot id. Life With Data can also pick it for a site that runs HubSpot's banner instead. The tag then follows the banner:
| Banner | What the tag does |
|---|---|
| Cookiebot | Waits for statistics consent. Full analytics on accept; cookieless analytics on decline. |
| HubSpot's cookie banner | Waits for the analytics category. Full analytics when granted; cookieless when denied. |
| Anything else, or none | Starts immediately. |
That last row matters. The tag only recognises the banners listed above, so if you use a different consent tool the tag will not see it and will begin capturing straight away. Tell Life With Data which tool you use and support for it can be added.
Cookieless means nothing is stored on the visitor's device: no cookie, no local storage. Page views are still counted, keyed by a server-side hash that rolls over daily, so a decline does not make the visit vanish from your numbers.
Google's tags follow the same setting. The Consent Mode defaults in the snippet start granted on a site that tracks every visit, and denied on a site that waits. The snippet is pasted once, so if the setting changes, paste the new snippet from the Websites page to bring Google's tags in line.
Two details a privacy review usually asks about:
- The analytics library is fetched before consent is answered, but it is loaded switched off — it sends no events and sets no cookies until consent is granted. That is the analytics vendor's own documented pattern.
- If your banner loads more slowly than the tag, a single page view can be recorded before the banner has an answer. Declining still stops everything from that point on, and the recorded view is discarded with the visitor's other data.
A visitor who declines still has their submission reported if they go on to submit your form — submitting a form is its own act of consent. The tag keeps the click ids and UTM parameters from the page the visitor landed on in memory and attaches them to the submission, so the source survives even when the banner was declined or an ad blocker dropped the first page view.
Updates
The tag is served from Mark, not copied into your pages, so improvements
reach your site on their own within a few minutes. You never need to paste
it again. The v1 in the URL only changes if the tag ever changes in a way
that needs your attention, and Life With Data would tell you first.
Turning it off
Delete the script tag from your pages and the integration stops immediately; nothing on Mark's side depends on it still being there. If Life With Data needs to withdraw a change to the tag itself, they revert it and every page picks up the correction within five minutes without you doing anything.
Checking it works
- Open a page with the tag on it and look at your browser's network panel.
You should see requests to the analytics domain on your own site (the
one Life With Data set up as the reverse proxy) and none at all to
posthog.com. - Submit your form with a real email address.
- The
lead_submittedevent appears in your PostHog project, and your own thank-you page and CRM still work exactly as before — the tag only reports the submission for attribution, it never touches either.
A submission your own form rejects — failed validation, or a failed bot challenge — is not reported, so your validation stays the gate on what counts.
If the form submits but nothing reaches PostHog, the selector is the usual culprit — check it still matches after any redesign.
To post a lead to Mark directly instead of relying on the tag — for a form
that has no submit event, or a vendor the tag has no adapter for — see the
lead capture contract.