So, you want to track exactly what matters in your product—not just what comes out of the box. You’ve probably heard that FullStory’s “custom events” can help, but finding clear, honest instructions is another thing. This guide is for people who need real answers, not hand-waving: product managers, engineers, or anyone troubleshooting analytics headaches. I’ll walk you through the practical steps to set up custom events in FullStory, call out any gotchas, and help you avoid wasted time.
Let’s get right into it.
Why Custom Events Matter (and When to Skip Them)
Before you dive in, a quick reality check: custom events are just signals you send to FullStory when something important happens in your app. Maybe a user clicks “Upgrade,” finishes onboarding, or triggers a hidden feature. Out-of-the-box tracking won’t catch these—custom events will.
But don’t go nuts. If you try to track every mouse wiggle, you’ll drown in data and make it impossible to find what matters. Only set up custom events for actions you actually care about measuring or want to build funnels/segments around.
Good reasons to use custom events: - You want to know when users hit meaningful milestones (not just page views). - You need to build funnels or segments based on actions unique to your product. - You care about tying behavior to backend events, not just clicks.
Skip custom events if: - You only want to track generic actions like button clicks (FullStory’s auto-capture does a lot already). - You’re not clear on what you’ll do with the data.
Step 1: Get Your Team on the Same Page
Before you jump into code, pause. Agree on what you need to track. Otherwise, you’ll end up with a mess of random events and zero insight.
Quick checklist: - What are the key actions or milestones you care about? - Who will add the events—engineers, or can your tracking tool handle it without code? - Are you mapping these events to business questions or just tracking for the sake of it?
Pro tip: Write down your event names and descriptions somewhere everyone can see. “User_Onboarded” means different things to different people; make it specific.
Step 2: Understand FullStory’s Event Model
FullStory splits things into two main buckets: - Auto-captured events: Page views, clicks, form submissions. No setup needed. - Custom events: What you send in yourself. This is where you get to define what matters.
Custom events are sent via the FullStory SDK (JavaScript, or mobile SDKs if you’re tracking in an app). You’ll call a function in your code whenever the action you care about happens.
Don’t confuse custom events with user properties. Events are “this thing happened.” Properties are “about this user.” They work together, but they’re tracked differently.
Step 3: Set Up the FullStory SDK (If You Haven’t Already)
If this is your first rodeo with FullStory, you need their SDK installed. Most web apps use the JavaScript snippet. If you’re on mobile, grab the iOS or Android SDK.
For web:
- Copy the FullStory snippet from your FullStory settings.
- Paste it before the closing </head> tag on every page you want tracked.
For mobile:
- Follow FullStory’s docs for iOS or Android SDKs. (There’s more setup—don’t skip the docs.)
If you’re already capturing sessions and seeing data in FullStory, you’re set. Move on.
Step 4: Define Your Custom Events
Don’t wing it here. Decide: - Event name: Keep it short, clear, and consistent. Use underscores or camelCase, but pick one. - Parameters: What data do you want to include? E.g., plan type, amount, referral code.
Example:
If you want to track when someone completes checkout,
- Event name: Checkout_Completed
- Parameters: { order_value: 99.99, item_count: 3 }
What not to do: - Don’t include sensitive info (PII, passwords, etc.). - Don’t make event names too generic (e.g., “Clicked_Button”).
Step 5: Add Custom Event Code
Here’s the practical bit. In your app code, when the action happens, call the FullStory event function.
For JavaScript (web):
js if (window.FS && typeof window.FS.event === 'function') { window.FS.event('Checkout_Completed', { order_value: 99.99, item_count: 3 }); }
A few notes:
- Always check window.FS exists to avoid errors for users with blockers or privacy tools.
- Parameters are optional, but super useful for filtering later.
For React (or any frontend framework):
Put the call wherever the event occurs—after a successful API call, for example.
js import { useEffect } from 'react';
function ConfirmationPage({ order }) { useEffect(() => { if (window.FS && typeof window.FS.event === 'function') { window.FS.event('Checkout_Completed', { order_value: order.total, item_count: order.items.length }); } }, [order]);
// ...rest of your component }
For Mobile (iOS/Android):
The idea’s the same, but the function call changes. Check FullStory’s SDK docs for the exact method (usually FS.event() or similar).
Don’t ignore error handling:
If the event call doesn’t fire, you won’t know. Consider adding some logging (in dev, not prod) to make sure it’s working.
Step 6: Test Your Events
Don’t just assume it’s working because you wrote the code. Test it yourself. - Open your app, trigger the event. - Go to FullStory’s “Events” section and see if your event shows up. - If it doesn’t appear within a few minutes, check your browser console for errors or debug logs.
Common gotchas: - Ad blockers can block FullStory entirely—test in a clean browser profile. - Event names are case-sensitive. “checkout_completed” is not “Checkout_Completed.” - FullStory can take a minute or two to process new events.
Step 7: Use Your Custom Events in FullStory
Now the fun part—actually using these events.
- Segments: Filter users who triggered (or didn’t trigger) your custom event.
- Funnels: Build multi-step funnels using your events to see where users drop off.
- Search: Find specific sessions where your event fired (super helpful for debugging).
- Metrics: Visualize counts or trends for your custom events.
What works well: - Pinpointing where users get stuck in onboarding or checkout flows. - Measuring adoption of new features (e.g., “Used_AI_Assistant”). - Debugging: Jump straight to sessions where something weird happened.
What doesn’t:
- Don’t expect FullStory to replace a full-blown analytics tool (like Amplitude or Mixpanel) for heavy-duty querying or cohort analysis. FullStory’s custom events are great for session-level insight, not deep BI.
Step 8: Maintain and Clean Up
It’s easy to end up with a graveyard of old, unused custom events. Every few months: - Review your event list. - Remove or rename events no one cares about. - Update documentation so new team members aren’t lost.
Pro tip:
Naming conventions matter. If you start with “User_” for some events and “user_” for others, you’ll regret it later.
Final Thoughts
Custom events in FullStory are a powerful way to connect the dots between user behavior and product outcomes—but only if you keep it simple. Track what matters, don’t overcomplicate, and revisit your setup often. Set up your first few events, see what insights you get, and adjust as you go. The best analytics setups are the ones you actually use.