Yesterday Microsoft announced that in 24 countries, including the US and UK, Nokia (Navteq) will be delivering traffic data to Bing Maps. The company also said that it would start using Nokia’s geocoding services in several (unnamed) countries to improve directions.

In May last year I wrote Bing Maps To Be Powered (Replaced) By Nokia? A source argued to me that over time Nokia would gradually replace most of the infrastructure behind Bing Maps. I was very surprised at the time but it appears to be happening.

This mapping integration was allegedly, according to my source, one of the sticking points that caused Nokia to pass on Android as a platform. Google wouldn’t similarly agree to a commingling of Google Maps with Nokia on the back end. However if Windows Phone fails to deliver for Nokia — so far results have been modest — the company may be compelled to embrace Android as a survival move.

Nokia is also behind the new Yahoo Maps. My suspicion is that Nokia hopes to eventually make these third party mapping services part of its local ad network.

Related Entries

• Microsoft And Nokia Unify Maps On PC, Mobile
• Report: Apple Replacing Google Maps With Own Product In iOS 6
• Will Apple’s Move Bring A Real & Perhaps Better Google Maps To iOS
• Microsoft Makes Venue Maps More Visible On Bing
• Bing Maps To Be Powered (Replaced) By Nokia?
• Nokia Now “Powering” Bing Maps
• Powered By Nokia, The New Yahoo Maps Goes Live
• Google Maps Vs. Bing Maps: Summer Vacation Planning Showdown

While that may not surprise much of the SEO industry, it contradicts what some Google employees have previously said, as well as another recent study on Wikipedia’s search visibilty.

Last week, Conductor released updated data about Wikipedia’s search visibility, this time including Bing for comparison to its previous study that focused solely on Wikipedia’s Google visibility.

In the previous study, Wikipedia appeared on page one of Google 46 percent of the time, and on page two for 25 percent of the searches/keywords.

In its updated study, Wikipedia appeared on Bing’s page one for 31 percent of searches, and on page two only five percent of the time. The chart below shows Wikipedia’s visibility on Google (blue) and Bing (green) for all 2,000 combined keywords, as well as for the separate informational and transactional keywords.

(Note: The image above is a replacement provided by Conductor because the original image had a typo.)

At various conferences that I’ve attended, Google’s Matt Cutts has mentioned seeing earlier studies that had Bing showing Wikipedia more often in its search results than Google does. He echoed that sentiment in the comments of his Google+ post about Conductor’s earlier study. A recent Search Engine Watch study also suggested that Bing favors Wikipedia more than Google.

Why the discrepancies? It’s likely due to survey methodology, not to mention the rapidly changing search results landscape. (Search results can differ day-to-day, even hour-to-hour, so a study done one month is likely to differ from another study done a month later.)

In its studies, Conductor compared 2,000 informational and transactional keywords of varying word lengths. Navigational keywords were not included because Conductor found very low Wikipedia visibility for those types of keywords.

Bing Still Loves Wikipedia, Just Differently Than Google

Conductor’s recent study did reveal an interesting trend: Even though Wikipedia appears more often on Google’s page one, when Wikipedia does show up on Bing’s page one, it’s at the top of the results more often.

When Wikipedia is one page one, Conductor found it in the top three results 83 percent of the time on Bing, compared to 65 percent on Google.

Conductor also removed one-word queries from its study and found that, overall, Wikipedia appeared about 10 percent more often on Google’s page one than on Bing’s page one.

As I mentioned above, with search results changing so frequently, no study is likely to end the discussion on Wikipedia’s search visibility. But, if nothing else, all of this data related to search visibility — whether it’s Wikipedia or other major sites like Amazon — makes for good industry discussion.

Many have lamented the rise of apps and the return of “closed” proprietary platforms  (e.g., Apple, Facebook). Recently in a widely discussed interview Google’s co-founder Sergey Brin pointed to “walled gardens” and government censorship as threats to the established web. He later clarified that the biggest threat to the web was from government censorship and not Apple.

One of the reasons that Brin and others don’t like apps is that their internal content is not indexed. Plenty of apps surface in search results but not what’s inside.

A number of app search engines have arisen to confront the so-called “app discovery problem.” Among them are Quixey, Chomp (recently acquired by Apple), Appsfire, Appolicious and Xyologic. Yahoo has built an app search engine; and one can also search Google Play for apps of course. Bing also dabbled in app search for a time.

