Dave’s Answer:

This isn’t true, and I don’t know why people think it’s a risk. Google has a ton of smart engineers: do you think they’d have a popular product like Google Analytics (which I run on this site) be something that could be exploited by hackers? I sure don’t.

But to clarify, I asked my friend Bennett Haselton to share his thoughts on this matter. Bennett writes for the programmer/geek site Slashdot, among others, and has a good handle on how people who break into sites exploit weaknesses. Here’s what he said:

Your friend, or his web team, is in the twilight zone or something. It’s not even theoretically possible for Google Analytics to provide a “doorway” to hackers.

When you add Google Analytics code to your website, your webserver just sees that as normal “content” — just a sequence of bytes, like an image or a video file or a text file — and when the user requests it, the webserver sends it to them, just as the webserver sends other content like images and videos. Thus it’s not possible for adding Google Analytics to enable anyone to “hack” your site, because from the point of view of the webserver, it’s just normal content that it sends to the user.

What follows is how I would summarize it for a non-techie audience, although only a non-techie can tell if the explanation is any good

What happens when someone goes to your website, if you have a Google Analytics tag on your page:

1. The user loads your page
2. The user’s web browser sees that you have a tag on your page. This tag is basically a set of instructions that tells the user’s browser to request some content from the Google Analytics server.
3. The user’s computer requests that content from the Google Analytics server.
4. At the end of the month, you as the webmaster, can go to the Google Analytics page and log in to your Google Analytics account, to see how many times a user loaded the content that was requested in step #3. That way Google can tell you how many times the content was loaded, what countries it was loaded from, etc. That’s what Google Analytics does.

Note that in these four steps, there is never a point where any “instructions” (code) are actually run *on* your webserver. After step #1, your webserver is out of the loop entirely. The Google Analytics code is a set of instructions on your webpage, but those instructions (which say “Go and fetch some content from Google’s servers”) are instructions that are followed by your web browser. The Google Analytics code doesn’t tell your webserver to “do” anything.

The only time installing third-party programs onto your website could expose your website to security attacks, would be in the case of programs like WordPress, because WordPress consists of code (instructions) that is actually run *by the webserver*. If the authors of WordPress have programmed it carefully, the code won’t do anything harmful, but sometimes attackers will find ways to exploit it and cause it to do harmful things. In that case you always have to make sure you have the latest WordPress fixes installed.

The distinction between *code* and *content* can help simplify things without having to spend years learning about computer security. It’s what makes it intuitive to see why installing Google Analytics (or an image or a video file) cannot enable anyone to “break into” your website, but installing WordPress could (sometimes) enable a break-in.

Comments

Segmentation is at the heart of most real analysis – and in this series I’m focusing on analytic segmentation – not segmentation of large and significant populations for reporting purposes. In the last post, I showed how we used segmentation to isolate, study and improve the behavior of printed catalog searchers coming online to look for a specific product. Today, I’m going to show an example where visitor geography turned out to be the key to effective segmentation and personalization.

Example: Geo-Based Searching

Use Case: A real-estate focused site knew that geography was probably important to visitor behavior, but despite many years of operation there was significant disagreement about the online population’s searching behavior and how it related to where they accessed the internet. 

Client Question: The client wanted to know how visitor geography and search behavior were related. Key questions included:

• Did most visitors use the site to look at properties outside or inside their current location?
• Did visitors search the same locations repeatedly?
• Were there significant differences between visitors searching in their own geography vs. those searching outside their own geography?

Measurement Issues: Search geography was captured as an input search string – making it difficult to consistently resolve since it had many variations.

Tool: We used Omniture’s Data Warehouse tool for the analysis.

Methodology: One of the challenges here was that we didn’t have a direct correlation between search term and visitor geography. Getting that kind of report is one of the reasons we usually recommend that companies deploy a Vista rule to copy the visitor geography into variables. However, with data warehouse, we could get at the data. It was more a question of how to do it conveniently.

Let’s start with how we tackled the first question – did visitors use the site to look at properties within or outside their current geography? Obviously, we knew we were going to see both behaviors, but the relative percentages were hotly debated.

Unfortunately, in web analytics systems as they exist today, you can’t generally create a segmentation based on the comparison of two variables. In other words, we couldn’t use a query that selected all the visits where the internal search term was contained within the SiteCatalyst visitor DMA. In addition, we didn’t have the ability to apply any operators to the various strings involved – so comparison would be inherently hit or miss.

One alternative was to produce a giant data warehouse request that simply gave us all the combinations of visitor geo and search term along with visit count. We could then load this into Access or SQL-Server and have at it.

