Much like a funnel in the kitchen, a properly configured conversion funnel will start with a large opening– the 50,000 visitors who hit your site in a month– and narrow down to a smaller number– like the 200 who buy– at the end. At each step, it should get narrower. There’s value in all of these factors– how fast it narrows, as well as how many people enter and leave the whole process.

Insight From The Funnel

The most obvious detail a conversion funnel provides is where dropout occurs. If you have 60% of visitors who reach a step abandoning the conversion process, it’s worth reviewing that step. However, there are plenty of side-notes to be seen:

* If you’re seeing a lot of users jumping into the middle of the funnel, you may have an incorrect view of the customer’s workflow. Maybe they’re starting at a product page, provided by Google, rather than your home page, and it may be worth concentrating efforts to close the sale there.

Another common source for mid-funnel visits is the “split session” mindset. For example, many visitors will review the first few pages of a site, to confirm features and price, and then return to the one which offers the best deal to complete their order. Knowing where they pick back up can help you customize a message for returning visitors, or a plea to keep them from searching elsewhere first.

* If all your visits aren’t registering, you may have issues with the tracking code. This is especially true if you need to send users across domains, such as to a shared-SSL site. A fix here can also improve your overall analytics experience.

* Filtering the funnel by additional variables can provide “passive” data about compatibility. Rather than wait for people to say “It’s broken in Safari”, you can see “Safari users had a 98% dropout at step 3″ yourself.

Setting Up The Conversion Funnel with Google Analytics

In Google Analytics, it’s possible to digest traffic data into a conversion funnel without having to add any new tags. All you need to do is go into the Analytics control panel and select the “Goals” system.

First, you determine a goal page, like “/thankyou.php”. Here is where you know the conversion has occured- a good choice is the reciept, or “thank you for contacting us” page.

Then, you plan a specific path to that page that you plan to monitor. For example, “/index.php” to “/contact.php” to “/thankyou.php”. Here’s the big thing they don’t mention: if you set up several conversion funnels, they can’t cross.

It’s easiest to set up the funnel steps by using the “head match” option, as it just relies on easily legible names. For example, a “head match” of “/thankyou.php” will match “/thankyou.php”, “/thankyou.php5″, and “/thankyou.php.not.really”. However, it avoids having to fight with complex syntax, and in most cases, avoids the risk of having pages which inadvertently trigger matches. The more sophisticated techniques, using regular expressions, can be valuable for building a funnel with variable paths, such as “any product page”, as a step. But if you’re just monitoring, say, the pages in a standard checkout, or the front page to a contact form, it’s overkill.

Once this chain is set up, you have to wait for it to process new data to fill the funnel report. Unfortunately, the five years of back data you have won’t be resorted into the new funnel.

Conclusion

A conversion funnel is a relatively easy way to get more value and understanding out of the analytics package you’re already using.

Now, many of the same searches will go directly to intensely local results without qualification. They rely on geo-location of your IP address, or perhaps your information in your Google profile.

Now, the reasoning for this is sound, from a business perspective. Many searches are legitimately local. Odds are, you’re not searching for a restaurant in Barstow if you’re in Baltimore. But, more importantly, it provides a set of results which they control more: the Google Maps and Places products. In addition, it allows those $25 “tagged” listings to show alongside already paid ads. The more they can steer you to one of their sites, the less they have to deal with that pesky “rest of the internet”.

However, it can backfire from a customer perspective, due to several technical problems:

Geolocation’s spotty, on a good day. While progress has been made, especially on mobile where it’s most useful, there’s huge gaps in support. With geolocation defaulted to off (a standard security setting), sites believe my phone is in California, about 800km away from where it is. If you use a proxy-based browser package like Opera Mini, or your ISP or carrier has a transparent proxy designed to shrink image downloads, it can result in your percieved location in the middle of a server farm somewhere. You may remember the old days with AOL – at work on a local ISP, you’d see a bunch of regionally targeted ads, but on dialup at home, you were identified as part of a server farm in Virginia and saw only generic ads.

Many searches that seem local are ironically not: you don’t need Google to find the nearest location of a chain store, but may be seeking their corporate site. This tends to be the ultimate form of customer hostility– it’s easy to refine a search by saying “I don’t want BestBuy.com, I want the Best Buy in Tempe”, but very difficult to de-refine a service which insists on framing a question with local information.

Local results tend to be far more inconsistent than national ones. The reason for it is fundamental. The pages returned for a national search tend to be consciously built, whereas local pages tend to be generated from gathered or bought databases of company info. The disparate sources tend to result in inconsistencies and absurdities– while nobody would deliberately write their old office address on their own website, a massive database acquired from public records and scraping other people’s sites would easily absorb the info. Consider this: even over two years after we moved two blocks, there are still local sites insisting we can be found at our old location.

