Welcome to the Q&A Forum

David,

No it would not, UNLESS the user doesn't click on any more links on the homepage. Really, a bounce is calculated based on whether or not there was more than one pageview of a site in a single session, not whether or not the user left. GA (without doing some custom work) doesn't even know the user has clicked on an external link.

Edit: My apologies. I misread your question. I thought you were saying that the banner click was a click off to another site. Still, the answer stands.

As long as the GA snippet exists on the 2nd page, it will trigger a pageview and look like the 2nd pageview in the session, meaning it's not a bounce.

I wouldn't expect UA to be the catalyst for having this behavior changed in the future (based on what I know about how Google separates data amongst property/profile - those concepts aren't changing in UA).

This isn't possible, and I've heard no whispers of it being in the works.

No. Provided you have the code on every page and it's properly firing, the disparity should not be very high at all.

Perhaps you have filters in your GA profile that are blocking traffic? Like, say, an internal office IP filter?

Another thing to consider:

• If the user clicks 2 links in the email, that will register with Silver Pop as 2 clicks, but in GA as just 1 visit (as long as the clicks took place within 30 minutes).

I'm not sure what your email template looks like, but if it's a design that lends itself to multiple clicks, this could account for the disparity?

I would be a little wary of combining hit-level dimensions (page) with session-level metrics (conversion rate). A better option would be to look at a hit-level metric like Page Value. More info here in this great post by Avinash:

http://www.kaushik.net/avinash/hits-sessions-metrics-dimensions-web-analytics/

Yeah, I'm about 99% certain that this is not possible. Filters are essentially evaluated at the hit-level. There's no way to exclude a full session according to one hit characteristic.

Usually the question is asked the other way around (multiple AdWords one GA), so I had to do some research. Seems to me that this may not actually be possible.

Diego,

It's rather simplistic, really. GA will look at all conversions that had the direct channel within the user's conversion path. For any that has at least one occurrence of 'direct', it will apply the full value of that conversion to the tally of "assisted conversion value". It will only apply that full value once, say, if direct appears 10 times within that single conversions path.

direct -> organic - > direct -> ppc leading to sale of $100 product

would give direct $100 of credit in assist.

To add another reason that this is possible:

GA Goals only count once per session. So in the event that someone purchases twice in one session, that goal will only have registered once.

Rich,

Because responsive design inherently only uses one html file, what you're describing isn't so simple. Obviously, you only want to include 1 GA tracking code, but you COULD include some logic that fires a different one on page load depending on detected screen width. I think your best bet is to just use the standard GA code in your HTML, then include some JS that detects which of the layouts are displayed on load, and sends it in a custom variable. Alternatively, GA, by default, will capture screen size as a data point, so, as long as your responsiveness is working properly, you can just create segments in GA based on those and view site behavior accordingly.

Mike

Indeed, the Google rep is talking nonsense. Audience Overview reports looks at all traffic. Is it possible that you don't have the GA snippet on every page? Specifically, you should check to make sure that it's on the landing pages that you use for PPC. That would explain the traffic not showing up in GA.

The data comes direct from Google Webmaster Tools, which only displays data back 3 months. I can't recall if GA stores the data for us so it holds further back, though. Still, this seems to be pretty common. Oh well.

301s will preserve the referral data, so it should not be the case that it's being stripped out.

Hi There,

Well there are two ways to approach this problem:

1. The rightest way to fix the problem is to implement a server side redirect system, rather than a JavaScript redirect (client-side). This is best practice for mobile redirects, and the way that a majority of the sites on the web do it.

The reason why you're getting those first pageviews is because the GA snippet has time to fire before the user is redirected to mobile. With a server-side redirect, no HTML is loaded, so the GA snippet never fires.

2a) The sort-of hacky way to fix this would be to apply filters that exclude mobile visits from your reports. It'd be wise to create a new profile, though, so you still have the mobile device traffic for analysis in your regular profiles.

2b) Another hacky fix: Suppress the GA snippet when a mobile device is detected. You could adapt the logic you have in place that redirects mobile users to the mobile site to the GA snippet. For example:

var deviceMatch = navigator.userAgent.match(/Blackberry/i) || navigator.userAgent.match(/Symbian/i) || navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPod/i) ||navigator.userAgent.match(/Android/i);
if (!deviceMatch && $.cookie('full_site')) {

{Fire GA}

}

