Privacy & consent

• Stores data on the device. The visitor's journey — first touch, last touch, one entry per session, a pageview count, timestamps — lives in first-party localStorage under the key mtk_attribution, and persists across visits until the visitor clears site data.
• Reads ad-platform cookies. _fbc and _fbp (set by the Meta Pixel) and _gcl_aw(set by Google's tags), on the site's own domain. MTK sets no third-party cookies and does no cross-site tracking.
• Captures marketing data. UTM parameters, the referrer, landing paths, the full landing query string, and ad click IDs (gclid, gbraid, wbraid, msclkid, fbclid).
• Captures coarse device info. Browser, OS, and device type as family names only — the raw user-agent string is never stored.
• Joins it to the person. On submit, every mapped value travels with the form, next to the name, email, and phone the visitor typed, into the site's CRM. From that point it is personal data about a named lead.
• Shares it with the page's tags. The values are pushed to the dataLayer, where any Google Tag Manager tag (GA4, ad pixels) can read them.

None of it reaches Boggs MTK: the tag server logs only which hostname requested the tag and a daily request count. Full list of values in What MTK Attribution captures; our side is covered in the privacy policy.

1. What is collected— traffic source and campaign data, ad click identifiers, pages visited and visit timing, browser and device type. Under CCPA these sit in the “identifiers,” “internet or other electronic network activity,” and device-information categories.
2. How — first-party browser storage, plus reading advertising cookies set by Meta and Google.
3. Why — to measure which marketing channels and ads produce enquiries.
4. That it is linked to form submissions and stored in the CRM with the visitor's contact details.
5. Who receives it — the CRM vendor, the agency running the marketing, and Google, Microsoft, or Meta if click IDs are uploaded for conversion tracking (offline conversion imports, the Conversions API).
6. How long it is kept— in the browser (until cleared) and in the CRM (the site's own retention period).
7. How to opt out — clearing site data, the consent banner, and a Do Not Sell or Share link where that applies.

Adapt to the site — keep or drop the bracketed sentences to match what the site actually does with the data.

Marketing attribution. When you visit our site, we use a first-party
script (MTK Attribution) that stores information in your browser's local
storage about how you found us — such as the referring website, advertising
campaign parameters (UTM tags), ad click identifiers from Google, Microsoft
and Meta, the pages you landed on, the number and timing of your visits, and
your general browser and device type. It may also read advertising cookies
set by Meta and Google on our site. If you submit a form, this information is
sent with your submission and stored in our customer-relationship system so
we can understand which marketing brought you to us. [We may share ad click
identifiers with Google, Microsoft or Meta to measure the performance of our
advertising.] [Where consent is required, this script runs only after you
accept marketing cookies.] You can remove this information at any time by
clearing your browser's site data for our website[, or opt out through our
cookie settings / "Do Not Sell or Share My Personal Information" link].

If the consent banner keeps a storage or cookie declaration, add the tag's entry:

Name:      mtk_attribution
Type:      localStorage (first-party)
Provider:  [your site's domain]
Purpose:   Remembers how the visitor arrived (traffic source, campaign,
           ad click IDs, landing pages, visit count) so form submissions
           can be attributed to the marketing that produced them.
Duration:  Persistent until the visitor clears site data
Category:  Marketing

EU, UK, Switzerland (GDPR + ePrivacy / PECR). Writing to localStorage counts the same as setting a cookie, and attribution is not strictly necessary for the site to work. The tag needs prior, opt-in consent — treat it as a Marketing tag and load it only once that category is accepted.

Brazil (LGPD). Treat it the same as the EU.

United States (CCPA/CPRA and the other state privacy laws). Disclosure in the privacy policy is the baseline. If the site sends click IDs or _fbc / _fbpback to Google, Microsoft, or Meta to optimize ads, that is likely “sharing” for cross-context behavioral advertising (or “targeted advertising” under the Virginia/Colorado/Connecticut-style laws). Then the site also needs a “Do Not Sell or Share My Personal Information” link, has to honor Global Privacy Control, and should stop the tag or the uploads for visitors who opt out.

Ad-platform terms. Meta's Business Tools Terms and Google's EU User Consent Policy require the site to disclose these identifiers and collect consent where the law requires it — independent of MTK.

Our install guides put the tag straight in the <head>so a blocked GTM container can't take it down. That still works with a consent banner: most consent platforms block a script tag until its category is accepted, then run it on the same page. Mark the tag for the Marketing category.

Cookiebot

<!-- Cookiebot: blocked until the visitor accepts Marketing -->
<script type="text/plain" data-cookieconsent="marketing"
  src="https://attr.boggsmtk.com/v1/tag.js?k=YOUR_LICENSE_KEY"></script>

OneTrust— use the group ID the site's OneTrust setup assigns to Targeting/Marketing.

<!-- OneTrust: blocked until the Targeting group (C0004) is accepted -->
<script type="text/plain" class="optanon-category-C0004"
  src="https://attr.boggsmtk.com/v1/tag.js?k=YOUR_LICENSE_KEY"></script>

Other consent platformsuse the same pattern — check the platform's docs for its “manual script blocking” attribute.

Through Google Tag Manager (when the <head> is off-limits): put the loader in a Custom HTML tag, open Advanced Settings → Consent Settings, choose Require additional consent for tag to fire, and add ad_storage. Fire it on All Pages andon the consent platform's consent-update event, so it also runs on the page where the visitor clicks Accept, not only from the next page on.

• Visitors who decline are never tracked — their leads arrive with empty attribution fields. That is the intended result, not a bug.
• Consent on the landing page loses nothing: the banner runs the tag on that same page, with the UTMs and click IDs still in the URL.
• Consent on a later page means the landing URL is gone. The tag ignores the site's own pages as a referrer, and recovers a Google or Meta ad click from a fresh _gcl_aw / _fbc cookie when the platform tag set one. Anything else — UTM-only campaigns, organic search — reads Direct. Showing the banner on the first page view keeps this rare.

• Sensitive verticals. On health, addiction-treatment, legal, or financial sites, landing paths like /services/addiction-treatmentand campaign names can reveal something sensitive about the lead. Those sites face extra rules (HIPAA, the FTC Health Breach Notification Rule, Washington's My Health My Data Act). MTK's terms rule out collecting sensitive personal information, so review which fields those sites map.
• The full landing query string. mtk_first_query and mtk_last_queryrecord the query string exactly as it arrived. If the site's links ever carry an email address or other personal details in the URL (some email-platform links do), that lands in the CRM too. Leave those two hidden fields off the form, or remove them from the license's field map in the dashboard.