The central difference between most of these sites and Quixey is that the latter is not simply indexing and searching mobile apps. Quixey characterizes what it does as “functional search” rather than app search. It’s indexing available apps across platforms (including the PC), as well as web content pertaining to those apps.

The idea is that users will enter queries that describe tasks or goals to accomplish rather than specific apps or even app categories. For example, in response to the query “learn french,” the search engine produces a range of results that show mobile apps but also “apps” for Firefox, Facebook, Mac and Windows (both paid and free).

Quixey won’t go so far as to say that it’s a direct competitor to Google. However it does regard itself as more effective for discovering apps and app content (broadly defined). It also suggests by implication that it’s something of a Google successor in some respects. It uses the tagline “a new type of search” on its site.

The company was founded in 2009 and has raised just over $4 million to date. Eric Schmidt is an investor. It’s also talking to various third parties about powering their app search. This is something that other app search engines are doing as well.

In one way of looking at the world apps now represent a parallel universe of content to the more traditional “open web.” HTML5 may eventually succeed in bridging the two worlds; however that hasn’t happened yet. Many assume and some are banking on the idea that apps are now a permanent new way to deliver web content — whether in mobile or online. In that arena Quixey is trying to the Google for the new apps era.

Related Entries

• App Search Engine Appolicious Introduces “AdWords For Apps”
• In Chomp, Apple Gains A Social Search Engine For Apps
• Chomp: An Apps Search Engine Or “Yelp For The App Store”
• New comScore Study Suggests 50 Percent Of Local-Mobile Search Happening In Apps
• More People Now Using Mobile Apps Than Browser — comScore

Today the company launched the latest of several search features that continue to position Foursquare firmly as a formal local search engine: a fully searchable history page where users can review their entire check-in history, including photos, tips and who else was there.

The history page offers a date-based dropdown, plus filters to narrow results by location, who else was there and business category.

It’s fair to question when or why anyone would want to return to an old check-in, but here’s a piece of anecdotal evidence to show one way this tool is valuable: I was up in Spokane a couple weeks ago and a friend was telling me about a great Mexican restaurant he’d eaten at in my hometown. He couldn’t recall the name, but he did remember checking in on Facebook. After browsing through his Timeline, he came up with the place. And now I’m making plans to try it out myself.

Foursquare’s moves in local search have been interesting to watch. Back in December, the company hired a former Google senior engineer to boost its local search smarts. About a month later, Foursquare launched its Explore search tool on Foursquare.com and effectively became a true local search engine at that point. They’ve added restaurant menus and partnered with Open Table to enable making reservations from Foursquare’s website. For business owners, Foursquare has also launched an express verification tool that gives access to Foursquare’s business tools immediately. (Verification by mail can take several weeks.)

What the final result of all this will be is anyone’s guess. It may just be positioning Foursquare as a more attractive buyout option for a bigger player. But, in the meantime, it’s intriguing to watch the speed and commitment with which the company is moving into local search.

Last month, Foursquare announced that it had 35 million places in its location database, and that its users had checked-in more than two billion times.

Diego Basch, a former Senior Software Engineer at Inktomi, who is now Director of Engineering at LinkedIn explained why on his personal blog.

He outlines the major signs of the fall of Inktomi when he noticed most of the engineers at Inktomi using Google to find content, instead of Inktomi. But why? Why did Inktomi fail? He feels there are many reasons but the core reasons include:

• Inktomi didn’t control the front-end, they feed results to their partners such as Yahoo who controlled that search results experience.
• Inktomi didn’t have snippets or caching despite his efforts to do so, he was shot down by the executives.

Basch explains:

In short, Google had realized that a search engine wasn’t about finding ten links for you to click on. It was about satisfying a need for information.

In reality, with Google’s Old Possum/Skip Redirect update in December, user agent redirection is all that’s necessary for mobile sites to rank ahead of desktop sites in smartphone search, even if it’s the same content formatted differently.

With canonical tags back to the desktop site for duplicate mobile pages, both mobile and desktop pages will be able to rank for competitive terms. As I’ve said often in this column, and as Google has said elsewhere, it’s a different paradigm in mobile search, and mobile sites are not, by definition, duplicate content.

However, there are duplicate content issues in mobile SEO that don’t exist in traditional or desktop SEO. These issues will split link equity within a mobile site.

