Why bounceRate in GA4 Is Not 0.94 (And How to Ask ChatGPT for the Right Number via Kondado MCP)

You open ChatGPT connected to your Google Analytics 4 data, ask "what is the bounce rate of my main landing page?" and get: 94. Looks great. 0.94, or 94%? Hold on. If you or the LLM interpret it as 0.94 (a decimal between 0 and 1), the automatic conclusion is that the page performs excellently, with only 6% bounce. But the GA4 API returns bounceRate as a percentage from 0 to 100. The number 94 means 94% bounce, an engagement disaster. This semantic trap, documented in the Kondado GA4 data source code, has led analysts and AI assistants to completely inverted diagnoses.

What makes this trap dangerous: bounceRate in the GA4 API ranges from 0 to 100 (percentage), not 0 to 1 (decimal). A value of 94 is 94% bounce (terrible), not 0.94, which would be 6% bounce (excellent). The confusion exists because engagementRate in the GA4 UI is 0 to 1, but bounceRate = (1 - engagementRate) × 100 in the API: the unit shifts mid-pipeline and LLMs do not know this by default. With the Kondado MCP, you ask in plain English and receive the correct interpretation. "Which landing page has bounceRate > 60% in the last 30 days?" returns the right pages because the model learned to treat bounceRate as a percentage, knowledge sourced directly from the data source code. The solution is not learning the Google API internals. It is using the Kondado MCP, which understands this and other traps and delivers the correct interpretation when you ask in plain English.

What does the GA4 API actually return in the bounceRate field?

Google Analytics 4 exposes bounceRate as a metric in the Data API v1beta. The official documentation is available in the Google developer portal. In Google's definition, the description reads: "the percentage of sessions that were not engaged sessions." The key word here is percentage: the return range is 0 to 100.

In practice, what the API delivers is a number like 94.0, 67.3, or 12.8. It is not a normalized ratio between 0 and 1 like other metrics in the Google ecosystem. For example, click-through rate in the Ads API returns as 0.05 for 5%. bounceRate already comes pre-scaled × 100.

The Kondado GA4 data source code (creator.py:683-686) treats this field exactly as the API delivers it, raw percentage, without applying any additional normalization. This is intentional: normalizing to 0 to 1 would introduce ambiguity. But an LLM does not know this unless someone teaches it.

Why does the confusion between 0.94 and 94% break any analysis?

The problem starts in the GA4 UI itself. The engagement report shows engagement rate as a decimal between 0 and 1. For example, 0.35 means 35% engagement rate. Since bounceRate is the inverse (bounceRate = (1 - engagementRate) × 100), the unit changes mid-pipeline.

Here is what happens in practice with a real landing page:

1. The GA4 UI shows engagement rate of 0.06 (6% engagement, poor page)
2. The API returns bounceRate of 94.0 (94% bounce, consistent)
3. An LLM without context receives "94" and, seeing other GA4 metrics use decimals, assumes it is 0.94
4. LLM conclusion: "the page has 94% engagement, it is excellent". The opposite of reality.

The consequences are severe:

• Wasted paid traffic budget. You direct Google Ads to a page that 94% of visitors abandon without interacting, thinking it retains 94%.
• Inverted content diagnosis. The marketing team believes an article performs well and invests more in link building, when it actually needs to be rewritten.
• Compromised reports. Every funnel analysis, channel segmentation, and period comparison becomes wrong when the base engagement metric has its interpretation reversed. Reports that depend on this column become sources of misguided decisions.

No competitor documents this trap in the context of AI + GA4. This is knowledge that only exists by reading the data source source code. And it is exactly this kind of information the Kondado MCP injects into the system prompt so the LLM gets it right.

How to ask for the correct bounceRate with ChatGPT or Claude via the Kondado MCP

The Kondado MCP connects ChatGPT, Claude, or any compatible client to your data destination in Via Kondado. Instead of consuming the GA4 API directly, the LLM queries the SQL tables Kondado has already replicated, including blending data from multiple pipelines in the same query. Most importantly: the knowledge of semantic traps, including the bounceRate unit, is embedded in the model behavior for your queries.

This means three things in practice:

1. You do not need to explain that bounceRate is a percentage. The LLM already treats the field correctly. Asking "what is the bounce rate?" returns interpretation as a percentage, not a decimal.
2. Filters work as you expect. "Show landing pages with bounceRate > 60" correctly filters pages with more than 60% bounce, without worrying whether the threshold should be 0.6 or 60.
3. Comparisons and rankings come out right. "Sort pages by highest bounceRate" puts the worst at the top, not the best.

To connect, simply add the MCP endpoint URL in your ChatGPT or Claude client settings: https://mcp.kondado.io/mcp. OAuth 2.1 authentication binds your session to your Kondado workspace. The LLM then queries your data in read-only KSQL, without consuming Google API quota on every question. See the full setup guide on the Kondado MCP page.

Practical example: which landing pages have bounceRate above 60% in the last 30 days?

This is a real question you ask in plain English in ChatGPT connected to the Kondado MCP. The LLM translates it to KSQL, queries the ga4_landing_page_analysis table, and returns:

• List of landing pages with bounceRate > 60, sorted from worst to best
• engagedSessions per page, so you know whether the high bounce is on a high-traffic or low-traffic page
• total screenPageViews, to size the impact of each problematic page

The ga4_landing_page_analysis table is one of 13 tables Kondado replicates from GA4. It provides, per landing page per day, metrics like bounceRate, engagedSessions, screenPageViews, newUsers, and sessionSourceMedium. With the MCP, you cross-reference this data with other sources connected in the same Via Kondado (Google Ads, Meta Ads, or your ERP) and ask questions no isolated tool can answer.

In traditional GA4, this same analysis would require: opening the landing page report, adding bounceRate as a secondary metric, creating a threshold filter, setting the 30-day period, exporting to a spreadsheet, and sorting manually. With the MCP, it is one sentence in English.

Other questions the MCP answers correctly because it understands the bounceRate unit:

• "Which traffic channel has the highest bounceRate?" Crosses sessionSourceMedium with bounceRate and filters correctly.
• "Compare bounceRate of mobile vs desktop on my top 10 landing pages" Uses deviceCategory from the ga4_device_region_performance table.
• "Did bounceRate improve or worsen this month compared to last month?" Compares 30-day windows without interpretation errors.
• "Which pages have bounceRate < 30 AND more than 1000 pageViews?" Identifies high-traffic, low-bounce pages that are your most valuable content assets.

Data ready for AI: connect your GA4 to ChatGPT

Start your 14-day free trial on Kondado. Kondado replicates 13 GA4 tables to the destination you choose: BigQuery, PostgreSQL, Redshift, Google Sheets, or MySQL. With the MCP enabled, you ask in plain English in ChatGPT or Claude and receive analyses based on your real data, without opening the GA4 UI, without writing SQL, and without falling into unit traps like bounceRate. Knowledge of the 9 GA4 semantic traps (including bounceRate as percentage, eventValue in local currency, and the difference between purchaseRevenue and totalRevenue) is embedded in the queries the MCP runs. Connect your GA4 today.