# Product analytics missing events: why they disappear and how to find them on Mac

> Product analytics missing events usually means a delay, a hidden report, a blocked call or a schema rule. Here is how to check each one on your Mac.

URL: https://www.lazur.app/for/product-managers/problems/product-analytics-missing-events-tracking
Updated: 2026-11-08

Product analytics missing events usually means the event is late, hidden, blocked, or rejected before it reaches your tool. Often the code is fine, and the data sits where you are not looking. This page shows how to sort each case on your Mac, what a gap costs your team, and which checks need no new software.

## Quick answer

- Check the clock first. Amplitude says new items can take about 24 hours to appear. A third-party guide says GA4 can take 24 to 48 hours.
- Then check hidden views. Mixpanel hides events that have not fired in 30 days from report dropdowns, but the raw data keeps them.
- Use a live view to see if the event leaves the app: GA4 DebugView, Mixpanel debug, or Safari Web Inspector on your Mac.
- Bring engineering in once you know the call leaves the app and gets dropped, rejected, or blocked.
- Keep a short event spec in Notion or Google Sheets so the next gap is easy to spot.

## What missing analytics events costs you

- **A bad bet on the roadmap.** If a feature looks like it failed, you may cut it. If it looks like it succeeded, you may build more on top of it. A missing event can push a decision in either direction. Teams rarely trace the decision back to tracking. Say the gap out loud before you act on the chart.
- **Experiments that read wrong.** A test with missing exposure or goal events can show a winner that did not win. It can also hide one that did. Check that both the exposure and the goal events fire in every variant before you call a result. If one arm loses more events than the other, the comparison is unfair.
- **Hours lost in the wrong place.** Teams often spend the first day arguing about the number. Engineers then chase code that works, while the real gap sits in the reporting setup. A short check of the live view separates the two problems before anyone opens a ticket.
- **Trust with engineering.** Each vague report gets sent back with questions. Engineers learn that analytics bugs take long to pin down, so they reply later. A clear note with the event name, the state, and the evidence protects both sides of the work.
- **Silent gaps on mobile.** Mobile data can arrive late or in batches. A gap on one day can look like a drop on the next. If you only check the web view, you may miss the problem for longer. Compare each platform separately when you review a release.

## Why it happens

1. **The SDK batches or drops the event.** Mobile SDKs queue events before they send them. Amplitude's mobile SDKs batch by default at 30 seconds or 30 events. Mixpanel's iOS SDK flushes when the app goes to the background or every 60 seconds. If the user closes the app before the next flush, the queued events may not go out in time. Mixpanel recommends calling flush before key moments such as sign-up.
2. **The schema rejects unplanned events.** A tracking plan can block events you did not plan for. Amplitude says that if the tracking plan rejects unplanned events, it does not store the event or its properties. A typo in a new event name is one way this happens. Nothing in your app warns you when it does.
3. **Ad blockers and consent choices.** Browsers and users can stop analytics calls before they leave the page. Analytics Mania lists ad blockers and consent mode with analytics storage denied as causes of missing GA4 events. Google's DebugView help adds that events stay hidden in debug mode when the user has not consented to Analytics cookies.
4. **An instrumentation limit or a wrong host.** Amplitude says over-limit event types and properties cannot be queried. New events can run into its instrumentation limit. Mixpanel says events sent to the wrong data-residency host are not ingested. Both look like a silent gap from the report side, even though the app sent something.
5. **The report hides the event.** Some tools hide events from menus without deleting them. Mixpanel can hide events in Lexicon. Its report dropdowns hide events that have not fired in the last 30 days. Event properties unused for 28 days are hidden the same way. The data is still there, but the dropdown does not show it.
6. **Renamed rules and long names.** Analytics Mania lists Modify event rules and event names over 40 characters as causes of missing GA4 events. A rule that renames an event can make the name you expect hard to find. Check the rule list before you change the code, so you do not fix the wrong thing.
7. **Filters and processing delay.** Active Internal or Developer traffic filters in GA4 can remove test traffic from reports. Data can also take 24 to 48 hours to appear, according to a third-party guide. These two causes look the same on the day you ship. Check the filter status before you assume the event is gone.

