If you’re using LogRocket to watch user sessions, you know how easy it is to drown in data. Not every session matters. You want to zero in on the sessions that actually tell you something—like why users drop off, or what’s tripping them up during onboarding. This guide is for developers, PMs, and anyone else tired of wading through endless replays. Here’s how to get meaningful results by filtering sessions based on user properties.
Why filter by user properties?
Out of the box, LogRocket records a ton of sessions. That’s great until you’re staring at hundreds of anonymous page views with no clue who these people are or what they were trying to do. Filtering by user properties lets you:
- Focus on real users, not bots or random drive-bys.
- Spot patterns among specific user groups (think: paying customers, beta testers, or folks using a certain browser).
- Debug issues faster, because you’re not hunting through noise.
But—this only works if you’re actually capturing and using the right user properties. Let’s walk through how to do this well.
Step 1: Decide which user properties actually matter
First, don’t just dump all your user data into LogRocket. More isn’t better—too many properties make filtering confusing and slow. Focus on what’s actionable. Ask yourself:
- Who do I care about? (Logged-in users, admins, new signups, etc.)
- What signals a “problem” session? (Failed payments, feature usage, rage clicks)
- What properties help me debug issues? (Browser, device, account plan)
Common useful user properties:
- userId or email (so you can find user-specific sessions)
- Account type or role (admin/user, free/premium)
- Signup date (for catching onboarding bugs)
- Feature flags or beta access status
- Custom tags for known segments (like “internal tester”)
What to ignore: - Anything that doesn’t help you narrow things down. If you never care about ZIP code, don’t track it. - Super granular stuff like “last clicked button” as a user property—save that for event tracking.
Pro tip: Start simple. You can always add more properties later, but removing noisy or useless ones is a pain.
Step 2: Send user properties to LogRocket
LogRocket can only filter by the properties you send it. There are two main ways:
2.1. Set user identity and traits in your code
Right after a user logs in or whenever their info changes, call:
js LogRocket.identify('user-id-or-email', { name: 'Jane Doe', email: 'jane@example.com', accountType: 'premium', signupDate: '2024-05-01', isBetaTester: true });
- The first argument is a unique user ID (email or database ID).
- The second is an object with key-value pairs for properties.
Don’t:
- Send sensitive data (passwords, security tokens).
- Overdo it—stick to what you’ll actually filter by.
2.2. Use group/organization properties (optional)
If you need to filter sessions by company or team, LogRocket supports a group method:
js LogRocket.group('org-123', { name: 'Acme Corp', plan: 'enterprise' });
This is handy for B2B products, but honestly, most folks can skip this unless you really need org-level filtering.
Step 3: Build filters that actually work
Now that you’re sending the properties, it’s time to use them.
3.1. Basic filters
In the LogRocket dashboard, hit the “Filter” button. You’ll see options like:
- User email or ID
- Custom properties (account type, beta status, etc.)
- Browser, device, OS
Build filters using simple logic:
- accountType is premium
- isBetaTester is true
- email ends with @yourcompany.com (for internal dogfooding)
Avoid:
- Building crazy-complex filter chains unless you really need them. Simple is almost always better.
3.2. Combine filters for better targeting
You can stack filters to get very specific. For example:
- Sessions from “premium” users on Safari where
featureFlagX is true - New signups (
signupDate after 2024-06-01) who encountered an error
But: every extra filter shrinks your results. If you’re getting zero sessions, loosen them up.
3.3. Save filters you’ll use again
Don’t reinvent the wheel. If you check the same segment often (e.g., “free users with failed payments”), save the filter for easy access later.
Pro tip:
Name saved filters clearly—future you will thank you. “Test filter 1” is useless.
Step 4: Watch out for common pitfalls
Filtering by user properties sounds easy, but there are a few traps:
4.1. Property values are case-sensitive
LogRocket treats Premium and premium as different. Pick a convention (all lowercase is easiest) and stick with it in your code.
4.2. Properties must exist before you can filter
If you forget to send a property, it won’t show up in the dashboard. Double-check your implementation if you can’t filter by something you expect.
4.3. Privacy matters
Don’t send PII you shouldn’t. Email addresses are usually fine, but skip anything sensitive. If you’re not sure, err on the side of less.
4.4. Filtering ≠ Analytics
LogRocket is great for debugging and session review, but it’s not a full analytics suite. For trends, stick with tools built for that (Mixpanel, Amplitude, etc.). Use LogRocket filters to find sessions worth watching—not to run reports.
4.5. Filters can slow down if you go overboard
The more properties you track, the more sluggish filtering gets. Keep the property list tight and focused.
Step 5: Iterate—don’t try to get it perfect on day one
Your first set of filters probably won’t be perfect. That’s fine. Use them for a week, see what feels clunky, and tweak:
- Are you still digging through junk sessions? Tighten your filters.
- Not seeing enough? Broaden them or check if you’re missing properties.
- Is your team confused by property names? Standardize them and update your docs.
Filtering is an ongoing process, not a checkbox to tick once.
What actually works—and what to skip
What works: - Start with 3–5 core user properties you know you’ll use. - Save filters for your most important user segments or flows. - Review and prune properties every few months.
What doesn’t: - Tracking every possible property “just in case.” - Overcomplicating filters to the point where you forget what you’re looking at. - Using LogRocket as a catch-all analytics tool—it’s not built for that.
Ignore:
- Hype about “AI-powered filtering” or “automatic insights.” They’re not magic. Good filters come from knowing your product and your users.
Keep it simple and keep improving
Filtering user sessions in LogRocket isn’t hard, but it does take some thought. The trick is to keep things simple: focus on the user properties that matter, build clear filters, and don’t be afraid to adjust as you go. Start small, iterate, and you’ll spend less time sifting through noise—and more time actually solving real user problems.