Email scheduler, PDF export, and a transition to the new Google Analytics interface

Two of the most requested features from the old version of Google Analytics that have been absent in the new interface are report email scheduling and PDF export.  We are happy to announce that both email scheduling and PDF export functionality will be the new interface in a few weeks.

Because there are significant differences between reports in the new and old versions of Google Analytics, we would like to use this opportunity to solicit your feedback regarding which scheduled email reports should be preserved in the new version. We suspect that many of you would like to use this opportunity to “reset” the number and types of scheduled Google Analytics emails. As we roll out the new email system in the coming few weeks, we encourage you to examine your existing scheduled emails and make a personal decision on whether to recreate a similar scheduled email report.

Every standard and custom report will have an email scheduling option, shown below in the report options bar:

Clicking on the “EMAIL” button pulls up the following email scheduling dialog:

(A more detailed blog post about the emailer and its new functionality will be available when the it is released in a few weeks.) The above email preview shows the work we have put into improving the email report setup over the older Analytics interface.

PDF export for every report will also be available within a few weeks.

With the upcoming release of both the new emailer & PDF download, we want to give you three months notice (as of today) that the old Google Analytics interface as well as all existing scheduled emails will be sunset starting in January 2012. We believe that the new Google Analytics interface provides significant advantages over the old version, including access to Real Time Analytics, Multi-Channel Funnels, Social Plugin Analytics, & Flow Visualization. And hope you’ll find enough value in these new features that you’ll switch to the new version well before then.

Optimize Engagement using AddThis and ShareThis with Analytics

Increasingly users are discovering great content, products and links through social referrals such as +1 button endorsements, comments, likes, and shares. Earlier this year we introduced Social Plugin Analytics to help you analyze how users engage with any social plugin installed on your site – after all, what can be measured can also be improved and optimized!

MilkADeal started using Google Analytics earlier this year. It is a company in Malaysia that has benefited greatly from using Social Plugin Analytics. By using these new reports, they are able to uncover insights and create significant business process improvements. As reported in the New Straits Times, “In particular, the newly introduced social interaction tracking tool…We’ve been using it only in the last couple of weeks but we have seen an increase of almost 60% in social interaction visitors to our site,” said Wilson Quah, founder of MilkADeal.”

By optimizing the instrumentation of a few buttons on their site, MilkADeal is able to achieve better engagement, a big boost in number of high quality referrals, and better outcomes! Today, we are happy to announce that our partners, AddThis and ShareThis, are making this social plugin analysis even easier. Just as the +1 button is automatically instrumented for you by the Google+ team, publishers using AddThis and ShareThis will now have first class integrations with Social Plugin Analytics!

“Providing real-time analytics to 10 million domains each month, we see what big data can do every day. Integrating AddThis social signals into Google Analytics is a big win for publishers. We’re excited to contribute social sharing insight where it can be viewed in context of the GA interface.”

Will Meyer, VP of Publisher Products, Clearspring

“At ShareThis, we work to provide our publisher network of one million+ websites with actionable analytics on their social activity. It’s great to see Google paving the way for the entire industry to derive meaningful insights from the social Web and we’re incredibly pleased to be a launch partner.”

Kurt Abrahamson, CEO, ShareThis
To enable the integration for all of your AddThis buttons, you are now just one line of code away, and ShareThis users don’t have to do a thing. If you have Google Analytics installed, and you are using a ShareThis widget, simply login into Google Analytics and check out your new social reports!

BCIT increases visitor satisfaction with 4Q Suite and the Google Analytics API

One of the great aspects of being part of the Developer Relations team for Google Analytics is that I get to work with a lot of awesome partners that build cool and successful apps using the Google Analytics API. We’ve decided to share these successes as a series of mini case studies highlighting a variety of Google Analytics Apps. And to start off with we have iPerceptions’ 4Q Suite.

Objective: Improve the visitor experience

British Columbia Institute of Technology wanted their website to be both functional and satisfying. But, behavioral data alone wasn’t telling them what key audiences thought about the site. BCIT knew what visitors were doing on the site but wanted to learn more about why they behave the way they do. The overall objective for BCIT was to gain a better understanding of which content and processes were most effective for various audiences.

The Solution: 4Q Suite and the Google Analytics API