## How to fix it

- **Check the live view before anything else.** Turn on debug mode, then trigger the action on a test account. In GA4, debug_mode must be set to true for the test session, because Google says setting it to false does not turn debug mode off. Watch DebugView's Seconds stream, which shows the last 60 seconds. If the event appears there, the app sends it.
- **Wait out the normal delay.** Give new events time before you decide they are gone. Amplitude says new items can take about 24 hours to appear. A third-party guide says 24 to 48 hours is normal for GA4. Write down the time you triggered the event, so you can compare it with the report later.
- **Trace the request in Safari.** Turn on Show Develop menu in Safari's Advanced settings. Open Develop > Show Web Inspector, or press ⌥⌘I. Open the Network tab, trigger the action, and filter by the vendor name. A request that never appears means the page did not send it. Apple's guide also lists a JavaScript Console in the same Develop menu.
- **Inspect phone or desktop traffic with Proxyman.** Proxyman is a native macOS app that captures and decrypts HTTP(S) requests. Its site says it is free to start, with no credit card needed. Use it on your own test devices to see whether a mobile event leaves the phone. Read its setup steps before you turn on HTTPS decryption, since that needs extra setup.
- **Use Mixpanel's own recovery steps.** Mixpanel's debugging guide covers Lexicon and the event dropdowns. Before you assume an event is gone, fire it once. Mixpanel says firing one instance, or typing the exact name in the dropdown search, brings a hidden event back. Then check Lexicon for a hidden status.
- **Ask for a flush before key moments.** Mixpanel recommends calling flush manually before key moments such as sign-up or app shutdown. Ask engineering to add that call to the sign-up path and the close path. Then compare the mobile count again after one test session on a real device.
- **Check consent and traffic filters.** Look at your consent banner setting and the GA4 traffic filters. If consent is denied, DebugView hides events for that user. If an Internal or Developer filter is active, your test traffic can vanish from reports. Change the filter only if your team agrees.
- **Trim unused event types on purpose.** If you hit an instrumentation limit, delete the event types you no longer use. Amplitude says hidden or blocked items still count toward the limit, but deleted items do not. Hiding an event does not free room. Keep a list of what you delete and why.
- **Keep names short and consistent.** Long event names can cause misses in GA4. Analytics Mania lists names over 40 characters as one cause. Use a simple pattern such as object_action, and write it in a shared spec. Check each renamed event in the live view before you trust the report.
- **Test in a clean browser and on a phone.** Ad blockers and privacy extensions can stop calls before they leave the page. Test once in a Safari window with content blockers turned off, then compare with your normal setup. Repeat the test on a phone for any event that fires in the app. A gap on one device only points to that device.

## What a missing event looks like

A missing event shows up as a flat line where you expected a bump. A feature launches, people click the button, and the chart stays at zero. Or the web numbers look normal while your iOS app sends nothing. You usually notice when someone asks why the funnel dropped.

Missing events hurt in a quiet way. Nobody gets an error. The number is just lower than it should be, and people believe it. That is why the gap can run for weeks before anyone checks. Before you blame the code, sort the problem into one bucket: late, hidden, or never sent.

