I’m not sure what you mean with “just talk with JSONp”. Isn’t a simple 1×1 interface much simpler than a full JSON interface?

To your point about client side JS… yes you can do this with two client javascript files. I’m not a huge fan of this approach for two reasons. (1) You are giving someone else access to write to your cookie space. (2) Not calling server-code means not logging/tracking which is important to understand how often you are matching, how often you succeed, etc..

-Mike

My sales told me to read this article for implementing something similar in our systems but:

Why wouldn’t they just talk with JSONp? “ad.exchange” has to do lots of stuff anyways. Why not just call real data gathering service instead of just 302 redirect? This is really “too simple” solution that is based on presumption that both ad servers will have this capabilities of syncing with just so small amount of data. You can also add 2 js files on different domains (ad.exchanged and ad.bidder) and let them do the cookie rewritings (XSS exception is based on domain since js is added from different domains it’s ok) – then you don’t even need to call any server code (!).

This information is very useful for me.

-Nandhini

They’re actually two completely separate processes. You’ll see these sync pixels tacked on to a large number of ads you see on the internet today but are disconnected from the actual real-time process.

-Mike

No there’s not because the cookie syncing process actually happens *before* the actual RTB bid requests. There is a problem of too many pixels on too many web pages, but that’s an entirely different one!

-Mike