On September 29, 2026, Google Analytics tore down a wall that had stood since GA4 launched: your app conversions finally enter the cross-channel reports. Until now, multi-touch attribution and cross-channel models only looked at the web. From now on, three reports (Conversion Performance, Attribution Analysis and Attribution Models) also account for app conversions, with attribution settings you configure separately for web and for app. Good news, but there is a catch: not everything is supported, app credit stays capped, and your numbers still will not match Google Ads or Firebase. This guide sorts out what is real, then gives you a 5-step setup checklist and a grid for knowing exactly where the numbers will diverge.
What actually changed on September 29, 2026
Until that date, a journey ending in a conversion inside your app stayed invisible in GA4’s cross-channel attribution reports. You could see your app events in standard reports, but not their share of credit in a multi-touch model mixing web and app. That is precisely what opens up now.
Three reports welcome app conversions: Conversion Performance, Attribution Analysis and Attribution Models. In other words, you can finally compare how one model (data-driven, say) splits credit across your app conversions, not just the web. The structural change comes down to one word: attribution settings are now independent between web and app. You are no longer forced to impose on your app the window and model designed for your site.
Two caveats before you get excited. First, the rollout is gradual: if you do not see this data yet, it is not a configuration bug, the rollout simply has not reached your property. Second, “cross-channel for app” does not mean “every channel for app”, and that is the point most news write-ups skipped.
Supported or not: the real list
Before you build reporting on top of this, look coldly at what is covered and what is not. The nuance is the whole difference between a correct analysis and a wrong conclusion.
| Item | App status |
|---|---|
| Conversion Performance, Attribution Analysis, Attribution Models reports | App conversions included |
| Attribution settings (model, windows) for web and app | Independently configurable |
| Cross-channel credit attributed to app | Limited to Google paid channels |
| Cross-channel budgeting (projection plans, Scenario Planner) | Web only |
| Conversion Paths report | Not included for app |
| Data API access to cross-channel reporting | Alpha, allowlisted |
| Rollout | Gradual through 2026 |
The number-one trap is the “cross-channel credit attributed to app” line. In practice, app only receives cross-channel credit on Google paid channels. An app journey that starts on Meta, TikTok or an organic channel will not see that touchpoint credited the way it is on web. If you build multi-platform media arbitration on these numbers, you mechanically overweight Google. The second trap: cross-channel budgeting stays web-only, as detailed in our guide on GA4 cross-channel budgeting. Do not expect to plan an app budget from the Scenario Planner yet.
Web and app attribution, finally set separately
This is the real gift of the update, and it deserves a pause. A web journey and an app journey share neither the same latency nor the same decision cycle. Forcing a single conversion window on both meant distorting at least one of them. You can now pick, for app, an attribution model and windows (click and engagement) distinct from the web.
The right reflex: do not copy your web defaults. Start from your app’s actual behavior. An app where install precedes purchase by several days needs a wider window than a flash-sale site. If you do not know which value to set, the method is the same as on web and I laid it out in the guide on the GA4 conversion window: measure the real distribution of the delay between interaction and conversion, then size the window on that rather than on habit. To understand why your attributed volumes already shifted in 2026, the context is in the article on GA4 attribution changes in 2026.
Audit your app conversions before reading the reports
An attribution report is only as good as the conversions it measures. On the app side, the classic confusion is between key events and conversions. Not every key event is a conversion: GA4 only credits events marked as conversions in these reports. If your app purchase is not marked, it will not show up in Conversion Performance, and you will wrongly conclude that the app does not convert.
The audit pass is three checks. First, verify which app events are actually marked as conversions, and prune the ones that should not be (a login marked as a conversion inflates everything). Second, verify that these events come through cleanly, with no duplication or loss: a double-counted app event poisons attribution just as surely as on web. If your app collection runs through a server-side pipeline, the guide on server-side GTM for mobile apps covers the deduplication and naming traps. Third, verify that the definition of a conversion matches the rest of your stack, otherwise the comparison with Google Ads or Firebase is already skewed.
Setup in 5 steps
Here is the sequence I recommend to use these reports without getting trapped.
- Confirm the rollout. Open Conversion Performance and check that your app conversions are there. If nothing shows up, the rollout has not reached your property: come back later rather than reconfiguring everything.
- Audit your app conversions. Separate key events from conversions, mark the right events, remove the false positives. This is the foundation for everything else.
- Set app attribution separately. In the attribution settings, choose the model and windows specific to the app, based on your real interaction-to-conversion delay.
- Cross-read the three reports. Read Conversion Performance for volume, Attribution Analysis for credit distribution, Attribution Models to compare the logics. A gap between the three is information, not an error.
- Document the expected divergences. Before any comparison with Google Ads or Firebase, write down why the numbers will not match (see the grid below). It saves you bad meetings.
Where the numbers will diverge (and why)
This is the part nobody wants to read and everyone should. Comparing your app conversions across GA4, Google Ads and Firebase without knowing where they diverge is setting yourself up for absurd conclusions. Here is the grid of structural divergences.
| Source of divergence | GA4 (cross-channel reports) | Google Ads | Firebase |
|---|---|---|---|
| Channel scope | All channels, but app credit limited to Google paid channels | Google Ads channels only | Configured networks, SKAdNetwork logic |
| Attribution model | Configurable, independent web and app | Google Ads own attribution | Last interaction or network model |
| Conversion window | GA4 app setting | Google Ads setting | Network or SKAN setting |
| Date anchoring | Interaction date or conversion date depending on report | Conversion date | Event date |
| Conversion definition | Key events marked as conversions | Imported or measured conversions | Firebase events |
Two rows deserve a word. Date anchoring is a silent trap: depending on the report, a conversion can be counted on its interaction date (the day of the click) or its conversion date (the day of purchase). Comparing an interaction-anchored report with a conversion-anchored one means comparing two different days and being surprised they differ. Channel scope, meanwhile, explains most of the gaps with ad platforms: the mechanism is the same one described for web in the article Meta Ads vs GA4, each tool measures in its own frame of reference.
Accessing cross-channel reporting via the Data API (alpha)
For those who want to pull this data out of the interface, Data API access to cross-channel reporting exists, but in alpha and allowlisted. Useful to feed a Looker Studio or a warehouse, as long as you accept alpha instability: schemas that may shift, incomplete scope, quotas to watch.
My practitioner’s advice: do not rebuild a production pipeline on it right away. Until the alpha stabilizes and the rollout is general, keep your source of truth elsewhere. For robust, reproducible conversion analysis, the raw export stays the most reliable base, as shown in the essential BigQuery queries for GA4.
FAQ
Do my app conversions appear in every cross-channel report?
No. They are included in Conversion Performance, Attribution Analysis and Attribution Models, but not in the Conversion Paths report, which stays out of scope for app at this stage.
Can I plan my app budget from cross-channel budgeting?
No. Projection plans and the Scenario Planner stay web only. Cross-channel budgeting does not cover app conversions yet.
Why do my app numbers differ from Firebase and Google Ads?
Because each tool measures in its own frame of reference: channel scope, attribution model and window, date anchoring and conversion definition all differ. The divergence grid above breaks down each axis.
Should I think in interaction date or conversion date?
Both exist depending on the report. Fix the convention before comparing anything, otherwise you are comparing offset periods.
How do I access cross-channel reporting through the Data API?
Access is available in alpha, allowlisted. Keep it for exploration for now, not a production pipeline.
In summary
Opening cross-channel reports to app conversions is a real step forward: you finally set app attribution independently of web, and you see your app conversions inside multi-touch models. But keep a cool head on three limits: app cross-channel credit is confined to Google paid channels, budgeting stays web-only, and the Conversion Paths report still ignores app. The path is simple: audit your app conversions, set app windows that match your real delay, cross-read the three reports, and document your divergences with Google Ads and Firebase before drawing any budget decision. Do that groundwork, and these new reports become a solid decision aid rather than a source of misunderstandings.