How we proved a Google Ads attribution fault and recovered $50,000 in credits

A UK business had Android conversion rate collapse overnight, from roughly 30% to 10%, with click volume completely unchanged. Real installs were still happening but Google Ads had stopped counting them.

The sudden step change, not a slow decline, is what proved this was a platform fault rather than a campaign problem, and it’s what let us build a case that ended in Google confirming the root cause and approving a credit package worth $50,000. The diagnostic sequence we used to get there and assess the commercial impact is the reusable part of this story, and it applies whenever a paid media account moves in a way that doesn’t match anything you’ve actually changed.

At a glance

Metric	Before	During	After
Android CVR	~30%	~10%	~25%
Installs/day	~500	~150	~500
MMP ping-claim rate	~40%	15%	~35%

The fact other businesses in our portfolio were not seeing the impact led us to find the root cause quickly: a Google Ads engineering fault affecting apps with DMA consent signals implemented, confirmed by Google after the first report.

What actually happened?

On April 15th, the reported conversion rate on every Android campaign dropped overnight, and stayed down for two weeks. On May 1st, it recovered overnight, again across every campaign at once. Nothing in the ad account change history explained either date. The account hadn’t changed. The users hadn’t stopped installing the app. The platform had simply stopped attributing a large share of the installs that were genuinely happening.

Because the bidding algorithm optimises on that attribution signal, a measurement fault became a real performance and spend efficiency problem. Every day the fault continued, the algorithm kept learning from a conversion rate that wasn’t real.

How do you tell a platform fault from a genuine performance problem?

Check the shape of the anomaly: A genuine market or creative decline shows up as a curve. A platform or infrastructure fault cliff edges. Both the drop on April 15th and the recovery on May 1st were single day step changes, not gradual movements.

Compare clicks against conversions: Click volume stayed flat while conversions fell 70%. That rules out auction, budget, bid and demand explanations in one move, and points straight at the measurement layer.

Check every conversion action together: Installs, sign up and subscription all fell together, in the 70–90% range. A genuine funnel problem degrades progressively further down the funnel. A signal path problem takes the whole tree out at once.

Isolate by operating system: iOS was completely unaffected throughout, on the same app, same account, same team. That narrows the fault to something specific to Android attribution.

Isolate by channel, cross checked in the MMP: The same pattern showed up for this platform’s Android traffic specifically. Other ad platforms’ Android traffic, running through the same MMP, same SDK and same install pipeline, stayed clean. That rules out the app and the MMP, and narrows the fault to one specific platform to Android attribution path.

Monitor against other accounts and isolate differences: After comparing against other accounts we found that the only ones impacted were Android apps on Google, that weren’t using Postback.

Audit the change history: No account changes on either the drop or recovery date, and no SDK changes. One minor app release fell inside the window, but its timing meant it couldn’t be causal, which closed off the platform’s own first theory.

Track the ping claim rate: The MMP confirmed it sent install pings continuously throughout, with no change to integration, Link ID or attribution rules. The share of those pings claimed by the platform fell from 40% to 15%, then recovered to 35% from May 1st. That metric isolates the receiving side of the handshake only, and once we had it, the idea that something had changed on the client’s own side was no longer arguable.

Worth flagging: the platform’s own first two hypotheses both pointed back at the client’s side, first an MMP issue, then an SDK or app version issue. Each was closed off with evidence rather than assertion.

Why didn’t performance return to normal once installs recovered?

Volume recovered before quality did. Installs snapped back to their prior level on May 1st, but cost per subscription stayed well above baseline for weeks afterwards. The bidding algorithm was still optimising against the degraded signal it had learned during the outage, which meant the account kept driving installs less efficiently than before, even once the raw numbers looked healthy again. The lasting damage sat in the algorithm’s learned state, not in the outage window itself.

How do you put a number on a platform fault?

Once the fault was confirmed, we quantified the impact. The method split the analysis into the two incident windows plus the recovery periods that followed each, and measured two distinct types of loss within each window:

Direct impact: the shortfall in paying subscriptions against the pre-incident baseline run rate, priced at gross profit per subscription by territory.

Efficiency impact: the excess cost per subscription during the periods when cost per acquisition stayed inflated above baseline, even after installs had recovered.

To keep the figures fair, we stripped out the share of that cost increase explainable by the client’s own spend scaling, using a diminishing returns model, and claimed only the residual.

What did the client actually get?

The platform’s engineering team formally confirmed the root cause, the DMA signal dependency, both incident windows, and that preventative measures had been implemented. The commercial impact analysis went through the platform’s own Product, Finance and Billing teams for independent validation before reaching leadership.

The approved package of $50,000 credits also unblocked something bigger than the billing line: they materially improved the client’s internal business case for a planned 4x monthly spend increase by December, which had stalled after the performance dip made that investment harder to justify internally.

Big thanks to Google for honoring and owning the issue, the collaboration has been genuinely efficient.

Final takeaway

A platform fault only becomes provable and compensable, once you can rule out every other explanation in order. Build the evidence chain step by step, and a measurement problem stops being an argument and starts being a fact.