Tuesday, June 12, 2012

AdWords < 3 Mobile Apps

AdWords < 3 Mobile Apps: Cross posted from the Google Mobile Ads blog



When we acquired AdMob two years ago, we made a big bet on mobile - and on mobile display advertising. As smartphone adoption has continued to grow around the world, we’ve seen that bet pay off with the increasingly strong appetite to engage customers on mobile devices.   Starting today, over one million AdWords advertisers will now be able to reach engaged consumers on more than 350 million mobile devices in the AdMob network and in some of the world’s most popular mobile applications.



By bringing our products and tools together, advertisers can work with Google to more effectively accomplish their marketing goals.  Earlier this week, we unveiled a newly unified digital ad platform that makes online marketing easier and more effective for large marketers and agencies using Doubleclick’s ad serving tools.  Similarly, with today’s announcement, AdMob mobile advertising becomes a seamless part of AdWords.



AdWords advertisers’ will now have access to mobile app inventory from directly within the AdWords interface, giving them the ability to create and manage ad campaigns that run across more than 300,000 mobile apps in the AdMob network.  Advertisers will be able to easily build, launch, and optimize their mobile campaigns across multiple platforms, and have full transparency about where their mobile ads run. AdMob’s network of apps gives advertisers true global reach with 23 countries each generating over one billion ad-requests last month, up from 11 countries in April 2011.



Starting today, a new campaign type is available in AdWords that makes it easy to launch an ad campaign to run on mobile apps on the AdMob network.  To start this new campaign type, advertisers can select “new campaign” from the Campaigns tab, and then “Display Network only (mobile apps)”.  


In addition to the ability to launch a mobile app campaign from within AdWords, advertisers can now reach individuals by targeting specific smartphone or tablet device models (e.g. Samsung Galaxy) or by targeting a particular manufacturer brand.  AdWords already enables targeting by operator, wifi, or operating system version.

Advertisers can also reach their desired audience by selecting from the categories available in the Google Play Store (e.g. ‘Games’) or App Store and search for individual apps (e.g. ‘Flood it’).  In the next several weeks, we’ll also provide an estimate on the number of devices reached and impressions targeted given your selections.




For more information on these new features, please join our webinar on mobile apps inventory in AdWords today at 10:00 AM PT / 1:00 PM ET (register here).

This is the latest chapter in our ongoing efforts not only to bring AdMob’s and Google’s tools together, but to mobilize all of our ads products and services.  Over the last year, we’ve brought mobile app inventory to the Doubleclick Ad Exchange, transitioned AdMob CPC campaigns to an AdWords-style auction, and launched the ability for advertisers to serve ads from DFA into the AdMob network.

As mobile continues to grow, we’ll continue to develop integrated advertising solutions designed to harness the specific features of mobile devices, usage, and context.

Posted by: Jonathan AlfernessDirector Product Management, Mobile Ads

Monday, May 7, 2012

Search quality highlights: 52 changes for April

Search quality highlights: 52 changes for April:

Update 6 May, 950am: We accidentally had one change included twice, "No freshness boost for low-quality content." We've removed the duplicate entry and updated the number of total launches from 53+ to 52+. - Ed.




We’ve had a zerg rush of 52+ launches this month in search. One of the big changes for me was our latest algorithm improvement to help you find more high-quality sites. But, that’s not all we’ve been up to. As you may recall, a couple months back we shared uncut video discussion of a spelling related change, and now that’s launched as well (see “More spell corrections for long queries”). Other highlights include changes in indexing, spelling, sitelinks, sports scores features and more. We even experimented with a couple more radical features, such as Really Advanced Search and Weather Control, but ultimately decided they were a little too foolish.



