Wherefore Universal Analytics

, Wednesday, April 16th, 2014

Since it has come out of beta, we have been fielding a lot of questions about Universal Analytics, the latest and greatest analytics package from Google.  So I’ve decided to answer a few of those questions here.

 What Makes Universal Analytics So Different?

There are a few things that make Universal Analytics different from Google Analytics. There are the three in particular that we at Beaconfire are super-excited about.

The ability to report more on visitors instead of visits.

With standard Google Analytics, the focus has always been on the visit. While there were hacks, there has never been an easy way to say “if someone comes to the site on their work computer, then their home computer, then their phone, treat them as one person.”

With Universal Analytics, it becomes possible to link those three visits. It will work best when a user can have a unique identifier (like a constituent ID). So this may not be for everyone. But we’re still pretty thrilled about it.

It’s also possible to make advanced segments based on visitors instead of visits. In the past, if you made an advanced segment, it could only be visit-based: “Show me all the visits where someone converted.” Now it can be “Show me all the visits for any visitors who ever converted.” It can give you more interesting insights into user behavior across visits.

Custom Dimensions & Metrics

In Google Analytics, you can have their dimensions (page, page title, etc.) and their metrics (bounce rate, pageviews, visits, visitors, etc.) In Universal Analytics, you can make your own. So, for example, let’s say you tag all your pages with topic tags. You could pass those topic tags to Universal Analytics, and just as you might run page reports, you could run topic reports and analyze site performance based on the various topics site visitors go to.

Integration with Google Tag Manager

Integration with Google Tag Manager is not exclusive to Universal Analytics. But it’s the direction that we’re taking for any new analytics set up. In the past, you put  analytics code on a page. Then, if you wanted to do any customizations to the analytics (event tracking, cross-domain tracking, just to name a few), you’d have to go back into the code and make updates.  There is always something about going into codes in templates that makes me a little nervous, and I heavily lean on a lot of tech folks here at to help me out with these things.

Google Tag Manager changes that. You create a Tag Manager Account and you get a piece of code. You put that code on the page. But after that, much of the configuration will take place in the Google Tag Manager UI, and NOT in the code. It has a testing mode. It still takes a bit of “programmer brain” to navigate and set up the tag manager, but it is significantly easier and less risky than going into templates and updating script files.

Another bright spot of the tag manager – it’s not exclusive to Analytics, or even to Google tools. If you have pixels or code from other tracking tools, you can enter it in tag manager, and tag manager will deliver it to the site.

What is the future of “old” analytics?

According to Google, at some point, standard Google Analytics will be deprecated. They’ve said this in Phase 4 of their plan (right now, we are in Phase 3):

https://developers.google.com/analytics/devguides/collection/upgrade/

Once we hit Phase 4, old analytics will work for about 2 years.

I suspect that once we hit that point, you will not be allowed to create any new “old analytics” properties. Which means if you have a mini-site or a website, you will have to put Universal Analytics on it.

In short, Universal Analytics is inevitable.

 Are there any privacy or security concerns?

Some folks think you need to update your website’s privacy policy if you want to use Universal Analytics, but that is not entirely true. There is one features within Universal Analytics that does require you to change your privacy policy, and that is the collection of demographic data. But you have to turn this feature on.

I find it convenient that with Google Tag Manager, I can slap some code on a page, and then use the Tag Manager UI to make any changes. But that also has its security risks, as well. You’re essentially giving Google permissions to write on your web page. It makes the security-conscious a little bit nervous. While I’m not ringing any alarms just yet, you should take care. If you do decide to implement with Tag Manager, you should have good security policies in place (like changing passwords whenever someone leaves, for example).

How/when to migrate

You can run Universal Analytics in tandem with Google Analytics. In fact, that’s what we’re recommend. One of my colleagues wrote a blog post on it here: http://www.beaconfire.com/blog/2014/04/universal-analytics-to-upgrade-or-not-to-upgrade

Make Your Website Mobile Friendly with Responsive Design

, Friday, April 11th, 2014

This is a re-post of a piece that first appeared on the NTen blog on 4/7/2014

The 14NTC was a great time for me and everyone else I ran in to. I especially appreciate the tenacious group who attended the ”Make it Mobile!“ session that I did with Niki Hammond from MSDS on Saturday, March 15.  We had a good time presenting about Mobile and Responsive Design, and similar to every session I attended, the Q&A was definitely the best part.

Responsive Web Design is the latest in a long line of terms that have really caught on and, depending on who you ask, either signals a complete shift in the way that we work, or describes some cool new techniques to consider when designing and building websites.  I tend to fall into the first group to such an extent that I believe a year from now, what we are now calling “Responsive Web Design (RWD)” will simply be called “Web Design.”

We need to call it responsive now because it represents a big enough evolutionary leap to require us to define specific techniques that we could use to accomplish it, but the more we do responsive sites, the more it sinks in that there’s really no reason to not make a website responsive.

 

That said, here are a few important terms that may help to clarify what I’m talking about when I say “responsive.”

Adaptive Web Design uses a pre-defined set of layout sizes based on screen size. You can make informed decisions based on your site analytics that tell you which devices people are using when they visit your site, and then targeting those devices.  There will likely be some device detection going on here as well, and some amount of server-side changes depending on the device.

Responsive Web Design on the other hand, is comprised of three things: a fluid grid, flexible images, and media queries (CSS rules that kick in at certain viewport widths, or based on other properties of the device viewport).

