The shadowy transmission of user data that Aaron mentions raises concerns for multiple reasons. For one, end users have an interest in protecting their own privacy. Two, people who make websites have an obligation to protect user privacy for the benefit of their users (to what degree they are obliged is of course the subject of much debate).

There’s a third case that gets less attention, and it has to do with the interest that audience-monetized websites have in protecting user data for their own benefit. And I don’t mean it in the sense that honorable websites that look out for their users will be rewarded by appreciative customers. I’m referring to the importance of not letting valuable audience data escape to your competitors’ servers. That’s what this post is about.

First, I’ll restate the problem and concerned parties so you can decide if this is something you’re interested in.

Problem: Adding third-party widgets like Facebook’s Like button and Twitter’s Tweet button to your site opens up a one-way channel of data transmission between your site and the widget provider. This data allows the widget provider to know which pages on your site their users view.

Who should care about this: In the broadest sense, anyone who works on digital products. In particular, digital products with revenue streams dependent on providing third parties access to audiences. More particularly, products that generate revenue from advertising. Most particularly, the publishing industry, who, having spent the better part of the last decade hoping the internet would go away, is most vulnerable as it tries to wobble up off the mat.

What’s the big deal if Facebook knows that one of their users viewed certain pages on your site? Let’s get into it.

Free content cannot be monetized

First off let’s agree that free content is never monetized. Content you give away for free has no exchange value. That’s why it’s free. You can, of course, make lots of money offering free content by monetizing the audience that consumes your content.

Niche media markets provide an easy way to illustrate how this works. Imagine you’re in the business of selling vintage gumball machines to gumball machine enthusiasts. How do you get exposure to the small group of people interested in your product?

Ten years ago you would buy an ad in a print publication aimed at gumball machine enthusiasts. The publication would contain all sorts of interesting content for people who love antique gumball machines but the person paying for this whole operation—you, the advertiser—would obviously not be paying for the content but for access to a particular audience. And access to that audience would be worth a lot because how the hell else are you going to find those people?

For the publisher this is all good until someone else slithers into the market with a competing publication and offers access to the same audience for less.

OK, so this is Publishing 101, Advertising 101, nothing new, you already know this, everyone who works in the industry already knows it. And yet…

Who are we competing with?

Last year a financial institution invited a handful of media companies to their offices to talk about an upcoming rebranding campaign. I was in attendance and the list of invitees was made up of standard players like The Economist, Dow Jones, and Time. But there was one name that stood out from the others: LinkedIn.

I was delighted because LinkedIn’s name on the schedule was proof of something that I and one of my tech colleagues had been trying to impress upon others for awhile—that social networks like LinkedIn and Facebook are not partners with media companies, but competitors.

At first the response from some of my colleagues was one of confusion. “LinkedIn? Why are they here?” What was surprising was how quickly the confusion was dismissed and the threat shrugged off. Here we were competing for the same advertising budget on the same afternoon and yet they could still not see a social media company as a competitor. Now I was confused.

After a little discussion the answer emerged: “Yeah, but LinkedIn doesn’t write news.” Right. So as long as LinkedIn doesn’t start writing news we’re all good. Hmmm.

Fuuuuuuungibility

One of the very best pieces I’ve read on the state of online journalism is a recent article by Stijn Debrouwere titled Fungible. If you’re unfamiliar with the term, a fungible object is one that can be exchanged for another object of identical substance and value. It’s a basic economic concept… and a brilliant title.

The article’s thesis is that “…journalism is not being disrupted by better journalism but by things that are hardly recognizable as journalism at all.” Stijn writes about how sites like Quora, Wikipedia, IMDB, and EveryBlock now fulfill many of the needs that people used to turn to journalism for. Audiences are exchanging journalism for non-journalism. And the thing is that they’re not exchanging it for something else, but for something that amounts to the same thing. (That’s the fungible part.)

Eggs

So again, it’s audience and not content that is the true business asset. Your audience, whether it’s a literal database of registered users or a free-roaming anonymous swarm of eyeballs (as is the case with most free content sites) is the thing to guard.

Mark Twain said, “Put all of your eggs in one basket—and watch that basket!” Media companies already have all the eggs in the audience basket. How well are they watching it?

This gets us back to the main point, which is that the web makes it very easy for one site to leak its precious audience data to another. All it takes is one widget, one little snippet of Javascript, to open up the gates.

Take the gumball machine example again but fast forward to the present and swap roles. Now you’re the publisher of GumballGuru.com and companies buy advertising on your site to gain access to your audience. On each of the pages on your site you have a Facebook Like button that reports back to Facebook which of their users are regular visitors to your site. This allows Facebook to build a database of people interested in gumball machines. The like button earns you some traffic from Facebook. Woot. But in exchange, you hand over your users. You squander your eggs.

Now your advertisers have another way to reach their target audience. Instead of buying ads on GumballGuru.com—as well as on your competitor GumballManiac.com—they can go to Facebook and purchase ads targeted at both users who like GumballGuru and GumballManiac. And they can do this at a much better cost.

By the way, if you don’t know, this is a real thing. You can go to Facebook today and purchase advertising exactly this way.

The sad thing is that publishers have been an accomplice to a heist they don’t yet realize they’re the victim of. It’s true that Facebook can collect this sort of data in other ways but they could never gather it so quickly and in such detail without cooperation from sites that did the hard work of building the audiences in the first place.

I’m using Facebook only as an example. It’s probably safe to say that the majority of third party widget providers are harvesting user data in some way. AddThis does, ShareThis does, Twitter does, LinkedIn does. We shouldn’t vilify them. The fact that the data is being collected doesn’t mean it’s been used in nefarious ways. You should just understand that when you add a piece of third-party JavaScript to your site, in exchange for whatever service you’re getting you’re giving the provider access to your user base.

It’s not the end of the world

I’ve painted a stark picture and admittedly reached out to extremes in an effort to clearly illustrate the problem. Not all media outfits are critically exposed to this threat. Advertisers and media agencies are not shifting their entire budgets to Facebook and LinkedIn tomorrow. There’s still question about the value of social network advertising. Journalism still has value and publishers are still more than capable of cultivating important relationships with their audiences. Facebook is not going to replace The New York Times (although it may replace GumballGuru).

The goal of this post was to draw attention to two ideas. One, that in a digital world, data about your audience IS your audience. And two, that data on the web is incredibly exposed and prone to being shared in ways even the people building the websites aren’t aware of.

What’s the solution? I have no idea. Building a fence around your product isn’t the answer. Probably the best thing to do is to continue to focus on building products that solve problems for people. Products that people will pull into their lives. While at the same time being aware of who you’re competing with and who you’re sharing data with.

That should make for a good start.

The misunderstandings grow further when you get into the matter of different types of cookies: first-party cookies, third-party cookies, Flash cookies, etc.

This post is concerned with third-party cookies, a subject I’ve singled out because of its day-to-day relevancy, importance to user privacy, and ease with which users can exercise control of it. It’s also something that I find even web developers can be easily confused about.

I hope this provides a clear understanding of how third-party cookies work and answers some of the questions you may have. First…

There’s no such thing as a third-party cookie

Right? OK, I’ll explain. Your browser maintains a collection of cookies. It receives a request from a website to store a cookie and it adds the cookie to the collection. There isn’t a collection of first-party cookies and a collection of third-party cookies, there’s just a collection of cookies.

The thing to understand is that there is no intrinsic difference between a first-party cookie and a third-party cookie. There are just cookies. The distinction only exists at runtime, within the context of a particular visit.

If a cookie is associated with a file requested from the same domain as the page you are viewing, it’s a first-party cookie. A cookie associated with a file requested from a different domain is a third-party cookie. That’s it.

Notice that the same cookie can be a first-party cookie one moment and a third-party cookie the next. For instance, when you visit twitter.com your browser sets several cookies associated wth the *.twitter.com domain name. In the context of your stay on Twitter these are first-party cookies. If you then visit huffingtonpost.com, Huffington Post requests files from twitter.com and those requests include the same *.twitter.com cookies, which are now third-party cookies.

What’s a cookie again?

We’ll do this real quick. (Begin obligatory http-request-as-casual-conversation-to-explain-how-cookies-work):

You visit a website and your browser starts requesting all the files that constitute the website. So your browser asks the server, “Can I have sleepy-cat.gif?” and the server is like, “Yeah, here you go oh and take this thing and bring it with you when you come back for more files. So I know it’s you.” Your browser says “kthxbye” and then returns a nanosecond later: “Hi can I have invisible-bike-cat.jpg? Oh and here, I have this thing.” And then the server goes, “Oh it’s you.”

At this point you’ve probably figured out that the mentioned thing is the cookie. That’s far from a complete description and it doesn’t explain why a server might want to recognize a browser but that’s stuff you can easily look up elsewhere and also I said we were going to keep this short.

Cookies are powerful

So in a sense, cookies connect the dots for the server. Without cookies there’s no way for the server to know that the requests for sleepy-cat.gif and invisible-bike-cat.jpg came from the same browser—from the same user.

There’s the rub. Cookies enable servers to aggregate requests—and thus data—around a particular user.

At the first-party level this is (mostly) all well and good. If you’re logged into Twitter the server uses a cookie to maintain your session, letting you stay logged in with each request.

But third-party cookie transactions perform no such value and instead tend to be used for behind-the-scenes tracking purposes. Again, if you’re reading an article on the Huffington Post, identification information is sent back to Twitter when the requests are made for the Tweet and Follow buttons. And just to be clear, you don’t have to interact with these buttons for the cookies to be sent. They are sent automatically as soon as the page loads.

Network inspector screenshot showing third-party cookie sent to Twitter.

What happens when you disable third-party cookies

So third-party cookies can be pretty gross. The good news is that you have the ability to shut this whole party down by disabling third-party cookies in your browser preferences. Disabling third-party cookies does two things.

One, it prevents HTTP responses and scripts from other domains from setting cookies. The instruction to store a cookie is simply ignored.

Is that enough? Just block third-party cookies from being set? Nope. Because you’ll remember that there is no intrinsic difference between first- and third-party cookies and that the same cookie can act as both in different contexts.

So the second thing disabling third-party cookies does is remove cookies from requests to domains that are not the document origin domain. In other words cookies are only sent to the current site that you’re viewing.

Privacy

I want to mention that not all third-party cookie activity is part of a data mining effort to stalk you across the web. Once a cookie is set the receiving site has no say about when the cookies are sent. They’re simply sent all the time. So just because a cookie is pinned to a request doesn’t mean the receiving server is tracking your activity.

In other cases, tracking your activity across different sites is exactly what the third-party cookies are for.

As users, most of us have an interest in protecting our privacy. Disabling third-party cookies is recommended for anyone concerned with privacy, as it can drastically reduce the amount of data collected about what we do online.

If you make websites you also have to worry about the privacy of your users. This means being aware of the privacy implications of third-party code and knowing how these vendors use third-party cookies. (Aaron Gustafson wrote a great post about this a few weeks ago. You should check it out. Link below.)

I hope this helped with your understanding of third-party cookies. If you have any questions or recommended additions/subtractions, please leave a note in the comments.

Related Articles

• Don’t Sell Out Your Users by Aaraon Gustafson
• HTTP Cookies Explained by Nicholas Zakas
• Serving Static Content from a Cookieless Domain by Me

Clumsiness on my part is mostly to blame. But it also has something to do with the fact that the primary interaction method on touch screens is overloaded (i.e., the same action has to perform multiple functions).

Anyway, when this happens I sometimes wish there was a way to “link lock” a page the same way that the orientation lock works. Toggle a switch and links are turned off so that scrolling, zooming, and gesturing can be performed without risk of leaving the page.

Of course this doesn’t make a ton of sense, considering that links and page interconnectedness are sort of the whole point of the web, but I think it’s an idea worth poking at, if only for the length of this short blog post.

So here’s a working demo. If you’re reading this on a device that supports touch events, tap-and-hold with three fingers anywhere on the screen. If it worked you’ll see a lock icon in the center of the screen and an opacity effect on all of the page’s links. At this point links are disabled. Repeating the gesture will turn them back on.

If you’re not using a touch device you can view this desktop demo that I hacked together. Just click and hold and you’ll see how the link lock toggling works.

That’s pretty much it. Deactivate links with a gesture to enable a less distracting reading experience.

Surely there’s a better gesture than tapping-and-holding (something faster would be preferred) but I wanted to choose something that was unlikely to conflict with OS-level gestures—also something that was easy to detect reliably with JavaScript.

If you want to play with the code or try it on your own site (I currently have it running throughout my blog), you can find it on Github.

Again, this is just a rough concept and not something that I think has much practical potential. To the degree that accidental link activation is a problem (not very much I assume) a better solution would be to do a better job of identifying intent rather than toggling an on/off state for the entire page. Still, if you have any thoughts on it I’d love to hear them.

If you’ve ever participated in an ontological debate about “the fold”, you know that how far users are willing to scroll down a page (and whether they’re willing to scroll at all) is an important concern for both designers and business stakeholders.

So how can we measure it? One option is to sign up for a service like Chartbeat that offers scroll depth as a reporting metric. Another option is to use a little jQuery to record the data in Google Analytics. Here’s a plugin for that.

jQuery Scroll Depth

This is a plugin that watches for scroll events and then reports data back to Google Analytics using the Events API. By the default the plugin will record Baseline (0%), 25%, 50%, 75%, and 100% scroll events. You can find the data in the Events section of Google Analytics. The category is “Scroll Depth”, the action is “Percentage” and the label is the scroll depth percentage.

Google Analytics Events can be viewed at both the site and page level. This means you can see site-wide scroll depth as well as scroll depth for individual pages.

In addition to the 25%, 50%, 75%, and 100% marks you can record scroll events for specific elements on the page. Has an ad been scrolled into view? Did the user scroll down to the article comments section? To track these elements you just pass the selector as one of the plugin options.

Setting it up

It’s easy to set up. First, make sure you’re using the Google Analytics asynchronous tracking code. This is required; the plugin will not work with the old version of the tracking code. Then include jQuery and the plugin. After that you just have to initialize the plugin. It looks like this:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script src="jquery.scrolldepth.js"></script>
<script>
$(function() {
  $.scrollDepth();
});
</script>

The code should be placed after your Google Analytics snippet and preferably at the bottom of the page, just before the closing body tag. (Note: If you’ve put the code at the bottom of the page, wrapping the plugin initialization in jQuery’s document ready event is not necessary.)

Try it out

To download the plugin or read more about the options, check out the jQuery Scroll Depth project page. If you have suggestions for improvement or would like to report bugs, please visit the Github repo.

Update (5/11/12)

I’ve posted a one-question poll asking for people’s opinion about what goal the “scroll depth” metric really tracks. If you have an opinion on this and would like to help advance this plugin, please take a second to weigh in!

Using it

Writing and reading your own cookies is easy enough but if you want to operate at a slightly higher level firstImpression.js offers a simple API for detecting first-time visitors.

// Basic usage
if ( firstImpression() ) {
  console.log('New user');
}
 
// Specify cookie name
if ( firstImpression('foo') ) {
  console.log('New user');
}
 
// Specify cookie name and expiration in days
if ( firstImpression('foo', 365) ) {
  console.log('New user');
}

Some stuff:

• firstImpression() returns true for a new user, false for a returning user.
• Calling firstImpression() also sets a cookie if one does not already exist.
• The default cookie name is “_firstImpression” and the default expiration is 2 years (730 days).
• You can specify your own cookie names if you want to manage multiple instances of firstImpression across a single site.
• If you want to check if someone has visited within a certain time frame you can specify the cookie expiration (in days).

Deleting Cookies

If you need to delete cookies you can do so via firstImpression.js like this:

// Remove default cookie
firstImpression(null);
 
// Remove custom named cookie
firstImpression('foo', null);

Browser Support

This should work in any browser that supports cookies. Tested briefly in Chrome, Firefox, Opera, IE6-10, iOS, Android, and Opera Mobile.

Download or Contribute

Download

Contribute on Gitub