For an analysis that required comprehensive coverage, that might have been our approach. But this was just a piece of wider site analysis and we really couldn’t afford to spend more than about 8-10 hours on the whole use-case. So what we decided to do was focus on a small set of target markets that we took to be representative – markets like Bakersfield for mid-size cities and Tahoe for vacation destinations.

We then built a segmentation based on search terms that contained the relevant target area. This took advantage of the segmentation builder’s ability to use “Contains “and multiple rules strung together.

Using segments like this, we generated reports on visitor geography for each target area. This allowed us to answer the first question in detail. For each target area, we knew what percentage of the searchers originated in the target area, what percentage were adjacent (from nearby DMAs) and what percentage were outside the target area.

It turned out that on this particular site, for all areas except resort cities like Tahoe, a very heavy majority of searchers were local.

Note that this segmentation was visit-based – in the next step we extended it to include visitor behavior.

This was almost too easy. The most important decision was simply to focus on a set of target markets that represented different potential use-cases instead of trying to answer the question for every market and for every search.

The second case was just a little bit trickier. We wanted to understand whether the site displays could be tuned based on previous visitor search behavior. So the question was did visitors tended to search on the same places when they returned to the site.

For this analysis, we extended our original target market segmentations to look at all visitor behavior when the first visit included a search of the target market. The segmentation looked something like this:

Note that the Visit filter is now nested inside a Visitor filter. This means we’ll get all of the behavior for any Visitor that meets the Visit criteria. To the Visit criteria, we added that the Visit Number for the target market search had to equal one. This gave us a population of visitors who started by searching in one of our target areas.

Now, we generated a report that looked like this:

With this filter, we were able to see all the searches done by visitors in subsequent visits to the site when they began with a Bakersfield search. We used Excel to aggregate the results and with a little arithmetic (or another segment) we could get all the Bakersfield searches who started off by doing something else in their first visit.

It turned out that for this particular site, the vast majority of visitors in all of our target markets tended to repeat their searches identically on subsequent visits.

Conclusions and Recommendations: This analysis answered some fundamental questions about how visitors used the site – but it also suggested some extremely important personalizations. For any site, the faster you can get visitors to the stuff they want, the better and more successful the experience. The analysis strongly suggested that the site could profitably display results for visitors as soon as they arrived on the site – without even waiting for a search. It also suggested that keeping and using previous results to tune session re-entry pages would have similar benefits.

Reflections: One of these segmentations was trivial, the other only a little more complicated. But used judiciously along with the idea of isolating a representative set of target markets and they were able to answer definitively some questions that had persisted within the business for years. In addition, the answer suggested some significant personalization opportunities that the site was missing.

One other really important aspect of this analysis – and one I find repeated over and over – is the importance of visitor level segmentation. In nearly every real analysis, it turns out to be vitally important to be able to extend a segmentation to retrieve all the behavior for a visitor meeting certain behavioral criteria. As an extension of that, the ability to report on behavior by visit number is almost equally important. We use visit number in reports with startling regularity – and because of that we recommend that visit number be kept in Omniture variables (using a Vista rule or plug-in).

Comments

Measurement depends on setting goals, establishing benchmarks and then measuring progress toward the goal.  But is engagement too fuzzy a concept to be able to measure?

What exactly is this engagement thing we’re trying to achieve?  According to a post at eConsultancy.org you want people to

• make a noise.
• store and share things.
• love your website.
• visit more frequently
• refer your company to their friends.
• buy into your brand.
• and of course buy your products.

I’m not so sure about the make a noise one.  Any old noise is no good – they have to be saying good things about you to others.

What I do agree with wholeheartedly is that you have to give people a way to interact with you – online and offline.  There is overwhelming evidence that people want to contribute, they want to be involved.  They have opinions and ideas about your business.  Witness the success of Dell’s IdeaStorm  and MyStarbucks Idea.

And if you think it’s an odd notion that customers would want to have a say in your business, both these companies were featured in the Engagement study that showed that the most engaged companies in the US are also the ones that did the best financially through the recession.

So what activities count as engagement?  These 36 are from Chris Lake who is working on a new social commerce start up in the UK.

A list of social interaction metrics / KPIs