Finally, “responsive” (little “r”) is a less strict way of describing this new world of design thinking, along with some of the techniques used to accomplish them.  RWD has a real definition forwarded by Ethan Marcotte, this “little r” version is more a feeling; a sensibility; an ethos.

“Today, anything that’s fixed and unresponsive isn’t web design, it’s something else. If you don’t embrace the inherent fluidity of the web, you’re not a web designer, you’re something else.”

-Jeffrey Zeldman

What Sets Responsive Apart from Adaptive?

A site should work on any screen size you can throw at it. It’s not about the specific device being used, it’s about the size of the screen.  The web is responsive by nature.  It’s always been responsive, and it is through our own design decisions and coding practices that we have built sites that were not responsive but were, rather, trying to mimic the print world with which we were more familiar.

Being successful with RWD means accepting that you can’t control everything.  It’s a change in philosophy as much as it is a change in design and coding practices.  It’s about UX folks, Designers, Front End Developers, Tech Leads, Software Engineers, all of us, understanding how web pages behave and using that to our advantage when planning and designing the experiences we ultimately build for our target audiences.

RWD is less about the techniques and more about the process.

Those of us that are doing RWD recognize that it’s not something that just happens after the site has been planned and designed, and is now ready to be built.  It involves a sea change in the entire process we follow from the first workshop with clients, to pushing the new site out the door onto the big scary Internet.  Check out Jared Spool and Jason Grigsby talking about how RWD has impacted their design process.

For the past couple of years, most of the sites we have built at Beaconfire have been responsive.  From our perspective, the reason is simple: The end results are more usable for more people and, as your process evolves and you adjust to designing sites in a responsive way, it just doesn’t make sense to do it any other way.

What if you can’t pull up stakes and do an entire RWD process from soup to nuts? 

What if you just redesigned your organization’s website last year and you really need it to work better on handheld devices now, but can’t redesign the whole site for another year or two? 

“Responsive Retrofit” can be a viable option depending on the site.  It is entirely possible that you do not need to completely redesign your site or go through an entire separate creative process. By not creating wireframes or designs and, instead, simply starting with the HTML and CSS that you have now, we add responsive CSS and can, in many cases, make the layouts work better on smaller screens. Results may vary and you may be limited in how much of the site you can make responsive.  The important thing is to be able to evaluate the site up front and have a clear idea of how responsive it can be made, and what tradeoffs there may be.

Be forewarned: In a true responsive design you have plans that minimize the amount of markup, CSS, JS, and images that you deliver to devices.  The retrofit approach very commonly increases the number of files delivered to the device and the overall “weight” of the page, and should only be considered if your site already performs well in terms of speed.

Here are six key things to look for when evaluating an existing static website for a retrofit:

  • How well was the site coded?  Is there nice clean HTML and few (if any) tables?
  • Is the order of blocks already correct for what you want to accomplish in a layout where everything will stack in a single column?
  • Are there classes and IDs for you to leverage without the need for overly complex CSS selectors?
  • Does the site contain consistently sized images that will all work well at 300-400 pixels wide (small images don’t size up well, huge images are, well, huge)?
  • Are all your page layouts consistent and few?  Too much variety will make for more work.
  • Is the navigation simple, and does getting to deep content not *require* the use of navigation?  If so, do your mobile users need access to that content?

Of all of these things, the hardest nut to crack is almost certainly going to be your navigation. This is especially if you have a really deep architecture.  But generally, if you like the answers to those six questions, your site may very well be a candidate for a retrofit.

Universal Analytics – To Upgrade or Not to Upgrade

, Wednesday, April 9th, 2014

Recently, a lot of our clients have been asking us if they should upgrade their standard Google Analytics (ga.js) to the new Universal Analytics (analytics.js.) Based on how Google has treated past versions of analytics (remember Urchin) we know that they will continue to support standard Google Analytics for several years, but that all new development will be done on the new version, Universal Analytics.

So, let’s upgrade, right?
As expected, Universal Analytics has a lot of great features that can’t be found in standard Google Analytics. This includes the ability to do more configuration customizations, the ability to import offline data (including offline conversion data), and from a reporting perspective the ability to see multi-device activity. As more users utilize different devices to interact with your website, multi-device tracking is essential.

Read the rest of this entry

In-Page Font Resizers are Bad

, Friday, April 4th, 2014

I’m never one to soften a polemic stance, so here we go.

“In page font resizers are bad.  Bad usability.  Bad accessibility.  Bad design.”

-Tim Arnold 4/4/2014

There, I said it.  I feel so free.

First, let me say that most websites I code have included a font resizer. I’ve been pushing back gently on some of the assumptions about what they accomplish and how successful they are at doing so but I think the time has some to be less gentle and take a more critical look at whether we are doing good or harm when we use these things.

Read the rest of this entry

Responsive Email Design & More

, Friday, March 28th, 2014

On Wednesday, my colleague Justine and I produced a webinar entitled “Mobile Friendly Emails for any Organization.” In the webinar, we covered the shifting landscape of email including where users are reading email and how it impacts your marketing program. We also discussed tactics on how to get the most out of your email marketing program, and provided a framework for creating responsive emails. Finally, we tackled basic reporting concepts.

Read the rest of this entry

Get Updates

New posts, webinar and event invitations, and more.