Here’s the real list for April:



  • Categorize paginated documents. [launch codename "Xirtam3", project codename "CategorizePaginatedDocuments"] Sometimes, search results can be dominated by documents from a paginated series. This change helps surface more diverse results in such cases.
  • More language-relevant navigational results. [launch codename "Raquel"] For navigational searches when the user types in a web address, such as [bol.com], we generally try to rank that web address at the top. However, this isn’t always the best answer. For example, bol.com is a Dutch page, but many users are actually searching in Portuguese and are looking for the Brazilian email service, http://www.bol.uol.com.br/. This change takes into account language to help return the most relevant navigational results.
  • Country identification for webpages. [launch codename "sudoku"] Location is an important signal we use to surface content more relevant to a particular country. For a while we’ve had systems designed to detect when a website, subdomain, or directory is relevant to a set of countries. This change extends the granularity of those systems to the page level for sites that host user generated content, meaning that some pages on a particular site can be considered relevant to France, while others might be considered relevant to Spain.
  • Anchors bug fix. [launch codename "Organochloride", project codename "Anchors"] This change fixed a bug related to our handling of anchors.
  • More domain diversity. [launch codename "Horde", project codename "Domain Crowding"] Sometimes search returns too many results from the same domain. This change helps surface content from a more diverse set of domains.
  • More local sites from organizations. [project codename "ImpOrgMap2"] This change makes it more likely you’ll find an organization website from your country (e.g. mexico.cnn.com for Mexico rather than cnn.com).
  • Improvements to local navigational searches. [launch codename "onebar-l"] For searches that include location terms, e.g. [dunston mint seattle] or [Vaso Azzurro Restaurant 94043], we are more likely to rank the local navigational homepages in the top position, even in cases where the navigational page does not mention the location.
  • Improvements to how search terms are scored in ranking. [launch codename "Bi02sw41"] One of the most fundamental signals used in search is whether and how your search terms appear on the pages you’re searching. This change improves the way those terms are scored.
  • Disable salience in snippets. [launch codename "DSS", project codename "Snippets"]
    This change updates our system for generating snippets to keep it consistent with other infrastructure improvements. It also simplifies and increases consistency in the snippet generation process.
  • More text from the beginning of the page in snippets. [launch codename "solar", project codename "Snippets"] This change makes it more likely we’ll show text from the beginning of a page in snippets when that text is particularly relevant.
  • Smoother ranking changes for fresh results. [launch codename "sep", project codename "Freshness"] We want to help you find the freshest results, particularly for searches with important new web content, such as breaking news topics. We try to promote content that appears to be fresh. This change applies a more granular classifier, leading to more nuanced changes in ranking based on freshness.
  • Improvement in a freshness signal. [launch codename "citron", project codename "Freshness"] This change is a minor improvement to one of the freshness signals which helps to better identify fresh documents.
  • No freshness boost for low-quality content. [launch codename “NoRot”, project codename “Freshness”] We have modified a classifier we use to promote fresh content to exclude fresh content identified as particularly low-quality.
  • Tweak to trigger behavior for Instant Previews. This change narrows the trigger area for Instant Previews so that you won’t see a preview until you hover and pause over the icon to the right of each search result. In the past the feature would trigger if you moused into a larger button area.
  • Sunrise and sunset search feature internationalization. [project codename "sunrise-i18n"] We’ve internationalized the sunrise and sunset search feature to 33 new languages, so now you can more easily plan an evening jog before dusk or set your alarm clock to watch the sunrise with a friend. 
  • Improvements to currency conversion search feature in Turkish. [launch codename "kur", project codename "kur"] We launched improvements to the currency conversion search feature in Turkish. Try searching for [dolar kuru], [euro ne kadar], or [avro kaç para].
  • Improvements to news clustering for Serbian. [launch codename "serbian-5"] For news results, we generally try to cluster articles about the same story into groups. This change improves clustering in Serbian by better grouping articles written in Cyrillic and Latin. We also improved our use of “stemming” -- a technique that relies on the “stem” or root of a word.
  • Better query interpretation. This launch helps us better interpret the likely intention of your search query as suggested by your last few searches.
  • News universal results serving improvements. [launch codename "inhale"] This change streamlines the serving of news results on Google by shifting to a more unified system architecture.
  • UI improvements for breaking news topics. [launch codename "Smoothie", project codename "Smoothie"] We’ve improved the user interface for news results when you’re searching for a breaking news topic. You’ll often see a large image thumbnail alongside two fresh news results.
  • More comprehensive predictions for local queries. [project codename "Autocomplete"] This change improves the comprehensiveness of autocomplete predictions by expanding coverage for long-tail U.S. local search queries such as addresses or small businesses.
  • Improvements to triggering of public data search feature. [launch codename "Plunge_Local", project codename "DIVE"] This launch improves triggering for the public data search feature, broadening the range of queries that will return helpful population and unemployment data.
  • Adding Japanese and Korean to error page classifier. [launch codename "maniac4jars", project codename "Soft404"] We have signals designed to detect crypto 404 pages (also known as “soft 404s”), pages that return valid text to a browser, but the text only contains error messages, such as “Page not found.” It’s rare that a user will be looking for such a page, so it’s important we be able to detect them. This change extends a particular classifier to Japanese and Korean.
  • More efficient generation of alternative titles. [launch codename "HalfMarathon"] We use a variety of signals to generate titles in search results. This change makes the process more efficient, saving tremendous CPU resources without degrading quality.
  • More concise and/or informative titles. [launch codename "kebmo"] We look at a number of factors when deciding what to show for the title of a search result. This change means you’ll find more informative titles and/or more concise titles with the same information.
  • Fewer bad spell corrections internationally. [launch codename "Potage", project codename "Spelling"] When you search for [mango tea], we don't want to show spelling predictions like “Did you mean 'mint tea'?” We have algorithms designed to prevent these “bad spell corrections” and this change internationalizes one of those algorithms.
  • More spelling corrections globally and in more languages. [launch codename "pita", project codename "Autocomplete"] Sometimes autocomplete will correct your spelling before you’ve finished typing. We’ve been offering advanced spelling corrections in English, and recently we extended the comprehensiveness of this feature to cover more than 60 languages.
  • More spell corrections for long queries. [launch codename "caterpillar_new", project codename "Spelling"] We rolled out a change making it more likely that your query will get a spell correction even if it’s longer than ten terms. You can watch uncut footage of when we decided to launch this from our past blog post.
  • More comprehensive triggering of “showing results for” goes international. [launch codename "ifprdym", project codename "Spelling"] In some cases when you’ve misspelled a search, say [pnumatic], the results you find will actually be results for the corrected query, “pneumatic.” In the past, we haven’t always provided the explicit user interface to say, “Showing results for pneumatic” and the option to “Search instead for pnumatic.” We recently started showing the explicit “Showing results for” interface more often in these cases in English, and now we’re expanding that to new languages.
  • “Did you mean” suppression goes international. [launch codename "idymsup", project codename "Spelling"] Sometimes the “Did you mean?” spelling feature predicts spelling corrections that are accurate, but wouldn’t actually be helpful if clicked. For example, the results for the predicted correction of your search may be nearly identical to the results for your original search. In these cases, inviting you to refine your search isn’t helpful. This change first checks a spell prediction to see if it’s useful before presenting it to the user. This algorithm was already rolled out in English, but now we’ve expanded to new languages. 
  • Spelling model refresh and quality improvements. We’ve refreshed spelling models and launched quality improvements in 27 languages.
  • Fewer autocomplete predictions leading to low-quality results. [launch codename "Queens5", project codename "Autocomplete"] We’ve rolled out a change designed to show fewer autocomplete predictions leading to low-quality results.
  • Improvements to SafeSearch for videos and images. [project codename "SafeSearch"] We’ve made improvements to our SafeSearch signals in videos and images mode, making it less likely you’ll see adult content when you aren’t looking for it.
  • Improved SafeSearch models. [launch codename "Squeezie", project codename "SafeSearch"] This change improves our classifier used to categorize pages for SafeSearch in 40+ languages.
  • Improvements to SafeSearch signals in Russian. [project codename "SafeSearch"] This change makes it less likely that you’ll see adult content in Russian when you aren’t looking for it.
  • Increase base index size by 15%. [project codename "Indexing"] The base search index is our main index for serving search results and every query that comes into Google is matched against this index. This change increases the number of documents served by that index by 15%. *Note: We’re constantly tuning the size of our different indexes and changes may not always appear in these blog posts.
  • New index tier. [launch codename "cantina", project codename "Indexing"] We keep our index in “tiers” where different documents are indexed at different rates depending on how relevant they are likely to be to users. This month we introduced an additional indexing tier to support continued comprehensiveness in search results.
  • Backend improvements in serving. [launch codename "Hedges", project codename "Benson"] We’ve rolled out some improvements to our serving systems making them less computationally expensive and massively simplifying code.
  • "Sub-sitelinks" in expanded sitelinks. [launch codename "thanksgiving"] This improvement digs deeper into megasitelinks by showing sub-sitelinks instead of the normal snippet.
  • Better ranking of expanded sitelinks. [project codename "Megasitelinks"] This change improves the ranking of megasitelinks by providing a minimum score for the sitelink based on a score for the same URL used in general ranking.
  • Sitelinks data refresh. [launch codename "Saralee-76"] Sitelinks (the links that appear beneath some search results and link deeper into the site) are generated in part by an offline process that analyzes site structure and other data to determine the most relevant links to show users. We’ve recently updated the data through our offline process. These updates happen frequently (on the order of weeks).
  • Less snippet duplication in expanded sitelinks. [project codename "Megasitelinks"] We’ve adopted a new technique to reduce duplication in the snippets of expanded sitelinks.
  • Movie showtimes search feature for mobile in China, Korea and Japan. We’ve expanded our movie showtimes feature for mobile to China, Korea and Japan.
  • MLB search feature. [launch codename "BallFour", project codename "Live Results"] As the MLB season began, we rolled out a new MLB search feature. Try searching for [sf giants score] or [mlb scores].
  • Spanish football (La Liga) search feature. This feature provides scores and information about teams playing in La Liga. Try searching for [barcelona fc] or [la liga].
  • Formula 1 racing search feature. [launch codename "CheckeredFlag"] This month we introduced a new search feature to help you find Formula 1 leaderboards and results. Try searching [formula 1] or [mark webber].
  • Tweaks to NHL search feature. We’ve improved the NHL search feature so it’s more likely to appear when relevant. Try searching for [nhl scores] or [capitals score].
  • Keyword stuffing classifier improvement. [project codename "Spam"] We have classifiers designed to detect when a website is keyword stuffing. This change made the keyword stuffing classifier better. 
  • More authoritative results. We’ve tweaked a signal we use to surface more authoritative content. 
  • Better HTML5 resource caching for mobile. We’ve improved caching of different components of the search results page, dramatically reducing latency in a number of cases.
