# 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. Source: https://docs.use-mark.com/docs/install-the-site-tag 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 `` of every page, in the order it is given. To find that row, see [Manage websites](/docs/manage-websites). Mark's own line looks like this: ```html ``` 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 Cookiebot, then the Tag Manager loader, then Mark's tag. Keep that order, and paste the snippet above any other script: Cookiebot needs to load first. Loaded before Tag Manager, Cookiebot hands a returning visitor's saved choice to your tags on the first page they view. The consent defaults are pasted once, here. After that, Cookiebot tells your tags each time a visitor makes a choice. Mark never changes consent itself. If you pasted an earlier snippet with Tag Manager above Cookiebot, move the Cookiebot block up above the Tag Manager block, or copy the snippet again from the Websites page. Fixes to Mark's tag itself reach your site on their own within a few minutes; you only paste again when the snippet's blocks change. 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 1. 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`. 2. Submit your form with a real email address. 3. The `lead_submitted` event 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](/docs/capture-leads).