GA4 BigQuery Export Attribution: Which Traffic-Source Field Should You Actually Use?

The 60-Second Answer

The GA4 BigQuery export stores attribution at three scopes. Use traffic_source.* on the first_visit event for user acquisition, session_traffic_source_last_click.* for session source, and traffic_source.* on a conversion event for event-scoped last-click. Picking the wrong scope silently misattributes revenue — usually inflating whichever channel a customer first discovered you through.

Most Shopify and DTC teams who pull their own attribution out of BigQuery get a number that looks plausible, ships to a dashboard, and is quietly wrong. Not because their SQL is broken — because they read a correctly-populated field at the wrong scope. This guide gives you a test to prevent that, and then shows why even perfectly-scoped last-click numbers still cannot tell you what to do with your budget.

Why This Field Is So Easy to Get Wrong

Here is the thing almost nobody tells you: traffic_source is scope-polymorphic. The same field name carries a different meaning depending on which event row you happen to be reading it from.

Per Google's traffic attribution documentation, traffic_source.source on a first_visit event is user-scoped — it describes how that user was originally acquired. But traffic_source.source on a conversion event is event-scoped, and reflects Google's cross-channel last-click model for that specific conversion.

Same column path. Two entirely different questions answered.

This is why a query like SELECT traffic_source.source, SUM(purchase_revenue) FROM events_* WHERE event_name = 'purchase' returns a result that is not wrong at the row level but is frequently misread as "the channel that acquired this customer." It is not that. If you then present it as acquisition data, you have built a reporting layer that systematically over-credits discovery channels and under-credits closing channels — or the reverse, depending on which event you filtered to. Nothing errors. Nothing looks broken. The number is just answering a different question than the one on the slide.

This is a close cousin of the problem described in the UTM tagging problem and the reason every attribution dashboard tells a different story.

The Scope-Match Test

Before you write a line of SQL, answer one question in plain language, then let the scope follow from it. We call this the Scope-Match Test, and it has three rungs.

The test is deliberately blunt: if you cannot state your question in one of those three forms, you are not ready to write the query. Most misattribution in home-built BigQuery reporting comes from skipping this step, not from bad joins.

A practical note on the session rung: session_traffic_source_last_click is a nested record with separate branches for manual tagging and for each Google advertising platform. Manual UTM traffic lands in manual_campaign; Google Ads traffic lands in google_ads_campaign, with parallel branches for SA360, DV360 and CM360. If you only read manual_campaign.source, your Google Ads sessions will look empty — a very common false alarm that sends teams hunting for a tracking bug that does not exist.

Step-by-Step: Building a Defensible Session-Source Query

1. Confirm your export is actually complete. Daily export creates events_YYYYMMDD; streaming export creates events_intraday_YYYYMMDD. Querying both with a events_* wildcard double-counts today. Decide which you want and filter _TABLE_SUFFIX explicitly.
2. Write your question down first. Use the Scope-Match Test above. Put the sentence in a SQL comment so the next person knows what the query claims to answer.
3. Pick the scope, then the field. Do not start from the field you already know exists.
4. Coalesce the campaign branches. For session source, read both manual_campaign and google_ads_campaign and coalesce, rather than assuming one.
5. Deduplicate to one row per session. The session record repeats on every event in the session. Aggregate to user_pseudo_id + ga_session_id before you join to revenue, or you will multiply revenue by event count.
6. Reconcile against the GA4 UI. Session-scoped last-click should broadly match your Sessions acquisition report. If it does not, your problem is upstream — see how to troubleshoot data discrepancies.
7. Reconcile against Shopify. Expect a gap. Google and Shopify revenue rarely match, and the gap is diagnostic, not noise.
8. Write down what the number cannot tell you. This is the step everyone skips, and it is the subject of the rest of this guide.

A Worked Example (Illustrative)

The figures below are a constructed example to show the arithmetic, not data from a specific brand.

A Shopify skincare brand runs a month at €80,000 in ad spend and books €400,000 in revenue. They pull two numbers from the same BigQuery export.