And here are some other changes we’ve blogged about since last time:

Posted by Matt Cutts, Distinguished Engineer

Saturday, May 5, 2012

1000 Words About Images

1000 Words About Images: Webmaster level: All



Creativity is an important aspect of our lives and can enrich nearly everything we do. Say I'd like to make my teammate a cup of cool-looking coffee, but my creative batteries are empty; this would be (and is!) one of the many times when I look for inspiration on Google Images.






The images you see in our search results come from publishers of all sizes — bloggers, media outlets, stock photo sites — who have embedded these images in their HTML pages. Google can index image types formatted as BMP, GIF, JPEG, PNG and WebP, as well as SVG.



But how does Google know that the images are about coffee and not about tea? When our algorithms index images, they look at the textual content on the page the image was found on to learn more about the image. We also look at the page's title and its body; we might also learn more from the image’s filename, anchor text that points to it, and its "alt text;" we may use computer vision to learn more about the image and may also use the caption provided in the Image Sitemap if that text also exists on the page.



 To help us index your images, make sure that:


  • we can crawl both the HTML page the image is embedded in, and the image itself;
  • the image is in one of our supported formats: BMP, GIF, JPEG, PNG, WebP or SVG.
Additionally, we recommend:


  • that the image filename is related to the image’s content;
  • that the alt attribute of the image describes the image in a human-friendly way;
  • and finally, it also helps if the HTML page’s textual contents as well as the text near the image are related to the image.
