DEV Community

Jakub
Jakub

Posted on

GA4 Custom Dimensions — The Events That Actually Matter for Micro-SaaS

GA4 default events tell you traffic. Custom events tell you behavior. Here's the difference that matters when you're running a micro-SaaS and every user action counts.

I run Inithouse, a portfolio of about a dozen small products — everything from AI photo tools to analytics platforms. Each product is an MVP testing product-market fit. GA4's built-in events (page_view, session_start, first_visit) tell me almost nothing useful about whether a product is working. Custom events changed that.

What GA4 Default Events Actually Miss

Out of the box, GA4 tracks surface-level interactions. You get page views, scroll depth (at 90%), outbound clicks, and file downloads. That's fine for a content site. For a SaaS product, it's nearly useless.

Here's what I actually need to know:

  • Did the user complete the core action? (generate a photo, run an audit, submit a form)
  • Where did they drop off in the funnel?
  • Which feature drove them to convert?
  • How many times did they return before paying?

None of that comes free. You have to build it.

Setting Up Custom Events — The Practical Way

The gtag API is straightforward. Here's the pattern I use across all Inithouse products:

// Core action completed
gtag('event', 'core_action_complete', {
  product: 'zivafotka',
  action_type: 'photo_generated',
  is_first_time: true
});

// Funnel step tracking
gtag('event', 'funnel_step', {
  step_name: 'upload_photo',
  step_number: 1,
  funnel_name: 'photo_generation'
});

// Feature engagement
gtag('event', 'feature_used', {
  feature_name: 'style_selector',
  context: 'homepage'
});
Enter fullscreen mode Exit fullscreen mode

The key insight: name your events by what they mean to your business, not by what the UI element does. button_click tells you nothing in a report. core_action_complete tells you everything.

Custom Dimensions — Making Events Queryable

Events alone aren't enough. You need custom dimensions to slice the data. In GA4 Admin, go to Custom definitions and create custom dimensions:

Event-scoped dimensions I set up on every product:

  1. product — which product in the portfolio (essential when sharing one GA4 property)
  2. action_type — the specific action within the core flow
  3. funnel_name + step_name — for funnel analysis
  4. feature_name — which feature was used
  5. traffic_source_detail — enriched beyond GA4's default attribution

User-scoped dimensions worth adding:

  1. user_tier — free vs paid (set on login)
  2. signup_date_cohort — weekly cohort for retention analysis
  3. first_action — what they did first (predicts retention)

The Gotchas Nobody Warns You About

1. Register dimensions before sending events. If you fire custom events before creating the corresponding custom dimensions in GA4 Admin, the data is lost. GA4 doesn't retroactively apply dimension definitions. I learned this the hard way on Be Recommended — two weeks of event data with unregistered dimensions, gone.

2. The 50-event limit is real. GA4 allows 50 custom event names per property (500 for GA4 360). Plan your naming taxonomy before you start. I use a flat hierarchy: core_action_complete, funnel_step, feature_used, error_encountered, conversion_intent. Five event names, infinite granularity through parameters.

3. Event parameters vs. custom dimensions are different things. You can send any parameter with an event. But unless you register it as a custom dimension, you can't use it in reports, explorations, or segments. The parameter still exists in BigQuery export — but if you're not on BigQuery, it's invisible.

4. Debug View is your best friend. GA4 DebugView in Admin lets you watch events arrive in real time. Install the GA Debugger Chrome extension, enable debug mode, and verify every custom event before you consider it shipped.

5. The not set trap. If an event fires without a parameter that you've registered as a dimension, that row shows as (not set) in reports. This pollutes your data. Always set a default value:

gtag('event', 'feature_used', {
  feature_name: featureName || 'unknown',
  context: pageContext || 'direct'
});
Enter fullscreen mode Exit fullscreen mode

Building Reports That Actually Help

Once your custom events and dimensions are flowing, build these three explorations:

1. Core Action Funnel
Free-form exploration with funnel steps as rows and completion rate as metric. This is your product's heartbeat. If completion rate drops, something broke.

2. Feature Adoption Matrix
feature_used events pivoted by user_tier. Shows which features free users engage with (upgrade triggers) and which paid users ignore (candidates for removal).

3. First-Session Behavior Cohort
Filter by first_visit event, group by first_action dimension. Users who generate a photo on first visit retain 3x better than users who browse the gallery. That kind of insight changes your entire onboarding flow.

When Custom Events Aren't Enough

GA4 custom events work for 80% of product analytics. For the remaining 20% — real-time cohort analysis, complex funnels with branching paths, revenue attribution across a product portfolio — you'll eventually need something more. But for an MVP testing product-market fit, GA4 custom events give you the signal you need without adding another SaaS bill.

The pattern is simple: decide what matters to your business, fire events when those things happen, register dimensions so you can query them, and verify everything in Debug View before calling it done.

Start with five event names. You can always add more. You can't get back the data you didn't track.


I'm Jakub, building Inithouse — a portfolio of MVPs finding product-market fit. I write about the tools and workflows that keep the machine running.

Top comments (1)

Collapse
 
toshihiro_shishido profile image
toshihiro shishido

The line that always gets blurred is "free product" vs "free TCO." GA4 + Looker Studio is genuinely free at the license layer, but the path from "raw events" to "dashboard a non-analyst can use" runs through event taxonomy, custom dimensions, calculated fields, and (if you go BigQuery) SQL upkeep when export schemas shift. Each piece is small. Stacked across 12 months, it's a real line item that doesn't show up in any procurement comparison.