Both queries are correctly written. Both read a correctly-populated field. They disagree by €92,000 on Meta alone — because they answer different questions. Meta is where people discover the brand; branded search and email are where people close.

Now the part that matters. The team's instinct is to average the two, or to pick the one that supports the plan. Neither is defensible, because both numbers are correlational. They describe which touchpoint was present, not which touchpoint caused the purchase. A causal analysis of the same period might find that a large share of that branded-search revenue would have converted anyway — customers who already decided, typing the brand name — meaning the incremental return on that spend is far below the €140,000 it is credited with. That is the difference between incremental and attributed revenue, and no amount of correct field selection surfaces it.

This is the ceiling of the BigQuery export used on its own: it can tell you what happened next to a touchpoint. It cannot tell you what would have happened without it.

Common Mistakes

• Reading traffic_source off a purchase row and calling it acquisition. The single most expensive error in this guide.
• Ignoring the Google Ads campaign branches of session_traffic_source_last_click and concluding tracking is broken.
• Forgetting to deduplicate sessions, which inflates revenue by the number of events per session.
• Mixing daily and intraday tables with a wildcard, double-counting the current day.
• Treating (direct) as a real channel. It is mostly a measurement gap — see direct traffic.
• Assuming BigQuery precision equals causal truth. Row-level accuracy and causal validity are unrelated properties. Last-click has known structural problems regardless of how cleanly you query it.
• Rebuilding the platforms' own bias. Querying last-click faithfully reproduces the same self-attribution incentives that make Meta and GA4 disagree.

Checklist

• Business question written in one sentence, in the query comments
• Scope selected before field selected
• Daily vs. intraday tables explicitly filtered
• Both manual_campaign and google_ads_campaign branches read
• Deduplicated to one row per user_pseudo_id + ga_session_id
• Session totals reconciled against the GA4 UI
• Revenue reconciled against Shopify, with the gap explained
• Stated in writing that the output is correlational, not causal

From Correct Queries to Correct Decisions

Getting the scope right upgrades you from wrong to precisely correlational. That is a real improvement, and it is where most in-house ecommerce data warehouse projects stop.

The next upgrade is different in kind. Instead of asking which touchpoint was last, causal attribution asks what each channel actually added — modelling the counterfactual so that spend which would have converted anyway stops being credited. In practice this means Bayesian inference over the same GA4 export you already have, which is why causal inference for marketing attribution and MMM vs MTA vs causal inference are worth reading before you invest another quarter in dashboard-building. If you want to validate the output, incrementality testing is the ground truth.

Usefully, none of this requires new tracking. Your historical GA4 export already contains the raw material — which is the whole premise behind retroactive attribution analysis from your GA4 export and attribution for historical data when the pixel wasn't installed.

Key Takeaways

• The GA4 BigQuery export holds attribution at three scopes: user, session, and event.
• traffic_source means different things on different event rows. Read it on first_visit for acquisition, on a conversion event for last-click.
• Use session_traffic_source_last_click for session source, and read all campaign branches, not just manual_campaign.
• Apply the Scope-Match Test — question first, scope second, field third.
• Correct field selection eliminates a class of silent errors. It does not make the number causal.
• Deciding budget requires knowing what each channel added, which is a counterfactual question the export alone cannot answer.

---

For €99, upload any historical GA4 period and get causal attribution for every channel in 5–10 minutes — no pixel, no migration. Go Pro at €299/mo for continuous attribution, an AI chatbot for your data, and a developer API.

Further reading

Start with the ecommerce analytics stack for 2026, then compare tooling in the best marketing attribution tools and GA4 attribution alternatives. For the limits of the GA4 interface itself, see Google Analytics 4 attribution limitations and how to connect Google Analytics 4. Related: exporting and analysing Shopify marketing data, how to export attribution data, attribution models compared, multi-touch attribution problems, cohort-based attribution, server-side vs client-side attribution, data-driven attribution in Google Ads, SQL dialect differences, one dashboard, one number, and what the €99 analysis includes. Glossary: traffic source, session, attribution window, last-click attribution, first-touch attribution, data warehouse, UTM parameters, Bayesian inference, counterfactual, and incrementality.