Though this will likely not be a problem for mobile duplicates that are properly redirected, these issues could make it more difficult for your unique mobile URLs to rank, and could result in less link equity being passed to your desktop pages from your duplicate mobile URLs.

If your mobile site exhibits any of these seven common characteristics, you could have canonicalization issues that make your desktop and unique mobile content less competitive in search.

1.  App Interstitials

Many sites promote their mobile app when searchers try to access mobile Web content, taking them to a page created for users of their platform before taking them to the home page.

For example, Open Table takes Android users to an Android page and iPhone users to an iPhone page, and both of these pages are indexed in Google.

Does your mobile site have one of these? You could be splitting link equity.

Like Flash intro splash pages in the early days of this century, there’s a possibility( however remote) that users will link to and share the platform-specific URLs rather than the home page. This can split link equity of one of your strongest pages, making it less competitive in search.

Some companies get around this issue by promoting the app within the page rather than taking the searcher to a separate URL. Others get around it by making a mobile Web user experience that’s good enough to stand on its own. If you must promote your mobile app on your mobile website, it’s best not to have separate URLs per platform.

2.  Carrier Pages

Years ago on Google’s mobile webmaster guidelines, they warned about creating duplicate pages for each carrier. And though that warning is no longer on their mobile guidelines, many companies are still creating deck-specific content that could dilute link equity.

For example, NBC’s mobile site lists a show recap here that’s exactly the same as this show recap here, with the exception of the return to t-zones text at the bottom of the second page.

NBC.com page for T-mobile's t-zones is a duplicate of another recap page except for two words: t-zones Home

Both of these pages are indexed in Google with their own link equity.

If you must create carrier pages, use the canonical tag; or if the page is parameter-based, use Google parameter handling to let Google know they’re duplicates.

3.  Indexed Legacy Transcoder Duplicates

In the initial rush to go mobile, many companies used solutions like Usablenet as a stopgap solution to allow them to provide some sort of mobile content to their users. For various reasons, including SEO, some of these companies then elected to stop using a transcoder like Usablenet and build a mobile site in-house.

Sears.com is one such case. Usablenet currently has 180,000 pages indexed in Google with Sears.com in the URL, but Sears no longer uses Usablenet to power their mobile site.

In fact, they’ve created a jQuery mobile showcase on m.sears.com, which has 381,000 pages indexed in Google. Many of these Usablenet pages are duplicates with older, potentially more trusted links, and they’re splitting the link equity of the Sears mobile site.

One of 180,000 indexed pages of the legacy Sears Usablenet site

Canonical tags on the Usablenet legacy content could fix this problem, but contacting an old vendor to have them implement changes on a site they no longer generate revenue from is never very easy to do.

4.  Other Cross Domain Duplicates

Though transcoded mobile content seems to be the most common instance of cross domain duplicates, there are other instances where the same content will be hosted on two different domains with no canonical tags to indicate which one the search engines should promote.

For example, if you access CBS Sports mobile site directly you could do it through m.cbssports.com. But if you were to access the same page from T-mobile’s deck, you would see the same content at this URL: http://cbstmobile.mo2do.net/?src=tmobile.

If you were to attempt to access it through search by putting in the keywords [cbs sports mobile], you would find the same content at this URL: http://wap.sportsline.com/

Is this a screenshot of A) m.cbssports.com B) wap.sportsline.com C) cbstmobile.mo2do.net D) all of the above?

Again, the same content on different domains could indicate reduced ability to rank for competitive terms. Best to indicate a canonical site through rel canonical or parameter handling in Google Webmaster Tools.

5.  Mobile Site Showcase On Desktop Site

Major League Baseball, the NBA and the NFL all have pages on their desktop sites promoting their mobile websites.

NBA's desktop page promoting their mobile app may appear when mobile searchers are looking for the mobile site.

In spite of Google’s focus on relevance in search results, sometimes these pages intended for a desktop user show up in search results for brand + “mobile site” queries ahead of actual mobile sites.

While these types of pages rarely result in any significant link equity, they can take link equity away from the actual mobile site and make it difficult for it to rank (assuming it’s not a duplicate, which will rank with redirects).

We would love to hear from Google whether pages like this can safely include canonical tags back to the mobile home page, as the content is similar and isn’t something desktop searchers are going to want to find in search. But if the canonical tag is questionable, the pages should at least be excluded or redirected back to the mobile site for mobile users so that they don’t compete with the mobile site in search results.

6.  Duplicate WAP Sites

