If you've noticed gaps in your conversion data or your pixel-based tracking suddenly looks unreliable, Safari's Intelligent Tracking Prevention (ITP) is almost certainly the culprit. Apple introduced ITP to limit cross-site tracking in Safari, and while it's designed to protect user privacy, it creates a real problem for marketers who depend on browser-based pixels to measure ad performance.
ITP aggressively restricts third-party cookies and shortens the lifespan of first-party cookies set via JavaScript. That means your Facebook Pixel, Google Ads tag, and other tracking scripts may be firing just fine while capturing far less data than you think. The events are triggering, but the attribution chain is quietly breaking in the background.
For B2B SaaS companies running paid campaigns, this is not a minor inconvenience. It directly distorts your attribution data, inflates your reported cost per acquisition, and makes it nearly impossible to accurately measure which ads are driving pipeline and revenue. When your sales cycle stretches across weeks or months, a cookie that expires in seven days is essentially useless for attribution.
The fix is not to work around ITP with clever client-side hacks. Those approaches are temporary at best, and Apple keeps tightening restrictions with every Safari update. The real fix is to move your tracking infrastructure to a place where ITP cannot touch it: the server.
This guide walks you through exactly how to diagnose ITP-related tracking loss, implement server-side tracking as your foundation, and configure your ad platform integrations to restore accurate conversion data. By the end of these steps, you will have a tracking setup that works regardless of what Safari does next, and you will be able to trust your attribution data again.
Step 1: Diagnose How Much Data ITP Is Actually Costing You
Before you fix anything, you need to understand the scale of the problem. Many marketing teams assume their tracking is working because events are firing, but firing and accurately attributing are two very different things. Start by pulling your actual numbers.
Open your analytics platform and compare Safari traffic volume against conversion events attributed to Safari users. If Safari accounts for a meaningful share of your total sessions but a disproportionately small share of attributed conversions, that gap is your ITP problem made visible. The discrepancy tells you how much revenue attribution you are currently losing.
Next, check your Meta Events Manager and Google Ads conversion tracking for any browser-level breakdowns. Look specifically at whether Safari conversions appear underreported relative to Safari's share of your overall traffic. This comparison gives you a platform-specific view of the damage rather than just a site-wide one.
Look for signs of cookie expiration in your data. ITP caps JavaScript-set first-party cookies at seven days, and in some scenarios reduces this to 24 hours when it detects referral traffic patterns that suggest cross-site tracking. In practice, this means returning visitors who first clicked an ad more than a week ago may be appearing as brand new users in your analytics, and their conversions are not being connected to the original ad click.
Review your attribution window settings in your ad platforms and compare them against ITP's cookie lifespan restrictions. If you are running 30-day click attribution windows in Meta or Google Ads but your cookies expire in seven days, you have a structural mismatch. Any conversion that happens after day seven is invisible to your pixel-based tracking.
Document all of these baseline numbers before making any changes. Write down your current attributed conversion volume, your cost per acquisition by channel, and your Safari-specific conversion rates. You will need these figures to measure the actual impact of the fixes you implement in the steps ahead.
Step 2: Understand Why Pixel-Based Tracking Fails in Safari
To fix the problem properly, you need to understand why it exists. Browser pixels like the Meta Pixel and Google Ads conversion tag work by placing a small piece of JavaScript on your website. When a user visits your site, that JavaScript fires and either sets a cookie to identify the user or reads an existing cookie to recognize a returning visitor.
There are two types of cookies involved: third-party cookies, which are set by a domain different from the one the user is visiting, and first-party cookies, which are set by your own domain. ITP blocks third-party cookies entirely in Safari. There are no exceptions and no workarounds on the browser side. If a tracking script tries to set a cookie from a third-party domain, Safari simply does not allow it.
First-party cookies set via JavaScript face a different but equally damaging restriction. ITP limits these cookies to a maximum of seven days of storage. In some cases, when Safari detects that your domain is being used primarily for cross-site tracking purposes, it can reduce that window to 24 hours. This means that even if your pixel successfully identifies a user on day one, that identification expires quickly.
For B2B SaaS companies, this is particularly damaging. Think about a prospect who clicks a LinkedIn ad on a Tuesday, visits your pricing page, and then comes back three weeks later after a colleague demo and signs up for a trial. In a world with ITP, the cookie from that first click is long gone. The trial signup gets attributed to direct traffic or the last-touch session, not the ad that actually started the journey.
Ad platform pixels like the Meta Pixel and Google Tag operate entirely in the browser, which means they are fully exposed to ITP restrictions with no ability to override them from the client side. This is not a bug you can patch. It is a fundamental architectural limitation of browser-based tracking. A cookieless tracking solution is the only way to reliably resolve this at its root.
Step 3: Set Up Server-Side Tracking as Your Foundation
Server-side tracking sends conversion events directly from your web server or a middleware layer to ad platforms, bypassing the browser entirely. Because the communication happens server-to-server, ITP has no ability to interfere. It does not matter what browser a user is running or what privacy settings they have enabled. The data flows directly from your infrastructure to the ad platform.
You have a few options for implementing server-side tracking. The most common approaches are a server-side tag management container (such as server-side Google Tag Manager), a direct Conversion API integration built into your application, or a dedicated attribution platform that handles server events natively. Each approach has different complexity and maintenance requirements, so choose based on your team's technical capacity and the scale of your tracking needs. To evaluate your options, review the top server-side tracking tools available today.
Once you have chosen your approach, configure your server to capture the key conversion events that matter for your B2B SaaS funnel. These typically include form submissions, free trial signups, demo requests, and any downstream CRM events like marketing qualified leads, sales qualified leads, or closed-won deals. The goal is to capture events at every meaningful stage of your pipeline, not just the top-of-funnel actions.
One of the most important things to get right in your server-side setup is passing matching parameters. Ad platforms use these parameters to match your server events back to the users who interacted with your ads. The most valuable matching parameters are hashed email addresses, phone numbers, and IP addresses. The more parameters you pass, the higher your event match quality score will be, and the more accurately the platform can attribute conversions to the right campaigns.
Before moving to the next step, verify that your server events are actually arriving at your ad platforms. Check Meta Events Manager and Google Ads conversion settings for incoming server events. You should see them appearing with a source labeled as "server" rather than "browser." If events are not showing up, troubleshoot your server configuration before proceeding. Building on a broken foundation will create compounding problems later. For a deeper look at why this approach outperforms browser tracking, see why server-side tracking is more accurate.
Step 4: Implement Meta Conversion API and Google Enhanced Conversions
With server-side tracking in place as your foundation, the next step is to connect it to your specific ad platforms. For Meta, this means implementing the Conversion API (CAPI). For Google Ads, it means configuring Enhanced Conversions. Both are the official server-side integration methods from their respective platforms, and both are designed to work alongside your existing browser pixels rather than replace them.
Meta's Conversion API sends conversion events from your server directly to Meta's servers, completely bypassing Safari's ITP restrictions on the Meta Pixel. When you implement CAPI, you are creating a parallel data stream that does not depend on the browser at all. Even if a Safari user's pixel cookie has expired, the server event still fires and reaches Meta with the correct attribution data. Understanding how Facebook Pixel tracking interacts with server events is essential before configuring deduplication.
The critical configuration detail here is deduplication. Because you are now sending the same conversion events from both the browser pixel and the server, Meta needs a way to know that a "Lead" event from the pixel and a "Lead" event from CAPI represent the same conversion, not two separate ones. You accomplish this by assigning a unique event ID to each conversion and passing that same ID from both the pixel and the server. Meta uses the event ID to deduplicate automatically. Without this, you will see inflated conversion numbers and your optimization algorithms will be working from corrupted data.
Google Enhanced Conversions works on a similar principle for Google Ads. It uses hashed first-party data, primarily email addresses, to match conversions on Google's side rather than relying on cookies. When a user converts on your site, you send their hashed email address to Google along with the conversion event. Google matches that hash against its own user data to attribute the conversion accurately, even when cookie-based tracking has failed.
For both platforms, prioritize passing as much hashed customer data as possible: email address, phone number, first name, and last name. More matching data translates directly to higher match rates, which means more conversions get accurately attributed. This improved attribution also feeds better signals to the ad platform's optimization algorithms, which improves campaign performance over time.
Once both integrations are live, verify that deduplication is working correctly. In Meta Events Manager, look at the event match quality score and check for duplicate event warnings. In Google Ads, review your conversion settings to confirm Enhanced Conversions is active and processing data. Only move forward with scaling ad spend once you have confirmed the data is clean.
Step 5: Implement First-Party Cookies Set via Your Own Domain
Even with server-side tracking handling your conversion events, you still need to accurately capture the initial ad click and UTM parameters on the client side. This is where your attribution story begins, and getting it right ensures you can connect server-side conversion events back to the specific campaigns and ads that started the customer journey.
The key distinction here is how cookies are set. ITP treats cookies set via JavaScript (document.cookie) very differently from cookies set via HTTP response headers from your own server. Server-set cookies, delivered through the Set-Cookie HTTP header, are not subject to the same aggressive expiration policies that ITP applies to JavaScript-set cookies. By setting your tracking cookies from your own server rather than through JavaScript, you create more durable attribution data.
Use a subdomain of your own domain for any tracking scripts or cookie operations. For example, if your main domain is yoursaas.com, you might use track.yoursaas.com for your tracking infrastructure. Cookies set on a subdomain of your own domain are classified as first-party by Safari, which means they receive more favorable treatment under ITP than anything set from a third-party domain. This is a meaningful architectural decision that affects how long your tracking data persists.
When a user arrives on your site after clicking an ad, capture the UTM parameters and ad platform click IDs from the URL immediately. Understanding what UTM tracking is and how it works will help you configure this correctly. The most important ones are fbclid (Facebook's click identifier), gclid (Google's click identifier), and your standard UTM parameters like utm_source, utm_medium, and utm_campaign. Store these values in server-set first-party cookies so they persist through the session and remain available when you send server-side conversion events.
This approach gives you durable click attribution data that survives ITP's JavaScript cookie restrictions. When a conversion event fires on the server, you can pull the stored click ID and UTM parameters from the cookie and pass them along with the event, giving your ad platforms and attribution platform the full picture of where that conversion originated.
Step 6: Connect Your CRM and Pipeline Data for Full Revenue Attribution
Server-side tracking solves the ITP problem for conversion events, but B2B SaaS companies need to go further. A form fill or trial signup is not revenue. The events that actually matter for your business are the ones that happen weeks or months later in your CRM: opportunities created, deals closed, MRR generated. Connecting those downstream events to your original ad data is what transforms good tracking into genuine B2B attribution.
Start by passing your ad click data into your CRM at the moment a lead is created. When someone submits a demo request form, your server should capture the UTM parameters, click IDs, and session identifiers from their first-party cookies and write those values into the corresponding CRM record. This creates a durable link between the ad click and the lead record that does not depend on any browser cookie surviving long enough to connect them later.
Once that link exists in your CRM, you can use webhooks or native integrations to send downstream CRM events back to your attribution platform as offline conversions. When a deal moves to closed-won, that event can fire a webhook that sends the revenue amount, the original UTM data, and the click IDs to your attribution platform and your ad platforms. This closes the attribution loop completely. For a detailed breakdown of how to handle this process, see our guide on tracking closed-won revenue.
The result is attribution data that shows you not just which ads drove form fills, but which ads drove actual pipeline and closed revenue. This view is completely immune to ITP because none of it depends on browser cookies. The connection between the ad click and the closed deal lives in your CRM and your attribution platform, not in a cookie that Safari can expire.
Platforms like Cometly are built specifically for this workflow. Cometly connects your ad platform data, website events, and CRM revenue data into a single attribution view designed for B2B SaaS teams. Instead of manually stitching together multiple tools and hoping the data stays consistent, you get a unified picture of which campaigns are driving pipeline and revenue, with server-side event ingestion handling the ITP problem natively.
Putting It All Together: Your ITP-Proof Tracking Checklist
If you have followed the steps above, you now have a tracking infrastructure that does not depend on browser cookies to function. Here is a quick checklist to verify that every component is in place before you consider the implementation complete.
Diagnose your baseline: You have documented your pre-fix conversion volume, cost per acquisition, and Safari-specific attribution gaps so you can measure improvement.
Server-side tracking is live: Conversion events are firing from your server and appearing in your ad platform event dashboards with a "server" source label.
Meta CAPI is configured with deduplication: Server events and pixel events share the same event IDs, and Meta Events Manager shows no duplicate event warnings.
Google Enhanced Conversions is active: Hashed customer data is being passed with conversion events and Google Ads confirms Enhanced Conversions is processing data.
First-party server-set cookies are capturing click data: UTM parameters and click IDs are stored in server-set cookies on your own domain and are being passed with server-side conversion events.
CRM data is connected: Ad click data flows into your CRM at lead creation, and downstream revenue events flow back to your attribution platform as offline conversions.
This setup is durable against future ITP updates because it does not depend on browser cookies at any critical point in the attribution chain. It also feeds better conversion signals to ad platform algorithms, which improves campaign optimization over time.
If you want to see this entire workflow handled in a single platform built for B2B SaaS, Cometly connects your ad data, server-side events, and CRM revenue attribution in one place. Get your free demo and see how Cometly gives you accurate attribution data that Safari ITP cannot touch.
