On redirects & avoiding them

Mike on Ads continues to show how the sausage is made in online advertising with a very detailed post on browser-based redirects. Go read it.

I’ve got a couple comments:

First, the typical ad system integration, where every call is done in sequence through browser redirects, can’t just be converted to parallel server-side calls.  This is because the later ad system integration calls depend on the results of the earlier ones, unlike Mike’s ‘get content from Flickr and del.icio.us in parallel’ example. If you’re doing some analysis (contextual, behavioral, what-have-you) and then calling an advertising provider based on the results of that analysis, you’re making those two calls sequentially whether they’re from the user’s browser or from your server. That’s not to say there won’t be time savings, because your server-side connection to your contextual / behavioral / what-have-you is bound to be faster than a browser redirect, especially if you can stick all the systems in the same colo. But complete parallelism isn’t likely to happen.

Second, browser-based redirects have a benefit that server-side redirects don’t – cookie access. A server-side call to ‘adweasel.com’ doesn’t let adweasel read or set browser cookies, while a browser-side redirect does. Mike calls this a security risk, but let’s be honest — cookie access is necessary for the vast majority of ad engines out there. Even the contextual ad engine Mike uses as an example will need to read and write cookies if they’re supporting some very common features, like frequency capping, user opt-out, or cost-per-action campaigns.

Developing a system that lets a third-party utilize its own cookies without access to the browser isn’t easy. You can’t just write the third-party’s cookies to your own domain, because you’ll rapidly bump into per-domain cookie limitations if you integrate with multiple parties. Perhaps you could store the third-party’s cookies server-side in a database, referenced with a unique ID. However, the third party would still need to integrate the information in those cookies with the information he’s stored elsewhere about the user – which resides on the user’s browser or in the third-party’s database but referenced from a unique ID on the user’s browser. Perhaps if you could somehow coordinate to use the same IDs… good luck!

Mike’s a brilliant guy, and I’m looking forward to seeing what comes next from him. But this is a ridiculously tricky problem.  His post does have me thinking – perhaps a combination of server-to-server communications and third-party pixel calls from the browser could work?