There’s also still a creepiness factor to localization. Since the most prominent real-world use of localization are those omnipresent “Arizona Moms Encouraged to Sign Up For Ripoff Non-Accredited Colleges” ads, people are going to associate it with either “too much personalization” or “scam”.

So where do we go from here?

I expect to see heroic efforts from Google to increase the robustness of their Places offering. Keeping users on-site longer is too desirable to lose, and it represents a way to reach an advertising audience who never had sites or a reason to buy AdWords. Some people claim to report Google actually checking out individual local businesses, which could indeed add legitimacy to local results.

However, I expect that, like the “searching for … instead”, the localization will eventually come with a vaguely hidden way to turn it off.

In the footer down below you will find the following bit of html:

<font size="1" face="Tahoma" color="#FFFFFF">www.cop-usa.com
	www.cop-usa.com www.cop-usa.com www.cop-usa.com www.cop-usa.com
	www.cop-usa.com www.cop-usa.com www.cop-usa.com www.cop-usa.com
	www.cop-usa.com</font>

That page’s actual title is:

Arizona SEO: Search Engine Marketing – Internet Marketing Strategies

“System and method for modulating search relevancy using pointer activity monitoring “

according to the patent title and abstract. If you read on, it explains that the data the patent suggests collecting is the mouse location on page and hover duration. What could this mean for SEO?

The simple answer is that there’s a new factor influencing rankings. The patent calls it the “client attention coefficient.” That wording suggests that it will have a direct effect on how “relevancy” is calculated for all Google searches. Any time a search engine makes a change in how they rank sites it’s reflected in the rankings. That may sound obvious, but it’s something every good SEO thinks about when changes start happening. Should Google incorporate this mouse tracking idea into their search engine it could produce some interesting results both good and bad. One thing we know is that we’d have to start paying more attention to how our indexed pages appear on SERPs (Search Engine Results Pages.)

When Google builds a SERP for a search query it takes the titles and descriptions of the results and serves them up as a vertically aligned list with higher ranking pages at the top. The typical searcher begins scanning with their eyes at the page and sometimes follow with a mouse pointer. Referring back to the patent, this shouldn’t have a direct effect because the patent proposes a timer or “threshold value” that would filter out times when a cursor “temporarily passes through [these] regions.” However, this doesn’t change the fact that the results at the top are more likely to get mouse pointer attention. Depending on how much weight Google assigns to this new metric this could strengthen the barrier-to-entry for new rankings even more.
    The “client attention coefficient” might also accidentally favor indexed pages with longer titles and descriptions. The two search results below illustrate an example case.

A result that shows up on a serp (search engine results page) looking like the first result might not hold a visitor’s attention as long as the second. Another advantage the second has over the first is that it simply occupies more space on the page. It will grab more mouse time because of this but, Google’s engineers aren’t dumb. I bet they’ve already thought up a solution but there’s no best way around it. There will be some artificial-ness leaking into the organic rankings.

We won’t know how effective it is in improving results until Google actually implements it if they ever do. They may never implement this hopefully out of respect for our privacy. Hopefully we can prevent Google from looking through visitor’s webcams and tracking eye movement across the page. Anyone want to file that one now before Google does?

It’s important to recognize that client-side and server-side analytics never match exactly. Since a client-side system cannot record traffic by robots, and some limited users– like mobile users with no image or script support, it tends to undercount by a few percent. Server-side systems often mis-classify users based on browser headers- many obscure browsers emulate IE or Safari.

Moreover, even inside a category, disputes occur. Does a visitor who sees a second tab on one page count as a bounce? Is a user who hits a Bing ad driven by Bing or the Microsoft ad network? Analytics vendors have many judgement calls. An important guideline is to use analytics data for month-to-month comparison in a single vendor. Google Analytics for June compares sensibly with Analytics for May, but trying to reference it against AWStats for June leads to confusion and bad decisions. Occasionally, a disparity between packages can reveal unusual user behaviour, such as a denial-of-service attack seen by the server-side system and not Google Analytics, but it’s more often statistical noise.

You can verify for yourself that I never got around to making an open search xml file by trying the following link: https://hawaiitours.com/opensearch_desc.xml – which of course doesn’t exist and never has. If you want to check if Google has found your site’s search feature and included it just visit your domain and start typing the domain name sans www.

I’m personally not sure whether or not I think this is a good idea. I could see several potential problems where a site had several search features and it could be a bug as opposed to a feature. I suspect that simply adding an open search meta tag would resolve it.