GA4 AdMob Links: What the Native Setup Actually Reports

Connecting an AdMob app to Google Analytics used to run through somebody else's console. The app was linked in Firebase, Firebase was linked to the GA4 property, and the AdMob half of the relationship lived in the AdMob interface with its own set of roles. Revenue appeared in the Monetization reports when all three pieces lined up, and when they did not, the interface told you very little about which piece was missing.

On 13 July 2026 Google closed the loop. The changelog entry AdMob linking within Google Analytics added an AdMob Links option under Product links in the Admin panel. An app data stream and an AdMob app can now be connected from inside Google Analytics.

That link decides whether an app property has any ad revenue data at all, and it changes what you need to check before you put a monetization number in front of a client.

What the link actually does

Admin, then Product links, then AdMob links. That row did not exist before July. The link table creates, views and removes connections between Google Analytics app data streams and AdMob apps.

Permissions decide whether you see any of it. Creating a link needs Administrator permission in AdMob and the Editor or Admin role in Google Analytics. Both, not either.

This is the first place an agency setup breaks. Plenty of agencies hold Editor on a client property, which is enough for most reporting work and not enough for this button. AdMob access is often held by the publisher alone, under a role that is contributor level rather than Administrator. The link option then sits greyed out or missing, with no error message explaining why. If you are setting up an app measurement project, put the permission conversation on the same agenda as the access request. It saves a week of guessing.

One more thing about the app list. AdMob apps that already have a link to a Google Analytics data stream cannot be selected again, and they will not appear as options. An app missing from that list is usually already connected through an older Firebase route.

The prerequisite nobody reads

Your Google Analytics app stream must be linked to Firebase before the AdMob link will work. That is a stated prerequisite, not a suggestion, and it is the most common reason a link attempt goes nowhere.

There is a detail in the documentation worth knowing even if you have no Firebase project. Linking an AdMob app to a Google Analytics app data stream also links that AdMob app to Firebase. Google says so directly. So creating the link in Google Analytics does not require you to have completed the Firebase setup separately, because the action establishes that relationship as a side effect.

Setting it up, in order

1. In Admin, under Product links, click AdMob links.
2. In the link table, click Link.
3. If you are an Admin for one or more AdMob accounts, use the row for Link to AdMob accounts I manage and click Choose an AdMob app.
4. Select the app you want to link, then click Confirm.
5. Under Configure settings, use the drop-down menu to choose the data streams that will collect data.
6. Click Next, then review and submit your configuration settings.

Step five is the one people rush. The link is not only about the app. It decides which data streams are configured to collect the ad data, and a property with several app streams can end up collecting into the wrong place if nobody reads the setting. If your AdMob account holds several apps, this is per app rather than per account, so a portfolio of five apps means five links and five configuration reviews.

What lands in your reports

Ad revenue data shows up in the Publisher ads report, a pre-made detailed report under Advertising, then Publishing, then Publisher Ads. It is desktop only. The report needs at least one linked AdMob, Google Ad Manager or AdSense account before it appears at all.

The report carries four dimensions and four metrics. The dimensions are Ad format, with typical values of Banner, Interstitial and Rewarded, Ad source, where you see networks such as AdMob Network, Meta Audience Network and Mediated house ads, Ad unit, and Page path and screen class. The metrics are Ad unit exposure measured in milliseconds, Publisher ad clicks, Publisher ad impressions and Total ad revenue.

Total ad revenue does not stay in its own corner. It feeds Total revenue, which Google defines as purchases plus in-app purchases plus subscriptions plus total ad revenue minus refunds, and it feeds ARPU through that same sum divided by active users. If your property reports both subscriptions and ads, then your headline revenue metric has been combining two very different data sources, one measured event by event and one sent over from AdMob.

Underneath all of it sits the ad_impression event. Linking AdMob or Google Ad Manager populates the dimensions and metrics above on their own. If part of your ad revenue comes from a third-party monetization platform, you send the ad_impression event yourself with the right parameters, or those rows stay empty.

The 72-hour adjustment, and why your numbers will move

AdMob reporting is the definitive source for revenue figures, because it reflects valid clicks and impressions after processing. Google Analytics works differently. AdMob sends revenue to the property in near real time, and that figure is adjusted within 72 hours to reflect finalized revenue.

