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.)
Related
Looking more for some fresh ideas to help me troubleshoot the below problem than solving any coding issues (which may come next).
Creating a similar site to an existing one that uses all previous GA tech (analytics.js, _gaq.push, Google_Service_AnalyticsReporting_ReportRequest(), etc) and provides all the easy data needed for my simple GA reports (i.e. page views by date and location).
However, not quite ready to bite off the whole enchilada (GTAGMgr, GA4, and such) so created dual Properties (UA and GA) as many forums have recommended when making the transition.
Setup the website same as the active [UA] site but using the gtag.js (per the Property Tracking Code snippet provided in ADMIN) vs the analytics.js code. Created View(s), new Service Account for the "user", an API Map Key for the Google Map Charts, and any other pieces I could find.
Have the GTAG.JS setup on each page and added any special page tracking via gtag('event', 'page view', {...}) but letting the default page view still occur as well.
Page view hits are coming through as expected EXCEPT the page views locations (City, State, Country, Region) are not being populated. All that comes thru is the "not set" for any location. Ironically, the old analytics.js code was still active initially and location data was being populated.
Would think if gtag.js is collecting standard page view info for the configured Property, that location data would be there as well. Am sure it is but possibly the older getReport calls need tweaking. No doubt I probably have a something not quite right but if REALTIME data shows usage, page views, etc. AND my GA Report calls are working, would think location data would be there too.
Any brainstorming ideas would be appreciated.
Thank you,
LarryG
ANSWER ... the EZ Button ... my code and calls were correct using old and [semi] new way. The majority of the problems were McAfee VPN kicking in. It is set to turn on with reboot and I do not always remember to turn it off. The first obvious clue was the realtime location for my actions were not where they were supposed to be. Also, appears Google API PHP Client has some issues with PHP7.4FastCGI.
So if you took the time to read ... check your VPN settings if you are getting an abnormal amount of NOT SETS in your GA data.
Begs the question ... with the increase in companies providing VPN services out of the box, that renders some of the tracking a moot point.
LarryG
I am trying to learn AMP Analytics. I stumbled upon this statement which I am unable to understand.
Since analytics priority is lower compared to content on the page, it's recommended that clicks are tracked using a browser redirect to avoid click loss.
Can someone please make me understand how redirect helps in avoiding click loss.
The problem that's referred to is that analytics have low priority, i.e. they are not guaranteed to fire immediately. Clicking on a link navigates you to a different page, which may happen before analytics has a chance to fire a click event.
Thus, it's safer to track links through other means, like a redirect, rather than to rely on amp-analytics which may result in a race condition.
So I've been working on a website for a while. GA account has been up for a couple months but I waited for the website to be finished before putting up the actual JS tag.
In the meantime, the website is being HTTP password restricted (basic authentication) so it isn't even accessible unless you know the user/pwd combination.
To my surprise, I realized today that GA has logged several hundred views to the root of my website. Paths are mostly things like:
/
/?from=http://social-widget.xyz/
/?from=http://www.traffic2cash.xyz/
Bounce% and exit% both at 100% for all of them.
I realize this looks like referral spam, and there are ways to prevent it. Came across this upon googling:
http://botcrawl.com/block-social-widget-xyz-referral-spam-in-google-analytics/
My question is: how can GA log anything anyway when no tag is up and the website isn't even accessible?
Thank you very much in advance
Because it's spam. They hit Google Analytics directly with random GA codes and don't even go through your website.
GA can't tell if these are real hits (from website visits) or fake hits (from spam bots who hit GA directly calling the same ode as they would if on the website). Though arguably they should do more about this.
Massively annoying - particularly when first starting out as this can be a heavy proportion of your "traffic".
It's easy to set up a filter rule is to catch a lot of this by filtering on hostname. As they are randomly hitting GA and don't even know what website they are hitting GA for, they don't usually set this correctly. Real traffic should only come from yourwebsitedomain.com so add a filter for that.
STRONG piece of advice: abandon the default UA-########-1 tracking code of your new website -- simply do not use it!
Create a second and third property on the Admin screen, then use the tracking code for the third property. You will immediately see a lot less spam. No filters or segments necessary!
If you want the whole sad story about spam visits in GA, I have been maintaining the Definitive Guide article for over a year now:
http://help.analyticsedge.com/spam-filter/definitive-guide-to-removing-google-analytics-spam/
What people are doing is basically taking the UA-XXXXXX code that you normally get with analytics, and they are generating calls against it. This is skewing my analytics stats. On top of that, in Google WebMaster tools, it's also causing this:
It looks like somehow these pages, with my code on or at least with the generated code on, is making Google Webmaster tools think I have lots of 404's. This can't possibly be good for my rankings.
Anyone know if there is anything you can do to stop this?
Try making async call from your server end using CURL.That way you will never expose your GA code.
I have not implemented it, but it might work as per theory
Since you can filter by custom dimensions you can set a "token" in a custom dimension on every page and filter out any traffic in your view settings that does not include the token.
Obviously this will not help against people who use the code from your website (unless you also implement shahmanthan9s suggestion - which is a lot of work but will give you cleaner data), but it will work against drive-by shooters who randomly select UAIDs to send data to (which is the situation you refer to in your comment).
I created my own analytics for my site to track outbound click events using jquery. Now the thing with preventDefault() is that it does not allow for the Ctrl+Click or COmmand+click operation in the browser to open the link in new tab/window. So my solution was to detect e.metaKey || e.ctrlKey and use window.open. This does not work very great with safari unless the user changes browser behavior. I am wondering if anyone here knows what other analytics users do - like how does google etc deal with this problem in tracking outbound links? From this link: http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55527 - looks like google will also face the same problem.
Thoughts?
The timeout there exists to increase accuracy on Google Analytics Tracking. Without it there's a chance the page unloads before the track goes through.
The good news is, you don't need it if you don't mind about accuracy and are only interested on trendings of outbound link clicking on your website. If you remove that setTimeout call and the return false; from the end of your code it will be ok.
For outbound links a good alternative is to force them to open on new tabs. For that just add a target="_blank" to the links. This way they will always open on new tabs. And you don't need to worry about the tracking not going through, since the page won't unload and, again, can get rid of that setTimeout.
Disclaimer: Personal Opinion Bellow
Web Analytics Tools are not Accurate by design. And that's not bad. They are built to find and measure trends and noise in that trends. So any attempt to increase accuracy in Web Analytics tools won 't pay back. Specially when it comes in the form of ugly Javascript hacks.
Read more about Accuracy X Precision:
http://www.whencanistop.com/2009/11/difference-between-accuracy-and.html