GA4 App Conversions: Now in Your Cross-Channel Reports

If you run a website and a mobile app, your conversion reporting has been split down the middle. Web conversions appear in the Advertising section of Google Analytics. App conversions sit somewhere else, in Google Ads, in Firebase, or in a spreadsheet somebody maintains by hand. Anyone trying to answer what marketing actually drove last quarter ends up stitching two systems together and hoping the definitions line up.

Google changed that on 29 September 2026. The changelog entry runs to three sentences. App conversions are now fully supported in conversion reports, including performance, attribution analysis and attribution models. Conversion attribution settings can now be adjusted independently for app conversions. Short entry, wide consequences.

What the release note says, and what it implies

The wording is that Google is extending its cross-channel reporting features and conversion management tools to support app conversions. Cross-channel reporting in Google Analytics is the Advertising workspace: the Conversion performance report, the conversion attribution models page, the attribution analysis report, and the Conversion management page. Until this release that workspace was built for web conversions. App conversions were created and reported in Google Ads, and Google Analytics did not carry them into the same views.

The practical effect is that a business with an app can now compare web and app conversion performance inside one report, using one set of channel dimensions, without exporting anything. The conversion attribution models page puts app conversions alongside web conversions so you can compare how different models credit your campaigns.

There is one more sentence in the entry, and it matters most for anyone with an eligibility problem. This feature may not be available to your Google Analytics property, and the Google Analytics team is actively working to expand it to more properties. Cross-channel conversion reporting has carried that caveat since it launched, and the app support inherits it. Check your own property before you commit to a reporting change.

The attribution settings split nobody expects

The more interesting half of the release is the settings change. Conversion attribution settings are now adjustable independently for app conversions. That sounds administrative. It is not.

Google's own conversion documentation states the rule plainly: paid and organic channels applies to web conversions only, because app conversions always use Google paid channels. So the "Channels that can receive credit" control you find under Admin, Data display, Events, Key events attribution never gives app conversions the broader paid and organic view. Web conversions can take credit from search, email and direct traffic. App conversions cannot.

That is not an oversight. App conversion attribution depends on identifiers that exist inside ad platforms and app stores rather than in browser storage, which is why the plumbing looks so different from web. What the release adds is the ability to set app conversion settings without disturbing the web side. Before this change, adjusting one tended to move the other.

If you have wondered why your app conversion totals look smaller and more Google heavy than your web totals, this is the reason, and it is structural rather than a tracking fault.

What has to be in place first

None of this appears by itself. The Conversion performance report has four stated prerequisites, and app conversions add a fifth consideration.

The property must be collecting data. At least one event must be marked as a key event. Your Google Ads account must be linked to the property. And a conversion has to be created in Google Ads from that Analytics key event. A linked Google Ads account is mandatory, because Google Analytics cannot create a conversion without one.

The app side then needs its own link, and this is where a lot of setups fall over. App conversions reach Google Analytics through a property that carries an app data stream, which comes from Firebase. If your Analytics property has only a web stream, there is no app conversion data to report, whatever the release notes say.

One structural detail catches people out. Google documents that for each key event you can create one web conversion and one app conversion in each linked Google Ads account. Mark 'generate_lead' as a key event, run four linked accounts, and you can end up with eight conversions from that single key event. That is by design, and it is why a naive count of conversion actions across accounts tells you very little.

The app measurement plumbing is not the web plumbing

The reason app reporting behaves differently comes down to how app attribution works. Google Analytics attributes app events using the reporting attribution model you select, and connects app events to key events through identifiers rather than the browser storage that web tracking relies on.

App installs are the clearest example. They are recorded as first_opens, because the Google Analytics for Firebase SDK does not run until the app is opened. Google supports several routes for attributing those installs: auto-tagging, universal links on iOS, Android app links, the Play Store Referral API, and Apple Search Ads installs. Each route produces different source and medium values.

A few of those values are worth recognising on sight. A Play Store install arrives with source set to google-play when the user was deep linked with a referrer, or when they found the app organically in the store. A deep link without a referrer shows up as direct. Apple Search Ads installs arrive with source Apple, medium search, and the keyword ID in the term dimension, provided the AdServices framework is present in the app's Xcode project.

