Ad monetization and ad server integration

Google Ad Manager, AdMob, IMA for video and GMA for mobile display are routinely discussed as a single interchangeable thing. They are not. Each has its own initialization order, its own request shape and its own failure modes, and treating them as one is the usual source of an integration that appears to work and earns less than it should.

The mobile display SDK serves both AdMob and Ad Manager, which is exactly why the confusion persists. The request objects are not the same: an Ad Manager request carries custom key-value targeting and publisher-supplied signals that an AdMob request has nowhere to put, and the two use different ad unit identifier formats. Code written for one and pointed at the other compiles, requests ads, renders ads, and drops the targeting on the floor.

Video is a different model again. IMA requests against an ad tag rather than an ad unit, gets back a VAST or VMAP response, and has to be wired into your content player: an ads loader, an ads manager, a display container over the video surface, and a scheduler that pauses content, plays the break, and returns control. Its failures look nothing like display failures, and none of them resemble a null pointer.

Identity and signal enrichment has an ordering constraint that nothing in the toolchain enforces. The adapter or signal collector has to be registered and ready before the ads SDK initializes, and its readiness has to be awaited. Get that wrong and the first ad request of the session goes out unenriched. No exception is thrown. No log line appears. An ad is returned and displayed. The only symptom is that the session earned less than it should have.

This matters more than a normal bug because of which request is affected. The first request of a session is often the app-open or first-screen placement, which is frequently the most valuable one, and it is precisely the request that a warm-up race condition loses. QA cannot see it: an ad appeared, the screen looked right, the tester moves on.

Consent sits in the same sequence and is subject to the same trap. A consent decision collected after the ads SDK has already initialized and requested did not apply to those requests. On iOS, the tracking permission prompt is part of this ordering too. So the initialization path deserves to be written down as an explicit sequence and reviewed as one, rather than distributed across whichever lifecycle callbacks were convenient.

Awaiting readiness means awaiting it. A timer that waits a second and hopes is not a fix; it is the same bug with worse reproducibility, and it will behave differently on a cold start, on a slow network and on a low-end device. If requests can arrive before the stack is ready, queue them and flush the queue when the completion callback fires.

Enrichment has to be applied at every place the app requests an ad. Real apps accumulate request sites faster than anyone tracks: a banner in a list, an interstitial between two screens, a rewarded placement inside a game loop, a native unit in a feed, a pre-roll in the video player, and a second copy of one of those added behind a feature flag last quarter. Missing one degrades that placement quietly and permanently.

Nothing in the logs points at it, because there is no error. The request was well-formed and the ad server answered. This is why the durable fix is structural rather than diligent: one function builds every ad request, applies targeting and signals there, and is the only place a request object is constructed. Then coverage is a question you can answer by searching the codebase instead of by remembering.

There is no unit test for whether the ad server received the parameter you think you sent. A test can assert that your code put a value into an object. It cannot tell you that the value left the device, survived the SDK, and arrived. Between the assertion and the ad server there is a request builder, an SDK version, a mediation layer, a consent state and a network, all of which can drop a field without complaining.

So verification is empirical. Make real ad requests. Capture them. Read them. The SDK's own inspector and test device configuration cover the client side; a proxy shows what actually went out; for video, the ad tag response is the artifact to read, since an empty response and a broken player look identical from the couch. On the receiving side, the ad server's own reporting and diagnostics are what confirm arrival, which means this work needs somebody with access to that account, not only to the codebase.

Confirm the negatives as well. A placement showing nothing can be a no-fill, an error, or a request that was never made, and those three have completely different fixes while looking the same to a user staring at an empty rectangle. Distinguishing them is most of an audit.

It usually starts with an audit rather than a rewrite, because reading the code tells you what somebody intended and only the requests tell you what happens. That pass produces three things: the actual initialization sequence, the real list of request sites per platform, and a set of captured requests showing what each placement sends. Then the fixes are small and specific, and they can be verified the same way they were found.

The multiplier is platforms. The same integration on Android, iOS and a cross-platform wrapper is three integrations with three sets of failure modes, and the Android side inherits the release-build problem: ad SDKs and mediation adapters get resolved by class name, so shrinking without correct keep rules produces an integration that works in debug and fails in the build you publish. That verification belongs to the same job.

Audit and fix work of this kind normally sits in hourly work at $85 to $165 per hour for hours actually worked. A full integration across platforms is scoped as a build instead, at $5,000 to $10,000 per estimated month of work, positioned in the range by how many platforms and placements are in scope.