GA4 reporting for multilingual sites: locale-based funnel analysis
GA4's Language dimension measures browser language, not your site version. Custom dimension setup, Funnel Exploration and reporting practice for locale funnels.
By Roozbeh Nazari · CEO
On a multilingual site, GA4's default reports show you a single pool: all languages, all markets, one curve. The sentence "the site is doing fine" gets built on that pool, and it is dangerous; strong Turkish performance can hide a quietly leaking Arabic funnel for months. To make market-level decisions, the basic unit of reporting is not the session but which language version the session happened in. This article walks through building locale-based funnel analysis in GA4 end to end: with which dimension, which events, which reports.
Start with the first and most common trap: GA4's built-in "Language" dimension measures the user's browser language, not your site's language version. A user in Dubai browsing your /ar/ section with an English-configured browser shows up as English in that dimension. Both pieces of information are valuable, but they answer different questions; browser language describes your audience's language profile, while site version tells you which experience converts. Funnel analysis needs the second one, and GA4 does not know it by itself — you have to add site locale to your measurement yourself. The good news: this is a setup that fits into an afternoon. The bad news: reports for the months it wasn't in place cannot be fixed retroactively, because GA4 stores data with the dimensions it had on the day of collection.
There are two practical routes. The first is content grouping: you add a content_group parameter derived from the language prefix in the page path (/tr/, /en/) to your configuration; Content group then appears as a ready-made dimension in page reports. Setup is a few lines and it is sufficient for page-focused analysis. Its limit: content group is tied to the pageview concept, so its flexibility drops when slicing event-based steps like form submissions or WhatsApp clicks.
The second route — the one we recommend — is an event-scoped custom dimension attached to every event: site_locale. In Tag Manager you define a variable read from the URL path or from the page's html lang value, and it gets added as a parameter to every event, from pageview to form submission. Then you register site_locale under Admin, in Custom definitions; an unregistered parameter never shows up in reports, and this step is the most commonly forgotten link. Standard properties are limited to 50 event-scoped custom dimensions; permanently spending one slot on locale is one of the best uses of that quota on a multilingual site. With this in place, every step of the funnel — whatever event it comes from — becomes sliceable by language version. On the GTM side the variable needs nothing complicated: a small custom JavaScript variable reading the first segment of the page path, or a lookup table doing the same job, is enough; what matters is that the values come from the same dictionary everywhere.
With the dimension ready, the funnel itself comes next. A realistic skeleton for a service-focused site: session start, service page view, engagement intent (form_start or a WhatsApp button click), submission (generate_lead). These steps need consistent event naming, and the ones that count as conversions must be marked as key events in GA4. Then build a Funnel Exploration in Explore: the steps are these events, the breakdown dimension is site_locale. Turn on the option showing elapsed time between steps too; the difference in decision speed between markets is often more instructive than the difference in conversion rate. Also take care to keep step definitions identical across locales; if one language runs form-first and another WhatsApp-heavy, build the funnel template on the common denominator and examine channel-specific steps in a separate view. Putting two funnels built on different definitions side by side produces an illusion, not a comparison.
One subtlety: users move between language versions. The user who lands on an English page and submits a form on an Arabic page is not an exception. Event-scoped site_locale is the right choice precisely for this; it records each step in the version where it happened and makes the switches visible. Put an entry-point view next to it as well: reading the landing page dimension together with locale shows you which language pulls the traffic. Separate two questions deliberately: "which language brings visitors" is a marketing question, "which language version convinces" is an experience question; reports that mix the two into one metric answer both wrongly.
Because locale-based analysis splits the data, it also forces you to face small-number realities. On properties with Google Signals enabled, reporting thresholds kick in and rows can be hidden in small segments; over a narrow date range your Arabic funnel may look partially empty. The fix is widening the window: look weekly rather than daily, monthly if needed, and read rates as trends rather than single days. If you compare value across markets, make sure the currency parameter is sent correctly in every market; GA4 converts values into the property's reporting currency, but it will not fix a mislabeled currency for you.
The locale dimension shows its real power when joined with the paid side. Standardize language information in campaign naming and UTM discipline; then, when you cross source/medium reports with site_locale, you see which market's ads land on which language version. The first mistake this cross-view catches is almost always the same: ad traffic landing on the wrong language. Mismatch accidents like an Arabic-targeted campaign landing on an English page quietly burn budget at the top of the funnel. Also build GA4 audiences filtered by site_locale and split your remarketing lists by market; remarketing from a single pool is the shortest route to showing users ads in the wrong language.
The last link in reporting is putting this analysis in front of the decision-maker regularly. A one-page view in Looker Studio is enough for most teams: locales in rows, funnel steps in columns, step conversion rates beside them, and the weekly trend. For those who prefer to stay inside GA4, the comparisons feature is a quick alternative. Propose an early-warning layer too: if submission events drop to zero in one locale, the cause is usually not marketing but a broken translation or a failing form validation; setting up alerts for such anomalies with GA4's custom insights catches the problem before the weekly report does. Write the data freshness and last verification date at the top of the report page as well; the biggest risk of an unwatched dashboard is not wrong data, but nobody noticing it broke.
A closing field warning: multilingual measurement is not a system you set up once, but one you verify continuously. Every deploy, every change touching the GTM container and every new language version can silently break the site_locale chain — and the first to notice is usually not a report but a budget meeting months later. In SEO Evaluate's Analytics & Data service we don't leave multilingual measurement at setup; we run it together with a regular verification routine. The principle is simple: first a measurement that sees every market separately, then the budget decision. A multilingual site managed on pooled data isn't really being managed at all.