It’s springtime in America, and many sports fans are rooting for the home team again until the big finish in October.

Do you think any of them can tell the difference between this:

Screenshot of wap.mlb.com

And this?

Screenshot of m.mlb.com. Don't look too hard for differences.

That’s because it’s the same content. The difference is that the former was built for feature phones and the latter was built for smartphones.

These days many companies are building accessible mobile sites at m.domain.com with progressive enhancement in mind, eliminating the need for a duplicate site on a wap.com subdomain.

If you do have a wap site on a separate subdomain (and there are almost 8 million pages indexed on wap.*.com subdomains in Google) the best practice is to use canonical tags to transfer the link equity to one mobile site.

7.  Promoting Mobile Apps Ahead Of Mobile Web Content

Some companies don’t have a mobile website at all, but promote their mobile app instead. There are numerous problems with this strategy that I’ve covered in a past column, but from an SEO standpoint, it often results in creating native app content that can’t be linked to or shared.

So while companies are often duplicating their content and splitting link equity, this particular duplication doesn’t result in any additional links or shares which could ultimately help them rank for competitive terms in search.

If you are creating software or mobile Web functionality that truly can’t be replicated on the mobile Web, by all means build an app. But if you’re just building a stripped down version of your desktop website with mobile searchers in mind, make your mobile content accessible on the Web first.

Wolfram|Alpha now knows the locations of some 2.4 million retail establishments for 1,300 major chains in 220 different categories—gas stations, restaurants, department stores, and much more. It also knows the typical business hours for roughly one third of those locations, which makes queries like that one possible.

When I tried it online (PC) the user experience proved to be very poor. It located me in the wrong city — I’m in an LA hotel right now and it’s probably a case of IP targeting getting it badly wrong. However in search after search (even with geomodifiers in the query) it located me in Dallas, with no easy or obvious way to manually change location. My efforts to do so were consistently frustrating.

When it works the information provided is very basic. Using Google, Yelp, Foursquare or IYP sites is going to be faster and much more effective. There’s also no evaluative (e.g., reviews) or much enhanced information available. In other words, there’s nothing to set local search on Wolfram Alpha apart from other local sites.

I tried the HTML mobile site and the results were no better. I did not use the Wolfram Alpha mobile apps and so cannot report on that experience. However I cannot imagine it’s much better than the PC or HTML mobile site experiences.

It was a mistake for Wolfram Alpha to publicly announce this capability when it’s in such poor shape. The company needs to  work through the usability problems but more fundamentally needs to answer the question: Why would I want to use it for local search?

Chitika “looked at hundreds of millions of impressions between April 8 and 14 and broke down traffic depending on operating system, search traffic, and the type of search query.” The company also broke out local searches (often inferred from the query category).

These data don’t measure activity within or involving apps in any way.

Chitika reported that 54 percent of browser-based web traffic from iOS was being driven via search (Google, Bing, Yahoo, etc.). Chitika didn’t report the breakdown of that traffic by search engine and told me that would require an additional analysis. However other data suggest that Google represents about 95 percent of mobile search traffic coming from browsers.

The data argue that iOS browser activity is more “search-centric” than usage behavior on PCs (Mac or Windows). This is also somewhat counter-intuitive given than search is generally easier to use on a PC than on a mobile device.

In terms of local search, the directional relationship among iOS, Android and Windows is roughly the same as in general search chart. However Mac and Linux-based searches reverse positions in the local search data chart. It’s curious and Chitika didn’t really have an explanation for the phenomenon. I asked whether there could have been an error and I was told essentially “no.”

Chitika is saying that 36 percent of search query volume coming from iOS devices has a local intent. This compares to Google’s 40 percent figure for mobile. In contrast, 28 percent of Android search traffic carries a local intent according to Chitika. Figuring out why is an interesting exercise.

Why would iOS users be doing more local searches than Android users? That’s a version of the larger question about why iOS users might be doing more searches generally than Android users? (Once again, these data don’t reflect or measure activity in apps.)

One partial explanation might be that iOS includes iPads, where there is a lot of search activity. But that doesn’t fully explain these findings.

A few Florentines, mostly former colleagues from the Italian internet company Dada, set out in April 2011 to develop a new search engine, Attrakt, which would focus specifically on hosting specialized search engines curated by the Web community.

Attrakt’s Index Relies On Curator Contributions

As such, Attrakt isn’t a generalist search engine, with a broad index ready for everyday searches. Attrakt’s index is primarily seeded through links specified by curators of custom search engines, what Attrakt calls boxes.

