> For the complete documentation index, see [llms.txt](https://docs.adpage.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adpage.io/integrations-websites/shopify/cookie-recovery-on-shopify.md). # Cookie recovery on Shopify Safari deletes tracking cookies after seven days, even when you use your own subdomain for server-side tagging. Safari deletes tracking cookies after seven days, even when you use your own subdomain for server-side tagging. This article explains why that happens, what the cookie recovery script does about it, and how to install it on your Shopify theme. ### What this script does The script stores a visitor ID (the `_taggingmk` cookie) in two places: * **In a first-party cookie on your main domain:** the primary storage location * **In localStorage:** a backup, used to restore the cookie if it disappears That ID is the anchor our server uses to rebuild your tracking cookies when a browser wipes them. ### Safari erases your marketing data Safari's Intelligent Tracking Prevention (ITP) automatically deletes cookies after seven days. Using a custom tracking subdomain such as `tagging.webshop.com` does not solve this: Safari recognises that the subdomain resolves to a different server than your webshop, and treats its cookies as third-party-ish. The result is that after one week you lose the link to your visitor. Repeat visits from Safari users look like brand new visitors, and your conversion attribution stops adding up. In practice that means: * Returning customers are counted as new visitors * Your customer journey data becomes unreliable * Attribution analyses go wrong, for example first-click versus returning customer * Conversion paths are incomplete #### How cookie recovery works around it Three steps: **1. The anchor.** We place a cookie directly on your main domain (`webshop.com`). Because your own website sets it with JavaScript on the primary domain, Safari allows it to live longer than a cookie on your tracking subdomain. **2. The check.** On every page load, the script sends this anchor ID to our server, the proxy. **3. The recovery.** Our server checks whether the tracking cookies on `tagging.webshop.com` are still present. If Safari removed them after seven days, the server writes them back based on the anchor ID. The localStorage backup protects the anchor itself. If the anchor cookie is cleared but localStorage survives, the script restores the cookie from the backup instead of generating a new ID, so the visitor keeps the same identity. The outcome: your tracking stays accurate over a longer period, which means you can measure and optimise your marketing campaigns properly. ### Installing on Shopify 1. Log in to your Shopify admin. 2. Go to **Online Store → Themes**. 3. On your active theme, click the three dots and choose **Edit code**. 4. In the left sidebar, open **`theme.liquid`** (under Layout). 5. Paste the script below directly after the opening `` tag. Placing it high in the `` matters: it needs to run before your other tracking scripts. 6. Click **Save** in the top right. ```html ``` ### Verifying the installation Open your website in an incognito window, then open Developer Tools with F12. #### Test 1: the cookie is created Go to the **Console** tab. You should see `MK Tagging: New visitor ID generated`, followed by `MK Tagging: Visitor ID backed up to localStorage`. Then go to **Application → Cookies** and look for the `_taggingmk` cookie. Its value should be a UUID, for example `a3f2e1d4-5b6c-4d7e-8f9a-0b1c2d3e4f5a`. Refresh the page and confirm the value stays the same. #### Test 2: the localStorage backup works Go to **Application → Local Storage** and look for `_taggingmk_backup`. Its value must be identical to the cookie value. #### Test 3: recovery works Delete the `_taggingmk` cookie manually in Developer Tools, then refresh the page. The Console should now show `MK Tagging: Visitor ID restored from localStorage`, and the cookie should be back with the same value as before. If the value changed instead of being restored, the localStorage backup is not being read. Check the Console for JavaScript errors and confirm the script is present in the rendered ``. ### How the logic flows ``` Visitor arrives on site ↓ Does the cookie exist? → YES → Sync to localStorage → Done ↓ NO Does the localStorage backup exist? → YES → Restore cookie → Done ↓ NO Generate new UUID → Store in cookie + localStorage → Done ``` ### Privacy and GDPR * **No personal data.** The script stores a random UUID only, no personal information. * **First-party cookie.** The cookie is set on your own domain, not by a third party. * **Technically functional.** This is a technical cookie used for analytics, which is often permitted without explicit consent. One caveat: check with your privacy officer whether this cookie qualifies as strictly necessary in your situation, or whether it needs to sit behind consent in your cookie banner. That assessment depends on what you use the data for, not on the script itself. ### Troubleshooting **The script does not seem to do anything.** Check the Console for JavaScript errors, and make sure the script sits before your other tracking scripts in the ``. If another script throws an error earlier in the page, the recovery script may never run. **The cookie still gets deleted.** In some Safari modes ITP restricts localStorage as well, which removes the backup along with the cookie. In that case server-side tracking is the more durable primary solution rather than a client-side recovery layer. **Different IDs across subdomains.** By default the cookie is scoped to the exact hostname. Adjust the `mkTagging_setCookie` function to include `domain=.yourdomain.com` so the same ID is shared across all subdomains. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.adpage.io/integrations-websites/shopify/cookie-recovery-on-shopify.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.