To meet this objective, BCIT chose 4Q Suite, an online survey tool built by iPerceptions. 4Q uses the Google Analytics API to link 4Q Suite survey responses with the corresponding Google Analytics session data. An analyst can then use this data to answer questions related to visitor intention and satisfaction. 4Q tracks six “Voice of Customer” events within Google Analytics. These events are related to survey completion, task completion, purpose of visit, and overall satisfaction. With 4Q survey data available in Google Analytics, marketers can better prioritize site enhancements, monitor the effectiveness of ad campaigns and marketing events more closely, and quickly identify changes in conversion. The Google Analytics API also makes it possible for 4Q to export GA data into the 4Q Suite dashboard, enabling analysis of the integrated dataset and open-ended feedback. And, users can view or receive automated alerts of significant changes based on the combination of 4Q Suite and Google Analytics data.

Result: Increased visitor satisfaction

Alan Etkin, Project and Web Analytics Manager at British Columbia Institute of Technology uses Google Analytics and 4Q Suite to segment site visitors by key audiences (students, prospective students, and faculty & staff), and see the differences in task completion and satisfaction. When BCIT redesigned their site with a strategic focus on prospective students, they saw a 15% increase in satisfaction among these visitors. Their behavioral analytics data also showed a 279% increase in a key conversion event for prospective students. From a strategic standpoint, 4Q Suite has given BCIT a clearer understanding of key audiences and has helped them report their results to the leadership team with easy to understand metrics. This, in turn, has helped them secure additional resources and the support to move forward with new projects.

About 4Q Suite and Google Analytics

4Q Suite was built by iPerceptions. According to Claude Guay, President & CEO, “The response has been tremendously positive. Many of our clients insist that the integration between 4Q Suite and Google Analytics is the most valuable feature that iPerceptions has to offer because it connects what visitors are doing on their website with why they are doing it and how satisfied they are. 4Q Suite has rounded out our Voice of Customer analytics offering. Now companies of all sizes can hear what their website visitors are saying, connect the what with the why, and react to the issues that affect satisfaction and conversion. In the space of a few weeks since launching, hundreds of 4Q Suite customers have already enabled Google Analytics integration.”

4Q Suite can be found through the Google Analytics App Gallery or directly from the 4Q Suite website.

GET, POST, and safely surfacing more of the web

As the web evolves, Google’s crawling and indexing capabilities also need to progress. We improved our indexing of Flash, built a more robust infrastructure called Caffeine, and we even started crawling forms where it makes sense. Now, especially with the growing popularity of JavaScript and, with it, AJAX, we’re finding more web pages requiring POST requests — either for the entire content of the page or because the pages are missing information and/or look completely broken without the resources returned from POST. For Google Search this is less than ideal, because when we’re not properly discovering and indexing content, searchers may not have access to the most comprehensive and relevant results.

We generally advise to use GET for fetching resources a page needs, and this is by far our preferred method of crawling. We’ve started experiments to rewrite POST requests to GET, and while this remains a valid strategy in some cases, often the contents returned by a web server for GET vs. POST are completely different. Additionally, there are legitimate reasons to use POST (e.g., you can attach more data to a POST request than a GET). So, while GET requests remain far more common, to surface more content on the web, Googlebot may now perform POST requests when we believe it’s safe and appropriate.

We take precautions to avoid performing any task on a site that could result in executing an unintended user action. Our POSTs are primarily for crawling resources that a page requests automatically, mimicking what a typical user would see when they open the URL in their browser. This will evolve over time as we find better heuristics, but that’s our current approach.

Let’s run through a few POSTs request scenarios that demonstrate how we’re improving our crawling and indexing to evolve with the web.

Examples of Googlebot’s POST requests

• Crawling a page via a POST redirect

<html>

 

  <body onload=”document.foo.submit();”>

 

    <form name=”foo” action=”request.php” method=”post”>

 

      <input type=”hidden” name=”bar” value=”234″/>

 

    </form>

 

  </body>

 

</html>