As in the early days of Wikipedia, if you’re lucky enough to search on a topic someone has already curated, then you might be impressed. But for the most part, Attrakt is fairly empty, a problem Attrakt partners Andrea Dotta, Luca Ciavarella and Gabriele Miceli acknowledged won’t be resolved until Attrakt reaches a critical mass of contributing editors.

Putting Attrakt To The Test With Schema.Org Rich Snippets Use Case

Users can explore Attrakt’s potential by searching or creating a customized search engine on a topic of particular interest; the Attrakt team mentioned travelling in Italy and 80s synthpop among many examples. These two illustrate the use multimedia in addition to textual resources. I decided to try a search marketing use case: the Schema.org semantic web markup standard defined and supported by Google, Bing, Yahoo and Yandex.

By implementing Schema.org standards, websites can enable the display of many types of enriched search results, what Google calls rich snippets. Enriched results can be very beneficial for Web marketers and users alike but there’s a lot of material to wade through.

There’s the official standard, supplemented with separate documentation from each search engine. Extensions are available for many CMS‘ including WordPress, Joomla, Drupal and IBM WebSphere. Google, Bing and Yandex each offer testing tools.

Armed with around 60 selected links to pages and sites regarding schema.org and rich snippets, I created a new Attrakt box, or specialized search engine. Searches using the resulting Schema.org Attrakt box provide answers from these curated resources.

Creating an Attrakt custom search engine is a fairly straight forward process. An editor needs to provide a name for their engine, assign a category and country and add a few tags.

Each link is then specified together with a few attributes such as a link category (e.g. Blog, News, Tool, Official) and whether Attrakt should index just the URL or the entire site. The link categories allow an end user to browse through the links assigned to each of these categories.

Overall, the creation interface could be simplified: entering 60 URLs, one by one, is a tedious process. It would be quicker to paste all the URLs into a single form, assigning categories in a successive step. The box country should be optional. The topic of many curated search engines, including this one, will transcend geography.

Link categorization is also problematic: should an official Google blog post on Schema.org be tagged as Blog, News or Official? While at first glance blog might seem to be the best answer, a Google Blog Post is really an official company statement which in of itself is often a news item, which happens to appear on a blog publishing platform. Clear?

Once a custom search engine box is created, it can be modified or deleted, although the use of grayed out text for the edit link both makes it hard to find and implies it isn’t available as a function.

To be fair, the Attrakt team is continuing to refine both the user interface and the underlying search engine technology. By the time you read this article, much of what you see will undoubtedly be improved. In the future, it will apparently be possible to assign a link to multiple categories. Attrakt is also working with researchers at the University of Florence on algorithmic solutions.

Once a box is created, it can be shared with others via a link. Attrakt will periodically crawl a box’s URLs to check for changes. Box curators will see a message display when Attrakt detects changes. It would be nice if they could also receive notifications via mail or RSS, similar to the way Google Alerts works. Search box curators will be able to embed their Attrakt search box on other sites, a feature planned for May 2012.

Are Curated Search Engines Really Useful?

A curated search engine potentially has two specific advantages over a generic search using Google, Bing or Yandex. The first is it will exclude content which strictly speaking answers the query but is of low value, like the plethora of parrot posts which appear just after a Google blog post is published. It often seems that 9 out of 10 repeat the official news without adding any additional insight.

A second benefit is to surface specific content which might not have otherwise showed up in a generic search. At the time of this writing, Bing’s Schema.org testing tool is poorly indexed in Google, but can be found browsing the Tools links of the Attrakt Schema.org search box.

Attrakt Wants Crowd Sourced Curated Search To Go Social

The quality of a custom search engine depends on the ability of the curator and on the technology providing the search results. Currently, Attrakt will display the user name of a box curator, but there’s no way for a casual user to determine if the curator is authoritative or not.

Attrakt currently collects profile information during the user registration process; it would be nice if they would also display profile information together with other box attributes. Such display would also give search box curators a greater incentive to contribute quality search boxes to Attrakt.

Attrakt highlights some hot search boxes on their homepage, but it isn’t possible to search for a search box on a topic nor is there a directory of search boxes.

In some cases, search boxes are listed next to results in a general Attrakt search, although there are some geolocalization issues still to work out. Attrakt primarily relies on a search box’s author to promote a specific curated search engine.

