#tracking redirects

[digitalmeasure]

How to Retain Visitors During a Domain move - Part 3, Reporting & Taking Action

Reading the Reports

Once you've set up the redirects, you can examine the analytics reports. There are two simple ways to access the reports.

The first is through Google Analytics's stock reports. Click on:

Content

Events

Top Events

Select "inbound-redirect"

Select a destination URL to drill down and view all the sources that led visitors to this URL.

Recall from "How to Retain Visitors During a Domain move, Part 1" that the old URL redirects to the new destination URL. Only the new destination URL appears in the reports. So the old URL at foo.com redirects to the new destination URL at bar.com.

A Drill Down Look at all Redirected URLs: Here's a list of all the redirected visits by destination URL. This is the drill down of the "inbound-redirect" event category.

Drill Down Look at a Destination URL: Here's a look at pages that link to the old css.georgetown.edu URL (it's not shown in the report, but its cpass.georgetown.edu). This is the drill down of the "css.georgetown.edu" event action.

The second is through Custom Reports.

Create a custom report by clicking "Custom Reports" then "+ New Custom Report"

Give the report a Title and name

Type: "Flat Table"

Dimensions: add "Event Action" (for destination URL) and "Event Label" (for source URL)

Metrics: "Total Events" and "Unique Events"

Add a Filter, Include "Event Category" Exact and type "inbound-redirect" into the text box

Save

Configuring the Custom Report: These are the settings to create a report that shows pairs of destination URLs and source URLs.

A finished report is below. When you need to refer back to this report in the future, access it in Custom Reports.

View of Custom Report: Here's a look at the flat table report.

Taking Action

With these reports, your team can reach out to referring sites that are using the old domain or URLs. First identify the content managers for the Web pages, then reach out to them stating the back link containing the old URL and the new updated URL. These reports tell you how to prioritize your efforts and allow you to track progress from your link partners over time. You could even set up alerts. Lastly, if you see that direct visits to the old URL remain high long after the site migrated, you can turn up the annoyance meter to those who haven't updated their bookmarks by modifying the visitor message or make that message stand out more.

[digitalmeasure]

How to retain visitors during a Domain move: Part 2, technical implementation

My previous post covered the primary business reasons for tracking redirected domains, and delved into methods of tracking redirects. This post will examine the third method in more detail, Destination URL with hash tag, triggers JavaScript event. This is the best method for tracking redirects when moving content from an old domain to a new domain or performing other content refreshes where the URLs on your site are changing.

As a recap of the previous post, you want to retain search authority from backlinks to your old site, while having the data to chip away at updating these backlinks after your site goes live. You also want to encourage users to update their bookmarks.

This post introduces a JavaScript that gives us domain redirect analytics  and solves a number of issues related to tracking redirects in one neat little package. It is an ongoing GitHub project to provide JavaScript enhancements to Google Analytics for businesses and organizations serious about analytics. It has a slant towards content rich properties such as universities, non-profits and large corporate sites. Download the most recent Google Analytics script.

Implementing the script

Take the full script as is, or if you only wish to use the redirect tracking component, extract the section commented as // DOMAIN REDIRECTS, and wrap the script in the jQuery function.

$(document).ready(function() { //some code here }

Then simply add this script into the source of your templates. The script needs to load after loading jQuery, and it requires jQuery 1.4.2 or greater. It is tested with a number of jQuery versions, documented on GitHub.

You will need to have the tracking code included in your Web pages as usual. Start by reading the Google Analytics Plugin installation and configuration instructions. More on configuring redirect tracking is documented in a wiki article.

Destination URL hash tag

Ask the network/server admin to append the hash tag to the destination URL (e.g. http://bar.com#domain-redirected)

#domain-redirected

Reporting enhancements

Source (event label)

strip parameters from three most popular search engines (Google, Bing, Yahoo) but retain localized domains, such as google.ca, google.co.uk and yahoo.ca

report full non-search urls

report visits without a referral source as "direct"

supports multiple tracking codes. Use the name provided for the tracking codes and include them in the _gaq.push. The code currently includes use of two tracking codes

Visitor message configuration

Update the visitor message if desired. The message can hook into the main body area of your site's templates, or display at the top of every page. Take a look at the wiki for more details on configuring the message.

In some instances, you may not want to notify visitors that were redirected. If the domain redirect is long-term and continues to be used in marketing material, then simply tracking the redirect may be all you want to achieve (see my previous post, as marketing domains should use campaign codes instead of events to track the redirects).

To avoid displaying the visitor message, append this parameter to the end of the URL, after the hash tag (e.g. http://bar.com#domain-redirected&mssg=no).

&mssg=no

Making the URL friendlier

When we pass any analytics information through a parameterized URL string, we risk having the visitor reuse that same URL for other purposes. That is true for campaign codes as much as using the hash tag to track redirected visits like we're doing. The problem is that our analytics script and analytics package rely on that parameterized URL string to pass information we measure, and we need control over use of that URL string.

Nothing is to stop a visitor from bookmarking the parameterized URL. That same visitor could also copy the URL from her browser bar and link to it from a anywhere else, for instance a Facebook post telling her network to "check out this new site (http://bar.com#domain-redirected)". Ultimately, we are losing some control over that URL, and our data becomes a little less reliable.

Fortunately, HTML5 provides us with a solution. Modern, standards compliant browsers now support session history management, a JavaScript method of manipulating Web browser session history. We can take advantage of pushState or replaceState to remove the hash tag #domain-redirected without forcing the Web page to reload within the browser. That last bit, "without forcing the Web page to reload", is critical.

Virtually all Web browsers, including Internet Explorer, support basic JavaScript and we could rewrite window.location.href and reload the page. The page takes a few moments to reload, slowing down the visitor's experience. It also inflates pageviews for that Web page, and messes with the bounce rate calculation, as any visitor viewing that page will have viewed at least two pages during their visit. By updating the URL without reloading the page, and removing the URL with the hash tag from the visitor's browser history, we can be assured that the visitor cannot unintentionally reuse that URL for any other purpose.

According to Can I Use (a great source for Web developers), in April of 2013, fully two-thirds (66.8%) of global Internet users have Web browsers that support session history management. That data is based on StatCounter. This method is supported by most versions of Firefox and Chrome, and newer versions of Safari, Opera, iOS, Chrome for Android, and IE10. The biggest obstacles are IE8 and IE9, which still account for a large - though declining - share of Web browser usage.

Browser support for Session History Management: Major browsers and their support for session history management. This HTML5 method allows us to rewrite the browser window's URL without reloading the page.

Data capture in event

There are three elements of information that should be captured in the event:

The type of event (Redirect, Page not found, Redirect to a Page not found)

Destination URL

Source URL (Referral URL or Direct)

There are three types of strings that Google Analytics captures in an event:

categories

actions

labels (optional)

An event label is the string assigned to describe the event. For example, the name of a video, or in this case, the source URL. Ideally we would have two strings in the event, one to capture the destination URL and another to capture the source URL. There are better products in the market than Google Analytics to provide detailed event tracking. Mixpanel is one such product.

We could merge Source and Destination URL into the label field, but that muddies the data substantially, and increases the number of unique event labels (as each unique combination of source and destination would be counted as a unique label). This makes it difficult to make sense of the data.

The issue on GitHub provides more discussion about the pros and cons of each method for storing an event. The options are summarized below in a table. bar.com is the destination URL and baz.com is the referral source URL.

3 different ways to capture events: Each way is valid.

Here's how the script maps data to the Google Analytics event:

categories map to the type of event.

actions map to the Destination URL. As mentioned, this is less than ideal, as it is technically not an event action. But it works pretty well for our purposes.

labels map to source URL.

Using event actions as a label for the source creates an issue in how the generic reports are viewed in Google Analytics. However, it's an issue that we can easily overcome through custom reports or pivot tables. Custom reports use sampled data, but that's not a horrible tradeoff since precision isn't a requirement. The trend and general numbers are more important and it's still possible to access non-sampled data.

https://github.com/ignatiushsu/google-analytics-plugin/issues/8https://github.com/ignatiushsu/google-analytics-plugin/issues/8The next post shows us how to look at the reports once domain redirects are tracked.