• Crawling a resource via a POST XMLHttpRequest
  In this step-by-step example, we improve both the indexing of a page and its Instant Preview by following the automatic XMLHttpRequest generated as the page renders.
  1. Google crawls the URL, yummy-sundae.html.
  2. Google begins indexing yummy-sundae.html and, as a part of this process, decides to attempt to render the page to better understand its content and/or generate the Instant Preview.
  3. During the render, yummy-sundae.html automatically sends an XMLHttpRequest for a resource, hot-fudge-info.html, using the POST method.
     <html>
     <head>
     <title>Yummy Sundae</title>
     <script src=”jquery.js”></script>
     </head>
     <body>
     This page is about a yummy sundae.
     <div id=”content”></div>
     <script type=”text/javascript”>
     $(document).ready(function() {
     $.post(‘hot-fudge-info.html’, function(data)
     {$(‘#content’).html(data);});
     });
     </script>
     </body>
     </html>
  4. The URL requested through POST, hot-fudge-info.html, along with its data payload, is added to Googlebot’s crawl queue.
  5. Googlebot performs a POST request to crawl hot-fudge-info.html.
  6. Google now has an accurate representation of yummy-sundae.html for Instant Previews. In certain cases, we may also incorporate the contents of hot-fudge-info.html into yummy-sundae.html.
  7. Google completes the indexing of yummy-sundae.html.
  8. User searches for [hot fudge sundae].
  9. Google’s algorithms can now better determine how yummy-sundae.html is relevant for this query, and we can properly display a snapshot of the page for Instant Previews.

Improving your site’s crawlability and indexability
General advice for creating crawlable sites is found in our Help Center. For webmasters who want to help Google crawl and index their content and/or generate the Instant Preview, here are a few simple reminders:

• Prefer GET for fetching resources, unless there’s a specific reason to use POST.

• Verify that we’re allowed to crawl the resources needed to render your page. In the example above, if hot-fudge-info.html is disallowed by robots.txt, Googlebot won’t fetch it. More subtly, if the JavaScript code that issues the XMLHttpRequest is located in an external .js file disallowed by robots.txt, we won’t see the connection between yummy-sundae.html and hot-fudge-info.html, so even if the latter is not disallowed itself, that may not help us much. We’ve seen even more complicated chains of dependencies in the wild. To help Google better understand your site it’s almost always better to allow Googlebot to crawl all resources.

  You can test whether resources are blocked through Webmaster Tools “Labs -> Instant Previews.”

• Make sure to return the same content to Googlebot as is returned to users’ web browsers. Cloaking (sending different content to Googlebot than to users) is a violation of our Webmaster Guidelines because, among other things, it may cause us to provide a searcher with an irrelevant result — the content the user views in their browser may be a complete mismatch from what we crawled and indexed. We’ve seen numerous POST-request examples where a webmaster non-maliciously cloaked (which is still a violation), and their cloaking — on even the smallest of changes — then caused JavaScript errors that prevented accurate indexing and completely defeated their reason for cloaking in the first place. Summarizing, if you want your site to be search-friendly, cloaking is an all-around sticky situation that’s best to avoid.

  To verify that you’re not accidentally cloaking, you can use Instant Previews within Webmaster Tools, or try setting the User-Agent string in your browser to something like:

  Mozilla/5.0 (compatible; Googlebot/2.1;
  +http://www.google.com/bot.html)

  Your site shouldn’t look any different after such a change. If you see a blank page, a JavaScript error, or if parts of the page are missing or different, that means that something’s wrong.

• Remember to include important content (i.e., the content you’d like indexed) as text, visible directly on the page and without requiring user-action to display. Most search engines are text-based and generally work best with text-based content. We’re always improving our ability to crawl and index content published in a variety of ways, but it remains a good practice to use text for important information.

Controlling your content
If you’d like to prevent content from being crawled or indexed for Google Web Search, traditional robots.txt directives remain the best method. To prevent the Instant Preview for your page(s), please see our Instant Previews FAQ which describes the “Google Web Preview” User-Agent and the nosnippet meta tag.

Moving forward
We’ll continue striving to increase the comprehensiveness of our index so searchers can find more relevant information. And we expect our crawling and indexing capability to improve and evolve over time, just like the web itself.

Raising awareness of cross-domain URL selections

A piece of content can often be reached via several URLs, not all of which may be on the same domain. A common example we’ve talked about over the years is having the same content available on more than one URL, an issue known as duplicate content. When we discover a group of pages with duplicate content, Google uses algorithms to select one representative URL for that content. A group of pages may contain URLs from the same site or from different sites. When the representative URL is selected from a group with different sites the selection is called a cross-domain URL selection. To take a simple example, if the group of URLs contains one URL from a.com and one URL from b.com and our algorithms select the URL from b.com, the a.com URL may no longer be shown in our search results and may see a drop in search-referred traffic.

Webmasters can greatly influence our algorithms’ selections using one of the currently supported mechanisms to indicate the preferred URL, for example using rel=”canonical” elements or 301 redirects. In most cases, the decisions our algorithms make in this regard correctly reflect the webmaster’s intent. However, in some rare cases we’ve also found many webmasters are confused as to why it has happened and what they can do if they believe the selection is incorrect.

To be transparent about cross-domain URL selection decisions, we’re launching new Webmaster Tools messages that will attempt to notify webmasters when our algorithms select an external URL instead of one from their website. The details about how these messages work are in our Help Center article about the topic, and in this blog post we’ll discuss the different scenarios in which you may see a cross-domain URL selection and what you can do to fix any selections you believe are incorrect.

Common causes of cross-domain URL selection

There are many scenarios that can lead our algorithms to select URLs across domains.

In most cases, our algorithms select a URL based on signals that the webmaster implemented to influence the decision. For example, a webmaster following our guidelines and best practices for moving websites is effectively signalling that the URLs on their new website are the ones they prefer for Google to select. If you’re moving your website and see these new messages in Webmaster Tools, you can take that as confirmation that our algorithms have noticed.

However, we regularly see webmasters ask questions when our algorithms select a URL they did not want selected. When your website is involved in a cross-domain selection, and you believe the selection is incorrect (i.e. not your intention), there are several strategies to improve the situation. Here are some of the common causes of unexpected cross-domain URL selections that we’ve seen, and how to fix them:

1. Duplicate content, including multi-regional websites: We regularly see webmasters use substantially the same content in the same language on multiple domains, sometimes inadvertently and sometimes to geotarget the content. For example, it’s common to see a webmaster set up the same English language website on both example.com and example.net, or a German language website hosted on a.de, a.at, and a.ch.Depending on your website and your users, you can use one of the currently-supported canonicalization techniques to signal to our algorithms which URLs you wish selected. Please see the following articles about this topic:
   • Canonicalization, specifically rel=”canonical” elements and 301 redirects
   • Multi-regional and multilingual sites and more about working with multi-regional websites
   • About rel=”alternate” hreflang=”x”
2. Configuration mistakes: Certain types of misconfigurations can lead our algorithms to make an incorrect decision. Examples of misconfiguration scenarios include:
   1. Incorrect canonicalization: Incorrect usage of canonicalization techniquespointing to URLs on an external website can lead our algorithms to select the external URLs to show in our search results. We’ve seen this happen with misconfigured content management systems (CMS) or CMS plugins installed by the webmaster.To fix this kind of situation, find how your website is incorrectly indicating the canonical URL preference (e.g. through incorrect usage of a rel=”canonical” element or a 301 redirect) and fix that.
   2. Misconfigured servers: Sometimes we see hosting misconfigurations where content from site a.com is returned for URLs on b.com. A similar case occurs when two unrelated web servers return identical soft 404 pagesthat we may fail to detect as error pages. In both situations we may assume the same content is being returned from two different sites and our algorithms may incorrectly select the a.com URL as the canonical of the b.com URL.You will need to investigate which part of your website’s serving infrastructure is misconfigured. For example, your server may be returning HTTP 200 (success) status codes for error pages, or your server might be confusing requests across different domains hosted on it. Once you find the root cause of the issue, work with your server admins to correct the configuration.
3. Malicious website attacks: Some attacks on websites introduce code that can cause undesired canonicalization. For example, the malicious code might cause the website to return an HTTP 301 redirect or insert a cross-domain rel=”canonical” link elementinto the HTML <head> or HTTP header, usually pointing to an external URL hosting malicious content. In these cases our algorithms may select the malicious or spammy URL instead of the URL on the compromised website.In this situation, please follow our guidance on cleaning your site and submit a reconsideration request when done. To identify cloaked attacks, you can use the Fetch as Googlebot function in Webmaster Tools to see your page’s content as Googlebot sees it.

In rare situations, our algorithms may select a URL from an external site that is hosting your content without your permission. If you believe that another site is duplicating your content in violation of copyright law, you may contact the site’s host to request removal. In addition, you can request that Google remove the infringing page from our search results by filing a request under the Digital Millennium Copyright Act.