In practice, the revenue column you look at on Monday will not be the revenue column you look at on Thursday for the same dates. Any dashboard pulling the last three days of revenue is showing you an estimate wearing the same label as a finalized number.

Meta Audience Network revenue is a separate case. Revenue reported for Meta is always estimated, and Meta's own reporting is the definitive figure for Meta earnings. If Meta is a material share of a publisher's inventory, the GA4 total will not match the money, and the reconciliation needs to be explained rather than argued about.

A related trap sits in the mediated revenue figures. Where impression-level ad revenue, which Google shortens to iLAR, is not enabled, estimated third-party mediated revenue is sent in real time and adjusted within 72 hours to the finalized number. Where iLAR is enabled, the data is sent in real time and stays as it is. The estimate is worked out by taking the earnings reported by the optimized third-party ad network, dividing by the total impressions for every ad unit that uses the same mapping information, then multiplying by the impressions for the specific ad unit.

The duplication trap

Here is the part that costs people a quarter of misreported revenue. If you use a third-party mediation platform and you use its impression-level revenue data to log ad_impression events in Google Analytics, do not also link AdMob to Firebase. Google's documentation is explicit about avoiding data duplication in that combination. Two sources writing the same revenue into the same property will inflate your ad revenue, and the inflation is invisible in the interface because both sources look legitimate.

The clean version of the rule: one source of truth per revenue type. Either AdMob sends it, or your mediation platform reports it through ad_impression events. Not both, and not both with different estimates landing on top of each other.

Using ad revenue to bid

The link also carries a bidding signal. Target return on ad spend for ad revenue, which Google calls ARO, uses the ad_impression event to find users more likely to engage with in-app ads, running on the existing tROAS model and campaign type.

The criteria are worth reading before promising anything. The app must be bidding on Google Analytics events. The ad_impression event has to be imported from the Google Analytics property into Google Ads. The app has to derive a significant majority, or the entirety, of its in-app revenue from ads. Android and iOS both work, with iOS in open beta capacity. To get AdMob revenue flowing to Google Ads, the property itself has to be linked to a Google Ads account, and advertisers have to send all AdMob or third-party ad revenue data into Google Analytics for bidding.

Consent affects a different question here

Ad revenue in Google Analytics does not behave like the rest of your measurement. Sessions, key events and engagement all shrink when visitors decline analytics storage. Ad revenue does not shrink the same way, because the figure arrives from AdMob's own accounting rather than from user-level measurement in the property.

That difference creates a specific mistake. Divide ad revenue by sessions on a property with a high UK opt-out rate and you get a revenue-per-session figure that looks stronger than it is, because the denominator lost sessions to consent while the numerator did not lose revenue. Label it, or stop using it.

Consent still governs the advertising side, at a different layer. If the property builds audiences that go back to Google Ads, ads personalization and ad user data signals still decide what can be used for targeting, and on iOS App Tracking Transparency gates the identifiers used for personalization. None of that changes the revenue total AdMob reports.

What to check before you click Link

1. Confirm the app data stream exists in the property you are actually reporting on.
2. Confirm the stream is linked to Firebase. If it is not, the AdMob link has nothing to attach to.
3. Confirm you hold Administrator rights in AdMob as well as Editor or Admin in Google Analytics. Both sides, before the meeting.
4. Check whether the app is already linked somewhere, since an existing link removes the app from the selection list.
5. Decide which data streams the configuration step should collect into, especially on multi-stream app properties.
6. Fire ad_impression in DebugView with the correct parameters if any revenue comes from a third-party monetization platform.
7. Align time zones between AdMob and Google Analytics, because a report window that crosses midnight in one platform and not the other will never reconcile cleanly.
8. Write down which revenue metric you quote, whether it is near real time or finalized, and how long after the date range it settles.

The short version

The AdMob link is now a product link inside Google Analytics, which removes the worst part of app revenue setup, namely that the console you needed was never the console you were in. What has not changed is the accounting underneath. Revenue arrives near real time, settles within 72 hours, comes from a source that treats AdMob reporting as definitive, and duplicates badly if you feed the same revenue in from two directions.

Treat the link as a data pipeline rather than a switch. Confirm the Firebase prerequisite, get both sets of permissions in writing, choose your revenue source once, and put the settlement window in the report notes. Then the number you show a client survives the question that always follows it.