1. Alerts
2. Bookmarks (onsite, offsite)
3. Comments
4. Downloads
5. Alerts (register and response rates / by channel / CTR / post click activity)
6. Email subscriptions
7. Fans (become a fan of something / someone)
8. Favourites (add an item to favourites)
9. Feedback (via the site)
10. Followers (follow something / someone)
11. Forward to a friend
12. Groups (create / join / total number of groups / group activity)
13. Install widget (on a blog page, Facebook, etc)
14. Invite / Refer (a friend)
15. Key page activity (post-activity)
16. Love / Like this (a simpler form of rating something)
17. Messaging (onsite)
18. Personalization (pages, display, theme)
19. Posts
20. Profile (e.g. update avatar, bio, links, email, customisation, etc)
21. Print page
22. Ratings
23. Registered users (new / total / active / dormant / churn)
24. Report spam / abuse
25. Reviews
26. Settings
27. Social media sharing / participation (activity on key social media sites, e.g. Facebook, Twitter, Digg, etc)
28. Tagging (user-generated metadata)
29. Testimonials
30. Time spent on key pages
31. Time spent on site (by source / by entry page)
32. Total contributors (and % active contributors)
33. Uploads (add an item, e.g. articles, links, images, videos)
34. Views (videos, ads, rich images)
35. Widgets (number of new widgets users / embedded widgets)
36. Wish lists (save an item to wish list)

How many of these do you offer on your site?  How do you know which ones to add?

Go back to step one of your social media strategy and listen to the conversations – tap in to the needs, likes  and dislikes of your visitors and customers.  The days of deciding for others are long gone.  You have to give them the tools they need and want, not what you think is right for them.  Everything on this list won’t work for every site.

For example:  A company that is involved in bath and kitchen makeovers is currently looking at adding social interactivity to their website.  After taking the list of ideas the CEO has, and listening to his customers and visitors to the site, this is the proposed list

1. Register for Alerts by RSS feed – to get new content
2. Views (videos,  rich images, design concepts)
3. Use the design widget
4. Put the widget on their blog or Facebook, etc)
5. Feedback (via the site)
6. Email subscriptions
7. Favorites (add an item to favourites)
8. Feedback (via the site)
9. Forward to a friend
10. Invite / Refer (a friend)
11. Social media sharing / participation (activity on key social media sites, e.g. Facebook, Twitter, Digg, relevant design forums, blogs  etc)
12. Time spent on key pages
13. Time spent on site (by source / by entry page)

How are you keeping track of your engagement stats?

And in web analytics, we often care more about whether traffic is going up more than its true absolute level. But this focus on rates of change, though something of a truism, hasn’t been consistently applied in many types of online reporting. In this short series, I’m going to discuss some areas of online measurement where concepts of rates-of-change and velocity haven’t been widely adapted but are, nevertheless, extremely useful.

Content Evaluation / Editorial Reporting
Nowhere is the concept of rate-of-change/velocity more important than when it comes to creating media metrics for editorial reporting. Raw numbers about article consumption are almost meaningless except when understood in the context of how long the article has been in circulation and what position it has been given during that time. If you’re providing your editorial staff with a daily report on content page views, you are forcing them to put each article in that context: mentally doing the arithmetic of when an article was pushed, what position’s it’s held, and, given those two facts, how that compares to previous content performance. That’s a lot to hold in your head and it makes using those reports much more difficult than it ought to be.

Using concepts of velocity, you have the ability to deliver crisper, far more informative editorial reporting.

This type of report uses an average of previous stories velocity curves (by time & position) to create a predicted interest line (in blue) for each article. It then maps the actual usage velocity (in red). This gives a simple, precise, and accurate depiction of how well a story is performing relative to proper expectations; it shows not only whether the story is more popular than average but what legs it has and how long it should probably stay in rotation.

To me, this is another example of what we at Semphonic call Analytic Reporting – reports that answer questions instead of just raising them.

Of course, a straightforward velocity report isn’t available out of the box in pretty much any web analytics solution – you have to do some work.

First, you need to create some metadata about the article in the web analytics solution. There are typically two ways of doing this. You can push basic information (like publish-date and position) as variables to be captured by the tag in real-time. Alternatively, you can push a content-id as a variable (or as part of the page name) and then transfer the metadata to the web analytics system (for example in Omniture this would be a SAINT file, in NetInsight a DataConduit).

Keep in mind that constructs like SAINT work pretty well for most article meta-data (e.g. push-date, author, service, length) but can be problematic for something like position. SAINT changes all of the data being viewed – regardless of whether it’s past or present. So you can’t capture the fact that an article may have been position 1 on the 24th of July and position 4 on the 25th using a SAINT table for metadata. This means that variables like position that change over time must be captured by the tag in real-time.

Having the push-date and positions for an article makes it easier to understand its performance, but it isn’t enough to make editorial reporting as easy and powerful as it should be. Web Analytics solutions don’t give you much flexibility in report generation and variable calculation – so getting to the data you really want – traffic by position and time since push date is still very difficult even when you’ve captured the push-date and the position in the data stream.