Then there is the limitation that shapes app install reporting more than any other. Auto-tagging is not supported for iOS app installs. On Android you can lean on it. On iOS you cannot, and you fall back to universal links or Apple Search Ads measurement. If iOS dominates your installs, plan around that rather than assuming parity with Android.

What still falls back to key events

App support is not complete across the whole reporting surface, and Google says so in the cross-channel documentation. Where a report does not support certain data, including app conversions, Search Ads 360, Display and Video 360 or Campaign Manager 360 dimensions, you continue to use key events for cross-channel measurement.

Two other limits are worth knowing before anyone plans a dashboard. Cross-channel budgeting still supports web conversions only, so the projection and scenario planning tools cannot fold app revenue into a spend forecast yet. The Conversion performance report also does not populate for subproperties or roll-up properties, and is not supported for properties with more complex Google Ads linking setups.

There is the report's own scope to remember too. It contains only conversions shared with Google Ads. It is not a general app analytics view, and it will not tell you anything about app sessions, retention or in-app behaviour. For that you are still in the reports and explorations built on your app stream.

Keeping the numbers honest

The release makes reconciliation easier, which means more people will attempt it. Three rules will save you an afternoon.

First, know which attribution perspective you are reading. The Conversion performance report lets you switch between Google Analytics property settings and Google Ads account settings. When Google Analytics is selected you can change the attribution model and it applies to the whole selected date range. When Google Ads is selected you cannot change the model, because the report reflects the active setting used for each conversion at the time.

Second, expect Analytics totals to run higher than Google Ads totals when paid and organic channels are in play, and remember that this applies to the web side only. The "All conversions" figure attributed to your Google Ads account should match Google Ads exactly when the Ads perspective is selected. That matched figure is the one to reconcile against. The Admin, Conversion management page shows Analytics and Ads settings side by side, which is the fastest way to find where two numbers parted company.

Third, check time zones before you blame the data. Google Analytics reports in the property time zone and Google Ads reports in the account time zone. If the two differ, the columns will never agree on a daily basis. Make sure you are also comparing like with like on the "All conv." column, because Google Ads defaults to conversion time while an interaction time view answers a different question.

One caveat from the documentation is easy to miss. For some large properties, conversions that Analytics cannot attribute to any channel are removed from the total, and a data quality indicator appears next to the report title. If that icon is showing, the figure you are reading has already been adjusted.

The consent question apps bring with them

Adding app conversions to your reporting raises a compliance question that web-only setups never have to answer, and it is worth settling before the first client report.

The ICO guidance on the use of storage and access technologies, finalised on 29 April 2026, applies to websites, mobile apps and other online service providers. It defines storage and access technologies broadly: tracking pixels, link decoration and navigational tracking, web storage including local storage, device fingerprinting, and scripts and tags. That list covers the SDKs and identifiers your app is running.

The guidance keeps advertising measurement behind consent, and confirms that no advertising purpose falls inside the strictly necessary exception. The statistical purposes exception introduced by the Data (Use and Access) Act 2025 allows analytics used to improve a service without consent, provided you give clear information and a simple means of objecting free of charge. Read that exception carefully before applying it to anything an ad platform can see.

On iOS there is a second layer. App Tracking Transparency means cross-app tracking needs a user permission prompt, and if you do not ask for it you lose access to the identifier that app conversion attribution leans on. Declining the prompt degrades measurement in Google Analytics in much the same way that rejecting a cookie banner degrades web measurement. Model it rather than pretending it did not happen.

Our reporting identity guide covers how Google fills those gaps, and the attribution models guide explains what each remaining model does to credit.

What to do this week

Open the Advertising section and check whether the Conversion performance report is available for your property. If it is not, nothing else in this article applies yet, and key events remain your cross-channel measure. Diarise a re-check rather than rebuilding a dashboard you cannot populate.

If it is available, list your conversions and mark which are web and which are app. Then open Admin, Conversion management and compare the Analytics and Google Ads settings for each one, because independent app settings give the two platforms one more place to drift apart.

Finally, decide which app events genuinely deserve conversion status. The one-web-one-app-per-key-event rule means app conversions multiply across linked accounts quickly, and a conversion list nobody can explain is worse than a short list everybody can.

The release itself is a paragraph. The work it saves is the manual matching you have been doing for two years, and the work it creates is keeping an app conversion that now looks like a web conversion honest about where its numbers came from.