If you’ve ever tried to answer “What are users actually doing in my app?” with out-of-the-box tools, you know the pain. Prebuilt analytics don't track the weird stuff unique to your product. That’s where custom event tracking comes in—and if you’re running a SaaS app, setting it up right in LogRocket can save you hours of guessing what’s going wrong (or right) with your users.
This guide is for SaaS developers and PMs who want to track more than just clicks and pageviews. We’ll walk through set-up, code samples, pitfalls, and a few honest takes about what’s worth tracking—and what isn’t.
Why bother with custom events in LogRocket?
Before diving into the “how,” let’s get clear on the “why.”
- Built-in events are generic. They’ll show you navigation, rage clicks, and JS errors. Useful, but they don’t tell you if someone actually used your killer new feature.
- Custom events give you context. Want to know who exported data, upgraded their plan, or invited a teammate? That’s custom territory.
- They make debugging less painful. See exactly what users did before reporting “it’s broken.”
Bottom line: If you’re serious about improving your SaaS, you need more than heatmaps. Let’s get to it.
Step 1: Get LogRocket set up (if you haven’t already)
If you’re already running LogRocket, skip to Step 2.
-
Sign up and create a project.
Head over to LogRocket and create an account. Follow the prompts to create a new project for your SaaS app. -
Install the LogRocket SDK.
In your frontend app, run: bash npm install --save logrocket
or use yarn if that’s your thing.
- Initialize LogRocket early.
Import and initialize LogRocket as close to app startup as you can. For example, in a React app: js import LogRocket from 'logrocket'; LogRocket.init('your-app-id/project-name');
Replace 'your-app-id/project-name' with the ID from your LogRocket dashboard.
Pro tip: Don’t put LogRocket initialization after heavy imports; you want it to catch user actions from the start.
Step 2: Decide what’s actually worth tracking
Here’s where most teams get overwhelmed: trying to track everything. Don’t do that.
Focus on what matters
For SaaS apps, these are usually good bets: - Feature usage. Did users try out that new dashboard view? - Lifecycle events. Signup, upgrade, downgrade, cancel, invite teammate. - Critical workflows. Did they export data, connect an integration, or complete onboarding?
Skip logging:
- Every button click (noise, not insight).
- Super granular events (e.g., “opened settings modal” unless it really matters).
If you’re not going to use it to make a change, don’t bother tracking it.
Step 3: Add custom event tracking to your code
Here’s the part that trips people up: LogRocket doesn’t have a drag-and-drop UI for custom events. You have to call a method in your code.
The method: LogRocket.track()
You’ll use: js LogRocket.track(eventName, properties);
eventName(string): Name of your event.properties(optional object): Extra data (e.g., plan type, feature name).
Example: Tracking a feature usage event
js LogRocket.track('Used Export Feature', { plan: 'pro', fileType: 'csv' });
Where to put it
- React: Right inside your event handler, after the action completes.
- Vue/Angular: Same idea—trigger it when the user action is confirmed, not just when they click.
- Backend? LogRocket is frontend only. If you want to track backend events, you’ll need to push them to the frontend (e.g., via a websocket or after an API response) and call
LogRocket.track()there.
Naming conventions
- Use human-readable names (“Upgraded Plan,” not “UPG_PLN”).
- Stick to a pattern, or you’ll hate yourself later.
- Don’t overthink the event properties—add what you’ll actually use in filters.
Step 4: Confirm your events are coming through
Here’s what most docs leave out: how do you know it’s working?
-
Trigger your event in your app.
Do the thing you just added tracking for. -
Go to your LogRocket dashboard.
Find your test session (it’s usually at the top under “Recent sessions”). -
Look for the event.
In the session timeline, you should see your custom event pop up with its name and any properties.
If you don’t see it, check: - Is LogRocket initialized before your event triggers? - Do you have ad blockers or privacy extensions on? (They can block LogRocket.) - Any typos in your event name?
Pro tip: Use a test account or incognito window to avoid polluting real user data.
Step 5: Filter sessions using your custom events
This is where the payoff happens.
- In LogRocket, go to “Sessions.”
- Click “Add Filter” and select “Custom Event.”
- Pick your event name from the dropdown.
- You can filter by event properties too (e.g., plan = “pro”).
Now you can watch sessions only for users who did the thing you care about. No more digging through hours of random clicks.
Step 6: Iterate, don’t overdo it
The temptation is to start tracking everything. Resist.
- Start with 3–5 critical events.
- Review the sessions—are you learning anything useful?
- Add more events only if you’re missing context you need.
- Clean up unused or noisy events every so often.
Honest take:
If you’re not using the data to make a decision or spot a problem, you’re just generating noise.
Real-world advice (Stuff you might not hear elsewhere)
- Don’t track PII. LogRocket will mask inputs by default, but don’t send anything sensitive in custom events.
- Event overload is real. Too many events will make filtering a chore. Keep it lean.
- Coordinate with your team. If you have multiple devs, agree on event names and patterns up front. Otherwise, it’ll get messy.
- QA loves this. Custom events make it way easier to find “that weird bug” in sessions.
- Ignore the hype: Custom events won’t magically fix your onboarding or UX. They just help you see what happened.
Wrapping up
Custom event tracking in LogRocket is not rocket science (sorry, had to). Start simple, track what matters, and actually use what you collect. If you’re spending more time setting up events than learning from them, you’re doing it wrong.
Set up a handful, review the sessions, and adjust. SaaS moves fast—your tracking should too.