To make reporting easier, I recommend doing a little more pre-processing on the records. In Omniture, for example, you do this using Vista Rules. By combining two Vista Rules, you can get to the information you really need into a report without a lot of complex segmentation or correlation. The first Vista Rule is the TimeStamp Rule. This simple, very common rule, just places the time stamp in a variable for every server call. The second Vista Rule you need is custom; it calculates the difference in hours between the time stamp and the push-date variable and saves this difference in another variable. You can really make your reporting easier by concatenating that difference and the position together in a single variable.

Keep in mind that while I’ve described all this as happening with Vista Rules, it can be done in other solutions as well (with DataConduits and processing rules in NetInsight for example) and it can be done in ANY tag-based solution using coding in the tag. So no matter what solution you are using: from Google Analytics to DoP, it’s possible to derive this simple but powerful metric of content activity by time from push-date and position.

What you get when you do all this work is a variable with content id and a variable with the number of views (and visits) by position by time since push-date. You can correlate this variable with the basic TimeStamp to get the actual day of week and the hour of day – that’s important since content pushed after midnight (for example) is going to have a different velocity curve than content pushed at 8AM.

That’s pretty much all the secret sauce there is to delivering a report just like the one I started this post with.

Actual Content Velocity vs. Predicted Content Velocity is the sort of Media Metric that I think adds real value to editorial understanding and it’s a great illustration of how useful concepts of velocity really are. It’s also the kind of metric that I’d like to see discussed at X Change in our first ever industry-specific Huddle – Media Metrics (led by Turner’s Tom Cattapan). There’s so much more to measuring media than page views and time-on-site and the vast majority of really useful metrics never seem to see the light of day!

Comments

Even broken down into four parts, my response was longer than allowed for comments on this blog, so I decided to make it a post on its own.  Here is my answer to Wilson’s question:

Great question. I will get to that, but let us look at another misunderstood part of the Google algorithm.

We have been wondering for years why Google has three different measures for PageRank. The real PageRank calculation used in their algorithm is a complex logarithmic calculation. All other things being equal, a link from a PR4.12964 page is probably worth many links from a PR3.45294 page, for instance (We have no idea to how many decimal spaces the real PageRank is calculated, not whether this has remained steady over the years or whether it fluctuates over time).

Then there is the PageRank in the Google Directory, which supposedly is on a scale of 8. I can’t find any reference to the 8-point scale in the Directory, but the Wikipedia article on PageRank is a good reference on this point. Interestingly, the Google Directory states that…

 ”The green ratings bars are Google’s assessment of the importance of a web page, as determined by Google’s patented PageRank technology and other factors. These PageRank bars tell you at a glance whether Google considers a page to be a high-quality site worth checking out.”

Note the “and other factors” wording.

Finally we have the famous Toolbar PageRank, a green bar on a scale from one to ten. This is what most webmasters mistakenly refer to as Google’s PageRank calculation. However, it is just an estimation that makes a PageRank of 4.0001 look the same as a PageRank of 4.9999, even though the latter might be worth many times the former. Meanwhile, it makes a PageRank of 4.9999 look much less valuable than a PageRank of 5.0001, even though the two are almost the same. Furthermore, everyone involved in SEO can recount numerous instances where a page “should” have a much higher or much lower PageRank than another page, based on the number and value of incoming links, but the Toolbar PageRank does not reflect that. (For instance, I have noted on many sites that a “links” page with identical link juice to a PR3 content page might nevertheless have a PageRank value of zero.)

What does this tell us about bounce rates?

Just like PageRank, bounce rates is a metric Google shares with its users. PageRank is viewable to everybody; bounce rates are viewable only to the website owner. In both cases, Google is showing a very simple calculation … a number people can use to quickly make comparisons between pages, between websites, between last month and this month, etc.