Now some answers to questions we’ve seen many times:




Q: Why do I sometimes see Googlebot crawling my images, rather than Googlebot-Image?

A: Generally this happens when it’s not clear that a URL will lead to an image, so we crawl the URL with Googlebot first. If we find the URL leads to an image, we’ll usually revisit with Googlebot-Image. Because of this, it’s generally a good idea to allow crawling of your images and pages by both Googlebot and Googlebot-Image.



Q: Is it true that there’s a maximum file size for the images?

A: We’re happy to index images of any size; there’s no file size restriction.




Q: What happens to the EXIF, XMP and other metadata my images contain?

A: We may use any information we find to help our users find what they’re looking for more easily. Additionally, information like EXIF data may be displayed in the right-hand sidebar of the interstitial page that appears when you click on an image.




Q: Should I really submit an Image Sitemap? What are the benefits?

A: Yes! Image Sitemaps help us learn about your new images and may also help us learn what the images are about.




Q: I’m using a CDN to host my images; how can I still use an Image Sitemap?

A: Cross-domain restrictions apply only to the Sitemaps’ tag. In Image Sitemaps, the tag is allowed to point to a URL on another domain, so using a CDN for your images is fine.
We also encourage you to verify the CDN’s domain name in Webmaster Tools so that we can inform you of any crawl errors that we might find.




