Migrating Off a Client-Side Pixel: A 30-Day Plan

You can migrate off a client-side pixel in 30 days by running both systems in parallel for two of those weeks and removing the pixel only once server-side conversions have matched it, and Curve is the HIPAA-compliant tracking layer built for that swap. The work is mostly sequencing, not engineering. Week one is inventory and baseline. Week two installs the server-side layer alongside the pixel. Week three maps events and destinations. Week four cuts over and removes the pixel. A signed BAA is included on every Curve plan, which is what makes the middle layer lawful.

What you are actually migrating

A client-side pixel runs in the visitor's browser and reports directly to the ad platform. Whatever the page contains, the pixel can see: the URL, the referrer, the query string, form field values when automatic collection is enabled, and any custom parameters someone added two years ago and forgot about. On a healthcare site that payload routinely carries condition names, treatment names, provider names, and appointment types in the URL path alone. Meta and Google do not sign BAAs for their advertising products, which means a disclosure of protected health information to them is a violation at the moment it happens, not a risk that something might go wrong later.

Server-side tracking moves the decision about what leaves your site out of the browser and onto infrastructure you control. Events go to your own endpoint first. That endpoint decides which fields forward to which destination, hashes identifiers to each platform's requirements, and sends a conversion signal carrying no health context. The migration is therefore not "install a different tag." It is relocating the decision point.

Two consequences set the schedule. First, you cannot validate the new system using the old system's dashboard, because the old system is what you are removing. You need a window where both run so you can compare like for like. Second, ad platform optimization models are trained on your existing conversion stream, and an abrupt discontinuity in volume can push campaigns back into a learning phase. A clean handoff matters more than a fast one. Thirty days accommodates both without dragging.

Week 1: inventory and baseline

Do no installation this week. You are building the two documents the rest of the migration depends on.

The tag inventory

List every script that runs on your site and every place it fires. Not just the ad pixels. Analytics, session recording, heatmaps, chat widgets, scheduling embeds, A/B testing tools, call tracking, and anything a contractor added through a tag manager. For each one, record what triggers it, what parameters it sends, and whether the vendor will sign a BAA.

People consistently underestimate this list. The pixel you know about is usually one of six or seven third parties collecting data on the same pages. A scan of your live site is faster and more honest than asking around internally, and it catches the tags nobody remembers adding.

The conversion baseline

Pull 30 days of conversion counts from each ad platform, broken out by conversion action and by campaign. Note the totals, the daily shape, and the typical lag between click and conversion. This is the number you will compare against in week three, and if you do not capture it before you start changing things you will spend the rest of the migration arguing about whether volume dropped.

Also record how each conversion is currently defined. A surprising share of healthcare accounts optimize toward a page view of a thank-you page rather than a real form submission, which means the count is inflated by refreshes and direct visits. Migration is a good moment to fix that, but fix it deliberately rather than accidentally.

The event plan

Write down the conversions that actually matter to the business: form submission, appointment booked, appointment attended, call connected, purchase. For each, note where it happens, which system knows about it, and whether it happens on your site at all. Bookings that complete inside a third-party scheduler are the most common blind spot, and they need a different mechanism than a page-based event.

Week 2: install the server-side layer in parallel

This is the week with the technical work, and it is smaller than expected. The tracking script goes on the site alongside the existing pixel. Nothing is removed yet, and no destinations are enabled yet. You are collecting into the new system and sending nowhere.

Running in parallel is the entire point. The old pixel keeps feeding your campaigns while the new system accumulates a comparable event stream you can measure against. If the new install is misconfigured, you find out during a period when nothing is at stake.

What to verify before the week ends

• Every conversion page fires an event. Walk the funnel yourself in a browser and confirm each step lands.
• Click identifiers are being captured. The Google click ID, the Meta click ID, and their equivalents are what let a server-side conversion be attributed to an ad. If they are not captured on entry, nothing downstream can recover them.
• UTM parameters persist across the session, including through internal navigation and any redirect your site performs.
• Off-site steps are bridged. If patients leave for a scheduling tool, the handoff has to carry attribution across the boundary.
• Nothing forwards yet. Confirm destinations are off. Duplicate conversions during a parallel run are the most common self-inflicted wound in this migration.

Week 3: map events and destinations, then compare

Now you decide what leaves. This is where compliance is actually implemented, and it deserves more care than the installation did.

Work destination by destination rather than event by event. For each ad platform, list the exact fields it will receive. The correct default is that nothing forwards unless you explicitly map it. Hashed email, hashed phone, the click identifier, a neutral event name, a timestamp, and a value if you use one is a complete list for most healthcare accounts. Page URLs, page titles, form field contents, and referrers should not be on it, because those are the fields that carry the condition.

Rename events to something the ad platform can optimize on without describing the service. A conversion called "consult_request" tells the algorithm everything it needs. A conversion called "hormone_therapy_consult_request" tells everyone with access to the ad account something about the people who converted.

Then enable forwarding and compare against your baseline. Expect server-side counts to differ, and expect them to differ upward more often than down, because server-side events are not blocked by ad blockers or trimmed by browser tracking protection. What you are looking for is not an exact match. It is a stable relationship: consistent daily volume, sensible campaign distribution, and no conversion action sitting at zero.

