Tagway: serve tracking from your own domain

Your tagging subdomain makes your tracking first-party, but Safari still keeps it at arm's length. Because the subdomain runs on Measurebase's servers rather than your website's, Safari limits the cookies it sets to 7 days. Tagway moves your tagging onto a path of your own website, such as https://www.example.com/mb, so Safari sees your own site and your cookies keep their full lifetime.

Why Safari cuts your cookies short

Since Safari 16.4 (March 2023), Safari checks where a subdomain is hosted. When a subdomain of your site runs on a server unrelated to your website's, Safari caps the cookies that subdomain sets in its responses at 7 days. It is a defense against trackers hiding behind a site's own subdomain, and it hits honest first-party tagging just the same.

Safari decides by IP address. One address on IPv4 and the other on IPv6, or two IPv4 addresses that share fewer than their first 16 bits, count as unrelated. Your tagging subdomain, for example mbase.example.com, runs on Measurebase's servers, so for nearly every site the cap applies.

In practice: on Safari, the cookies Cookie Keeper re-issues and the cookies your server container sets itself last 7 days. A Safari visitor who comes back after more than a week counts as a new visitor.

What Tagway changes

With Tagway, your website forwards one path (default /mb) to your Measurebase tagging server. The browser only talks to your own website: https://www.example.com/mb instead of https://mbase.example.com. To Safari that is your own site, so the cap does not apply.

• Full cookie lifetime on Safari. Cookie Keeper and your server container's cookies last as long as they are set to, so returning visitors stay recognized.
• No separate tracking hostname. Blockers have no tagging subdomain to match. That is a bonus, not a guarantee: filter lists can match paths too.
• Nothing else changes. Same server container, same power-ups, same request log. Attribution windows and consent rules stay exactly as they are; Tagway is about your identifiers surviving.

Tagway is available on every plan.

Setting it up

1. Open Power-ups > Tagway for your domain in the dashboard. Enter your website address, for example https://www.example.com, and the path. /mb is the default; any path your site does not use yet will do.
2. Add the forwarding configuration for your platform. The dashboard generates it with your own address, path and tagging host filled in, ready to paste. Deploy it.
3. Run the check. Measurebase requests the path through your website and checks four things: it is reachable through your website, it reaches Measurebase, the visitor IP is forwarded, and cookies pass through. A failed check says what to fix.
4. Switch your site over to the new address, as described below.

Your tagging subdomain keeps working the whole time, so nothing breaks while you switch.

Platforms

Tagway works wherever you can forward a path to another address. The dashboard shows the exact configuration for each of these:

• Vercel · a rewrite in vercel.json
• Next.js · a rewrite in next.config.js
• Cloudflare · a Worker plus a route on your site
• Netlify · one line in _redirects
• nginx · a location block with proxy_pass
• Apache · mod_proxy, on a server whose configuration you control
• WordPress and Shopware · a built-in Tagway mode in the Measurebase WordPress plugin (0.8.0 and later) and Shopware plugin (0.5.0 and later)

On Vercel, the whole configuration is one rewrite in vercel.json, with your own tagging host filled in:

{
  "rewrites": [
    {
      "source": "/mb/:path*",
      "destination": "https://mbase.example.com/mb/:path*"
    }
  ]
}

Tagway is not available on Shopify storefronts, which cannot forward a path with its cookies intact, or on basic shared hosting without a proxy. There, your tagging subdomain keeps working as it does today.

The visitor IP

Requests now pass through your website first, so Measurebase needs the visitor's IP passed along. The generated configuration sends it in an X-MB-Client-IP header (Vercel sends it by itself), so geo enrichment, the IP filter and IP masking keep working. The check tells you when it is missing.

After verification: switch your site over

Once the check passes, point three things at the new address:

1. The loader snippet. Generate your script again on the domain page. Once Tagway is verified, Generate script uses your own domain automatically. Replace the snippet on your site with the new one.
2. The Google tag in Google Tag Manager. In your web container, set the Google tag's server container URL to your new address, for example https://www.example.com/mb, then publish. With Google Tag Manager connected, Measurebase can propose this change into its own "Measurebase" workspace; you review and publish it.
3. Server preview. In your server container, open Admin, Container Settings, and put the new address first under Server container URLs. Tag Assistant opens server preview on that first URL, and the cookies it sets there only reach that host: left on the subdomain, preview shows nothing for hits that go through Tagway. Save (no publish needed) and restart preview. The tracking audit flags it while it still points at the subdomain.

Visitors move over as the new snippet and container version reach them. The tracking audit flags the Safari cap for each domain where it applies and confirms once Tagway is verified.

Frequently asked questions

Does Tagway work on Shopify?

No. Shopify storefronts cannot forward a path to another server with its cookies intact, so Tagway is not available there. Your tagging subdomain and the Measurebase Shopify app keep working as before.

Can switching break my tracking?

No. Your tagging subdomain keeps working throughout, and both addresses lead to the same server container. Run the check before you change anything on your site. If you turn Tagway off later, point the snippet and the Google tag back at your tagging subdomain first.

Does it stop ad blockers?

It helps, because there is no separate tracking hostname left for a blocklist to match. It is not a guarantee: filter lists can match paths too. Pick a path that does not look like tracking, so not /analytics or /collect, and keep Enhanced Ad Blocker Protection on for requests that would still be caught on their path.

Does it change consent or attribution?

No. Your consent banner and Consent Mode work exactly as before, and attribution windows stay what each platform sets. Tagway only makes sure the identifiers you already set survive on Safari, instead of being cut to 7 days.