Q: Is it a problem if my images can be found on multiple domains or subdomains I own — for example, CDNs or related sites?

A: Generally, the best practice is to have only one copy of any type of content. If you’re duplicating your images across multiple hostnames, our algorithms may pick one copy as the canonical copy of the image, which may not be your preferred version. This can also lead to slower crawling and indexing of your images.




Q: We sometimes see the original source of an image ranked lower than other sources; why is this?

A: Keep in mind that we use the textual content of a page when determining the context of an image. For example, if the original source is a page from an image gallery that has very little text, it can happen that a page with more textual context is chosen to be shown in search. If you feel you've identified very bad search results for a particular query, feel free to use the feedback link below the search results or to share your example in our Webmaster Help Forum.




SafeSearch

Our algorithms use a great variety of signals to decide whether an image — or a whole page, if we’re talking about Web Search — should be filtered from the results when the user’s SafeSearch filter is turned on. In the case of images some of these signals are generated using computer vision, but the SafeSearch algorithms also look at simpler things such as where the image was used previously and the context in which the image was used.
One of the strongest signals, however, is self-marked adult pages. We recommend that webmasters who publish adult content mark up their pages with one of the following meta tags:

<meta name="rating" content="adult" />
<meta name="rating" content="RTA-5042-1996-1400-1577-RTA" />
Many users prefer not to have adult content included in their search results (especially if kids use the same computer). When a webmaster provides one of these meta tags, it helps to provide a better user experience because users don't see results which they don't want to or expect to see. 

As with all algorithms, sometimes it may happen that SafeSearch filters content inadvertently. If you think your images or pages are mistakenly being filtered by SafeSearch, please let us know using the following form

If you need more information about how we index images, please check out the section of our Help Center dedicated to images, read our SEO Starter Guide which contains lots of useful information, and if you have more questions please post them in the Webmaster Help Forum

Written by Gary Illyes, Webmaster Trends Analyst