Fractional growth, run as revenue

Rebuilding Attribution After iOS 14.5

AI Infrastructure / Attribution

Elementor
100x
$200K to $20M ARR as acquisition lead, 2018-2020
Riverside
+337%
MRR growth driven as a growth operator
Across engagements
$100M+
ad budgets managed across paid social and search

The ios attribution rebuild after iOS 14.5

iOS Attribution Rebuild - Rebuild iOS Attribution

iOS 14.5 broke the pixel. App Tracking Transparency let users opt out, and most of them did. Overnight, the deterministic click-to-purchase chain that paid media ran on for a decade went dark. Reported conversions dropped. ROAS looked like it cratered. Budgets froze because nobody could prove what was working. An ios attribution rebuild is how I bring those numbers back to something you can act on.

Here is the part most teams miss. Your sales did not fall as hard as your dashboard says. The measurement fell. The revenue is still there. The job of an ios attribution rebuild is to reconnect spend to outcomes through channels Apple cannot blind: your own server, your own first-party data, and modeled estimates that fill the gaps the opt-outs left behind. I have run this exact rebuild across accounts where I managed $100M+ in budgets, so I know which signals survive and which ones lie.

The first move is server-side tracking. Browser pixels sit on the device, exactly where ATT and Safari Intelligent Tracking Prevention strip them. A server-side setup, conversions sent through Meta CAPI and a Google Ads server container, fires the event from your infrastructure with hashed first-party data. This recovers attribution that the front-end pixel silently drops. Apple publishes the framework that started all of this in its App Tracking Transparency documentation, and reading it tells you precisely which events you can no longer assume and which you must rebuild server-side.

Next is modeled and aggregated conversions. Meta's Aggregated Event Measurement and Google's modeling fill opt-out gaps with statistical estimates instead of raw counts. They are useful, but they are not gospel. A real ios attribution rebuild calibrates these models against the one source Apple cannot touch: your actual revenue in Stripe, Shopify, or your CRM. When modeled conversions and booked revenue disagree, booked revenue wins, and I tune the platform setup until the gap closes.

Then I rebuild the source of truth. Platform numbers are inputs, not verdicts. I stand up a measurement layer that ties spend to revenue independent of any single ad network: UTMs enforced at the link level, a self-reported attribution survey at checkout, and incrementality tests that prove which channels actually move the needle. This is the same discipline I used when I drove Riverside +337% MRR, because you cannot grow what you cannot measure honestly.

An ios attribution rebuild is not a tool you buy. It is a system you operate. Conversion lag matters more post-14.5, so I extend attribution windows and read cohorts, not single days. I separate brand spend from demand-capture spend so one does not flatter the other. I document the entire measurement stack so your team and your next analyst inherit something legible instead of a black box. The outcome of an ios attribution rebuild is simple: you spend the next dollar knowing what the last one returned.

Frequently asked questions

Why do I even need an ios attribution rebuild after iOS 14.5?

Because iOS 14.5 let users opt out of tracking, and the browser pixel can no longer see most of your conversions. Your dashboard underreports, so spend decisions get made on bad data. An ios attribution rebuild moves measurement server-side and ties it to actual revenue, so the next budget you approve reflects reality instead of a pixel that went half-blind.

What is server-side tracking and why does it survive ATT?

Server-side tracking fires conversion events from your own infrastructure instead of the user's browser. Tools like Meta CAPI and Google's server container send hashed first-party data directly from your server, where App Tracking Transparency and Safari ITP cannot strip it. It recovers attribution the front-end pixel drops. It is the foundation of any credible rebuild, not an optional add-on.

Can modeled conversions be trusted, or are they just guesses?

They are statistical estimates, useful but not gospel. Meta's Aggregated Event Measurement and Google's modeling fill opt-out gaps with math, not raw counts. I never accept them at face value. I calibrate them against booked revenue in Stripe, Shopify, or your CRM. When models and real revenue disagree, real revenue wins, and I tune the setup until the two converge.

How long does an iOS attribution rebuild take to show results?

Server-side tracking and CAPI usually go live within one to two weeks. Trustworthy reporting takes longer because attribution windows post-14.5 require reading cohorts, not single days, and incrementality tests need time to run clean. Expect a working measurement layer in weeks and confident, revenue-calibrated spend decisions within the first reporting cycle after that.

Will I lose historical data, and how do I compare before and after?

You do not lose history, but you stop comparing pre-14.5 pixel numbers to post-rebuild numbers directly. They count different things. I rebase your reporting against booked revenue, which is consistent across both eras, and use incrementality tests to establish a clean baseline. From there you compare like with like and judge channels on revenue moved, not on a broken pixel's reported count.

