Fourth-party calls: What you don’t know can hurt your site… and your visitors

There’s a growing awareness of the fact that third-party content can cause a major hit to your site’s performance. Good. Great. Now we need to tackle what I’ve dubbed “fourth-party calls”. Not only can these insidious server calls leach performance, they also have massive security implications.

Before I get into this, let me back up a little.

I came across this slide today, which reminded me how difficult the job of a marketer is on an ecommerce site. Look at all of the different technologies and intermediaries that exist between advertisers and publishers (click to see a larger version):

(Image source: LUMA Partners)

What does this huge landscape mean for the performance world?

In a nutshell, it means slower websites and more “single line of code” requests from marketing, which we as IT/Dev people try to fight — or at least try to analyze before implementing willy-nilly. The industry has covered this at length (examples here and here), I’ve written about it here, and we deal with this challenge every day at Strangeloop.

What has interested me lately is the complexity and potential speed and security impacts that site owners don’t even see — things that happen in the background after the third-party requests are called. Things that I have started to call “fourth-party calls”.

Example 1: Single third-party call –> many fourth-party calls you never authorized –> slower page load

You are a site owner and you are approached by a third-party company to add a single line of code. They send you an implementation guide and you task your developer to paste in a simple code fragment. The output on the page might look something like this:

<iframe src=” &mpuid=Wednesday, July 13, 2011 at 16:49:10 EDT” HEIGHT=”1″ WIDTH=”1″ FRAMEBORDER=”0″ ></iframe>

What happens next is the scary part: You effectively lose all control.

This file starts a cascade of fourth-party calls — calls from a third-party tag that you authorized to a ton of other sites. You thought that, with that single snippet of code, you had put in just one call to one server, but look at the waterfall below. Almost all of this is produced from that one line (click to see a larger version):

Waterfall showing fourth-party calls generated by third-party tag

If you’re new to reading waterfalls, here’s a quick primer. If you’d rather skip the primer, here’s a quick interpretation:

  • This “simple” third-party tag triggered 49 server calls — calls that the site owner did not authorize — to various fourth-party servers.
  • Of these 49 fourth-party calls, 21 are redirects. (These are indicated by the red dots.) The result: a ping pong effect as each redirected call ricochets from server to server, wasting valuable load time.
  • Every one of these fourth-party calls is over SSL, which has a significant impact on load time.
  • What this adds up to: all of these fourth-party calls add a 1.8 seconds to the page’s load time.

The impact on performance is serious. But what really concerns me is the fact that all of these fourth parties — companies you don’t have a relationship with — are filling up their databases with every last bit of data they can about your customers and your site.


Example 2: Fourth-party call –> data loss and privacy concerns

What is particularly concerning about the privacy and security implications of fourth-party calls is the fact that they have unfettered access to your user data: they can see and capture everything about your users without your explicit consent. And the type of information they can collect is amazing.

Here’s a fairly innocuous example. A few months ago, I  went to the Skechers site:

A short while later, I was visiting The New York Times site. Note the ad in the bottom right corner:

Fourth-party calls - The New York Times

This is a classic example of retargeting. Retargeting is when ads are delivered to you based on previous things you did or places you went online. Although Skechers is very happy (and pays a great deal of money) to have The NY Times show me this ad, my concern is that all of the data they authorized a third party to use to make this happen is available to any of the other fourth-party calls.

The data flowing out of the original site and into one, or perhaps even many, databases is scary. Do you want your users’ entire browsing history, including what products they looked at on your site, collected and sold by strangers?

Even worse, perhaps, is that the fourth-party calls could change any time at the whim of the third party — or even another fourth party — as many of these calls cascade and are handed from one company to the other.

People routinely get in a stew every time Facebook changes its privacy settings, but at least Facebook’s privacy settings are something you can control via a dashboard. If people knew how much of their personal browsing history has already been captured and stored in countless databases, the outcry would drown out the Facebook-related complaints.

If you’re using third-party tags, you need to ask yourself seven questions.

  1. Are you aware of the fourth-party calls made from third-party tags on your site?
  2. Have you talked about performance with your third parties and asked them what impact their tags will have on your page speed?
  3. If your third-party vendor decides to change the fourth-party calls it references, are you notified?
  4. Have you pushed your third-party vendor to optimize the way it handles calls or how it deals with fourth parties?
  5. What data are the fourth parties collecting?
  6. Does this usage comply with your corporate governance guidelines?
  7. Do these fourth-party calls contravene your customer-facing privacy policy?

What’s your experience with third-party tags and fourth-party calls? I’m curious to find out if this is emerging as an issue anywhere other than my corner of the universe.

Related posts: