Crafty Code

New Skin Objects for including jQuery, Javascript and CSS Stylesheets in DotNetNuke Skins

http://www.ifinity.com.au/Contact_Us — Thu, 05 Jan 2012 02:33:23 GMT

This blog post brings together two threads of thought that I have been thinking about. The first is related to my recent blog post Implementing jQuery and Javascript Libraries across DotNetNuke versions, and the second was a conversation with Scott Willhite at DotNetNuke World, who asked me why I hadn’t actually ever published anything in the DotNetNuke Forge despite writing lots of stuff. I didn’t really have a satisfactory answer that didn’t involve using an excuse of inertia or procrastination.

My prior post on jQuery and Javascript implementation has been pretty widely read, and one of the comments on twitter was thus:

So as two things lead to one, I decided to create a set of skin objects that would incorporate the work on jQuery and Javascript libraries into re-usable skin objects and create that as a DotNetNuke forge project.

I already had an older freebie project called iFinity SkinObjects but most of the innovations in that have now been adopted in the DotNetNuke core (nofollow on privacy/terms links, correct home page Url on the Logo, etc). The SkinObjects project was also written in VB which was now out-of-step with the DotNetNuke core.

So what I did was create an entirely new project, which I called DotNetNuke.SkinObjectsEx, or ‘Extra Skin Objects’ if you want the friendly name.

This has been created as a DotNetNuke Forge project, which has it’s associated Codeplex Project page. You can download the install package, example skin and Source code from these locations.

What’s in the box?

The SkinObjectsEx project contains 4 separate skin objects to use within your DotNetNuke skins. It comes in an installable DotNetNuke Extension Zip package which is installed as normal.

Script

The script object allows you to link a javascript file into your skin in a way that is safe for all DotNetNuke versions, and in a way that will leverage the increasing client-site functionality that has been gradually appearing since DotNetNuke 5.0 came out.

The Script object is also a simple way to ensure that both jQuery and jQuery UI are registered on the page in a DotNetNuke-safe way. I have seen many, many errors created on sites due to hard-coded jQuery or jQuery UI references into a skin, which then cause problems when new modules or DotNetNuke upgrades are introduced. This saves the skin author having to devolve into code-behind code, when they can just include a simple reference and be certain the correct version of jQuery is going to be registered on the site.

Stylesheet

The Stylesheet object is modelled on the standard DNN Styles object, but again brings in the compatibility with the DotNetNuke Client Resource Management framework in order to combine stylesheets for faster performance – in a way that works with all DotNetNuke versions. In addition, the Stylesheet skin object introduces the ability to link CSS files only for specific DNN versions. This is done in a from/to pattern, so that you can have one CSS File included up until, say, version 5.6, and another CSS File included from, say, 6.0. This power allows a skin author to tailor different approaches to different DNN versions, which is very important with the introduction of jQuery UI in DNN 6, which brought a lot of standard CSS definitions with it.

PageLink

The PageLink skin object provides a simple way to create a link to a specific page in your DotNetNuke site. While this sounds very simple, in reality skins are often developed away from the intended site, and hard-coding a Url into the skin creates a brittle implementation that is easy to break, and is usually done in a way that doesn’t leverage the proper DotNetNuke Friendly Url API accessed through the NavigateUrl() call.

Portal Date

This is an old one from the original Skin Objects project, and provides a simple way to add the current date or time to every page in the site. The most important part of this is that it loads up the localised portal date/time, rather than the date/time of the server which it is running on. For people who have their site hosted in a different timezone to their intended hosting locality, it’s a neat little way to make things look right.

In addition to the above objects, the CodePlex downloads include a variation of the DotNetNuke 6 ‘DarkKnight’ skin, which includes implementation of all of the above skin objects in an example.

This blog post will focus on the Script and Stylesheet skin objects from this point on.

Using the Script Object

Adding the Skin Object to a DNN Skin is done like this:

First, you register the skin object in the skin:

<%@ Register TagPrefix="dnn" TagName="SCRIPT" Src="~/DesktopModules/SkinObjectsEx/Script.ascx" %>

Then, for each Script library you want referenced on the generated page, you add a new Skin object:

The above example shows 4 different Scripts to be included on the output page. The first is a request for the jQuery library. The second is a request for the jQuery UI library. The last two are references to the ‘jquery.cycle.min.js’ and ‘jquery.hoverintent.min.js’ libraries which are referenced in the ‘DarkKnight’ skin.

The final two references replace this in the standard DNN 6 DarkKnight skin:

There are 6 different properties in the Script object, all of which combine to control the behaviour of the way the final script is linked on the output page.

The properties are:

ScriptType

ScriptType controls the type of script the skin object uses. There are three choices: ‘jQuery’, ‘jQueryUI’,’other’. The first two should be obvious – they just include a reference to the jQuery and jQueryUI libraries accordingly. The ‘other’ is anything else, apart from jQuery. You don’t need to include this value for ‘other’ types, as ‘other’ is the default.

Looking back at the prior example, you can see how the ScriptType is used in the 4 different examples.

Path

Path is also a value with set values. These are ‘Skin’, ‘Absolute’ and ‘Relative’. When using a path type of ‘Skin’, the library is referenced from the installed skin path. When using a path type of ‘Absolute’, the library is reference from the absolute location specified. When using ‘Relative’, the location is specified with a tilde (~) and is passed into the ‘ResolveUrl’ function to create a fully qualified path. In the above examples, you can see how the ‘hoverintent.js’ skin object replaces the included ‘code behind’ in the skin files.

Location

Location is the component that combines with the ‘Path’ value to create the fully reference Url. For Path=”Skin” location is just the relative path in the Skin directory (ie, where the skin is installed). For Path=”Absolute”, Location is the fully qualified Url to the file. For ‘Relative’, location is the relative Url that ASP.NET will resolve at runtime.

Name

Name is just a unique identifier that ensures that the script is not added twice in the one page.

Order

Order is used for DNN 6.1+ installations, and determines where in the list of resources the item is inserted. These values come from the earlier work done in the jQuery and Javascript Libraries in DotNetNuke post already referenced.

The values for Order are:

a_BeforejQuery, b_BeforeDnnXml, c_BeforeDomPositioning, d_BeforeDnnControls, e_Default

The alphabetic prefix just helps with understanding the overall order of things. This allows you to control where in the hierarchy of scripts your linked script will appear.

InHeader

This is a boolean value which controls whether or not to include the header within the section of the Html, or whether to include it in the section. In some cases, this will be overridden by the logic contained within the code, to prevent quirks for individual DNN Versions from breaking your javascript. These are always moving from to , and only apply to the jQuery and jQuery UI usage.

StyleSheet

The StyleSheet skin object uses a similar approach to the Script object in that it uses the same logic to seamlessly integrate regardless of the installed DotNetNuke version.

Here’s a reference as shown in the example DarkKnight skin:

<%@ Register TagPrefix="dnn" TagName="STYLESHEET" Src="~/DesktopModules/SkinObjectsEx/StyleSheet.ascx" %>

and the skin object usage:

Note that this replaces the DNN STYLES reference in the DNN 6 DarkKnight skin:

On first glance these would appear to be the same, and they largely are (the STYLESHEET object is a fork of the STYLES code). However, the StyleSheet skin object has some big advantages:
- it will utilise the DotNetNuke Client Resource Management (aka imbibe) framework to combine all stylesheets into a single downloadable file, if it is available

- it allows you to specify FromVersion and ToVersion properties which controls whether or not to include the stylesheet with a particular version or range of DNN versions. This allows the skin author to have a single installable skin that has a different stylesheet for, say, DNN 6 and DNN 5.

Here are the properties for the StyleSheet object:
Condition

Carried over from the Styles object, the condition allows you to add a CSS Condition which helps to determine usage for particular browsers

Media

This property is carried over from the Styles object, and allows you to specify the media attribute for the stylesheet.

Name

The Name property uniquely identifies a stylesheet so that a single version is implemented per page

Path

The Path location works the same as the Script object, in that it has a choice of Absolute/Relative and Skin. This controls the references of the Location property.

Location

As with the Script object, the Location is used to combine with the Path value, and determine the actual Url of the stylesheet. See the Script definition for ‘Location’ above for more information.

Order

As with the Script object, the Order path allows you to specify a particular insertion order for a stylesheet. Note this value only works for DNN 6.1+ versions, and is ignored in prior DNN versions (in these cases, order is determined by the execution order, ie, the location on the skin file). The values for order are:

a_BeforeDefault, b_BeforeModule, c_BeforeSkin, d_BeforeContainer, e_BeforePortal, f_Last

These are entered as a string property value, which then converts them to a numeric value.

FromVersion / ToVersion

These two properties allow you to specify from and to DNN Versions. If the currently executing DNN version falls greater than or equal to the FromVersion value, and less than or equal to the ToVersion value, the file will be included. You do not need both, but can specify both. So you can have a ‘FromVersion=”6.0"’ to always include the CSS File from Version 6, or you can have ‘FromVersion=”5.5” ToVersion=”5.7” to only use the file in versions 5.5, 5.6 and 5.7 (although 5.7 doesn’t exist). And you can have a single version like ‘ToVersion=”5.4”’ to include the file up to the 5.4 version.

The format allows you to specify any level of detail, so you can say ‘FromVersion=”6”’ which is just the major build version, or you can qualify to the minor version (“6.1”) or down to the revision value (“6.1.1”). The system will automatically take the value down to the lowest value for any part of the version that isn’t supplied. So “6” is represented as “6.0.0” and “6.1” is represented as “6.1.0”.

That’s all there is to it! As the entire component is built without the usual iFinity branding I include, and is distributed under the same free licence as DotNetNuke, any skin developers can integrate these features into not only custom skins for particular clients, or into distributable skins they sell on Snowcovered or elsewhere.

Frequently Asked Questions

I’m guessing at some questions here as I haven’t really spoken to anyone about this, but here goes:

Why wouldn’t I just use the DnnJsInclude and DnnCssInclude skin objects in DNN 6.1?

These are the future path for everyone targeting 6.1+ DNN releases, and work well and are fully integrated into the Imbibe framework. However, in the messy real world of DNN installs, not everyone is up to date on the latest release, and building a skin to suit both current installs and future DNN 6 upgrades is tricky. The approach in this project gives the best of both worlds : simple JS and CSS inclusion now, and a seamless future upgrade path for when the client finally brings their install up to date in DNN 6.

It also suits those who want to sell/distribute a DNN 6.1 compatible skin now, but not close themselves off to those who are still running DNN 5.

Why would you include a Script object of ScriptType=”jQuery” – even in DNN 5, this was included?

It’s true that DNN5 shipped with jQuery, however, it’s possible that a specific page doesn’t have the jQuery library referenced. This is because the DNN code – somewhere in the page execution – has to call the jQuery registration code. The Script skin object with ‘ScriptType=”jQuery”’ will guarantee to the skin developer that jQuery is reference on the output page, no matter what the installed DNN version is. That way no skin developer should ever have to include the jQuery library themselves.

The same goes for the jQuery UI library – which is included in DNN 6 but not DNN 5. By including a ‘ScriptType=”jQueryUI”’ Script skin object, you can be sure of a reference to jQuery UI being included on your output page, no matter if it is DNN5 or DNN6, and you can be guaranteed not to have a duplicate jQuery UI reference in DNN 6.

What about DNN 4? Is this compatible?

The project is compiled against DNN 5.1.2 so can’t be used on earlier versions. You shouldn’t be doing DNN 4 stuff, really, it’s way out of date. However, if the powers-that-be control your DNN life and DNN 4 is it, you can probably change the reference and recompile to a DNN 4 version. It should still work OK.

Why would I want different CSS references for different DNN Versions

The inclusion of jQuery UI and the extensive use (and redefinition) of jQuery UI components (like the jQuery UI Tabs CSS classes) means that, for example, a CSS Class built for a DNN 5 skin might not layout properly when installed on a DNN 6 install. A skin designer wishing to make a cross-version compatible skin can use this component to run slightly different CSS files for 5 and 6, and their clients won’t know the difference – and perhaps most importantly – won’t ring them in the middle of the night after upgrading their DNN install and finding their layout all broken (or is it just me that doesn’t share a timezone with anyone else in the world)

What’s with this ‘Imbibe’ stuff?

This is my little personal crusade towards better project naming. I mean ‘DotNetNuke Client Resource Management Framework’ – that’s a mouthful of syllables, and distinctly Acronym-challenged (DCRMF?). So I called it Imbibe and hope it catches on. It won’t, of course, but if anyone ever comes up to me one day and goes ‘I’ve got a question about Imbibe for you’ I will give them a little high-five!

Of course, with all those FAQ’s answered, please feel free to hit me up with more questions in the comments below, or in the CodePlex project. This is my first Forge project released into the wild, so please give valuable feedback to get it up and running and living an independent life in the DNN ecosystem.

More ...

Improve Urls for the Ventrian News Article Module with the News Articles Friendly Url Provider

http://www.ifinity.com.au/Contact_Us — Thu, 15 Dec 2011 00:11:55 GMT

The big change for Url Master 2.5 was the inclusion of the ability to build custom module providers for generating module-specific Friendly Urls. Part of this strategy was to develop a set of module providers for popular third-party modules. This kicked off with the DotNetNuke Blog module provider.

The next module provider to be developed is the News Articles Friendly Url Provider, which transforms the Urls generated and used by the Ventrian News Articles module.

The new provider is a plug-in for the Url Master module, and provides seamless and easy-to-use features that completely change the way News Articles Urls look.

Improvements to Article Urls

Consider this Url which is generated by installing the News Articles module on a fresh DotNetNuke 6 installation:

http://example.com/newsarticles/tabid/135/articleType/ArticleView/23/The-Title-of-the-Article.aspx

By implementing the Url Master module, plus the News Articles Friendly Url Provider, and setting a few options*, the above Url can be changed to this:

http://example.com/the-title-of-the-article

Yes, you read that right, that’s how short you can get the Url.

But maybe you use the News Articles module as a blog, and you want some Urls that make it clearly identifiable as a blog. Change the options **, and you can have your Url look like this:

http://example.com/2011/12/15/the-title-of-the-article

(incidentally, this matches the style of Url this blog now uses)

*options used in first Url : Url Master – spaces replaced with hyphens, converted to lower case, no page extensions. News Articles Friendly Url Provider – ‘Article Style’ Urls, Don’t show DNN Page path in Url.

** options used in second Url : as per first Url, but using ‘Blog Style’ Urls instead of ‘Article Style’

How does it work?

Well, it’s simple really. Assuming you’ve already got the Url Master module installed and configured, you just install the News Aricles Friendly Url Provider via the DotNetNuke extensions. Activate the provider using the Admin->Portal Urls page, and then choose your options using the built-in provider Settings page:

Using this page, you just choose the different Url options for each page in your portal that has a News Articles module on it, apply the changes, and the Urls are instantly transformed.

What about my existing Articles?

The News Articles module has been around for a while, and there are many thousands of articles out there on the web already written. Some have been around for a long time.

The last thing you want to do is break the Urls for these old articles, some of which have good search engine rankings.

Of course, implementing this provider doesn’t stop those old articles from working. They’ll still work as intended. But you’ve got some options.

Firstly : you can activate the ‘Redirect ‘old’ style Urls to newer Urls. So if you implement the provider, all your ‘old’ Urls will be redirected across.

Secondly : you can choose which article the new Urls will start from. By default, this is id 0 – as in, all articles will use the new Ids. But you can enter your last article created (say, 145) and then any article from 146 onwards will use the new format, and earlier articles will keep using the standard format. This prevents having changes to existing articles and large-scale 301 redirects implemented and leaves articles ranking well in search engines as they are. Naturally, the redirect functionality works with the starting Article ID.

Where to get the News Articles Friendly Url Provider

The News Articles Friendly Url provider is available from the News Articles Friendly Url Provider product page. This is a licensed module, prices start from $30, but you can get a free Trial Licence by going to the licensing page. That will give you the ability to install the provider, try it out and decide whether you like the new Urls.

Online help for the module is provided through the News Articles Friendly Url Provider Knowledge Base.

The News Articles Friendly Url Provider is shown at the Url Master demonstration site.

Comments, Questions

This is a brand-new module hot off the coding bench, so if you have any comments or questions, please feel free to leave a comment below.

More ...

Implementing jQuery, jQuery UI and Javascript libraries across DotNetNuke Versions

http://www.ifinity.com.au/Contact_Us — Mon, 05 Dec 2011 23:46:46 GMT

DotNetNuke 6.0 brought jQuery UI directly into the framework as a ‘1st class’ DotNetNuke member. It also allowed developers to request the DotNetNuke jQuery registration code instead of each developer independently including the library, which prevents multiple versions and the subsequent page errors this will create. I have previously blogged about this in my post Using jQuery UI with DotNetNuke 5 and 6 in the same module.

With the release of DotNetNuke 6.1, the new Client Resource Management (aka imbibe) framework has been included. This framework not only includes jQuery and jQuery UI in DotNetNuke, but it uses a client registration framework so that other libraries and Javascript files can be included in the correct order. The best resource for this is Ian Robinson’s blog post : jQuery & jQuery UI in DotNetNuke 6.1 and 6.1.1. Because all of the various scripts are then registered in a single place, the framework can then combine them into one large js file, which drastically improves client side performance. You can read more about this in the DotNetNuke Wiki entry on the Client Resource Management API.

The 6.1 changes are an exciting inclusion into the world of javascript management for DotNetNuke development, but many (if not most!) people are not yet building solutions that target the 6.1 environment exclusively. If you’re currently building for an earlier environment which will (one day) be upgraded, or you’re building a module that may be applied against a range of DNN versions, then this blog post is for you.

While my previous blog entry was about how to leverage the jQuery UI registration, I’m going to build upon this and provide a one-stop solution to all DNN / jQuery / Javascript / CSS needs. This is simple a code file which you can include in your own project which will save you the hassle of going through and trying to write code to get jQuery to work for a specific version. This code has the smarts to work around all of the DotNetNuke versions and register the libraries for you.

Download the ScriptController Code

What the code does

The code hides away the different ways you must handle both jQuery and Javascript/Css File registration in your page. It automatically chooses the best way to handle the request based on the current DNN version. The code is backwards compatible to DotNetNuke 4.x versions, so you don’t need to reference the latest 6.1.1 DotNetNuke libraries in order to use the code (this is handled by reflection). All this means you can compile in one version of the code and be confident it will run optimised for the DotNetNuke version it gets installed in.

	DotNetNuke 4	DotNetNuke 5	DotNetNuke 6	DotNetNuke 6.1	DotNetNuke 6.1.1+
jQuery	Adds Google CDN reference	Uses Dnn jQuery Registration	Uses Dnn jQuery Registration	Uses Dnn jQuery Registration	Uses Dnn jQuery Registration
jQuery UI	Adds Google CDN reference	Adds Google CDN reference	Uses Dnn jQuery UI Registration	Uses Dnn jQuery UI Registration	Uses Dnn jQuery UI Registration
Javascript Libraries	Adds Head or Body Script registration	Adds Head or Body Script registration	Adds Head or Body Script registration	Registers script for body inclusion	Registers Script for Head or Body inclusion
Css Files	Adds Head registration	Adds Head registration	Adds Head registration	Registers file for head or body inclusion	Registers file for head or body inclusion

Above : Table of actions for code library. To understand, look at the column as per the DNN version, then at the Row for the function you would use in your code. Where they meet, this is the action that the code library does for you. However, the function call (left hand side column) is the same for all versions, the complexity is hidden away for you.

An Example:

The following code snippet shows how, in the Page_Load of a module control, the above code library is called in order to setup the required client-side scripts and Css files. The code library is called ScriptController.

//now get the javascript in
ScriptController.InjectjQueryLibary(this.Page, true, true);
//module-specific jquery code
ScriptController.InjectJsLibrary(this.Page, "moduleEdit_js", this.ControlPath + "/js/moduleEdit.js", true, ScriptController.ScriptInjectOrder.e_Default);
//and get the css file in
ScriptController.InjectCssReference(this.Page, "moduleEdit_css", this.ControlPath + "/moduleEdit.css", true, ScriptController.CssInjectOrder.f_Last);
//and put in a pre-dnn 6 ui script plus the jquery tabs library
string preDnn6CssFile = this.ControlPath + "/ui-tabs.css";
ScriptController.InjectjQueryTabsCss(this.Page, preDnn6CssFile, null);

The above code shows the ScriptController library being used. The steps are:

Inject the jQuery library reference. This call gives you the option to include the jQuery UI library as well
Inject the moduleEdit.js Javascript library. This call gives you the choice of whether to include the script in either the page or . The ScriptController.ScriptInjectOrder is an enumerated type which gives you the choice of where in the overall page output the script should be located. Note, however, that this only works for DNN 6.1+ versions – in earlier DNN versions this value will be ignored, and it’s pot luck which order your script comes out.
Inject the moduleEdit.css file. This call, like the Js registration, gives you the ability to include the file in the or , and uses an enumerated type to give you the choice where in the page order the Css file gets registered, but again, only for DNN 6.1+.
Conditionally inject a Css File for the jQuery Tabs Css theme. This call gives you the option of providing a pre-DNN 6 Css file which defines a custom jQuery UI Tabs style, and also a post-DNN 6 (ie, 6 and above) Css file for defining jQuery UI Tabs styles. The reason for this is that DNN 6 has a built-in Tabs style for the various admin pages that use the jQuery UI Tabs, and this snippet is for a module edit page. So, for pre-DNN 6 versions, it defines it’s own style (because DNN 5 doesn’t have a ‘tabs’ style), but for post-DNN 6 versions, it uses null, which means just use the standard DNN 6 tabs style.

The built-in Enumerated types for ScriptInjectOrder and CssInjectOrder give the ability to conveniently broad-brush locate where in the script order you want the script to go. This only works with DNN 6.1 because it requires the Client Resource Management API to do the work of locating the script. The enumerated types are prefixed with a_, b_, c_ so you get an idea of the order of the libraries as they are output onto the page.

Wrapping Up

This code library is free for all to use and is licensed under the same licence as the DNN core. So please take it and use it in your modules, projects and more.

If you find any bugs or problems, please let me know so I can correct them. If you come up with a better way of doing things, also let me know. If there is sufficient interest it could be located on a public source solution.

Using this approach will massively simplify the ability for developers to create multi-version code instead of having to try and step through all the minefields again.

Questions/Comments/Brickbats and Bouquets through the comments below!

Download the ScriptController Code

More ...

Google Secure Search Impacts Keyword Analysis for SEO and gives you (not provided) in Analytics - What you can do about it

http://www.ifinity.com.au/Contact_Us — Thu, 01 Dec 2011 03:01:20 GMT

Something that quietly slipped past a lot of people at the start of November was the announcement from Google that was rolling out SSL Search for all logged-in Google users.

This can be broken down like this:

- SSL Search means that the search session is conducted over https

- logged-in Google users covers the universe of people who are logged into a google service, such as iGoogle, Google+, Gmail – plus a whole pile of others.

- SSL Searches do not provide the Keyword data in the referer value for a click-through from Google

This fact that SSL searches do not pass the search query data (ie, the keywords used) onto the site that is clicked on has a very large impact on Analytics packages, which collect that data and summarize it for analysis.

This means that data using any Analytics package (not just Google Analytics) will no longer provide keyword data for some Google searches.

The justification given was that:

As search becomes an increasingly customized experience, particularly for signed in users, we believe that protecting these personalized search results is important.

Sounds good, right? They just want to protect user privacy.

Unfortunately for them, there is this little caveat:

You will continue to see aggregate query data with no change, including visits from users who aren’t signed in and visits from Google “cpc”. (italics mine)

I would find it much easier to swallow their line on protecting user privacy, except for the fact that they don’t want to protect the privacy when it comes to websites buying ads. Privacy for the user is only a concern for free traffic, not for paid traffic – and most google users wouldn’t really be able to tell the difference.

But it’s OK, Google tells us, because:

Keep in mind that the change will affect only a minority of your traffic

Well, that’s very heartening for them. As I noted previously, the change affects Google Analytics, which will no longer provide keyword data for anyone who is signed in. Instead, you will get a value that says “(not provided)”.

But if we take a look at the referral data for this site, we see that in the month of November, 2011:

‘not provided’ included 10% of all keyword searches used on the site
‘not provided’ is the keyword used for 71% of all new visits
‘not provided’ has a bounce rate of 69%

So, for all these new visits to this site, I’m unable to :

Know what they were looking for
Work out why they didn’t find what they wanted
Improve the site content to make the site more valuable to these visitors.

However, if I paid Google to run some keywords, they will happily give me all this detail. It kind of flies in the face of the mantra given to people who want to work within Google guidelines of making sure you have relevant, quality content.

For example, if I find this blog post becomes popular, it will become very difficult to know whether this is because it contains information about Google Analytics, or because it contains information about the Google SSL Search. So I won’t know if I should write more articles about one or the other. Unless, of course, I go out and buy a heap of keywords to see which one works best – then I’ll know. Imagine trying to run a retail store where you’re not allowed to ask the customer what they are looking for? The whole idea is crazy. A website still gets lots of detailed information about each visitor – right down to their location, device, whether they’ve visited before, what pages they read, what language they speak, but somehow it’s a violation of privacy to know what keyword they used? Give me a break.

Now, some readers will realise this has turned into a bit of a rant, which is a bit uncharacteristic of this blog. Let me establish up front that I respect that Google is a private company with a profit motive and, as such, are free to do whatever they want with their service. But let me also state that this marks, to me, the official point where Google jumped the shark and is no longer the benign, helpful, benevolent ‘don’t be evil’ web property we’ve all regarded them as for the last decade or so. The sheer front of them saying it’s for privacy – unless you pay up, then we don’t care how much user data you get – reeks of the sort of thing you’d expect from a PR obsessed corporation or Government department. I can take a lot of things on the chin, but treating people as non-thinking idiots with spin is one thing that doesn’t fly well for me. Those of us from Down Under are fond of straight-talking and telling it like it is.

It’s personally frustrating for me, because I have spent a lot of time over the years making DotNetNuke tools for free Google services (Analytics, Sitemaps, etc) only to find out that the key information I use for SEO on this – and any other site – is now to be gradually denied to me as an increasing amount of search comes from Google properties and signed in users. But then I think if I’m honest I always knew that would be the case – a public company has a fiduciary duty to do it’s best to reward shareholders, and it would take a very strong-willed manager indeed to ignore the amount of cash Google has left lying on the table in the past.

However, the key takeaway message here is that the ‘Don’t be evil’ motto is dead and buried, and we’re dealing with a monopolist every bit as powerful and intent on maximising it’s position as Microsoft did with it’s operating system lockout. So everyone needs to start operating and making key decisions with that background.

OK, so now what?

Well, moving past the rant onto the action. The simple fact is that a lot of us gain a large percentage of our traffic from Google web properties (and devices, too, viz Android) and so we’ve got to take what is given to us. I’m itching to use more colorful language, but I’ll restrain myself.

The rest of the post is dedicated to being pro-active about it and working out ways to ascertain the impact and think about new strategies. After all, change implies opportunity, does it no?

Quantify the size of the problem

This means tracking the growth of ‘(not provided)’ searches over time. If it’s at about 5% or so, and remains that way, it’s unlikely to cause too much bother over time. The amount of signed-in searches will be highly correlated with your sources of traffic. Basically, the more ‘tech savvy’ your audience, the more likely they’ll have a Google sign-in and be using it. If it’s static, well, then you’ll just have to work with it.

If the (not provided) keyword starts to grow, however, then you’ll need to start working out ways to try and ascertain the data. This might mean doing your own analysis on the main keywords of a page, and then manually linking that to the page and assuming that the traffic the page is getting is from those keywords.

How to measure your (not provided) traffic.

It’s easy to make the mistake of comparing apples with oranges. First, only Google organic traffic is affected. So you need to drill down in your reports, going into:

>Traffic Sources >Sources >Search >Organic and then click on the (not provided) keyword.

Above: ifinity.com.au (not provided) keyword impact, Oct/Nov 2011.

If you have an even spread between different search providers (Google, Bing, Yahoo, etc) then you’ll need to filter out the other search traffic to get an accurate picture. However, if, like my site, you get a massive majority of search traffic from Google (ie, 97%) then it really isn’t that important to filter out the other search traffic because it really isn’t material.

Either way – the only thing that is important is that you are consistent over time – it’s about tracking trends, and the key feature in doing that is to have a consistent methodology of collecting the data.

Quantify the impact of the (not provided) traffic

Now that the number of ‘private’ searches is known – you can check it against performance of other groups of traffic. This means looking at the ‘not provided’ traffic as an advanced segment, and checking it against other sources.

To create an advanced segment, click on the ‘Advanced Segments’ section, click ‘add’ then just select ‘Keyword’ ‘Exactly Matching’ (not provided) and click ‘save segment’. Give it a name like ‘(not provided) keywords’.

Above: Create a (not provided) keyword segment.