What iOS 14.5 actually broke

App Tracking Transparency let users opt out of cross-app tracking, and browser changes piled on with shorter cookie lifetimes and blocked third-party scripts. The practical result is that the client-side pixel only fires for a fraction of your real conversions. Meta and Google each see a different partial slice, so they both over-claim, your blended numbers double-count, and the dashboards stop matching the bank.

You cannot fix this with a setting. The conversions that the browser can no longer report have to be captured server-side, where ad blockers and cookie limits do not reach, and sent to each platform through its server API with proper deduplication. That is an engineering and measurement project, and it is the one that makes every paid channel readable again.

What I rebuild

Server-side event capture

A server-side tracking layer that captures conversions the browser drops, then forwards them cleanly to each platform. See server-side GTM.

Conversions API and enhanced conversions

Meta Conversions API and Google enhanced conversions wired with deduplication and advanced matching for high signal quality.

Cross-platform reconciliation

One source of truth that reconciles Meta, Google, and your store so platforms stop double-claiming the same sale.

Reporting you can scale on

Dashboards that show real contribution, so budget decisions rest on data you can defend to a board.

How the rebuild runs

01

Audit the gap

I measure how far your reported conversions sit from reality and find where signal is leaking, so we fix the biggest holes first.

02

Build the server-side layer

I stand up server-side tracking and wire the Conversions API and enhanced conversions with deduplication, so platforms see complete events again.

03

Reconcile and hand off

I reconcile the platforms into one source of truth, document the system, and hand your team reporting they can run without me.

I build this layer myself

This is not a problem I hand to a vendor. I build server-side tracking and attribution for the ecommerce and SaaS brands I run growth for, and I run my own marketing operation on a self-hosted stack of n8n, the Claude API, and Postgres where the same measurement discipline applies. I led acquisition at Elementor from roughly $200K to over $20M ARR as it passed five million users, and I led growth at cnvrg.io ahead of its acquisition by Intel announced in November 2020 (TechCrunch). I drove 337% MRR growth at Riverside on measurement I trusted. See the n8n and AI infrastructure work.

When I am the right fit

Good fitNot a fit
Ecommerce or SaaS spending real money on paidNo paid spend and no conversions to track
Reported ROAS no longer matches revenueHappy to keep guessing on partial data
Want one operator across tracking and growthWant a tag-manager tweak, not a rebuild
Ready to invest in the measurement layerLooking for a free quick fix

Pricing

Attribution rebuilds run as an infrastructure project or fold into a broader operator role.

Diagnostic sprint
Fixed $6,000-$8,000

2-4 week audit of your growth stack plus a 90-day roadmap. Fixed scope, converts to a retainer.

AI Marketing infra
From $5,000/mo
  • Server-side tracking build
  • Conversions API and enhanced conversions
  • Cross-platform reconciliation
  • Reporting and handoff
Operator (embedded)
$8K-$18K/mo

Attribution plus the full growth picture. See marketing ops.

Frequently asked questions

Can I just fix this in the ad platform settings?

No. The conversions the browser can no longer report have to be captured server-side and sent through each platform's server API. That is a build, not a setting.

What is the Conversions API?

Meta's server-side endpoint for sending conversion events directly from your server, bypassing the browser limits that broke the pixel. Google's equivalent is enhanced conversions.

Why are my Meta and Google numbers both inflated?

Each platform only sees a partial slice of conversions and claims credit for what it can see, so the same sale gets counted twice across platforms. Reconciliation into one source of truth fixes that.

Does this work for Shopify and WooCommerce?

Yes. I build server-side tracking and the Conversions API on both, which covers most ecommerce stores, as well as SaaS apps.

What does it cost?

A fixed-scope diagnostic sprint runs $6,000 to $8,000. Infrastructure builds start at $5,000 per month. A full embedded operator engagement runs $8,000 to $18,000 per month.

How long does a rebuild take?

The core server-side layer is usually live within a few weeks, after which reported conversions converge with real revenue and scaling decisions become trustworthy.

Do you build it or just spec it?

Both options exist. On an advisor engagement I spec it for your engineers. On an infra or operator engagement I build it myself.

How does this connect to paid scaling?

Directly. Once measurement is trustworthy, Meta and Google relearn on complete signal and scaling decisions stop being guesses. See Meta ads and Google Ads.

Trust your numbers again, then scale

Book a 15-min call. I will tell you how far your reported conversions sit from reality and what the rebuild involves.

Next step

Let's turn this into measurable revenue

Book a 15-min call. I will tell you whether this is your next move, or whether your money is better spent elsewhere.