Since a while I've been playing around with the Analytics Measurement Protocol, and also used it in some test emails as described in this article:
https://developers.google.com/analytics/devguides/collection/protocol/v1/email
But what puzzles me is that Google recommends to track email views as events, not as page views.
From one side I can see the point, but on the other hand in Google Analytics I get an alert stating that I have events without page views.
Can anyone answer me why it should be done that way, or what arguments are there that speak for it? Otherwise I could also just use the Measurement Protocol to send a page view.
I do not know why Google recommends this, but I rather suspect it's because you will skew some of your metrics if you use pageviews - an opened e-mail would count as a bounce, which in turn would bring down average time on site, pages per session etc. If you make opened e-Mail an event you can avoid this.
Related
I manage the analytics of a website that uses a headless web, and have noticed an unusual amount of page_view events one some of the pages.
Perhaps it could have something to do with the website being headless, meaning that the URL doesn't change/refresh when clicking, even though the content on the site is changed as if it was a url redirect.
does this make sense? Anyone got any good suggestions on why my events might be off?
My first thought was that the event tracking configuration wasn't set up correctly, resulting in multiple pageviews on the wrong pages (i.e. first page visit → 2nd page → 3rd page = three pageview fires on first page), but upon investigation this doesn't seem to be the problem.
Checked for bot traffic and it doesn't seem to be that, as we're also tracking through UA and Matomo and those numbers look way more likely.
First, what you've described is not necessarily a headless website, it's just a misconfigured Single Page Application that doesn't care about updating the url. A Huge SEO issue, but not a blocker for Analytics. And when an SPA affects analytics, it's most commonly less events, not more.
If the bot traffic inflates one analytics system as a side-effect of whatever it does, it will inflate similarly pretty much any other analytics system, so if numbers in UA and Matomo look alike, it doesn't rule out bots. Especially if your GTM sends events to both systems on the same triggers.
Now, there are ways to debug it besides just going to the website and looking at a few pages tracking.
In cases like this, you want to use data to debug your tracking.
You build a report (custom report, or just use pregenerated UA reports) in which you compare the anomalous traffic period to the previous period so that you would have your base. Now, whatever dimension you're using, you're looking at the value or a few values of this dimension that contain most of the anomalous traffic. This is to see if any dimension contains the outlier that would explain the nature of the anomaly.
Dimensions that I would look at right away are: hostname, country, hour of the day, source, page, landing page, exit page, referrer. I would also take a quick look at all the conversion numbers, bounce rate and avg time on site.
If all of these look organic, then I would presume natural growth of good traffic.
I have a website that sells products and I'm using google analytics to know some statistics about the website. Sometimes, errors happens for various reasons and purchases doesn't go through. You then have to refresh the page and try again, then everything works. The website displays the message telling the user to refresh and try again. I'm curious how many people actually do that. My question is, is it possible to know what users do when this error happens? Do they refresh and try again? Do they close the tab or do they do something else?
The question is quite broad at this moment, but there are a couple of improvements to your measurement setup, that can help you to investigate this customer behavior.
What I would do, is to implement an event tracking to indicate, that this error has occurred. You can find details about event tracking in this guide. Although I suppose, that your users are not likely to enter the website at this page, it might be a good practice to set the non-interaction flag of the event, as it is not actually generated by a user interaction.
I'd also create tracking for page reload, either by creating an other event for this, or by adding -reload suffix to these repeated pageview URLs. You can find good resources for this on SO as well, e.g. this one.
If you have a special URL for this error page (e.g. purchase-error.html instead of purchase-success.html), it is also easy to track the exit rate specific to this page.
Besides of Google Analytics, you might also want to set up heatmap or screen recording tools to understand this behavior. Hotjar, Lucky Orange are a few examples. (No affiliation.)
I am working on a third party website that contains a web application embedded in an iframe on the home page. This iframe is hosted on the same same sub/domain.
Currently page views are being tracked with _trackPageview. Due to a requirement by marketing both pages use the same Google account Id.
Since the iFrame was implemented the marketing department has noticed that the bounce rate has dropped to almost nothing. I suspect that this is because Google is interpreting the pageView event on the iframe as the visitor hitting another page on the website.
Just for additional information, the domain of the _gaq object is being set to "none" for both the container page and iframe.
Does Google provide a mechanism by which you can trigger PageView in such a way that it isn't interpreted as subsequent pageview in this scenario? (I know that trackEvent has a noninteraction property to deal with this?)
Am I better off just disabling the PageView for the default iframe page?
Does Google provide a mechanism - apparently yes, but probably not for your use case.
The field documentation for Universal Analytics describes the non-interaction field thusly:
Specifies that a hit be considered non-interactive.
So in UA this does no seem limited to events but to apply to all hits (which would include pageviews). I want to point out that I have no tested it and that it seems counterintutive, so it might simply be that the documentation is incomplete/wrong here.
However as you are using "classical" Analytics this does not apply to you. Since upgrading the code is a good idea in any case you might want to push for an update to Universal Analytics (this piqued my curiosity so I will test this over the next few days and update this answer with the results - maybe you want to wait until then, or simply test it yourself).
It's possible, but not 100% clear to me that disabling the PageView event on the iframe will prevent your users from registering a page exit (the pageview may get recorded regardless). You can try removing that event and see if it works.
But a better way may be to implement a custom filter on a new View excluding traffic to that specific class of iframes. Make sure you keep your old View (or create a new one with further filters) to make sure you're capturing those iframe views, if you think that's necessary.
I'd like to track screenviews in my website, is this possible or are screenviews just meant to be used on apps? If so, how can I do it? Let me give you an overview of my situation.
I am restructuring a web site. Some of the pages that used to live under differents urls are now living under the same, with a hash id to denote the particular area of the page the user is in. So, for example, http://www.example.com/topics/topicA, http://www.example.com/problems/topicA and http://www.example.com/equations/topicA, are now in http://www.example.com/topics/topicA#content, http://www.example.com/topics/topicA#problems and http://www.example.com/topics/topicA#equations.
Now, I'd like to keep track of users visiting these areas. My initial idea was send a page view when the url is loaded and send a screenview each time the user clicks on the button to change the area of the page (i.e. #content, #problemas or #equations). For doing so, I used something like ga('send', 'screenview', {'screenName': 'content',});. As I couldn't see the screenviews in reports, I played a bit, setting the app name, the app id, the installer id etc before sending the screenview, for example:
ga('set', {
'appName': 'myAppName',
'appId': 'myAppId',
'appVersion': '1.0',
'appInstallerId': 'myInstallerId'
});
ga('send', 'screenview', {'screenName': 'content',});
So I can't see the screenviews in the real time reports (though I can see the page views). I can't see them in the regular reports either. I decided to create custom reports with dimensions Page and Screen name. There, I see sometimes screenviews are tracked (I think it happens when I set the appid etc before sending it, but not sure about this point).
Are screen views adecuate for tracking this behaviour or should I use just events, as I'm not on an app at all (just a responsive website)?
By the way, I am using Drupal 7 but that shouldn't make a difference.
Thanks in advance for your time and I hope I am making my question clear enhough.
Technically speaking its probably possible to send both pageviews and screenviews to the same Google Analytics web property.
The problem you will have is seeing the information. The way the Website is set up its either application or web account, Screenviews or pageviews. The reports are different, and you cant swap between them.
So you could send screenviews to a web site web property but you would never be able to analyse it on the website you would have to use the API to rip the data out. That and you would be analyzing apples and cars. Screenviews and pageviews are different they cant be analysed together.
Because of this web property's should be kept separate one for application (screenviews) one for web sites (pageviwes).
You should in my opinion do this using events.
+1 for an interesting question that made me think :)
Is possible, actually in BigQuery you can reach both data and see how this interact, both will have the same schema and will be stored in the same dataset(it is linked the raw data view). Even in the same sessions, you can send pageview and screen views having funny results.
But there is some important consideration when you implement this.
You need 2 different views, one Web View and One App View. Both views will let you access to different information and is not possible on the web interface of Google Analytics to access to both info at the same time. Not sure if with the API you can access to both info at the same time, I think that is totally possible
In the App View, you will able to see only information of screenview, events and ecommerce.Is also mandatory the App Name parameter on this hits.
In the Web View, you will able to see only the pageview reports,events and events.
The ecommerce info and events will be reachable from both views, there is no way to know if this comes from a web or an app ( technically). So is tricky to read this kind of reports in that case.
Sessions can experiment stranges behaviors. As example gosht sessions coming from the screen view with no page view, sending events.
Taking this into consideration, as Dalmto says, the best to you is use events or sent virtualpage view.
Mixing pageview and screen view is not recommended by Google but is totally possible.This kind of implementations is only useful when you have an embed web-app and a webpage on the same server and you want to have it all on the same dataset, if this case apply, is highly recommended to add a custom dimension to filter the app info on the web view and the web info on the app view and keep both worlds separated.
As the last point, your code is working, I can see the screen info on the desktop property. But not be able to see it in the web view.
Looking at the documentation on the web, it seems to be a common practise to track outbound links as a virtual pageview with a URL like /outgoing/{original_url}. But a lot of that documentation is from before Google added events to analytics. Which is the preferred method nowadays - page views or events?
The 'correct' way is to track outbound links, downloads, etc. as events. - Creating virtual pageviews is a hack, from back when events wasn't released.
Virtual pageview tracking artificially inflates the number of aggregated pageview, and thereby polutes the data, so best-practice is to avoid this if possible.
However, there are cases where virtual-pageview-tracking is the only solution, and thats when you need to track the outbound link (or download etc.) as a goal - and thereby being able to optimize against this goal in AdWords.
Examples include AdWords optimization with regard to PDF-download.
If this is not the case, use event-tracking.
--
A standard snippet is (which simply is included in the specific <a>'s onclick-attribute):
_trackEvent('Outbound link', 'Click', 'http://www.external-link.com', 0)
Google has another solution to this:
http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55527
Which tracks the events, waits 100ms and the redirects to the external link - this imo, is not the best solution.
--
Another thing to remember, is that the onclick-event is not fired when the user right-clicks -> open in tab, or the equilivant middle-click.