Once this segment is created, you can look at any report in Analytics then use the ‘Compare’ function to match between this segment and the ‘All Visits’ segment (or, better still, the ‘Non-paid Search Traffic’ segment.

Then you can apply these two segments to important metrics in your site, and see if the (not provided) traffic has a different profile:

Above : Goal Conversion Rate Non-paid Search Traffic vs (not provided) keywords

What this information tells me is that the (not provided) keywords follow a reasonably similar profile to all organic search traffic. Which means I can reasonably deduce that the distribution of keywords I no longer get to see is somewhat similar to the distribution of keywords I do get to see.

Taking this further, after reading this excellent blog post by Avinash Kaushik, who goes further into determining what is long tail and ‘head’, I decided to create two new custom segments in my analytics, one called ‘top 7 keywords’ and one called ‘long tail keywords’.

These segments are created by looking at a trailing 12 month history of keywords, and creating one segment that only includes traffic using those keywords (the ‘head’) and one segment that excludes all traffic using those keywords (the ‘tail’). The ‘head’ keywords are those that the site ranks very well for, and that are a clear intention of finding something on the site. These might also be called ‘brand’ keywords – because they are invariably a combination of ifinity + product name.

By applying this to the same Goal report, we can see that the (not provided) keywords perform much closer to the ‘long tail’ set than they do to ‘head’ set. Which leads me to my conclusion that, at present, the (not provided) keyword set is mostly long tail keywords and not brand keywords.

This is re-inforced further by checking the bounce rate for all content:

This shows that the bounce rate almost exactly matches the long tail keyword set.

Conclusion from this : it would appear that most of the redacted keyword traffic is of the same nature as the overall site profile, and performs closely to the ‘long tail’ of keyword data.

Action from this : monitor this over time (say, monthly) and see if any clear trends develop where this is no longer the case. If, for instance, the ‘(not provided)’ set started to outperform or underperform, you might rightly conclude that there is something significant in the set that is different in makeup to the rest of the keyword data.

Looking for other data sources

Of course, all the information in the previous post is just a ‘calm down’ action to work out what is inside the box of keywords we are no longer allowed to open. It doesn’t give us important data for tracking new keywords or developing themes presented in individual pages that perform well from search traffic (ie, hit the sweet spot of a high ranking in a well searched term). This would be vitally important if your site had relatively ‘fresh’ content (say, a news site). So what can you use?

This is where Google has thrown us a scrap of information by integrating Webmaster Tools into Google Analytics. This is a feature in the ‘new’ Analytics which has recently been rolled out. If you use Google Analytics and haven’t been on in a while, you should check out the new ‘Search Engine Optimisation’ feature. (> Traffic Sources > Search Engine Optimisation)

In order to use this function, you have to integrate your webmaster profile into your analytics profile. The webmaster profile can only be linked with a single Analytics profile.

So what does this new data give us?

Above : Search query data for ifinity.com.au.

Well, the cynic in me says a fat lot of pretty pictures with zero applicability to SEO. But you have to move on with the times – this is the new way things are going to be done so you have to get smart and move forwards.

There is a lot of junk data in here – I had no idea I was ranking for www.xxx.com (I’m guessing an adult site, I daren’t look) but throughout the forums on this site it’s a pattern people commonly use to redact the domain information when seeking help on Urls. Of course it gets me no click-through traffic, which is why I’ve never noticed. But it is noise that needs to get filtered out of the data in order to start working with the useful information.

It’s important to realise that this data has been in Webmaster console for a while, but is now presented in an easy-to-access way alongside your Analytics data. What we are looking at here is the google.com side of things - how many impressions search terms had, how many clicks, and your sites average position for those impressions. Finally it gives you a click-through-rate (CTR).

While it’s not obvious at first glance, this is the reverse side of your keyword data on your site. So when you have a suspicion that a particular keyword is performing well for you, you can go to this report and search on that keyword (or combinations thereof). If, in the hypothetical case I’ve already outlined, you have a page doing well and for some reason the majority of keywords working for that page are unknown to you, then you can come to this page and search on both sets of keywords and see which is performing better from the google.com side of things.

You can also do a search through the CTR rates and impressions to find which keywords you could improve and optimise for. Combined with the Google Keyword tool, you should be able to ascertain the broad trends well enough, despite the fact that it takes a little more work.

Conclusions

There is an old saying that goes like ‘when the rules change, the future changes’. The rules for keyword data have just changed, and so the future has now changed. You should probably be like me, get your toddler tantrum rant out of the way and then get on with figuring out how the future is going to work. This is all very new, so it’s definitely important to monitor this space for changes, and additions. It’s possible that Google might recant and start providing the data again, particularly if it affects their ad-buying business. Or it’s possible that Google+ takes off and challenge Facebook and a majority of users will be logged on by default. It’s possible that Android devices will stop referring search data or some other type scenario.

The important takeaway is to start thinking about these scenarios now and work out your strategy to find the good keywords for your site, and how to optimise for them. That part is unlikely to change at all.

What do you think about it? What percent of your traffic is now (not provided)? Please let me know via the comments below.

More ...

DotNetNuke World 2011 Wrap up

http://www.ifinity.com.au/Contact_Us — Tue, 22 Nov 2011 03:42:16 GMT

Well, it’s a week since I returned from the whirlwind that was DotNetNuke World. Already things are starting to slip back into normality from the head-spinning fury of activity that was the conference.

All I can say is that if you didn’t go, start pencilling in the date and the budget to go next year.

This was the first year that DotNetNuke had it’s own, stand-alone conference, one that wasn’t co-located with the bigger DevConnections conference. It was also a change in location, from Las Vegas to Orlando. These two changes made a very big difference to the feel of the conference.

Because it was only DotNetNuke people, it immediately felt more inclusive, more friendly and more focussed. Because it was no longer in the cavernous halls of the DevConnections conference with what seems like a mile of walking to and from the hotel, it immediately felt more accessible. And because there was *blink blink* outside areas to break out into, it gave everyone a chance to enjoy some warm Florida sunshine (not that I have any shortage of that where I come from, but those Northern types seemed to enjoy it).

Here was an event where everyone you saw with a white lanyard on was a great person to have a chat to.

Conference Highlights

The Keynote speeches from Shaun Walker and Navin Nagiah were top quality. Shaun covered off the achievements of DotNetNuke in the past 12 months, and the roadmap of features going forwards. This included showcasing the impressive new Mobile features released in DNN 6.1, and answering some of those burning questions, like when were the social features going to be included. Shaun also recapped some of the impressive awards gained by DNN in 2011, including making the Gartner Magic Quadrant and placing in the Inc. 500 list of the fastest growing companies. It’s easy to forget how fast all this has happened, because just 3 years ago DotNetNuke was a tiny company formed around the ownership of the DotNetNuke open source project. Now it’s growing fast and the conference is evidence for all to see. One statistics : all time DotNetNuke downloads are now at 7 million, and there are 700,000 live websites running DotNetNuke in the world.

Of course, the big laugh of the day was reserved for the revealing of the Shaun Walker Bobblehead doll. Mitch Bishop, the new Chief Marketing Officer at DotNetNuke, revealed that they had made a limited-edition run of 50 ‘bobblehead’ dolls of Shaun. Mitch presented one of these to a clearly flummoxed Shaun, and then told the crowd that any great questions, presentations, antics throughout the conference would result in the presentation of a bobblehead. From then, it was up to people to come up with interesting ways of what to do with their bobbleheads – in the bounds of good taste, of course! This even included stripping down and jumping in the pool to retrieve a bobble head, which Malik of Pointclick Technologies did, much to everyone's amusement.

Navin’s keynote was a more sober affair, and clearly laid out the philosophy and strategy behind DotNetNuke and exhorted us in the crowd to do better, to work harder, because the competition out there in the Website platform business is fierce. There is still a massive market for people to be running a complete website solution like DotNetNuke but it’s likely to be a winner takes all result, and with 1200 different options available, DotNetNuke needs to concentrate on being in the top 3.

The ‘DNN After Dark’ function was a huge improvement over previous events I had attended and everyone there clearly had a good time. If you were there, you’ll know about the infamous Nerf dart war that broke out using promotional toys from Arrow Consulting. If that sounds like a bunch of computer nerds gone wild, well, it would be hard to disabuse that notion. But more realistically it just shows that everyone was having a great time and it was a very fun event. The fact that the room was full shows how keen attendees are to engage in both the learning and the social segments of the conference.

Presentations

Sadly with three of my own presentations to deliver, and lots of interesting conversations to be had in the hallways and breakout areas, I didn’t get to attend many sessions, and only grabbed parts of different presentations throughout the two full days of presenting. But a lot of people told me there was some great sessions delivered. Every session I peeked into was well attended and well regarded.

For my sessions, I did three topics. As a few people remarked – I must have done something to annoy the organisers to get that many sessions. But in reality I had a lot of fun presenting and it was great to cover three entirely different topics:

DotNetNuke on Azure Cloud Servers

This presentation was both a discussion on how to create a DotNetNuke installation using the DotNetNuke Azure Accelerator, and also a discussion on how to strategically use Azure with DNN, both as a hosting service, but also for hosting content or using the CDN.

If you missed this presentation, you can read more about it here, and don’t miss the link provided by Microsoft to get a free 90 day trial for Azure. Everyone should grab a copy of the Azure Accelerator, sign up for a free Azure trial, and see how easy it is to create a DNN website on Azure.

See separate blog post on this session including the slides.

Your humble blogger presenting the session on DotNetNuke and Azure. Photo courtesy David Rodriguez.

Tracking Social Media Campaigns for Effectiveness

In this session, I covered off many of the tools available for tracking your Social media activity. I then presented the concept of gathering all these different metrics into a central location, and creating your own trend lines. The idea with this is to gather the metrics on a periodic basis, then map your own trends based on the things that are most important to your campaign. Part of this is identifying the goals of the campaign (followers, downloads, sales?) Once this is in place, you can monitor which parts of your social media campaign are the most effective (in meeting your goals) and use simple analysis to double-down on the things that work, and abandon or at least cut back on the things that aren’t.

See separate blog post on this session including the slides.

Selling code in the DotNetNuke Store : from idea to execution

I had submitted this concept to the organisers of DotNetNuke conferences for 3 years in a row, so I was delighted when it was selected as a topic. My only regret was the short 50 minute timeline with which to try and cram in all the things I have to say on this topic. What the audience received was a high-speed download of my thoughts on the world of software development, how to become a successful vendor, and a presentation on how the upcoming changes to Snowcovered (soon to be re-branded the DotNetNuke store) are about to make the DotNetNuke eco-system a great place to be if you have the ability to write good code and indulge in a bit of shameless marketing. This session was a lot of fun and it’s just a shame I didn’t get the chance to connect with more people who have questions on becoming part of this exciting little corner of the software industry. Perhaps I might start a new blog series or something similar on this very topic because I sense there is great interest in it.

See separate blog post on this session including the slides

Putting the last touches on one of my presentations while Scott Willhite questions my choice of hardware in the DotNetNuke Community breakout area.

Photo courtesy Will Strohl

Networking

All I can say about the networking at the DotNetNuke World conference is that it can’t be beaten. This is the third year in a row that I have attended a DotNetNuke conference and I still run into people I haven’t met, some of whom are new to using DotNetNuke, some of whom are old hands. And each year I enjoy renewing the friendships with people I have already met. If all the conferences you’ve ever been to are full of people politely sipping coffee and making small talk until they can escape back to their rooms, you’ve got to attend a future DotNetNuke conference to witness the high energy exchanges of ideas and information, the meetings and more. From the early morning breakfast discussions to the late-night free and frank exchanges of ideas in the hotel bar, the fun just never stops.

However, apart from the fun aspect of meeting people and finding out what they are working on, the networking at DNN World made me realise that the DotNetNuke platform is rapidly growing up. Where once my main conversations where with smaller system integrators, hosting firms and the like, increasingly my conversations where with government departments, representatives from larger companies, and people working on big projects. This is an important change, because it shows that developers like myself need to step up again to a higher level of quality and support, and to recognise that the combination of people ‘out there’ is changing quickly in the mix.

Deep in conversation at the lunch table during DotNetNuke World. Photo courtesy Will Strohl

Conclusions and Wrap up

It’s incredibly important for people like myself who are geographically isolated from many others who work on the same things to attend conferences like DotNetNuke World. It’s why I spend the time and the money to attend, even though doing so means spending well over 24 hours in transit to get from my home to the conference. The rewards certainly outweigh the costs, even though when it comes to booking it’s easy to feel that this won’t be the case.

With DotNetNuke World 2011 in Orlando, the concept of the DotNetNuke conference really came of age. It developed a confidence in itself as a conference, and a confidence of DotNetNuke as a platform not only for writing software and building websites, but also for building businesses and relationships that will probably endure for a long time. In the same way the conference no longer felt like a bolt-on to a .NET conference, the platform no longer feels like a bolt-on to the .NET framework but an entity unto itself that even Microsoft is taking notice of and supporting.

Mitch Bishop asked us all to tell 5 people about the conference so that it can double in size next year. I’m using my blog to do my part - I hope I’ve got those who attended smiling in memory, and those who didn’t pencilling attendance for 2012 into their personal plan for next year. The dates will be announced much earlier this time, so there will be no reason not to go. Will I see you there?

My Shaun Walker Bobblehead learns a thing or two between sessions

Want to see more? Visit the Flickr DotNetNuke World photoset. Please remember to abide by the licensing attached to individual photos.

More ...

Selling your code in the DotNetNuke store

http://www.ifinity.com.au/Contact_Us — Tue, 22 Nov 2011 03:35:00 GMT

This blog post is a summary of my presentation at the DotNetNuke World 2011 conference held in Orlando, Florida.

This presentation was one that I have wanted to do for years, and my only issue was that I only had 50 minutes to present the life-cycle of a developer who has a great idea to receiving money for their sales. The session covered ideas, marketing, support, pricing, licensing, the new DotNetNuke store and much more.

Tracking your Social Media Campaigns for Effectiveness using free tools

http://www.ifinity.com.au/Contact_Us — Tue, 22 Nov 2011 03:20:00 GMT

This blog post is a summary of the presentation I did at the DotNetNuke World 2011 conference.

The topic was tracking social media campaigns for effectiveness – and the synopsis of the talk I gave was on how to use different metrics available from free tools, and how to combine those together in your own way to aggregate the data. Once that was done, using trends to identify which of your social media actions are effective in achieving your goals, and then double-down on the things that are working well

Installing DotNetNuke on Microsoft Azure Cloud Servers

http://www.ifinity.com.au/Contact_Us — Tue, 22 Nov 2011 03:07:00 GMT

This post is a summary of the presentation I did at the DotNetNuke World 2011 conference in Orlando, Florida.

The sessions was centred around showing how to use the DotNetNuke Azure Accelerator which can be downloaded from Codeplex.

Google adds Snippets for Bulleted Lists Search Engine Result

http://www.ifinity.com.au/Contact_Us — Tue, 01 Nov 2011 01:06:41 GMT

While doing some poking around on Google today I noticed an interesting change in the SERP result for this site.

I tag all of the Blog posts with my own Tagger module which lists the tagged results out on a tag list page. This is reached under a Url like:

http://www.ifinity.com.auhttp://www.ifinity.com.au/Explore_Tags/Tag/Redirect

The above Url lists out all the items on the site that have been tagged with ‘Redirect’.

Incidentally, the Tagger module was recently upgraded to a new version, which included popup tag editing and now can merge the tag results with the Core tagging modules. This means you can use it as a tag cloud for core tags, or use it to add the custom tags as originally designed, or a blend of both.

Anyway, on this site it mostly is used to tag the blog entries, and then list them back out again when navigated from the tag cloud.

So far so good – nothing unexpected.

But it looks like Google has added yet another SERP listing type, which looks like this:

The ‘meta’ description for the page is nowhere to be seen, and a random sample of text has not replaced it. Instead we get a structured list of content taken from within the body of the Html itself.

Notice how this provides a couple of things:

- jump locations to popular content locations (Register, Login,Home)

- unordered list of the top results, using the link text (blog title) as the summary

- the list contains the most relevant links, and aren’t the same order/priority as the result in the actual page

- highlights within the list where the keyword search matched

- an estimate of how many items are listed on the page (ie, 10+ items).

This appears in the overall page like this (showing the preview):

This new feature has been named ‘SEP Bullet Lists’ and ‘Rich Snippet for Listings’

Possible advantages of these lists is it gives visitors a deep-dive into content. We all know the benefit of bulleted lists when trying to present complex topics in a way to time-poor observers or readers. The majority of Powerpoint slides ever made used bulleted lists, and they are everywhere.

This could particularly advantage e-commerce sites if they can get actual product listings into bulleted lists, because it will give visitors a very good idea of what types of products they might find within the site.

How do I get those on my site?

Well, like so many things in Google-land, you don’t get a (direct) choice whether or not you get upgraded listings. It’s something that the big brain of Google decides for itself when you’re worthy.

The obvious question might be whether you need to use a

blocks on the page.

Here’s the official word from the ‘Inside Search’ blog : New snippets for list pages

If a search result consists mostly of a structured list, like a table or series of bullets, we’ll show a list of three relevant rows or items underneath the result in a bulleted format. The snippet will also show an approximate count of the total number of rows or items on the page (for example, “30+ items” in the screenshot below).

This feature rolled out during September 2011.

So the key is:

- structured list for the html that contains your content – think a

elements.

- relevant results in that list and relevance for the entire page

If you’re building a content module or perhaps authoring your Html manually, you may want to consider these points. As has always been the case, clean, well structured Html is a factor in getting good search results.

Now would be a good time to check if you’ve already had your results changed, and to think about how you might be able to leverage this change to get a better click-through rate when your site does feature in the results page.

More ...

Maintaining your Google Analytics Tracking through redirects

http://www.ifinity.com.au/Contact_Us — Fri, 28 Oct 2011 08:02:38 GMT

A very useful feature of Google Analytics is the ability to track different urls for the same thing by including items such as campaign, source, medium, keyword and ad version. This allows you to host links in different locations and then determine which is the most successful location, ad version, or combination.

This gives you extra information in your Analytics page, like this:

Above : Detailed Medium + Campaign information shown in Google Analytics from Url tracking codes

However, sometimes during the process of redirecting, this detail gets lost, and as a result Google Analytics loses the information, and can’t provide accurate reports. This also affects the use of AdWords.

With the Url Master module, the redirection sometimes occurs because another part of the Url triggers a redirect action. This could be because it has the wrong domain name, the wrong case, or maybe it has a TabId parameter included in it.

Because of the way the module works, it attempts to discern which parts of a raw Url is part of a querystring, and which part is part of a friendly Url path. In DotNetNuke, a raw Url looks something like http://example.com/default.aspx?tabid=165&key=value. If this were redirected using the Url Master module, you’d end up with http://example.com/page-name/key/value.aspx – which is most likely correct.

However, if you include analytics tracking information in the Url, then the Url Master module tends to not know where the tracking codes start and the rest of the path ends. And so you might end up with a Url that looks like this:

http://example.com/page-name/key/value/utm_source/test+source/utm_keyword/test+keyword/utm_campaign/test+campaign.aspx

Which isn’t correct, because the analytics code looks specifically at the querystring of the Url for the tracking information, and it’s been moved into the main path of the Url.

What the above Url should look like is this:

http://example.com/page-name/key/value.aspx?utm_source=test+source&utm_keyword=test+keyword&utm_campaign=test+campaign

If you have the above problem, you’ll probably find out because expected analytics tracking isn’t working, and you’re getting discrepancies between your data.

NOTE: The Google Analytics Url Builder Tool is a good way to build these Urls quickly.

The Url Master ‘doNotIncludeInPathRegex’ Filter is the Solution

There is a regex field in the Url Master module which handles this situation. What this regex pattern does is identify key/value pairs that shouldn’t be in the path, and moves them to the querystring. So, in this case, all you need to do is identify the utm_ parts, and the inbuilt logic will shuffle them to a querystring value.

The one caveat is that you have to identify all of the path – not just the ‘key’ – you need to capture the /key/value pair.

For the above url with Google tracking codes, you could just write a matching pattern like this:

(/utm_source/[^/]+)|(/utm_keyword/[^/]+)|(/utm_campaign/[^/]+)

This would match both the key - /utm_source and the value /[^/']+ .

Small Regex tutorial – the [a] pattern matches any ‘a’ character. So [/] matches any / in some text. The ^ pattern is a NOT operator. So [^/'] matches anything that is NOT /. And the + character following means ‘match 1 or more times’. So [^/]+ means ‘match 1 or more characters you find that aren’t a ‘/’. And that’s how you match any value that follows utm_source. See, regex isn’t that hard, is it?

However, there is one small problem with the above pattern is that it (1) presumes the source/keyword/campaign values will always be in the correct order, and that there won’t be any other utm_ values. In fact there are 5 possible utm_ keys – including term, medium, keyword and content.

So what we need is a more generic function that will make sure NO Google Analytics tracking segments are matched and included in a Url path. And that’s our solution regex:

(/utm[^/]+/[^/]+)+

Anyone who was paying attention in the first Regex tutorial will know that this says match anything starting with /utmxxxxx and the value following that, and match as many of those as you can find, as long as they are all grouped together.

At this point, you need to go to your Host->Friendly Url Settings page, navigate to the Regex Settings tab, scroll down to the ‘doNotIncludeInPathRegex’ field, and copy and paste that value in.

Apply the changes, and you should have fixed your problem!

This information is also posted on the Url Master Knowledge Base.

A Note about the DotNetNuke Blog Module

If you’re thinking about tracking your Blog entries from your DotNetNuke hosted blog, you’ll come into a little bit of trouble.

The DotNetNuke Blog module has a feature where by it will enforce the ‘Permalink’ Url (which is just the canonical Url of a post) by comparing it to the requested Url for an entry, and if they are different, it will 301 redirect away from the requested Url to the stored Permalink Url. Which is great, because it means that you won’t get any duplicate content problems caused by different blog posts being linked with different Urls.

But the Blog authors didn’t foresee a world where everyone had utmsource=my+blog+campaign stuck on the back of the Urls, and it will detect a tracked blog entry as incorrect, and redirect away. And because the tracking in Google Analytics is done by javascript once the page is loaded, you’ll lose the extra utm_ parameters on the querystring, and your tracking will not work.

I’ve rolled my own solution on this blog, which just means cracking open the source code and adding a little change to compare the Urls sans querystring. I’ll monitor this for a while, and if it’s working OK will see if I can get it included in the next Blog release. But if you’re trying to track your blog entries using Analytics with unique tracking codes, you’ll find that it isn’t working.

Sound Interesting?

I’m doing an entire session on Tracking Social Media Campaigns for Effectiveness at the upcoming DotNetNuke World conference. Why not come along and learn more information like this?

Do you know of any more problems with tracking Urls in DotNetNuke via Analytics?

Let me know via the comments and I’ll ferret out an answer for you!

More ...

Crafty Code

New Skin Objects for including jQuery, Javascript and CSS Stylesheets in DotNetNuke Skins

What’s in the box?

Script

Stylesheet

PageLink

Portal Date

Using the Script Object

ScriptType

Location

Name

Order

InHeader

StyleSheet

Media

Name

Location

Order

FromVersion / ToVersion

Frequently Asked Questions

Improve Urls for the Ventrian News Article Module with the News Articles Friendly Url Provider

Improvements to Article Urls

Other News Articles Urls

Page Urls

Author Urls

Archive Urls

How does it work?

What about my existing Articles?

Where to get the News Articles Friendly Url Provider

Comments, Questions

Implementing jQuery, jQuery UI and Javascript libraries across DotNetNuke Versions

What the code does

Wrapping Up

Google Secure Search Impacts Keyword Analysis for SEO and gives you (not provided) in Analytics - What you can do about it

Quantify the size of the problem

Quantify the impact of the (not provided) traffic

Looking for other data sources

Conclusions

DotNetNuke World 2011 Wrap up

Conference Highlights

Presentations

DotNetNuke on Azure Cloud Servers

Tracking Social Media Campaigns for Effectiveness

Selling code in the DotNetNuke Store : from idea to execution

Networking

Conclusions and Wrap up

Selling your code in the DotNetNuke store

Tracking your Social Media Campaigns for Effectiveness using free tools

Installing DotNetNuke on Microsoft Azure Cloud Servers

Google adds Snippets for Bulleted Lists Search Engine Result

How do I get those on my site?

Maintaining your Google Analytics Tracking through redirects

The Url Master ‘doNotIncludeInPathRegex’ Filter is the Solution

A Note about the DotNetNuke Blog Module

Sound Interesting?

Do you know of any more problems with tracking Urls in DotNetNuke via Analytics?