Events
How to Find Event Design Mistakes in Firebase Analytics
Updated 2026-09-144 min read
Short answer
Most event design mistakes leave a pattern: too many events per user (duplicates), two versions of one event (naming), a parameter missing from reports or showing "(not set)" (unregistered or absent), most values under "(other)" (high-cardinality values), and events that never appear (reserved names or limits). Start from the pattern, confirm it in DebugView, and fix the code rather than the report.
An event plan looks tidy in a spreadsheet. The mistakes show up months later, as a number that is a little too high, a report that splits in two, or a parameter that is always empty. By then they are in every date you want to compare, which is why it pays to recognise each mistake by the pattern it leaves.
Symptoms and their usual causes
| What you see | Usual cause | Confirm by |
|---|---|---|
| Far more events per user than the action allows | Logged on every render, appearance or resume, or a listener registered twice | Performing the action once in DebugView and counting what arrives |
| Two events for one action, such as sign_up and signUp | A name changed between releases or platforms; event names are case-sensitive | Breaking the event down by app version and platform |
| Every screen_view doubled | Automatic screen reporting left on while the app also logs screen_view itself | Opening one screen in DebugView |
| Screen names that are class names, like a hosting controller or MainActivity | Automatic screen reporting in an app that uses one controller or activity for many screens | Checking firebase_screen_class in DebugView |
| A parameter missing from reports | It was never registered as a custom dimension | Admin → Custom definitions |
| "(not set)" for a registered parameter | Some code paths or older versions log the event without it | Breaking the values down by app version |
| Most values grouped under "(other)" | Unique values — IDs, timestamps, free text — used as a dimension | Counting how many distinct values the parameter has |
| An event that never appears | A reserved prefix (firebase_, google_, ga_), an invalid name, or a name longer than 40 characters | The SDK's debug logging while the event is sent |
The limits worth knowing
| Limit for app data | Value |
|---|---|
| Distinct event names | 500 per app user |
| Event name length | 40 characters |
| Parameters per event | 25 |
| Parameter name length | 40 characters |
| Parameter value length | 100 characters |
| User properties | 25 per property |
| User property name / value length | 24 / 36 characters |
Careful: Custom dimensions, key events and data filters take effect from the moment you create them. A parameter registered today will not fill in last month's reports, so decide on them before the data you care about arrives.
A review you can run in an afternoon
List events with counts and users
For the last 28 days, export event name, event count and total users. Sort by events per user and read the top of the list.
Look for near-duplicates
Sort the names alphabetically. Variants that differ by case, underscores or tense — share, shared, Share — are usually one action split in two.
Check key events against the system of record
Purchases against store transactions, sign-ups against accounts created. A key event far from its system of record is the one to fix first.
Break key events down by version and platform
A version where an event disappears or doubles dates the release that changed it.
Walk the main flow in DebugView
One device, one pass, counting every event and reading every parameter.
What goes wrong if you work around it
- Dividing one inflated event by another produces rates that look plausible and are not
- Merging split names in a spreadsheet every month fixes the chart, but never the data other tools read
- Renaming an event to tidy it up creates a third version and breaks every comparison across the change
- Putting user IDs or email addresses into parameters to make events unique creates high-cardinality data — and personal information such as email addresses must not be sent to Google Analytics at all
Rules that prevent most of it
- One naming convention — lowercase with underscores — written down and used on every platform
- Log where an action is confirmed, not where the interface appears
- Keep parameter values low-cardinality: categories, not identifiers
- Check every new event in DebugView before the release goes out
- Change what an event means by adding a new event, not by redefining an old one
How this looks in Appnaly
Appnaly lists each app's most frequent events and screens as GA4 reports them, without renaming or merging anything. That makes it a quick place to spot a split name — the misspelled variant tends to sit right next to the correct one — or an event whose volume jumped with a release. It does not guess that two names mean the same action, because a wrong guess would hide the mistake instead of showing it.