By definition, page views on any given site should be always be higher than the number of visits. However, myself and some other people have came across an anomaly in Google Analytics where visits are the one that is higher.
I don’t have a solution to offer yet, however I do have an explanation…
This is related to sub profiles and events. If you have a parent profile with events and make sub profiles from it, you will most likely run into this issue (until it is solved by Google). I’ll first explain events and sub profiles. If you’re already familiar, feel free to skip the next two sections.
Events
Events are not associated with page views at all. That was actually a perk of using an event to keep track of non page view type information. In the past, we had to use trackPageview() to reports that didn’t occur ‘naturally’. The drawback of that is that it created fake page views which inflated our page view numbers. Using events, that information is kept separate from page views, allowing us to gather useful data and still trust our page view figures.
Sub Profiles
In Google Analytics, you have a unique ID for every parent profile you have a unique Web Property ID and a parent profile for that web property. You can then create other profiles for that web property and filter out various data. The filters usually take out traffic to certain URL’s, certain hostnames, etc etc. This is useful when you want to view only a subset of data or want to see an abstraction of the data.
Ohnoes!
The anomaly occurs because filters in sub profiles won’t also filter events. So what? The events are associated with visits. Since events aren’t filtered, the visits come with them. If your parent profile has 562k visits with events (random number) then your sub profile will automatically have 562k visits even if you filtered out ALL traffic data. That’s exactly what happened in the screenshot from the first paragraph.
Hopefully that saves some head scratching out there. I’ll post again if I find a solution or if I notice that Google takes action on it.
George Gonzalez
Ray Dollete
dpchoung
Dieter said
no news regarding this ?
Spikey said
This sounds like the exact same problem I’m having. I have about 50 subprofiles on my main profile, and one of the subprofiles has the ecommerce script. Since the launch of the ecommerce script, I noticed zero page visits dripping in on every subprofile, except for the ecommerce profile. All these ghost visits seemed to have an ecommerce success of 100%. That means every ghost visit saw the page with the ecommerce script, which can’t be a coincidence.
It probably has to do with the transaction variable, which is related to visits instead of clickstream data; transactions are added to every subprofile (even if ecommerce is switched off on those subprofiles), along with the visits that, impossible to filter in any way but with afterwards with advanced segments (with the known tricks of ‘more than zero pageviews’, ‘hostname contains http://www.yoursite.com‘ etc). The main profile and the ecommerce subprofile seem to remain unaffected, because those visits are already counted there anyway.
Curiously, two of my profiles with certain advanced filters don’t have the ghost visits. This is hopeful, I’ll look into that as soon as I can.
Spikey said
For ecommerce ghost visits to not enter subprofiles, you need to filter your profiles differently; remove your regular subprofile filter and replace them with these two:
For a non-ecommerce subprofile http://www.yoursite.com/whatever
Filter 1:
Filtername: Whatever
Filtertype: Custom filter
select ‘Advanced’
Field A –> Extract A: -Request URL- ^/whatever
Field B -> Extract B: — (leave empty)
Output to -> Constructor: -Custom Field 1- whatever
Field A required: Y
Field B required: N
Override Output Field: Y
Case Sensitive: N
Filter 2:
Filtername: Whatever (extract)
Filtertype: Custom filters
select ‘Include’
Filter Field -Custom Field 1-
Filter Pattern: whatever
Case Sensitive: N
This may also filter subprofile ghostvisits for events, but I can’t check for certain since I don’t use them.
Nathan Ziarek said
I have a script that automatically tags all with onclick functions to check and see if they need a manual “trackPageview” / “trackEvent” call. Right after I installed this, my sub profiles started getting ridiculous data — 1,200 visits with 2 pageviews. I stripped everything from the code, leaving it just as Google recommends. Still saw these hugely inflated numbers.
At the same time as I was working on that, we were also working on adding transaction (ecommerce) data to Google Analytics. I never even considered it, since those were pretty much just normal pageviews and the directory filter should have extracted them.
But … after our ecommerce testing was done, I turned on ecommerce in a “good data” profile and it instantly had all the test data we’d run through. Since GA doesn’t go back and re-process old data, this clued me in to the fact that Spikey might be right. And if each transaction + each product call results in a new “visit” to the subprofile, that’d explain how these numbers shoot up so fast.
Experimenting now…will let you know how it goes.
Thanks Spikey!
Spikey said
Dear Nathan,
You can actually exclude ghost visits in subprofiles resulting from ecommerce tracking in irrelevant OTHER subprofiles by using the filter ‘exclude Ecommerce ID’ or something in that fashion for those profiles, and then entering .* as a regular expression to exclude ALL Ecommerce IDs. This should stop including the ecommerce transaction data from entering a subprofile.
Regards,
Spikey
Nathan Ziarek said
@Spikey — Thought about that and had experimented with it pretty thoroughly. It blocked out maybe 90% of the visits, but some still got through. To experiment, I first blocked all hostnames with .*, then worked through each of the ecommerce metrics to combine and see which would block out all of the incoming ghost visits. I never found that did. It is tough to tell if you solution is working or not, but my initial assessment is that it is much better than anything I’d come up with. It’s great having more pageviews than visitors!
Spikey said
Hostname was my initial intuition as well, but never was able to block the ghost visits with it, probably because it adds only transaction data + a visit for each transaction, but no other data like pageviews and hostname, and hence, you’re bound to be unable to use regular filters to block them out.