GA4 default events tell you traffic. Custom events tell you behavior. Here's the difference that matters when you're running a micro-SaaS.
The Problem With Default GA4
If you've launched a product — whether it's built with Lovable, Next.js, or anything else — GA4 gives you page_view, session_start, first_visit, and a handful of engagement events out of the box. That's fine for a blog. For a product trying to find product-market fit, it's almost useless.
Default events answer "how many people visited." They don't answer "how many people actually tried the core feature," "where do users drop off in the flow," or "which acquisition channel brings users who convert."
I run Inithouse, a portfolio of ~14 micro-SaaS products in various stages of finding PMF. Every single one of them needed custom events from day one. Here's what I've learned.
Which Custom Events Actually Matter
Forget tracking everything. Track the moments that tell you whether someone got value from your product.
Activation events — the user did the core thing your product exists for. For Be Recommended (an AI visibility tool), that's "ran first analysis." For a photo tool, it's "generated first image." For a challenge game, it's "completed first round." Name it something specific like core_action_completed and fire it exactly once per session.
Friction events — the user hit a wall. Form validation errors, failed API calls, empty states with no guidance. Track these as user_friction with a custom dimension for the friction type. You'll find patterns fast.
Conversion micro-steps — every step between landing and paying. Clicked pricing, opened signup modal, started checkout, completed payment. Each one is a separate event with a funnel_step dimension.
Feature discovery — did users find the features you built? Track feature_used with a dimension for which feature. If nobody finds your best feature, that's a product problem, not an analytics problem.
Implementation: gtag Basics and Gotchas
The basic pattern is straightforward:
gtag('event', 'core_action_completed', {
action_type: 'analysis_run',
result_count: 12,
time_to_complete: 4500
});
But here are the gotchas that trip people up.
Custom dimensions need registration. Firing custom parameters in gtag does not automatically create dimensions in GA4. Go to Admin, then Custom definitions, then Create custom dimension. Register each parameter you want to filter on. Until you do, the data is collected but invisible in reports.
Event-scoped vs user-scoped. Event-scoped dimensions describe what happened (friction_type, feature_name). User-scoped dimensions describe who it happened to (plan_tier, signup_source). A user plan tier is user-scoped since it persists. A specific error code is event-scoped since it is per occurrence.
The 50-event limit. GA4 allows up to 50 custom events (500 for GA360). Plan your taxonomy upfront. Use generic event names with descriptive dimensions instead of unique event names for every action. feature_used with a feature_name dimension is better than used_search, used_filter, used_export as separate events.
Debug mode is essential. Use the DebugView in GA4 while developing. Enable debug mode in your config:
gtag('config', 'G-XXXXXXXX', { debug_mode: true });
Without this, you are flying blind. Events take 24-48 hours to show up in standard reports.
Setting Up Custom Dimensions Step by Step
Start by planning your taxonomy. List every meaningful user action. Group by category (activation, friction, conversion, discovery). Aim for 10-15 events max to start.
Then register in GA4: Admin, Custom definitions, Create custom dimension. Set the scope (event or user), map to the parameter name in your code.
Implement in code and fire events at the right moment. For SPAs, handle route changes since GA4 will not auto-track virtual pageviews unless configured.
Validate in DebugView. Open your app with debug mode on, trigger every event, confirm they appear with correct parameters.
Finally, build Explorations in GA4 using your custom dimensions. Funnel explorations are particularly useful for conversion micro-steps.
Reporting That Actually Helps
Once your custom events are flowing, build three reports:
Activation funnel — from first_visit through each micro-step to core_action_completed. This is your north star. At Inithouse we check this weekly for every active product. If activation rate drops, everything else is noise.
Feature adoption matrix — how many users discover each feature, and which features correlate with retention. Build this as a free-form exploration with feature_used events broken down by feature_name dimension.
Friction heatmap — which friction events fire most often, on which pages, for which user segments. Sort by frequency and fix top-down. This is the highest-ROI work you can do since reducing friction directly improves activation.
When Custom Events Beat Mixpanel
For a solo builder or small team, GA4 custom events often beat dedicated product analytics tools. Mixpanel, Amplitude, and PostHog are great, but they add another service to manage, another SDK to load, and another bill to pay. If you are in the zero-to-one phase validating whether anyone even wants your product, GA4 custom events give you 80% of the insight at 0% of the cost.
The exception: if you need cohort analysis, real-time funnels, or complex behavioral segmentation, dedicated tools earn their keep. But for most micro-SaaS at the PMF-hunting stage, gtag with well-planned custom dimensions is more than enough.
The Checklist
Before you ship your next feature, make sure you can answer these with your analytics:
Can you measure the activation rate? (percentage of visitors who complete the core action)
Do you know where users drop off? (friction events with page context)
Can you compare acquisition channels by activation, not just traffic? (UTM + custom events)
Do you know which features get used? (feature discovery tracking)
If the answer to any of those is no, your next task is not building a new feature. It is adding the right custom events.
I am Jakub, building Inithouse — a portfolio of micro-SaaS products where every week is an experiment in finding product-market fit. Tools like Watching Agents and Be Recommended are where I test these analytics patterns in practice.
