Most GA4 properties cannot answer the question they were installed to answer. Not because GA4 is broken, and not because the tag is missing, but because the property is still running on defaults nobody ever mapped to the business. Events fire under names that mean nothing. Either everything is marked important or nothing is. And the reports get read as though they describe reality.
This is the configuration pass I run on every new engagement. It is not a complete GA4 manual. It is the subset that actually decides whether the attribution numbers can be trusted, starting from a typical default install.
One thing has to come first, because it invalidates most of the GA4 attribution advice still in circulation.
GA4 deleted the attribution models most guides still tell you to pick
Search for GA4 attribution advice and you will be told to weigh linear against time decay, or to choose position-based if you believe the first and last touch deserve more credit. That advice cannot be followed. Google removed the first click, linear, time decay and position-based models from GA4 in November 2023.
Three models remain:
- Data-driven attribution
- Paid and organic last click
- Google paid channels last click
Two of the three are last click. The question of which model to select has collapsed into one real choice: data-driven, or last click. Any guide walking you through six models is describing a product that has not existed for years, which is a useful tell about whether the person writing it has opened the interface recently.
Attribution modelling is no longer a lever you get to pull. What is left to control is the input, and that is where all of the remaining accuracy lives.
The setting is under Admin, then Data display, then Attribution settings. It applies to the property, not to an individual report.
The minimum conversion volume is folklore
You will also see the claim that data-driven attribution needs some monthly conversion count to work, usually a few hundred, and that GA4 quietly falls back to last click underneath it. Google's attribution documentation states no minimum and documents no such fallback. If a threshold exists it is not published, which means nobody quoting a specific number is quoting a source.
The real constraint is structural rather than numeric. Data-driven attribution assigns credit by comparing the paths that converted against the paths that did not. A model built on paths has nothing to learn from when every path is one touch long. If most of your traffic arrives as a single untagged session, no model will rescue you, data-driven or otherwise. That is an input problem, and unlike the model menu, it is one you can fix.
They are called key events now, and the distinction matters
Google renamed conversions to key events in Google Analytics. The word conversion still exists, but it now means something narrower: the subset of key events you send to Google Ads to measure and optimise campaigns. In GA4 you mark an event as a key event. In Ads, a conversion is built from it.
This is not pedantry about vocabulary. It is the seam where two teams stop agreeing on a number. The marketing lead quoting "conversions" from the Ads interface and the founder quoting "conversions" from GA4 are looking at two different populations, and the meeting goes badly for reasons neither of them can name. Decide which surface is the source of truth for which decision, and say so out loud.
Event names
If key events are named generically or inconsistently, form_submission in one property and lead_form_submit in another and generate_lead in a third, you cannot query across properties, you cannot compare channels between clients or campaigns, and every model downstream is working from noisy input.
Action + object + optional context
generate_lead form submission that creates a CRM record
book_consultation calendar booking
purchase transaction
start_trial trial account created
view_pricing pricing page intent signalWrite the scheme down before the first tag goes in, and apply it to every property. When I inherit an existing GA4 setup, the first hour usually goes on renaming events to something consistent before anything else is touched.
How many key events is the right number
The two failure modes are opposite and equally common. No key events at all, so the reports have nothing to attribute. Or every meaningful action marked as one, so a pricing page view and a five figure purchase carry the same weight and the signal flattens.
For a typical service business:
- One primary key event. The action that directly produces revenue or a qualified lead: book_consultation, submit_quote_request, purchase.
- One or two secondary key events. Strong intent signals that reliably precede the primary one: view_pricing, download_asset, start_trial.
- Nothing else. An event can be worth measuring without being worth marking.
If money changes hands, send the amount. The GA4 purchase event carries the monetary value in the value parameter with currency alongside it, in three letter ISO 4217 format. There is no purchase_value parameter, and a value sent without a currency will not reconcile into revenue properly.
Untagged traffic is the attribution bug nobody looks for
Before blaming the model, look at Direct. Direct is not a channel. It is the bucket GA4 uses when it cannot tell where someone came from, and on most sites it is inflated by links that were never tagged rather than by people typing the URL.
The usual sources, roughly in order of how often I find them:
- Email that went out without UTMs, especially transactional and plain text sends that skip whatever your platform tags by default
- Links pasted into Slack, WhatsApp, iMessage and LinkedIn messages, none of which pass a referrer
- Paid campaigns where auto-tagging is off, or where the landing page sits behind a redirect that eats the query string
- QR codes and print pointing at a bare URL
- In-app browsers opening links without referrer information
Rather than measuring Direct against a benchmark, run the diagnostic that actually settles it. Open the Traffic acquisition report, isolate Direct, and look at its landing pages. If Direct's top landing pages are the homepage and a couple of obvious entry points, that is plausibly real. If Direct is landing on a specific blog post, a pricing page, or a campaign page with a long path, those are untagged links. Nobody types their way to a deep URL.
Fix the tagging and two things happen at once: your channel report starts describing reality, and paths get long enough for a path-based model to have something to work with.
Identity, and what Blended actually does now
Reporting identity decides how GA4 stitches sessions into people. The options are worth stating precisely, because the older descriptions of them, including several still sitting near the top of search results, describe a mechanism Google has since removed. Google Signals no longer participates in reporting identity.
- Blended: User-ID if you collect one, then device ID, then modelling where no identifier is available.
- Observed: User-ID if you collect one, then device ID. No modelling.
- Device based: device ID only. Every other identifier is ignored.
The setting is under Admin, then Data display, then Reporting identity. Confirm it deliberately rather than inheriting it.
If your site has any logged-in state, account creation, checkout, a client portal, then collecting a User-ID is the single highest-value change available to you. Someone who reads three posts on a laptop and converts on a phone is one journey if both sessions carry the same ID, and two unrelated strangers if they do not. No attribution model can join those sessions for you. Only an identifier can.
Consent, without the hand-waving
The question is not what percentage of your traffic is European. It is simpler: do you have visitors in the EU or UK, and do you use Google Ads or Google's audience features. If both are yes, you need Consent Mode v2, because without it a rejected-consent session produces no signal at all and your attribution quietly tilts toward whichever channels bring the most cookie-accepting audiences.
- Deploy a consent management platform with a real Google Consent Mode v2 integration. Cookiebot, OneTrust and Usercentrics all ship native GTM templates that set the signals before GA4 fires.
- In GTM, default analytics_storage and ad_storage to denied, then update from the platform's response. Default-allow with a retroactive correction is not consent mode, it is a cookie banner with extra steps.
- Confirm in DebugView that consent_update events fire on both accept and reject. If you only ever test accept, you have tested half of it.
Validating that any of this worked
The sequence I run before calling a setup finished:
- DebugView, every primary action. Complete each one on the live site. Confirm the right event fires with the right parameters, not just that something fired.
- Realtime, same session. The key event should appear under the name you expect. A mismatch here is almost always a tag firing on the wrong trigger.
- Traffic acquisition, last 30 days, then the Direct landing page check above. This is the step most setups skip and most setups need.
- Explore a handful of real paths. Trace three to five journeys that ended in a key event. If they do not resemble how you know the business actually acquires customers, the event definitions are wrong, not the customers.
- Compare GA4 sessions to your server logs, and read the direction. GA4 lower than the server is normal and expected: consent rejections, blockers, filtered bots. GA4 higher than the server is the alarming one, and usually means a duplicate tag, a container included twice, or a page that also loads inside an iframe.
A property that survives that sequence produces attribution you can spend money against. One that does not is still producing numbers, and people will still make decisions with them.