As I wrote above, “It would be a ridiculously simplistic algorithm that calculates bounces using such simple calculations.” Any serious calculation of bounces applied to a search engine ranking algorithm would have to be such a complex multidimensional equation that it would be useless to you or I as humans viewing it with our eyes (unless you happen to be a mathematical genius – and I mean genius – which I am not by a long shot.

Except to the extent that a search engine chooses to reveal how it treats bounces and other actions in its algorithm, we will never know for certain what plays a role and what does not, nor how big a role each factor plays. This is par for the course with ranking algorithms.

It is also totally possible that Google and the other search engines do not include bounce rates and related user actions yet in their algorithms.  Adam Lasnik’s comments quoted in my previous post are good hints, but they are hardly official.     Google engineer Knut Magne Risvik speaking in Norwegian at Digi.no and saying that  Google can measure how many seconds it takes from when a user clicks on a link to click back to Google, and if it is a short time that visit was a failure, is not quite an official Google statement either.  The only search engine that has released anything official is MSN through its BrowseRank paper … and that is not a statement current practice but of future intentions.

As this very young field matures, Google might also change its Google Analytics definition of “bounce rate”. SEO aside, the raging debate over whether a high bounce rate could sometimes be a good thing (depending on the nature of a website) makes a good case for changing the Google Analytics definition, too.

The summary to all this is that I have to answer Wilson with a simple “I don’t know”.  But, just like defining “bounce rate” and “PageRank”, such simple answers are really a lot more complex than they look.

Comments

This post is kind of a how-to of getting Google Analytics setup on your Web site, whether you’re a DIYer or you want to provide the necessary snippet of code to your Web developer to keep your update costs down.

Step 1: Get a Google account.

Chances are, you may already have a Google account; if you have a gmail address, you already do. However, you may want to create a new Google account specifically for your Web site, separate from your personal Gmail.

If so, start by visiting http://www.google.com. In the top right corner you should see a Sign In link. Click it.

This will take you to a login page that will also allow you to Create an Account Now. Click it.

In order to create a new account you’ll need to enter your current email address and a password. If you already have a Google account you won’t be able to use the same email address here.

Google will then send a confirmation to the email you entered.

Click on the link (or copy and paste it into your Web browser’s address bar) to confirm your email and establish your Google account.

You now have a Google Account.

Step 2: Get a Google Analytics account.

Visit https://www.google.com/analytics/, click on Access Analytics (a big blue button at the time of this writing) and login using your Google account.

Once you’ve logged in you’ll be prompted to sign up for Google Analytics. Click the Sign Up button.

To start the account signup process you’ll be prompted to enter your Web site’s URL (domain name), your site’s country and time zone. Google will automatically create an account name for you based on the URL you entered, but you can override it if you have a preference. Click the Continue button.

On the next page enter your name, phone and country (if different than your Web site.) Click the Continue button.

On the next page you’ll need to agree to the Google Analytics Terms of Service which you’ll probably never read. What you do want to pay attention to is the Data Sharing Settings. By default, Google will use your analytics for benchmarking. If you want to be able to compare your Web site traffic to similar sized Web sites in your industry you’ll need to keep this as is.

The data is supposed to be shared only in aggregate to protect your privacy. However, if you’re not comfortable with this you can edit your sharing settings here. Keep in mind you won’t be able to compare your site to other sites if you don’t share your data.

Agree to the terms and conditions and click the Create New Account button.

Finally! You’ve arrived at the tracking code. Google offers both the “new” and “legacy” tracking code. I can’t imagine why you’d want to go with the legacy tracking code, so select and copy the New Tracking Code.

This code goes on the bottom of every Web page you want to track just before the </body> tag. You’ll either want to add it yourself or share it with your Web developer.

If you have multiple domains you want to track then you’ll want to generate unique tracking codes for each site. Each domain will need it’s own “profile.” You can create additional Web site profiles by clicking Add New Profile on your Google Analytics landing page.

Twenty-four hours (or so) after you install the code you should start seeing activity on your account. Read it and make the appropriate changes to your Web site or Internet marketing campaigns to increase your search engine visibility, Web site traffic and conversions!

Step 3: Add Users

If you’re working with a Web design or Internet marketing company and they need access to your account you can provide it without giving access to your Google account. On your analytics overview page near the bottom you’ll see a User Manager link. Click on it.

On the next page click on Add User.

You can then add the email address of your Web designer or search engine marketer so they can access your reports and continue to help you out. They should be able to provide you with their email (which must be associated with their own Google Account.)

Then choose View Reports Only if you just want to share the reports with them (so they can view them) or Account Administrator (if you want to provide full access to your account.)

Whether you have one or multiple domains you’re running reports on, you’ll need to select them under Available Website Profiles and Add>> them to the Selected Website Profiles. Select all the domains you wish to share and click the Save Changes button.

If you’d like to learn more about Google Analytics and how to make the most of it, here are a few articles to get you started:

• Beginner’s Guide to Google Analytics – Just as Advertised
• Does Your Web Site Beat the Competition? – About Google Analytics Benchmarking
• How Google Analytics Can Make You the Life of the Party – How to Improve Your Site Based on Your Analytics Reports
• Tracking Conversions: Does Your Web Site Turn Suspects into Prospects? – How to Setup Google Analytic Goals

Comments