Keep an unfiltered view beside the filtered ones, test every new filter in a separate view before it touches your main reports, and write down why each filter exists. Filtered visits never come back.

A report that looks too quiet

Somebody added a filter to Analytics a couple of years ago. Perhaps it was to stop the fake referral visits that filled reports with strange website names, or to remove the office's own clicks.

It worked, and the reports looked cleaner. Nobody has looked at the filter since.

Filters do exactly what they are told. A pattern slightly too broad removes real visitors as well, with no warning and no record of what was dropped.

The business goes on making decisions from reports that are missing part of its audience.

Where the filters came from

The first does the most damage. It was standard advice against spam, and it quietly drops every page that runs on another domain: a booking system, a payment page, a second site the business owns.

How a filter removes too much

Most mistakes take one of a few forms.

An address range typed too broadly. An office filter meant for one internet address, written to match everything beginning with the same first few numbers, can exclude a large share of the provider's customers in your area.

A hostname list with only the main domain. Booking and payment systems that carry your tracking code often run on the supplier's domain, and those visits vanish.

A typo in a pattern. Filters use regular expressions, a shorthand for matching text, where one stray character changes the meaning.

A pipe symbol left at the end of a list, for example, matches every visit, so an exclude filter carrying one removes the lot.

And two include filters on one view must both match, so adding a second can empty the view entirely.

Filtered visits do not come back

This is what makes filter mistakes expensive.

A filter acts on visits as they are recorded. Whatever it excludes is never stored in that view, and no setting brings it back later.

Fixing a filter corrects the reports from that day forward. The months it was wrong stay wrong.

A worked example

A chiropractic clinic with two chiropractors, a massage therapist and online booking had two filters added by a marketing contractor about eighteen months ago.

One kept only visits to the clinic's own domain, to stop referral spam. The other excluded the front desk's internet address, typed as a range.

The booking pages run on the booking supplier's domain, with the clinic's tracking code added. From the day of the first filter, Analytics showed people clicking Book online and then nothing.

The owner concluded that online booking was barely used and nearly cancelled it. The booking system's own records said otherwise: a good share of new patients booked that way.

The fix added the booking domain to the hostname filter, replaced the range with the office's exact address, and set up an unfiltered view alongside.

The missing months could not be recovered. The clinic now compares the booking system's count with Analytics once a month.

Keep one view with no filters

Analytics lets one property have several views, each with its own filters. Google's own advice is to keep one with none at all.

That raw view includes the spam and the office visits. That is the point: it records everything, so any other view can be checked against it.

If a filtered view suddenly drops while the raw one does not, the filter is the cause, not the market.

A new view records only from the day it is created, so the sooner it exists, the more it can show.

Test a filter before it touches real data

New filters belong in a test view first: a copy of the main view where a mistake costs nothing.

Apply the filter there, wait a week, and compare the two views page by page. Anything missing that should not be shows up before the filter reaches reports anyone relies on.

For some filter types the filter screen can also preview the effect on recent data. Use it where it is offered, as a first check rather than proof.

Only after that does the filter go on the main view.

Write down why each filter exists

Give every filter a name that says what it does and why, such as excluding the office address after the move.

Add an annotation on the date it was applied, so a change in the graphs has its explanation beside it.

Keep a short list outside Analytics as well: each filter, its pattern, who added it and when to review it.

Office addresses change when the internet provider changes. A filter for an address the office no longer uses now excludes whoever was given it next.

Checking the filters you have

In the Admin section, each view lists its filters. Open them one at a time and ask what each pattern actually matches, not what it was meant to match.

Then compare Analytics with something counted elsewhere: bookings in the booking system, orders in the shop, form messages in the inbox. If Analytics shows fewer completions than really happened, suspect a filter first.

Filters live in a list at the account level and can be applied to several views, so changing one there changes it everywhere.

If the patterns mean nothing to you, an hour of a professional's time costs less than a guess.

The counter-case

Filters are not the enemy. An office that visits its own site all day, or a site flooded with referral spam, needs them to read the reports sensibly.

A small site with modest traffic may lose little to an imperfect office filter. The damage grows with how much the reports drive decisions.

And some missing numbers are not filters at all: tracking code absent from a page template, or a booking system never given the code.

Keep the filters, then, but keep a raw view beside them, test each new one first, and write down why it is there.

The check

  1. Open the filter list for every view.
  2. Read each pattern and note what it matches.
  3. Create an unfiltered view if none exists.
  4. Compare completions with booking or order records.
  5. Test new filters in a separate view first.
  6. Name each filter with its purpose and date.
  7. Annotate the day any filter changes.

Step three is the one to do today. A raw view records only from the day it exists, so every day without one is a day that can never be checked.

Counting what visitors do once they are being counted at all is covered in counting PDF downloads in Analytics.

Frequently asked questions

Can Analytics filters remove real visitors?

Yes. A pattern slightly too broad, a hostname list missing your booking domain or a typo in a regular expression can exclude real customers without any warning.

Can I recover visits a filter excluded?

No. A filter acts as visits are recorded, and whatever it excludes is never stored in that view. Fixing it corrects reports only from that day on.

What is an unfiltered view for?

It records everything, spam and office visits included, so any filtered view can be checked against it. It only records from the day it is created.

Why did my booking pages disappear?

Booking systems often run on the supplier's own domain. A filter that keeps only visits to your domain drops them, so completed bookings vanish from reports.

How should I test a new filter?

Apply it to a test view first, wait a week and compare page by page with the main view. Only then copy it to the reports you rely on.

Why write down what each filter does?

Because filters outlive the people who added them. A name, a date and an annotation explain later changes, and office internet addresses change over time.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Analytics numbers that look too low?

Send us access to your Analytics. We will read every filter and tell you what each one removes.

Start a Conversation