You’re looking at analytics that “feels wrong” (traffic dropped, conversions doubled, events disappeared), and you need a calm way to decide what to check next—especially from a phone.

Compass and chart tiles representing analytics decision framework

This guide is a decision framework: if you see X, then do Y, with concrete examples using Firefox on Android.

One rule: you’re not trying to prove a theory. You’re trying to narrow the cause.

Step 0: Clarify what “wrong” means (so you don’t chase noise)

Before touching settings or tags, pin down the symptom in one sentence. Different symptoms point to different root causes.

  • If it’s a sudden step-change (e.g., conversions drop 40% exactly on Tuesday): suspect deployment, consent changes, tag loading failures, or routing changes.
  • If it’s a gradual drift (e.g., week-over-week decline): suspect traffic mix, SEO changes, seasonality, or campaign pacing.
  • If it’s “only on mobile”: suspect mobile consent UX, app webviews, ITP/ETP differences, or performance/timeouts.
  • If it’s “only some pages”: suspect SPA routing, conditional tag firing, or template-specific breakage.

Now pick one affected journey (example: “landing page → product → checkout → purchase”). You’ll test that journey end-to-end.

If events are missing entirely, then first check: “Is anything loading?”

Abstract network flow to a server for request checks

When you see zero events from a device/session that should definitely produce them, start with basic page and network reality.

  • If the site doesn’t fully load or feels stuck, then suspect blocked scripts, CSP errors, or timeouts. Try a different network (Wi‑Fi vs cellular) to rule out connectivity.
  • If the site loads but analytics is dead, then check whether tracking requests fire at all.

On Firefox for Android, you can still do a lightweight check without full desktop DevTools:

  • Open the page in Firefox.
  • Open the site menu and try “Desktop site” (this sometimes changes which scripts load or how consent banners behave).
  • Reload once after switching.

Example: Purchases show in your backend, but analytics shows 0 purchases since a release. If even pageviews are missing on the affected pages, treat it as “tag not loading” before debating attribution or filters.

If events show up, but numbers are “too low,” then check consent and Firefox protections

Shield and cookie disk representing privacy and consent checks

This is the most common “it worked yesterday” situation: tracking is partially blocked, or consent is preventing storage/event dispatch.

  • If your site uses a consent banner and you can’t reproduce tracking until you accept, then you may be counting “consented-only” users (or your banner isn’t persisting consent properly on mobile).
  • If it’s lower specifically in Firefox, then Enhanced Tracking Protection (ETP) can reduce third-party tracking calls depending on setup.

In Firefox on Android, do a targeted test:

  • If you suspect blocking, then temporarily set protections to a less strict mode for that one site (site-specific protections), reload, and retry the same journey.
  • If numbers jump back, then the issue is compatibility with protections (often third-party cookies or blocked endpoints).
  • If nothing changes, then it’s probably not ETP—move on to routing, caching, or tag logic.

Example: Add-to-cart events appear in Chrome Android but not in Firefox Android. If lowering protections restores events, you likely need first-party measurement, server-side tagging, or different endpoint/consent behavior.

If events duplicate or conversions inflate, then check double-firing and “back button” behavior

Inflated numbers usually come from the same action being counted twice, not from “extra customers.”

  • If a single tap counts two events, then suspect two tags firing (e.g., both a direct tag and a container tag), or a listener bound twice.
  • If duplicates happen when navigating back/forward, then suspect SPA route changes firing page_view repeatedly, or bfcache/back-forward cache quirks.
  • If duplicates happen after refresh, then suspect “on load” events that should be “on submit/success.”

A practical mobile reproduction pattern:

  • Do the action once (e.g., submit lead form).
  • Use the back button to return and wait 2–3 seconds.
  • Go forward again, or refresh.
  • If counts jump without a real second action, treat it as double-firing or mis-scoped triggers.

Single-sentence sanity check: if your conversion rate exceeds what’s plausible operationally, it’s almost always instrumentation.

If “some pages track, some don’t,” then look for routing and template differences

Branching route cards representing template and routing differences

Partial breakage is often a clue that your tracking code is not on every template, or your app’s routing doesn’t trigger the same events everywhere.

  • If only new pages fail, then the new template may be missing the container/script include.
  • If only the checkout fails, then it may be on a different domain/subdomain, a different app, or embedded in a webview/iframe.
  • If only SPA navigations fail (first pageview tracks, internal nav doesn’t), then you likely need virtual pageview events on route change.

Example: Product page events work, but category pages don’t. If categories were rebuilt in a different framework or served from a different origin, your “global” tag might not actually be global.

If attribution looks wrong, then test “link hygiene” before blaming the model

Attribution issues often come from how links are formed on mobile (redirects, missing UTMs, in-app browsers stripping referrers), not from the analytics platform being mysterious.

  • If paid traffic is landing as “direct”, then check whether final landing URLs keep UTMs through redirects.
  • If social/referral disappears, then check whether the journey starts in an in-app browser and ends in Firefox (handoff can drop referrer).
  • If campaigns split into many near-duplicates, then your UTM casing or parameters are inconsistent.

A quick Firefox-on-Android test:

  • Paste the exact ad URL into Firefox.
  • Watch whether it redirects once or multiple times.
  • Confirm the final URL still contains the expected parameters.

If the parameters vanish, the analytics tool is usually reporting correctly—it just never received the campaign info.

Checklist: a 10-minute “if/then” run you can repeat every time

  • If the issue is a step-change, then test one journey end-to-end on your phone immediately (before digging into dashboards).
  • If nothing tracks, then switch to Desktop site and reload; confirm the page is actually loading normally.
  • If tracking is low in Firefox, then temporarily relax site-specific protections and retest.
  • If counts are high, then try back/forward and refresh to see whether events duplicate without real actions.
  • If only some pages fail, then compare templates/paths: new vs old pages, checkout vs marketing site, SPA vs non-SPA.
  • If attribution is weird, then paste the campaign URL into Firefox and verify UTMs survive redirects.
  • If results differ by browser, then record exactly what differed (protections, consent state, redirects) before changing anything.

Takeaway: aim for one clear cause, not a perfect explanation

This framework works because each if/then test narrows the problem to a category: loading, protections/consent, double-firing, routing/templates, or link hygiene.

Once you can reproduce the symptom reliably on Firefox for Android, fixing it becomes a normal engineering task instead of a guessing game.