Why your GA4 conversion count is probably wrong

711 key events in 28 days, on a property with 293 active users. That reads like an app where something happens. Every one of those 711 was an install or a session start.

We opened the property on 6 October 2026 while auditing an assessment app on Android and iOS. Two events were producing the whole conversion count: first_open and session_start. Revenue read $0. Not low. Zero, because the purchase event had never been sent.

So the conversion count was an arrival count. 231 of the 293 users were new, about 98% of paid sessions came from a single Google Ads app campaign, and the campaign was being judged on the one thing it had already achieved by definition.

first_open fires once per install. session_start fires every time anyone engages the app, including the same person on day four. Google collects both automatically in any app with the Firebase SDK. Nobody wrote a line of code for either.

That is the trap. The two events that cost nothing to collect say the least about value, and they end up on the key events list because they are the only events in the property. screen_view was marked too, which would have made every screen change a conversion the moment screens were named properly. Here is the list before and after we changed it on 8 October 2026.

Google Ads bids towards what you mark. Import an install as your only conversion and bidding will find you the cheapest installs available, which are usually the ones least likely to open the app again.

Google’s own App campaign bidding documentation is direct about the alternative: to bid for in-app actions you need to set those actions up as conversion events in Google Ads, or use Firebase, and after you have linked Firebase and Google Ads you can bid on the in-app events you have set up as conversions. Without them, target cost per action for in-app actions is not a choice you can make. There is nothing for it to chase.

The cost is not theoretical. Spend drifts to the cheapest install, the cost per install chart slopes downwards, and the number of registered users stays flat. We see it most often where the Google Ads account and the analytics property were built by two teams who never spoke.

Open Admin, Data display, Events, then the Key events tab, and read the names. If everything on the list is something that happens to you rather than something a person decided to do, the count is wrong.

Three checks. One, is session_start, screen_view or page_view on the list. Two, does total revenue read zero while the app clearly takes money.

Three, open the Events report and look for an event that names an outcome, such as sign_up, generate_lead or purchase. If all you find is first_open, session_start, screen_view, user_engagement and app_remove, the property is collecting only what Google collects for free.

Then check the ad account. If the conversion action your app campaign bids towards is an install, and no GA4 key event other than that has been imported, the two systems are agreeing with each other about nothing.

Mark the moments a person has to choose. On this app there were six: sign_up, login, test_start, test_complete, appointment_booked and purchase. Each one needs a decision, and each one maps to a step in the funnel we wanted to read.

We left first_open marked, because install volume is still how you judge the reach of an install campaign, and we removed session_start and screen_view. You cannot have it both ways. Marking everything is the same as marking nothing, because the conversion column then measures attendance.

One note on sequence. GA4 marks an event with the star in Admin, Data display, Events once Analytics has received it, and an event that has not arrived yet can be marked ahead of collection so it counts from the first hit. Standard reports can take up to 24 hours to show it, Realtime shows it in minutes, and marking does not change historic data.

The key event count drops, often by 90% or more, and somebody senior asks why. Have the answer ready before you make the change: the old number was counting arrivals, and the new one counts people.

Google Ads gains real options. Once Firebase and Google Ads are linked and the in-app events are marked, target cost per action for in-app actions becomes selectable, and you can bid towards a sign-up or a purchase instead of an install. Target return on ad spend needs a revenue value on the event, which is why value and currency on purchase are not optional parameters.

And the funnel exploration starts working, because it finally has steps. We build those reports as part of business analytics work rather than as a one-off fix, because the first month after a tracking release is when the numbers get misread.

Nobody marks session_start as a conversion on purpose. It gets marked because the property was set up quickly, somebody wanted the conversion column to show a number, and the automatic events were the only ones available.

The second reason is retention. This property had event data retention set to 2 months, the shortest option GA4 offers; a standard property allows 14 months. The setting only affects explorations and funnel reports, not standard aggregated reports, which is exactly why nobody notices until the first attempt at a funnel finds the window too short. We raised it to 14 months before touching anything else, because the setting is not retroactive.

It costs nothing and takes one click. Change it in your own property now, then come back. We do the same check on the first day of every analytics engagement, before anyone asks for a report.

A standard GA4 property allows 30 key events and Analytics 360 allows 50. Thirty sounds generous until four people each mark the five events they care about.

Our rule is one key event per decision somebody makes with money or time. On this app that was six. Everything else is still collected, still reportable and still usable in an exploration. It is just not competing for the conversion column or acting as a bidding signal.

The test: if you cannot say what you would do differently when a number on that list moves, it does not belong on the list. Performance work with us is priced at the higher of 15% of monthly media or ₹50,000 plus GST a month, and this list is the first thing we go through on a new app account, before any bid changes at all.