Looker Studio's connectors — GA4, Google Ads, Sheets, BigQuery — hand you raw dimensions and metrics, but almost no report shows raw numbers unmodified. You need rates derived from two metrics, averages weighted by a third, and comparisons against a prior period. Calculated fields are formulas defined once (either on the data source, so they're reusable across every report using it, or scoped to a single chart) that compute a new field from existing ones using Looker Studio's formula language — a mix of arithmetic, aggregate functions, and a smaller set of string/date functions than a full spreadsheet, which is exactly why specific patterns come up over and over.

Blended conversion rate across mismatched sources

A "blended" rate — conversions from one source divided by sessions from another — is the single most requested calculated field in marketing reporting, and the one most likely to be built wrong. The trap is computing the ratio per-row before aggregation instead of letting Looker Studio aggregate the numerator and denominator separately and divide at render time. A calculated field written as conversions / sessions on a blended data source (one combining two connectors, e.g. GA4 and a CRM export) only works correctly if both metrics use the SUM aggregation and the join key between the two sources is clean — otherwise you get a per-row ratio that doesn't mean anything once summed across a table.

blended_conversion_rate.txt

text

Field name: Blended Conversion Rate
Formula:
  SUM(Conversions) / SUM(Sessions)

-- Applied to a blended data source joining GA4 (Sessions)
-- and CRM export (Conversions) on Date + UTM Campaign.
-- Using SUM() on both sides (not a per-row division first)
-- is what makes this correct when the table is grouped,
-- filtered, or has a date range control applied.

Never divide two raw fields without wrapping both in an aggregation

Conversions / Sessions without SUM() around each side will compute a row-level ratio before any grouping happens, and Looker Studio's default aggregation on the resulting calculated field (often SUM or AUTO) will then sum those per-row ratios — a number with no real meaning. Always decide explicitly whether a rate should aggregate its inputs first (SUM(a)/SUM(b)) or compute per-row and then average (AVG(a/b)); they produce different, both legitimate-looking, wrong-in-different-ways numbers if you pick the wrong one for the use case.

Weighted averages: don't let small samples skew the number

A simple AVG() of a rate column (like average conversion rate across campaigns) treats a campaign with 10 clicks the same as one with 100,000 — which is almost never what a stakeholder actually wants to see. A weighted average recomputes the rate from its underlying totals instead of averaging the rates themselves, which is the same "aggregate inputs, then divide" principle as the blended conversion rate above, applied to CPC, CTR, or ROAS.

weighted_average_cpc.txt

text

-- WRONG: averages the per-campaign CPC values equally,
-- regardless of spend or click volume
Field: Avg CPC (naive)
Formula: AVG(CPC)

-- RIGHT: weighted by actual clicks, via underlying totals
Field: Weighted Avg CPC
Formula: SUM(Cost) / SUM(Clicks)

Date comparisons without a second data source

Looker Studio's built-in date range comparison (comparing a metric against a prior period) works at the chart-control level, but calculated fields let you build custom comparison logic a standard chart control can't express — like a specific trailing-28-day-vs-prior-28-day delta that stays fixed regardless of what date range control a viewer selects, or a rolling classification of "this week vs. last week" for a scorecard.

period_over_period_delta.txt

text

Field name: Revenue Change %
Formula:
  (SUM(CASE WHEN Date BETWEEN
        DATE_SUB(CURRENT_DATE(), 28)
        AND CURRENT_DATE()
      THEN Revenue END)
   - SUM(CASE WHEN Date BETWEEN
        DATE_SUB(CURRENT_DATE(), 56)
        AND DATE_SUB(CURRENT_DATE(), 28)
      THEN Revenue END))
  / SUM(CASE WHEN Date BETWEEN
        DATE_SUB(CURRENT_DATE(), 56)
        AND DATE_SUB(CURRENT_DATE(), 28)
      THEN Revenue END)

-- Compares trailing 28 days to the prior 28 days, independent
-- of any date-range filter a viewer applies to the page.

Source-level fields beat chart-level fields for anything reused

A calculated field created on an individual chart only exists on that chart. The same formula created at the data source level (Resource > Manage added data sources > edit the source) becomes available to every chart and every report built on that source, and updates in one place if the logic ever needs to change. Build anything you expect to reuse — blended rates, weighted averages, channel groupings — at the source level from the start.

CASE statements for channel grouping and bucketing

Marketing reports constantly need custom groupings that don't exist in the raw data — collapsing twenty UTM source/medium combinations into five channel buckets, or bucketing order value into tiers for a distribution chart. CASE WHEN is the workhorse here, and it's worth building as a single reusable field rather than re-deriving the same groupings as filters on every chart.

channel_grouping.txt

text

Field name: Channel Group
Formula:
  CASE
    WHEN Medium = "cpc" THEN "Paid Search"
    WHEN Source = "facebook" OR Source = "instagram" THEN "Paid Social"
    WHEN Medium = "email" THEN "Email"
    WHEN Medium = "organic" THEN "Organic Search"
    WHEN Source = "(direct)" THEN "Direct"
    ELSE "Other"
  END

Common calculated field patterns at a glance

Need	Formula pattern	Common mistake to avoid
Blended conversion rate	SUM(a) / SUM(b)	Dividing raw fields without aggregation wrappers
Weighted average cost metric	SUM(cost) / SUM(volume)	Using AVG() on a pre-computed rate column
Period-over-period delta	CASE WHEN date range THEN metric END, summed and diffed	Relying on viewer-controlled date filter for a fixed comparison
Channel bucketing	CASE WHEN source/medium THEN label END	Re-deriving the same buckets separately on every chart
Reusable logic	Build at data-source level, not chart level	Duplicating formulas per-chart, drifting out of sync

What's next

Calculated fields make individual numbers correct; the next concern is whether the dashboard they feed is actually built for the person reading it. The dashboard best-practices module covers audience-appropriate design and avoiding vanity-metric layouts.

Next: Marketing Dashboard Best Practices →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →