Native Internal Traffic Filtering That Goes Beyond IP Detection

[William Davis]

Miva Team and fellow developers,

After decades on the Miva platform and years of trying to maintain clean, reliable Google Analytics data, I wanted to propose a dream feature that could significantly improve analytical accuracy for merchants who, like us, use Miva extensively both on the frontend and backend.

---

The Problem: Internal Use Contaminates Analytics


Miva is a powerful hosted solution, but because both the admin interface and storefront operate under the same domain (and in some cases, subdirectories), internal traffic often pollutes analytics data.

We routinely browse the site for:

• Fulfilling orders
• Customer service QA
• Image previews
• Testing promotions and pricing logic

All of this activity looks like real customer behavior unless we jump through significant hoops.

---

Why Simple IP-Based Filters Are Not Enough


While many analytics tools (including GA4) allow filtering by IP address, that method is completely unreliable in modern, real-world merchant environments because:

• Many team members work from home or remotely, often with dynamic IPs that change without notice.
• Some employees use mobile hotspots or switch networks throughout the day.
• We can't justify maintaining a list of 20+ staff IPs that rotate constantly and silently.

In short: IP detection fails in dynamic or remote work environments, especially when using ISPs that rotate IPs regularly or during power cycles.

---

Proposed Dream Feature: Internal Traffic Suppression Layer


We’d love to see a native solution that helps suppress or label internal traffic more reliably. Some ideas:

1. Internal Cookie/Session Flag
   • A Miva UI toggle in the admin that lets staff “mark themselves” as internal.
   • This sets a cookie or JS flag that third-party analytics (like GTM or GA4) can reference.
   • GTM tags could then be configured to block firing based on this flag.
2. Admin Auto-Tagging
   • When logged into the Miva admin, automatically inject a flag (e.g., window.isInternalUser = true) into all storefront sessions on that browser.
   • This would optionally apply even outside /mm5/, when staff view the storefront.
3. JavaScript Opt-Out Link
   • An internal-use-only link or button that toggles a persistent cookie like internal_user=true, allowing GTM or other scripts to ignore that device.
4. Option to Load Storefront Without Tracking
   • A special query string like ?internal-preview=true or session trigger to disable GA scripts entirely when browsing for QA or customer support.

---

Bonus: Help Us Help Ourselves


Even exposing a hook or template variable like g.internal_user or g.is_miva_admin_user would allow us to inject conditional JavaScript or GTM filters without complicated workarounds.

---

Why This Matters


This is not a "nice-to-have" for large merchants or analytics-driven teams, it’s essential. Accurate GA data guides ad spend, conversion optimization, and product decisions. Without a reliable way to filter internal use, we’re constantly scrubbing false positives that never should’ve been tracked in the first place.

---

Would love to hear how others handle this, or if any native features or best practices already exist that we've missed.

Thanks again for continuing to support a platform we’ve trusted for over 25 years.

[ILoveHostasaurus]

Options 1 through 3 won't work because Google only sets their own cookies, and only honors their own cookies. You cannot set a cookie on your site side that Google would see or use.

You can potentially create an optional GA4 custom dimension, appended to the GA4 cookie, but this would only allow for filtering out of staff data in reports, it would not stop it from being collected, and would be complicated since you'd have to ensure the modified cookie is set on staff computers and remember to filter it every time you build a report.

Option 4 would be ideal, and is already possible if you wrap your GA4 code in a conditional that only outputs it if the user does not have a cookie named mm5-admin-browserid. Users who have logged into the store admin in the prior 90 days would have such a cookie due to the email-based browser validation feature.

[Rick Wilson]

Also GA does not track in admin sessions, only the sessions of your staff who shop on the site.

[Bruce - PhosphorMedia]

Also,

We routinely browse the site for:

• Fulfilling orders

I don't know why you wouldn't want these types of orders added to your GA.

You *might* want to have these allocated seperately, and that should be relatively easy by adding a 'landing' page that is tracked as a seperate dimension in GA and have these types of processes start on that page.

[Brennan]

I curious to how big of an issue this is for Merchants you've worked with. I have not heard it come up before.

But to Davids point, if internal employees used Shop As Customer to view to store, Miva sets a Cookie to identify them. It would be fairly easy via template code to read in that cookie, and suppress/hide all GA code from firing. This sounds like it may be the easiest solution.

Happy to provide a code sample if needed.

[William Davis]

We always review any admin updates to confirm frontend is correct. We also routinely perform search on the frontend -which is how we know how bad our existing stock search solution is). We probably spend more time on the frontend than on the backend.

[captainboom]

Good thread, and is something we could use as well. We're often on our store pages while helping a customer on the phone, even without being in the admin.