I have a page (let's name it the overview page) with a lot of images of projects that on a click open a bootstrap (v3) modal with more info about that project. Each project also has its own page (single page).
I'd like to track pageviews for the projects when a user opens the modal with Google (universal) analytics. Now I'm planning on doing this by adding the following code to each link on the overview page:
onClick="ga('send','pageview','/url-to-project-page');"
I expect this works fine since I've seen this method in other posts regarding tracking pageviews on AJAX calls.
But I'm wondering how this affects time related metrics like average time on page, since analytics can't know when the modal is closed (the same as leaving a single page).
Does anyone know if the metrics will be comparable to a normal single page view, or will some parts of the metrics (I'm guessing time related metics) be off because analytics isn't able to track them?
If I understand it right, you want to track the opening of the modal as a pageview of the projects page. This can be accomplished with what you just said, but using a direct URL would be unwise in my humble opinion. You would be better off using a virtual URL(VURL) instead. Read more about virtual URLs here.
It is also available in Universal Analytics(UA) (analytics.js) and when you are sending such a pageview as you mentioned above, you are forcing GA to report a pageview of the specified URL. Your code,
(1) ga('send','pageview','/url-to-project-page'); will work.
In UA, ga('send','pageview'); is used to send the current pageview. If you need to send a virtual pageview (or a pageview which has not happened but you want to be recorded), you can also send it as:
(2)
ga('send', 'pageview', {
'page': '/url-to-project-page'
});
or as
(3)
ga('set', 'page', '/url-to-project-page');
ga('send', 'pageview');
or as
(4)
ga('send', {
'hitType': 'pageview',
'page': '/url-to-project-page'
});
The implementations 1, 2 and 4 are same, but 3 is different.
You can read more about the implementations here, here and here.
This would affect your pageviews count (you will see an increase), but would not increase your visits (as no user can 'land' on a virtual page (unless you make them do so)). This will impact your bounce rates, but it will not be 'off' in the sense that if they view your project in a modal, it means they have interacted with your site hence they should not be marked as a bounce, and this is what happens when you send a virtual pageview.
Though what you wanted to do was correct, your implementation suffers from not being able to differentiate modal views from actual project page views. I would overcome this by organising the VURL structure in a way that it makes sense and is semantic. As an example, instead of sending a VURL which corresponds directly to your project single page url, I would send it like: ga('send','pageview','/virtual/modal/url-to-project-page');
This way, you can filter out the VURLs by adding an exclude filter for /virtual from pageviews so that virtual pageviews are not shown. Also, you can view total pageviews for project pages by using /url-to-project-page. Also, you can view all virtual pageviews resulting from the opening of modals by using /virtual/modal.
Time on Page and Pageviews/Visit and such metrics will change, but it depends on how you see it, whether as an error or improvement in accuracy. Time on Page is recorded for the virtual pageviews until the user navigates to a new page, or a request to report a VURL is sent, or until the session is closed (whichever happens first).
Hope that helps! :)
Related
Background and Problem
I have a system that has core users augmented by some minor contributors who only need to be able to provide approvals for certain things. To support this, the system reacts to database changes and emails those approvers with a single button in the body of the email. This button is just a link to a unique url - something like https://myapp/response/12345-abcdefg-6789.
That "response" page is listed in the web config as not requiring a log in. Thus, the approver should only have to click on the link in the email, and the system should detect that and mark their response.
In all of our testing, this works great. All we're doing is marking the response via the page's code behind, and then displaying a message on the page that the response was received. On the surface, this seems like about as easy of a task as you can dream up.
However, we're getting false positives in production. The approvers are telling us that things are being marked as approved when they never clicked the link. I assume this has something to do with their browsers checking the links for safety or something - and by performing that safety check, it's triggering the system to record the response. Unfortunately, i haven't been able to reproduce this - even when we have some of the approvers on the phone while we try it.
The question is - what is the best strategy to avoid a false positive with buttons in an email?
Lots of companies do this kind of thing - i'm looking right now at an invitation from a friend via evite. It has Yes, Maybe, and No which appear to have the same kind of setup i described above.
Is there something i should be doing with redirects after x seconds? Is there some other javascript i should be deploying on the page? Is there some other potential cause for this? The IIS logs seem to indicate that the "fake clicks" are coming from the target users computers. Which is a bit of a relief, since it's hard to imagine how some other external machine could end up at a GUID based url that is not represented by a physical file that could be crawled over in some way.
I would like to avoid having another button for the user to click, where they would click "Approve" in the email, and then when they get to the page they have click the same thing again.
Thanks!
From my understanding there are two ways to go about it. But both methods assume the current "response" page is just an intermediary.
Add another button on the page (#
https://myapp/response/12345-abcdefg-6789 for instance) that actually
submits the response (or redirects to the actual response page). It would add an extra step for your approvers but
it should work. (You can even add a captcha there if paranoid)
Once the page is loaded, redirect to the actual response page via
javascript. The idea being if the link is automatically opened by
some kind of bot it's unlikely it runs the script.
It seems that Custom Dimensions are the new way to send custom data from a website to GA. I'm new to GA but my manager has used GA in the past and I'm guessing this was before the CD structure existed in GA. Do you know when the CD structure was introduced in GA?
He has sent custom data to GA in the past using events. This seems like a viable way of sending data and another manager at my company had referred to this approach last week so it seems like maybe this was a standard approach before GA introduced CD's. So given the following request:
var myRequest =
{
UserID:1234,
SelectedReportType:1,
};
What are the tradeoffs between sending this request data to GA as a CD like this:
ga('set', 'dimension1', JSON.stringify(myRequest));
ga('send', 'pageview');
Vs sending this request data to GA as event data like this:
ga('send', 'event', {
'eventCategory':'MyWidgetUserSelection',
'eventAction':JSON.stringify(myRequest)
});
?
Custom dimension where introduced with the switch from "classic" Analytics to Universal Analytics (IIRC that was in 2012), where they replaced (more or less) custom variables.
"Classic Analytics" (not an official name, AFAIK the previous GA version did not have a name other than GA) was a pretty messy thing that pretty much used the technology of the original Urchin tracker (Urchin was a web tracking company Google acquired in the early 2000s and rebranded their product as Google Analytics). Classic analytics pre-computed a lot of data on the client side (using up to five different cookies), including traffic source attribution, before it made a rather convoluted image request to the Google server.
In contrast Universal Analytics was designed on top of a clean protocol, the measurement protocol. It is "universal" because any device or program that can make a http request can now send data to Google Analytics. Universal Analytics does not compute any data on the client side, the data is processed only after it arrives at the Google tracking servers.
"Classic" Analytics had up to five custom variables in different scopes (hit, session,user)). They were displayed in the "custom" menu item of the GA interface (which is still there, but is now useless unless you have old data that was collected with classic analytics). Five variables posed a pretty tight limit, plus it was not always easy to understand how exactly they were supposed to work. So people developed a habit of storing additional data not in custom variables, but in events.
Universal Analytics in the free (commercial) version offers 20 (200) custom dimensions in four different scopes, to wit hit, session, user and product (and an additional 20 (200) custom metrics, although very few people seem to use custom metrics). "Hit scope" means you can add a dimension to every single interaction. "Session scope" only retains the last value for a session. "User scope" is primarily for values that are set once per recurring user (i.e. a user turns into a customer). With the product scope you can add additional properties to the products in an ecommerce-transaction (or production impression etc. if you are using enhanced e-commerce tracking).
Conceptually event tracking and custom dimensions are not remotely comparable. A dimension is a property that is connected to an interaction hit (or a collection of interaction hits like a session or a user) and allows to break down metrics into indivual rows. For example the "pageview" metric can be broken down by page path or page title, which are automatically collected. You might add a custom dimension "page category" and you can break down your total number of pageviews into separate rows that show the number of pageviews per category.
Custom dimensions do not have their own report; you can select them as secondary dimension in a standard report, or create custom reports based on them. You can also use custom dimensions to segment sessions or users by the respective values for the dimension.
Events on the other hand are interactions in their own right, with their own set of default metrics and dimensions (in fact you can amend events with their own custom dimensions). Proper usage of events is to track interactions that not load a new page (or do not change the page content enough to warrant a pageview call).
You can use events for segmentation (i.e. "show only sessions where the user had a certain event"), but you cannot break down pageview metrics by event properties. That is actually the main difference.
A more practical concern is that events, unlike custom dimensions, count toward you data collection limit (the free version of Google Analytics allows for 10 mio hits per month only, although the limit is so far not strictly enforced). Since custom dimension are not interactions by themselved they do not count towards the quota.
I am using a 3rd party plugin service (POWr.io) to add elements to our online store built using Shopify. The plugin does not support script tags, so I was unable to add tags using the Google Tag Manager
I use a variety of plugins from this service, and I would like to be able to collect data on them, specifically measuring loading time for photo galleries, and setting up goals in Google Analytics for newsletter submissions.
I can add custom JS directly into the individual plugins (in this case a photo gallery), and I have loaded the Google Analytics Tracking Code Snippet successfully. I am currently using ga('send', 'pageview'); but I think I need to use a different command to collect loading time, I have tried following what is written here
However, I am not sure how to modify:
ga('send', 'timing', [timingCategory], [timingVar], [timingValue], [timingLabel], [fieldsObject]);
To get the results I need and into Google Analytics.
Likewise, for a form submission, I imagine I would need to use this:
ga('send', 'event', [eventCategory], [eventAction], [eventLabel], [eventValue], [fieldsObject]);
But, again, not sure what how to modify this for my use in a plugin.
Any advice anyone could offer would be greatly appreciated
To measure timing events you need to create a timestamp when the event starts, another when it ends, and the difference between the two you pass in as timing value.
timingCategory, timingVar and timingLabel are just arbitrary strings that appear as dimensions in your reports (like category, action and label in event tracking).
timingValue is:
timingValue integer yes The number of milliseconds in elapsed time to
report to Google Analytics (e.g. 20).
With user timings GA is not doing the actual measuring for you, you need to determine the time yourself and put it in as a metric.
SETUP:
Having a few different information sites/domains about my products and one single site/domain shop-site where you the purchase, checkout and so on happens, I'm having troubles to find a proper solution for a comprehensive tracking of all the pages including the conversion tracking.
IDEAL:
What I want is to get reports seperated for each site (shop-site as well as information-sites), but add some conversion tracking. Ideal would be to be able to track a conversion when the user gets to the checkout process, so that I can see it in the statistics of the shop-site as well as on the site that referred to this sale/conversion and maybe even a funnel visualisation for the whole action.
WHAT I ALREADY GOT:
I already set up statistics for each site/domain. I do have set events for a referal to the shop-site as well as an event when the user checks out.
WHAT I TRIED:
I set up cross domain tracking for one of my information-sites and the shop-site, so now the events show up in that single property.
Unfortunately thats not the statistic I intend to get, as the whole data got consolidated from those 2 properties. Also it made the tracking goal/conversion only accessible for that single property, while I can't distinguish between a conversion made originally from this site or one of the others.
Is it possible to achieve what I actually intend to do or what's the proper way to track such a setup??
You can either use an additional tracker (so you have one UA id that goes in your "normal" domain, one that goes in your shpooing site and one that is placed on both sites) - you'd still have both pages tracked in separate properties, but you'd have one rollup property that tracks all your sites. This might however unwanted complexity if you use event tracking etc (since you'd have to see to it that events are always pushed to the correct tracker).
An easier solutions is via views/profiles - use the same UA id for both sites; create views based on domain name (filter in the admin section) to track each site separately; for the common data view that display data from both sites create a filter that includes the hostname in the reports so you can tell both sites apart in the report.
I have a page “Googlesapp_welcome” is showing up in the my home page report suite and accounting for ~10000 visits per month. I know this is necessary to enable the tracking of the registration process. But what is the best way to remove it from reporting? Is it to change the sitecatalyst code on this page to not increment a visit? Is it just to filter it out of our reporting.
(But I have to keep in mind with all reporting in the future prospective)
If you want to completely stop that page from being tracked, ie no beacon will be sent to Adobe, you can set "s.abort = true". Create a function after you set your s_account variable that matches the URL you want to filter and sets s.abort = true. Keep in mind, this will really mess up your referring data as the next page view will see an internal referral as the first page view on the visit. If you are using multi-suite tagging, you will lose all beacons to all report suites.
If I were you, I would create a segment that excludes page views or visits on that page from the report suite and look at the data that way. Or, if you just don't want to see the traffic that is bouncing, create your segment excluding and single page visits that entered on that page.
Aborting the pixel is a drastic step and should be very well thought out before employing that tactic.
Use VISTA rules to accomplish the desired result.