All that said, the 2nd options are NOT the right way to go about things. Option 1 is definitely what should be done.

Mike

CG8IeaO.png

It should also be noted that even with a completely proper setup of Google Analytics, some self-referrals are 'normal'. Anytime a user waits 30 minutes between clicks on your site, it will initiate a new session, and thus, a self-referral.

Obviously, it's not TOO common for this to happen, so your total self-referrals should always be a very small percentage of total referrals.

If you're seeing a LOT of self-referrals, as others have said, the most common cause is a page or pages that are missing the code.

Hey Lisa,

I was just reading a post about Google News errors and I remembered your question.

This part might help?

Unknown publication name – an error that I frequently come across in troubleshooting Google News issues is an “unknown publication name” error for the Google News sitemap, which is reported in the Sitemaps section of the site’s Google Webmaster Tools profile**.** This error is triggered when the publication name used in the <name>tags in the Google News sitemap is not an exact match to the publication name in Google News’ database</name>. To determine the correct name to use do a [site:domain] search in Google News and see what publication name is displayed for the indexed pages**.**

Source: http://www.adamsherk.com/seo/the-most-common-google-news-errors/

For something that repeats like that, I would instead use events, anyway. You'll be guaranteed that it's tracked.

Have you considered events? Would that work for you?

Lisa,

Tough one. Sorry for the delay, had to ping a few folks.

As for the naming error, is it possible that the site was registered in Google News originally with a slightly different name? In the application form, the name of the publication is a pretty important step, and any minor difference might raise a flag. The Sitemap calls the publication "Mother Nature Network". Perhaps it was registered with something slightly different?

Another thought: Considering the site is showing up when you do a Google News Site Search, is it possible that the traffic hasn't disappeared overall, but it's just not being properly attributed in Google Analytics anymore?

What this usually  means is that you have a page or set of pages that are missing the Google Analytics snippet. Whenever a user clicks from one of those pages onto a page with the snippet, it'll register as a self-referral.

This should be pretty simple. Add a line to your onLoad that looks like an event:

window.onload=function(){ 
 try {if ($buoop.ol) $buoop.ol();}catch (e) {} 
 var e = document.createElement("script"); 
 e.setAttribute("type", "text/javascript"); 
 e.setAttribute("src", "https://wxxxx.org/javascript/upda...");  (have replaced the domain name for this example)
 document.body.appendChild(e);

_gaq.push(['_trackEvent','browser-warning','{browser name}']);

Whenever the message is shown, an event is fired.

Yeah, I'm afraid this isn't something you'll be able to just view with a default GA installation.

With some custom code and server side logic, it's certainly possible. The modifications mentioned above would be a great place to start.

I'm sort of baffled, myself. I see no reason why this would be unfilterable. I'm marking this as an unanswered question, hopefully someone comes to our rescue here.

Was there any reason you're not trying just

localhost

as the filter pattern? No asterisks, quotes, backslashes or anything?

From what I understand, the # doesn't ever get sent to the server, so it would be impossible to include it in a rewrite rule.

This is a tough one. I've pinged a few folks who might be able to help. Sorry for the delay!

Ahahahah! Sorry, I just purchased from your site last month.

Alan,

It looks like you're using two trackers. There's nothing wrong with that, but you need to differentiate the trackers:

_setAccount, 'UA-XXXXXX-1'

_trackPageview

b._setAccount, 'UA-XXXXX-2'

b._trackPageview

_trackEvent

b._trackEvent

Otherwise, the differentiation is necessary otherwise Google won't know which account to send the _trackEvent to.

It's referenced (very poorly) here, https://developers.google.com/analytics/devguides/collection/gajs/#MultipleCommands

Like I said, many things can go wrong here. Just because the GA debugger shows the snippet was sent, doesn't mean it's getting to Google properly.

Would you mind sharing the link and I can take a look for you?

While GA isn't perfect, it should certainly not be missing out on 80% of anything. There must be something in the tracking implementation that isn't quite right. As you said, the hand off from PayPal back to your site could certainly be causing an issue with reporting hits on your thank you page. This can be difficult to overcome. Your event SHOULD be working, but clearly is not if you're underreporting by 80%.

Without seeing your implementation in action, it's nearly impossible to predict what's wrong here, but something certainly is.