HTTP cookies, or more commonly referred to as Web cookies, tracking cookies or just cookies, are parcels of text sent by a server to a web client (usually a browser) and then sent back unchanged by the client each time it accesses that server. HTTP cookies are used for authenticating, session tracking (state maintenance), and maintaining specific information about users, such as site preferences or the contents of their electronic shopping carts. The term “cookie” is derived from “magic cookie,” a well-known concept in UNIX computing which inspired both the idea and the name of HTTP cookies.

Cookies are subject to a number of misconceptions, mostly based on the erroneous notion that they are computer programs. In fact, cookies are simple pieces of data unable to perform any operation by themselves. In particular, they are neither spyware nor viruses, despite the detection of cookies from certain sites by many anti-spyware products.

Most modern browsers allow users to decide whether to accept cookies, but rejection makes some websites unusable. For example, shopping carts implemented using cookies do not work if cookies are rejected.

History
The term “HTTP cookie” derives from “magic cookie”, a packet of data a program receives but only uses for sending it again, possibly to its origin, unchanged. Magic cookies were already used in computing when Lou Montulli had the idea of using them in Web communications in June 1994. At the time, he was an employee of Netscape Communications, which was developing an e-commerce application for a customer. Cookies provided a solution to the problem of reliably implementing a virtual shopping cart.

Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Mosaic Netscape, released on October 13, 1994, supported cookies. The first actual use of cookies (out of the labs) was made for checking whether visitors to the Netscape Web site had already visited the site. Montulli applied for a patent for the cookie technology in 1995; it was granted in 1998. Support for cookies was integrated in Internet Explorer in version 2, released in October 1995.

The introduction of cookies was not widely known to the public, at the time. In particular, cookies were accepted by default, and users were not notified of the presence of cookies. Some people were aware of the existence of cookies as early as the first quarter of 1995,but the general public learned about them after the Financial Times published an article about them on February 12, 1996. In the same year, cookies received lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. Federal Trade Commission hearings in 1996 and 1997.

The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk mailing list. A special working group within the IETF was formed. Two alternative proposals for introducing a state in an HTTP transactions had been proposed by Brian Behlendorf and David Kristol, respectively, but the group, headed by Kristol himself, soon decided to use the Netscape specification as a starting point. On February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default.

At this time, advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was followed by RFC 2965 in October 2000.

Popularity: 67% [?]

Images or other objects contained in a Web page may reside in servers different from the one holding the page. In order to show such a page, the browser downloads all these objects, possibly receiving cookies. These cookies are called third-party cookies if the server sending them is located outside the domain of the Web page.

This condition is common with on-line advertisement. Indeed, web banners are typically stored in servers of the advertising company, which are not in the domain of the Web pages showing them. If third-party cookies are not rejected by the browser, an advertising company can track a user across the sites where it has placed a banner. In particular, whenever a user views a page containing a banner, the browser retrieves the banner from a server of the advertising company. If this server has previously set a cookie, the browser sends it back, allowing the advertising company to link this access with the previous one. By choosing a unique banner URL for every Web page where it is placed or by using the HTTP referer field, the advertising company can then find out which pages the user has viewed. The same technique can be used with web bugs. These, unlike the obvious banners, are images embedded in the Web page that are undetectable by the user (e.g. they are tiny and/or transparent)

Third-party cookies are used to create an anonymous profile of the user. This allows the advertising company to select the banner to show to a user based on the user’s profile. The advertising industry has denied any other use of these profiles.

Many modern browsers, such as Mozilla Firefox, Internet Explorer and Opera block third party cookies if requested by the user. Internet Explorer version 6 allows a mild form of blocking, called leashing. A leashed cookie is a third-party cookie that is sent by the browser only when accessing a third-party document via the same first-party. For example, if third.com sets a cookie when an image is requested, and this cookie is set for the first time when the user views a document from first.com, the same cookie is not sent if the user downloads a document that contains the same image but the document is on another site other.com, if the cookie is leashed. A leashed cookie is different from a blocked cookie in that it is sent, in this example, if the image is contained in another document from the same site first.com

Popularity: 67% [?]

The first step of the analytics process is to define your business metrics, which are typically called key performance indicators (KPIs). In doing this, remember that KPIs go well beyond your website. Site-centric statistics, such as hits, number of visitors, or average visit length, aren’t business metrics. They’re merely ways of measuring activity on your website, and in most cases they can’t tell you anything meaningful about your performance.

To get real business metrics, you need to look at your website in the context of your overall business strategy. Your business is the foundation for everything you end up doing with web-analytics data. And so, you need to determine how the behavior of users on your website relates to your overall business goals.

This isn’t as difficult as it may sound. The easiest way to think about user ehavior is to ask yourself what you want people to do on your site. In web analytics, we refer to these actions as desired behaviors. They include such things as the paths
you want users to take, the marketing initiatives you want them to come into contact ith, and the products you want them to buy. Desired behaviors may be as simple the ovement of customers from your home page to a specific initiative. Or, they may be omplex. For example, a content site may want its users to explore particular site areas hat have higher ad-conversion rates than others. There are as many possible desired ehaviors as there are business objectives; the important thing is to isolate what you ant users to do.

The second step is to monetize these desired behaviors. In other words, you hould figure out the value of each behavior to your business. For example, if you’re rying to drive customers to a particular offer, you should be able to define the likelihood that each new prospect will take you up on it and how much each conversion is worth to your company.

Popularity: 60% [?]

In 2005, Forrester Research asked web professionals what they found to be the hardest part of using analytics in their organizations. Surprisingly, only 24 percent replied “pulling together the data.” By contrast, 53 percent said “acting on the findings.”

This is a big problem. An organization that fails to act on its analytics findings is like a marathon runner who completes 25 miles in record time and then walks home without completing the race. By itself, compiling information won’t help your organization.
The surest way to achieve a 0 percent ROI on web analytics is to look at the data you collect and then do nothing with it.
To get the most out of analytics, you should plan to dedicate about 5 percent of your overall web budget to optimization. That should be enough to take advantage of the opportunities your analytics effort identifies without depriving your organization of the funds it needs for ongoing operations.

Of course, setting aside even such a small percentage of the overall budget to a new line item will raise objections. But any opposition you encounter should be easy to overcome. To justify the expenditure, pick two or three of your top KPIs, and look at their performance over the past 12 months. Next, model the financial impact that would result if you improved their performance by a small amount. Present the benefits of this change, and you should have little difficulty convincing others in your organization to provide the resources needed for optimization.

Popularity: 65% [?]

Setting proper KPIs is a great step toward building a data-driven organization. But often that initial effort turns out to be temporary. A few months later, companies lose sight of those goals. Soon, web-analytics reports become just pieces of paper (or e-mails) that float across desks on their way to oblivion.

To keep your organization thinking about its KPIs, you should make them part of your individual and group goals. As any manager knows, nothing can focus employee attention quite like the promise of financial rewards (or the possibility of a bad performance review). By holding teams and individuals accountable for web performance, you’ll
drive them to improve it.

But if you’re going to tie goals to KPIs, you should also distribute data effectively, the best way to do this is through customized scorecards that highlight individual and group goals.  Any decent analyst or tool provider should be able to set up this kind of reporting for you.

Popularity: 53% [?]