![Person at a laptop checking product analytics for missing events](https://images.lazur.app/content-images/problem/product-analytics-missing-events-tracking/product-analytics-missing-events-1-052e70.jpg)

## How to tell late, hidden, and never sent events apart

Start with the clock. Analytics tools take time to process data. Amplitude says new items can take about 24 hours to appear. A third-party guide, Analytics Mania, says waiting 24 to 48 hours for GA4 events is normal. If your event is newer than that window, wait before you dig.

1. Late: the event was sent, and the tool has not processed it yet.
2. Hidden: the event arrives, but the report, dropdown, or filter does not show it.
3. Never sent: the app or browser never makes the call, or something blocks the call.

Each state has its own first check. Late needs patience and a time check. Hidden needs the raw data or the live debug view. Never sent needs a look at the network request while you trigger the action on a test device.

## A worked example: a signup event that stops at a release

Say your team ships a new signup flow on a Tuesday. By Wednesday the dashboard shows signups near zero. The account table in your database keeps growing. That gap is your clue. The app creates accounts, so the app works. The event is the part that broke.

Next, open the live view and trigger signup on a test account. In GA4 that is DebugView. In Mixpanel, use the debug view in your test session. If the event shows up live but not in the report, you have a hidden or delayed problem. If it never shows up, the app is not sending it.

In a case like this, the release may have renamed the event. An event called signup_complete might have become sign_up_complete. Your saved report still filters on the old name, so it shows zero. That is a reporting fix, but you only know it after you see the new name in the live view.

## Why the same gap looks different in each tool

Each tool hides gaps in a different place. The table below shows where to look first. Use it as a starting map, then check the vendor's docs for your plan and setup.

| Tool | Look here first | A blank view often means |
| --- | --- | --- |
| Google Analytics 4 | DebugView, with debug_mode set to true | Consent denied, an active internal filter, or a name over 40 characters |
| Mixpanel | Lexicon and the debug view | Event hidden in Lexicon, no fire in 30 days, or a wrong data-residency host |
| Amplitude | Event list and the tracking plan | The schema rejected the event, or the instrumentation limit was reached |
| Mobile SDK | Flush settings and a test device | Events still queued when the app went to the background or closed |

_First places to look, based on vendor docs and one third-party guide._

## What a silent gap costs your team

Start with time. A 2022 survey from Monte Carlo found that data professionals spend 40% of their time evaluating or checking data quality. Monte Carlo commissioned the survey, and it covers data problems in general, not only events. Treat it as a sign of the problem, not a measure of your team.

- **40%** of data professionals' time goes to evaluating or checking data quality, per a 2022 vendor survey ([source](https://montecarlo.ai/blog-2022-data-quality-survey))
- **75%** of survey respondents take four or more hours to detect a data quality incident ([source](https://montecarlo.ai/blog-2022-data-quality-survey))
- **3%** of companies' data meets basic quality standards, per a 2017 Harvard Business Review headline ([source](https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards))
- **30 to 50%** of users may lose events with client-side tracking, per Mixpanel's debugging guide ([source](https://docs.mixpanel.com/docs/tracking-best-practices/debugging))

Treat the wider figures as warnings, not measurements of your app. None of these surveys measured missing analytics events directly. Your own live check tells you more than any industry average does.

## Mistakes that waste the most time

A few habits cause most of the detours. Teams change a report before they check the code. They trust a dropdown that hides older events. They test once on the web and call the job done. Avoid these mistakes early.

- Renaming a report filter before you confirm what the app sends. You hide the real gap behind a new label.
- Trusting a dropdown without checking Lexicon or the raw data. Mixpanel hides events that have not fired in the last 30 days.
- Testing in a browser with ad blockers or denied consent. Calls can stop before they leave the page.
- Testing only on the web when the gap is on iOS or Android. Mobile SDKs batch events and send them later.
- Deleting event types to free room without a list. Amplitude says deleted items stop counting toward its limit, but hidden or blocked ones still count.
- Sending engineering a message that says events are broken. Name the event, the state, and the test you ran.

## Mac tools to see what your app sends

You can see the request without buying anything. Safari has a built-in inspector. Go to Safari > Preferences, click Advanced, and tick Show Develop menu in menu bar. Apple's guide uses that path. Newer macOS versions may label the window Settings, so look for the Advanced tab.

Then go to Develop > Show Web Inspector, or press ⌥⌘I. Open the Network tab. Trigger the action, then type the vendor name in the filter box, such as mixpanel, collect, or amplitude. If no request appears, the page never sent the call. If a request appears but fails, check its status and response.

For phone apps or desktop apps, Proxyman is a native macOS app that captures and decrypts HTTP(S) requests. Its site says it is free to start, with no credit card needed. Decrypting HTTPS needs extra setup, so read its guide before you start. Test only on devices and traffic you are allowed to inspect.

> **Keep customer data off the screen:** Lazur sees your screen only while you hold the shortcut. Audio and the screenshot go to AI providers to answer, and they are not stored. If the page shows customer records, follow your employer's rules before you share it or ask about it.

## Edge cases that catch experienced teams

Consent choices can hide events for some users. Google's DebugView help says events stay hidden in debug mode when consent mode is set and the user has not agreed to Analytics cookies. Your numbers can drop after a banner change, even though the code did not change.

Mobile apps add a delay of their own. Mixpanel's iOS SDK flushes queued events when the app goes to the background or every 60 seconds. Its docs recommend a manual flush before key moments such as sign-up or app shutdown. Ask engineering to confirm that call exists on your sign-up path.

Old events can miss the window too. Mixpanel says events older than 5 days, sent to the /track endpoint, are not ingested. A phone that stays offline for a week may send its queue too late to count. Check the event timestamps when you see a sudden drop after a long offline period.

Names can cause misses too. Analytics Mania lists event names over 40 characters as one cause of missing GA4 events. Keep names short and consistent. A pattern such as object_action is easy to scan in a shared spec, and easy to search in a report.

## When to bring in engineering

Bring engineering in when you can show two things. The event fires in the live view or the network request, and the report still shows a gap. Then the question is about the SDK, the schema, the project setup, or a rule. Those are engineering areas, and they can act on them.

Make the note short. Include the event name, the device and app version, the test time, the state you think it is in, and a screenshot of the live view. Leave out customer data. A note like that is easier to act on than a message that says events are broken.

## A short weekly event check

Once a week, run a short check on the events that drive your main decisions. You do not need a full audit. Keep the routine small enough that you do it every week, even in a busy release.

![Laptop screen with a data dashboard and charts, the kind product teams check for missing events](https://images.lazur.app/content-images/problem/product-analytics-missing-events-tracking/product-analytics-missing-events-2-5ab938.jpg)

1. Pick the events that drive your main decision for the month.
2. Fire each one on a test account and watch the live view.
3. Compare counts with the database or payment system. A gap that keeps growing is a signal.
4. Check Lexicon for any event that has gone quiet for 30 days before you assume it is gone.
5. Write the result in one shared note so the next check starts from the last one.

## Privacy and regulated data

Events can carry personal data. If your product handles health, money, or legal records, follow your employer's rules on that data. Do not paste raw customer rows into a chat tool to debug them. Use event names, counts, and timestamps instead. Those are usually enough to find the gap.

> **How strong is this advice?:** The fixes here come from vendor documentation and one third-party guide. No controlled study tested them. Treat each one as a first check, not as proof that it works in your setup.

## What to do next

![Product team meeting in an office, discussing product analytics and missing events](https://images.lazur.app/content-images/problem/product-analytics-missing-events-tracking/product-analytics-missing-events-3-b1f8a3.jpg)

Pick one missing event this week. Run the clock check, then the live view, then the network trace. Write down which state it falls into. That one note will teach you more about your tracking than a long audit.

Then set a reminder for the day after your next release. Ask Lazur to set it, or add it yourself in Apple Reminders. The check takes a few minutes when the routine stays short.

## With Lazur

Lazur is a voice assistant for the Mac that lives in the notch. Hold ⌥ ⌘ and ask; it sees your screen, answers out loud, points at buttons and walks you through apps. Hold fn to dictate. Free for 3 days, then $18/month: https://www.lazur.app/download

- “Where is the Develop menu?”: You see the exact menu to open, and you still open it yourself. (Points at it)
- “Where is DebugView in my GA4 property?”: Lazur circles the DebugView link in the menu and labels it. You still click it yourself.
- “What does Hidden mean on this Mixpanel Lexicon row?”: Lazur explains the status out loud and what it changes for your reports.
- “Walk me through turning on the Develop menu in Safari.”: Lazur guides you one click at a time and waits for each click before it goes on.
- “Hold fn and dictate the bug note into Slack.”: Your words land at the cursor as clean text. Add vendor terms to your personal dictionary so they are spelled right.
- “Draft a note to engineering about the signup event.”: Lazur drafts the note with the event name, device, and test time. You edit it before you send it.
- “Research how consent mode affects GA4 event data.”: Lazur runs the search in its own Chrome tabs and returns a summary and report. Check the sources it lists.
- “Remind me Friday to check the signup event.”: Lazur adds the reminder to Apple Reminders for you to act on.

## A plan you can start this week

- **Day 1: Name the event and its state.** Write the event name, the screen where it fires, and the device. Note when it was last seen. Decide whether it looks late, hidden, or never sent, based on the clock so far.
- **Day 2: Run the live view.** Trigger the action on a test account with debug mode on. In GA4 use DebugView, and watch the Seconds stream for the last 60 seconds. In Mixpanel, use the debug view in your test session.
- **Day 3: Trace the network call.** Turn on Show Develop menu in Safari's Advanced settings, then open Develop > Show Web Inspector with ⌥⌘I. Filter the Network tab by the vendor name and repeat the action on the page.
- **Day 4: Check consent and filters.** Look at the consent banner setting and any internal traffic filters. A denied consent or an active filter can hide an event even when the app fires it correctly.
- **Day 5: Write the finding and ask.** Post one short note in Slack or Linear with the state, the evidence, and the next check. Ask engineering only about the part you could not see from outside the app.

## FAQ

### Why are my product analytics events missing even though the code is live?

Live code can still send nothing. A consent banner can block calls, an SDK may not flush, or a tracking plan may reject the event. Check the live view first. If the event shows there, the gap is in reporting. If it does not, the app is not sending it.

### How long should I wait before I decide an event is missing?

Amplitude says new items can take about 24 hours to appear. A third-party guide says 24 to 48 hours is normal for GA4 events. Wait that long, then check the live view and the raw data before you raise the alarm.

### Does a missing event in one tool mean it is missing everywhere?

No. Each tool has its own rules. Mixpanel can hide an event from dropdowns while keeping it in raw data. Amplitude can reject an event that GA4 accepts. Check each tool on its own.

### Can I see the event on my Mac without installing anything?

Yes, for web apps. Turn on Safari's Develop menu, open Show Web Inspector with ⌥⌘I, and watch the Network tab. Phone apps need extra setup, and Proxyman is one option to read about first.

### Should I delete events that never show up?

Not yet. Confirm with your team that the event is unused. Amplitude says deleted items stop counting toward its limit, so deletion has a real effect. Write down what you removed and why.

### Why does GA4 show my event under a different name?

A Modify event rule can rename it. Analytics Mania also lists event names over 40 characters as a cause of missing events. Check your rules, shorten long names, and confirm the new name in DebugView.

### Does Lazur check my analytics account for me?

No. Lazur sees your screen only while you hold the shortcut. It does not click buttons or operate other apps for you. It can point at the right menu, explain a status out loud, and walk you through the steps one click at a time.

### Is this only a problem for product managers?

No. Engineers, designers, and marketers see it too. Product managers often own the question of whether the number is right, so the first check often lands on your desk.

## Sources

1. [Missing or unexpected data](https://amplitude.com/docs/faq/missing-data), Amplitude, checked 2026-11-08
2. [Debugging](https://docs.mixpanel.com/docs/tracking-best-practices/debugging), Mixpanel, checked 2026-11-08
3. [Google Analytics Help: DebugView and debug mode](https://support.google.com/analytics/answer/7201382), Google, checked 2026-11-08
4. [[Solved] Google Analytics 4 Events Not Showing Up in Reports?](https://www.analyticsmania.com/post/google-analytics-4-events-not-showing-up-in-reports/), Analytics Mania, checked 2026-11-08
5. [Data Engineers Spend Two Days Per Week Firefighting Bad Data](https://montecarlo.ai/blog-2022-data-quality-survey), Monte Carlo, checked 2026-11-08
6. [Only 3% of Companies' Data Meets Basic Quality Standards](https://hbr.org/2017/09/only-3-of-companies-data-meets-basic-quality-standards), Harvard Business Review, checked 2026-11-08
7. [Safari Developer Help: Develop menu](https://support.apple.com/en-ie/guide/safari-developer/dev39df999c1/mac), Apple, checked 2026-11-08
8. [Proxyman: HTTP debugging proxy for macOS](https://proxyman.com/), Proxyman, checked 2026-11-08