maritimemarketing . agency
High angle view illuminated buildings night
Paid Media 22 Aug 2025

Server-side tagging for maritime websites

Why server-side tagging matters more for low-volume maritime accounts than for high-volume B2C, and how to set it up without breaking the existing tracking.

Nathan Yendle
Nathan Yendle
Co-Founder, Priority Pixels
maritimemarketing.agency / blog

Server-side tagging used to be an enterprise concern. For a maritime services site doing 100,000 sessions a month, it still is. But for the typical maritime account doing 3,000 to 15,000 sessions a month with very long sales cycles, the case for server-side has actually grown stronger over the last two years.

The reason is that browser-side tracking has been quietly degrading. Three forces compound:

  • Safari’s intelligent tracking prevention truncates first-party cookies to 7 days when set by client-side scripts. On a 12-month maritime cycle, the original click attribution is long gone.
  • Browser-level privacy extensions (uBlock Origin, Ghostery, Privacy Badger) block analytics tags before they fire. Adoption among technical and senior corporate users (the maritime decision-maker profile) is materially higher than in the general population.
  • iOS, Edge in private mode and Firefox in standard configuration all apply some level of cookie restriction by default.

The result, in most maritime accounts we audit, is data loss between 20% and 40% on browser-side tracking. That is the gap server-side tagging closes.

What server-side tagging actually does

Server-side tagging moves the analytics and ad-platform tags off the browser and onto a server you control, usually a Google Cloud Run or App Engine instance, or a Cloudflare Worker. The browser sends a single first-party request to your tagging server, which then forwards properly formatted requests to Google Analytics, Google Ads, LinkedIn, Microsoft Ads, Meta and so on.

Two things change:

  • The cookies set during this round-trip are first-party and server-set, which gives them a much longer lifetime in Safari.
  • The browser is not sending requests directly to ad-platform domains, so most ad blockers do not intercept them.

You also gain control over what data is forwarded to which platform, which is useful for both privacy compliance and accuracy.

Setup that does not break what already works

The mistake we see most often is teams ripping out the existing client-side tag manager and replacing it wholesale. Do not do that. Run the two side by side for a transition period.

A workable rollout for a maritime site:

  • Week 1: provision the sGTM container on Google Cloud Run or Cloudflare Workers, point a subdomain at it (analytics.yoursite.com), set up the basic GA4 client-side stream forwarding through the server.
  • Week 2: migrate Google Ads conversion tracking to the server side. Validate that conversions match within 5% of the previous week’s volume.
  • Week 3: migrate LinkedIn Insight Tag and Microsoft UET. These are more fiddly, especially the LinkedIn enhanced conversion fields.
  • Week 4: enable enhanced conversions for leads. This is where the long-cycle benefit really starts to show.

Throughout, leave the client-side tag manager in place but disable any tags that have moved to server-side. This avoids double counting and gives you a safety net if something breaks.

Where the maritime gain lands

Three places in particular:

  • Form-fill attribution. Form submissions captured server-side carry the original click ID and the user’s hashed email. This is what feeds enhanced conversions for leads, which is the thing that lets long-cycle pipeline data flow back to the bidders.
  • LinkedIn engagement. LinkedIn’s conversion API requires server-side data to function properly. Browser-side LinkedIn pixels are heavily blocked by the corporate IT estates that maritime decision-makers sit in.
  • GA4 reporting accuracy. Cross-device journeys and long-cycle returning-visit behaviour are far more legible in server-side GA4 than in client-side. For maritime, where one buyer might visit your site eight times across six months from three devices, this matters.

Accuracy compounds

Server-side tagging is unglamorous infrastructure work. It does not directly produce leads. It does, however, mean that every optimisation decision the paid-media platforms make is operating on accurate signal rather than degraded signal. For a maritime account where every signed contract is worth six figures or more, that accuracy compounds into real money over the cycle.

Frequently asked questions

Is server-side tagging worth it for a small maritime site with 5,000 monthly visits?
Yes, more than it is for a high-volume site. At low volumes, every conversion matters disproportionately to the bidder's learning. Losing 25% of conversion data to browser-side tag blocking on a 5,000-visit site can mean the difference between a campaign that learns and one that never accumulates enough signal.
How much does it cost to run a server-side tagging container?
On Google Cloud, a small App Engine instance for a maritime-volume site costs around £15 to £40 per month. Cloudflare Workers can run sGTM for similar money. The setup time is the bigger investment: budget two to three days of competent implementation work, including QA across the existing tags.
Will server-side tagging fix all our cookie-consent problems?
No, and treating it as a consent workaround will land you in trouble with the regulator. Server-side tagging changes how requests are routed and how cookies are set; it does not change the legal need for valid consent before fire. Wire the consent state through to the server-side container so it gates which platforms receive data, the same way a well-built client-side stack does.
Share

Want help putting this into practice?

We work with maritime companies on exactly this kind of programme. Tell us about yours.