Attrakt search boxes are curated by a single user. It would be interesting to allow collaborative search box editing, similar to Wikipedia’s support for multiple authors. In a world filled with spammers, this isn’t so simple to successfully implement.

Attrakt plans on adding a robust social layer – a layer which will undoubtedly make Attrakt much more attractive to curators and search users alike.

On this point, Attrakt says:

Users will soon be able to follow each other and each others’ boxes, create elaborate user profiles to declare their areas of expertise. A Twitter stream will soon help animate search boxes with up to date content. Boxes already have static URLs for sharing, and sharing will be encouraged by share buttons.

Outside of the Attrakt platform, we’re planning on using twitter to drive traffic to peoples’ search boxes using relevant hashtags, and if a twitter account is present in the user’s profile we’ll tag that user.

Attrakt Is Still In Early Stage Of Development

A reader would be forgiven if they have the idea that Attrakt is very much a work in progress. The Attrakt team began armed with a dream and a modest €50,000 in self-financing. They’ve come a long way in a year and attracted an additional €500,000 in funding but are still months away from realizing the product they have in mind.

Mindful of this, they’ve eschewed seeking out press coverage, preferring to release and refine features out of the limelight. However, a site focusing on Italian news tipped me off to this new source of traffic, so now you know about Attrakt too.

Services Similar To Attrakt

Google’s customized search is probably Attrakt’s closest competitor. Many websites have added a basic version of it to supply a quick and easy site search, although it also includes features like Attrakt’s link categories, what Google calls refinements.

Perhaps the primary difference, beyond Google’s algorithmic prowess, is that Attrakt says its embedded search boxes will be advertising free (Attrakt does carry advertising on their site).

Attrakt also facilitates the sharing of curated custom search engines and plans on further differentiating themselves with additional social features. Readers can compare the search results for the same Schema.org resources indexed by Attrakt and Google.

Mahalo has positioned itself as a human edited search engine, but they don’t crowd source their contributions.

Delicious is by far the most used collaborative bookmarking service, however they don’t actually index the content of the saved bookmarks.

Volunia is a social search engine also from Italy, however their focus is more general.

Attrakt Opportunities For Marketers

Attrakt offers marketers the opportunity to demonstrate their personal or company expertise in a particular subject area through the creation and promotion of a curated search box.

As with all things social, the rules of the game have changed. The most successful search boxes will include comprehensive coverage of a subject domain, even if that means including resources from competitors.

What Webmasters Should Know About Attrakt

Attrakt robots.txt Support

Attrakt supports the robots exclusion protocol, known as robots.txt. Attrakt’s crawler is called attrakt. If Attrakt is crawling the site, web server logs will contain the user agent:

Mozilla/5.0 (compatible; attrakt/1.0 +http://www.attrakt.com)

Meta tags are not yet supported, nor is there support for sitemaps.org and schema.org protocols.

Keyword Tracking In Google Analytics And Similar Systems

Attrakt provides search query information in URL referrers using the defacto standard q=<query> URL parameter name/value pair.

Users of most digital media measurement systems will need to add recognition logic for Attrakt searches, otherwise Attrakt will show up as a simple site referer. Google Analytics asynchronous tracking code users can add ['_addOrganic','attrakt.com','q'] to their tracking code.

The story behind the Attrakt name? When asked, the Attrakt team demurred. Its origins seem to be lost in the sands of time.

Below are the overall most-searched categories and the fastest growing across the YP Local Ad Network (Q3 vs. Q4 2011):

The top mobile search categories are similar but not identical to the list in the graphic above:

1. Restaurants
2. Automotive
3. Movie Theaters
4. Beauty Services
5. Hotels

Mobile searches now represent “more than 30 percent of all searches” across the YP Local Ad Network. This number is higher than the mobile percentage of general search, which is more like 15 – 18 percent overall, though higher in some categories.

Last quarter AT&T Interactive said that its mobile users click ads 2X more than PC users. Mobile users are also more inclined to call a business than their online counterparts, who are more likely to visit a website.

The graphic below reflects actions taken by consumers on a business profile/more information page, after the initial click:

In Q4 2011, AT&T said that the top advertisers on the YP Local Ad Network by ad spend were the following:

1. Building Contractors
2. Legal
3. Medical
4. Automotive
5. Financial Services
6. Home Maintenance Services3
7. Pet and Animal
8. Moving and Storage
9. Real Estate
10. Insurance