If a conversion action is at zero, the usual causes are a missing click identifier, an event that never fires because the page it lives on redirects, or a destination mapping that omits a required field. Work through them in that order.

Week 4: cut over and remove the pixel

Remove the client-side pixel and any other tag that lacks a BAA. Not paused, not conditionally loaded on some pages, removed. A pixel that fires only on "non-sensitive" pages still fires on pages whose URLs describe why the visitor is there, and the referrer it sends often carries the page they came from.

Then switch each campaign's optimization target to the server-side conversion action. Do this once, in one sitting, rather than trickling changes across a week. Campaigns tolerate one clean change better than five small ones.

For the remainder of the week, watch three things daily: total conversion volume against the week-three comparison, cost per conversion by campaign, and the delivery reports showing what your system actually sent to each platform. The third is the one teams forget. A conversion that your tracking recorded but never forwarded looks fine in your own dashboard and does nothing for your campaigns.

Finally, rescan the site. Tag managers and marketing plugins reintroduce pixels through routes nobody expects, including theme updates and embedded widgets that load their own scripts. Verifying removal is a separate act from performing it.

How Curve runs this migration

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and it is built to be the layer that replaces the pixel rather than a tool that sits beside it.

The tracking script installs in place of the Meta Pixel and Google tag, so events go to Curve's US-hosted infrastructure instead of directly to platforms that will not sign a BAA. From there, per-destination field mapping decides what forwards, and the default is that nothing does until you map it. Identifiers are SHA-256 hashed to each platform's conversion API requirements. Neutral event aliases keep the service line out of the ad platform interface. PHI-pattern detection monitors payloads for PHI-shaped values, such as long numeric sequences and date patterns, so you find out when an upstream form change starts pushing something new into your event stream.

Two features exist specifically for the gaps that show up in week two. Bridge tokens preserve attribution when a patient clicks out to a separate booking or intake tool such as IntakeQ, Calendly, or Jane App, which is otherwise where healthcare funnels lose the connection between ad click and appointment. Offline conversion uploads let you push confirmed outcomes from a CRM or EHR back into the ad platforms with click ID matching, which is how appointments that complete days later get credited to the campaign that produced them.

A signed BAA is included on every plan. For the architectural background, see our explanation of why client-side pixels create a HIPAA violation and the technical overview of conversion API architecture.

What stretches 30 days into 90

Four things account for most overruns.

Skipping the parallel period. Teams under time pressure remove the pixel in week one and spend the next month unable to tell whether a drop is a tracking problem or a market problem. The overlap is what makes the rest diagnosable.

Treating it as a tag swap. If nobody decides what each destination receives, the new system reproduces the old exposure through a different pipe. Server-side is not automatically compliant. It is compliant when the field mapping is right.

Leaving the rest of the stack alone. Removing the ad pixel while a session recorder, a chat widget, and an analytics tag without BAAs keep collecting on the same pages solves one quarter of the problem. Inventory the whole page.

Missing off-site conversions. If the booking happens somewhere else and nothing bridges the gap, the migration will look like a performance loss when it is actually a measurement gap that existed before you started.

Frequently asked questions

Will conversion volume drop when we remove the pixel?

Usually it does not, and it often rises, because server-side events are not blocked by ad blockers or browser tracking protection. What changes is the composition, since inflated events such as thank-you page refreshes disappear when you move to a real submission event. Compare against your week-one baseline rather than against yesterday.

Can we keep the pixel for retargeting only?

A pixel restricted to retargeting still loads on the page and still transmits the URL and referrer. On a healthcare site those fields are frequently the disclosure. If retargeting matters, build audiences from server-side signals instead.

Do we need engineering resources for this?

Usually very little. The script is a single line, and most of the effort is decision making: which events matter, which fields forward, how conversions are defined. Sites with custom checkout flows or single-page applications need more attention on event firing.

Will we lose historical data?

Your ad platform conversion history stays in the ad platform, and campaigns keep their learning. What does not transfer is granular event history from the old client-side analytics, which is one reason to export a baseline in week one.

What happens to campaigns in the learning phase during the cutover?

Changing a campaign's conversion action can restart learning, which is why week four groups the changes together rather than spreading them out. Avoid stacking budget changes and creative changes on top of the tracking change in the same week.

Can we migrate one platform at a time?

Yes, and for large accounts it is often the calmer path. Install once, then enable destinations sequentially, starting with the platform carrying the most spend. The compliance clock still argues for removing the client-side pixels together, since the exposure is on the page, not in the destination.

Where to start

Start with the inventory, because it determines everything else. Run our free compliance scanner against your site to see which third-party scripts are collecting on your pages right now, then pull a 30-day conversion baseline from each ad platform before you change anything.

From there the schedule follows. Install alongside in week two, map and compare in week three, cut over in week four. Curve handles the technical setup, brings a signed BAA on every plan, and forwards only the fields you have explicitly mapped, which is what turns a tag swap into an actual migration. See how compliant conversion tracking is set up across Google, Meta, and Microsoft, or visit curvecompliance.com.

Reviewed August 2026. This is general information, not legal advice. Have qualified counsel review your tracking configuration and vendor agreements.