SSP to DSP Cookie Syncing Explained

42 comments

1. This is great. Thanks for a detailed step-by-step explanation.

2. Could you expand on this statement:

   “After SSP123 selects a winning bidder though, it runs one last piece of javascript that forces user123 to call out to a handful of regular bidders, including DSP456”

   So how exactly does that happen?

   Thx

3. Hi Jason,

   Basically speaking, the SSP’s tag is a chunk of JavaScript that in turn references other scripts. That’s pretty common with JS ad tags in general, actually – they usually have to do a few things to get the ad to work as designed. Sometimes they need to reference jQuery libraries, access browser plugins, compile information from other servers, reference cookies values, and a bunch of other things. Specific to the SSPs, the first sub-script usually redirects the user to the SSP’s server which starts the auction process. The last sub-script is a call which tells the browser to go call a bunch of other companies for the sake of cookie syncing users. For most browsers, this last script in practice may run more or less simultaneous to the auction / ad load, because by then, the browser has been redirected downstream to other parties and has moved on to the next part of the tag. Most modern browsers can keep 6 – 8 HTTP connections active at any given time, so once it executes the first sub-script, it starts following that path with some of the available connections and starts executing the next sub-script with others, depending on what else it has to load on the page.

   Hope that makes sense –

   Ben

4. Hi Ben,

   Can one company be both SSP and DSP, then no syncing is necessary? Is it because of privacy concern?

5. Hi Wes,

   No, no company plays both sides of the fence and is at once a DSP and an SSP. Google does own both types of companies – Invite Media is a DSP and Admeld is an SSP, but those companies still maintain separate cookie spaces on separate domains, so still need to cookie sync with one another. Their is no real privacy concern, the reason that there isn’t a DSP / SSP hybrid is because having both advertisers and publishers as a client on the same platform is a large conflict of interest – how would the platform represent both sides fairly – that if such a platform existed, I doubt they would have any customers. You wouldn’t hire a real estate agent to sell your house if they also represented the buyer, would you? Why would the agent have any incentive to get a fair market value for your house? For the same reason, DSPs and SSPs must stay as separate systems – many expect clients to abandon Admeld because of the conflict of interest for Google to represent both a buying and selling technology, but I can’t say I know that it’s actually happened in practice. As far as I know Google keeps those two companies very separate, and there’s no reason to think that Invite and Admeld don’t effectively operate as two separate, independent entities.

   Ben

6. Thanks for the great explanation, just curious to know
   1. Will DSP always have their code on advertiser website or there will be cases when the DSP cookie needs to be synched with advertiser’s cookie ?

   2. As explained in your another post, DMP will have cookies synched with various 3rd party systems, now how will DMP integrate with DSP, will it require cookie synching ?

7. Hi Akhil,

   To answer your questions –

   1. There’s no reason I can see why an advertiser wouldn’t fire their DSP’s cookie at the same time they drop their own cookie for any users they want to target in the exchange. In some cases however, an advertiser may have offline data and work through a match partner and data management platform (DMP) to bring that data online to a cookie, in which case the DMP would need to sync with the DSP before those users would be active in the exchange. That’s a much less common use case however, and in that instance, the advertiser doesn’t really have a cookie in the classic sense, dropped from their own domain, but really reusing someone else’s cookie space for their own purposes.

   2. Yes, DMPs integrate with DSPs through cookie syncing. A system to system sync only needs to happen once however, not once per system per client. Once the users are synced, the bridge benefits all the clients on both systems, who can move securely move proprietary data from one place to the other through a server to server integration.

   Hope that helps –

   Ben

8. Hi,
   I am not sure I understand this:

   “The DSP knows the SSP’s cookie ID because of the query string in the piggyback call, and it can read its own cookie ID because that user called its web server as the end destination with the piggyback call. DSP456 now writes into its database that DSPcookie789 = SSPcookieXYZ for bid requests from SSP123. The next time user123 hits a page that SSP123 is helping to monetize, DSP456 will know it is the same user”

   – wouldn’t it be in the DSP’s favor to ‘fake’ the cookie match? Say for e.g. the DSP456 says that the DSPcookie999 = SSPcookieXYZ, then SSP has no way of knowing whether DSP has genuine match or not and it will have to favor DSP456 for the subsequent bids.
   [here I am assuming that winning the bid matters the most to the DSP rather than winning the right bid, for the purpose of getting visibility or some other xyz reason…]

9. Hi Rohan,

   It’s important to realize that the DSP and the SSP have a mutual benefit in syncing cookies – browsers only allow a cookie to be read by the domain from which it was set, meaning the SSP can only read its own cookie on a user, and can’t know if a DSP also has a cookie on that user. In the bid request then, the SSP can only show bidders its own cookie ID, it can’t provide the DSP’s cookie ID. So it’s critical then that the DSP have a way to know if it has a cookie on that user, and what it knows about that cookie, from the SSP’s cookie ID only. The way it does this is through the cookie syncing process.

   To your question about faking the cookie match, though, the DSP doesn’t really have anything to gain in that scenario. It’s not as if the SSP knows anything meaningful about that user through the match, they just know if the user exists in the DSPs system, and vice versa. The cookie match simply facilitates the transaction. And the fact of the matter is that DSPs don’t bid more for un-synced cookies, they bid less, because they don’t know if they know anything about that user. Even if they were lying some of the time, in general, the DSP will likely bid less for unsynced users overall, so the SSP won’t favor them at all in that case. But again, there’s not much point – it’s far more important for the DSP to win the right bids than to simply win any bid, that’s the entire point of using a DSP. Otherwise, you could just use an ad network to buy as many impressions for the cheapest price possible, regardless of any knowledge about the user set.

   Hope that clears things up –

   Ben

10. Hi Ben,

    What other information can be passed via an SSP ID to the DSP to add value in the bidding process. From your description, the cookie syncing only supports a binary decision from the DSP as to whether or not there is a DSP cookie on the users machine – yes or no. It is commonly referenced within the industry that publishers have a wealth of data points on their users, and the onus should be on the publishers to expose this data with a view to better monetizing their sites. With the above definition, all of the information used as the basis for the bidding decision is on the advertiser side; through the retargeting pixel. Is there any other information that can be passed via the SSP cookie which would give the bidders greater insight into the user and their behaviour, so for example; the segment IDs (and segment definitions) to which the user belongs as classified by the publisher or the SSP.

11. “you have a 1×1 pixel sitting on your shopping cart page”

    Hello,

    you mean embedded javascript right? not a real pixel ?

    Ty

    Franck

12. Hi Ty,

    What I mean by that 1×1 pixel is basically, “you have a mechanism to track a conversion event” – that might manifest as a simple image tag for a transparent 1×1, or a piece of javascript may configure that conversion beacon call in some kind of dynamic fashion, or you may simply drop a cookie on that user through an image call. But whatever the specific technical execution, the point is the same, to track a conversion, and associate it to a specific user and that user’s other actions and touchpoints.

    Ben

13. Hi Ben

    I’ve been reading all your blog trying to figure out the scope of every player or system in the ecosystem of RTB.

    I will try to explain my understanding and my doubts.

    I understood that in some cases the SSP and the Ad Exchange are the same system / company, is that right?

    Also the SSP is who offers the publisher inventory to the DSP’s.

    The thing that I don’t understand is how the SSP and DSP are connected? How is a deal between those players in commercial terms? Let’s say that I want to make an SSP, how do I connect with the DSPs?.

    I’ve readed that the DSP and SSP are not the same company in order to give some transparency and to avoid conflict of intesrest but Right Media is offering a DSP and SSP as well.

    I hope that you can help me to clarify these points.

    Thanks!

14. Hi Hernan,

    To your first question, the SSP and Ad Exchange can fill similar roles in the ecosystem in terms of providing a marketplace to aggregate supply and demand, and create liquidity in the ad market. The main difference between the two is that the SSP is a technology that work to optimize revenue for publishers only, whereas the Ad Exchange just creates a market and is agnostic to getting the best price for the advertiser or publisher. You might think of SSPs as a sub-type of Ad Exchanges.

    To your second question, yes, the SSP offers inventory to the DSP. The SSP and DSP connect through an API, which in most cases is compliant with the OpenRTB specification, detailed here: http://www.iab.net/media/file/OpenRTB_API_Specification_Version2.0_FINAL.PDF The SSP and DSP do sign commercial terms if they want to transact with each other, and while it’s hard to boil a lengthy legal contract down, it effectively says the DSP will bid on requests from the SSP, and if the SSP accepts the bid, the DSP must pay the SSP that price within a certain period of time. If you wanted to start an SSP, you’d need to aggregate some supply by working with publishers or networks, and then you’d have to negotiate contracts to sell that supply of inventory to DSPs (or ad networks, trading desks, or advertisers directly).

    To your last question, Right Media is an exchange, but as you can see, the lines between exchange, DSP, and SSP are easily blurred. Right Media might offer services to buyers that enable them to bid on inventory in real-time, but it wouldn’t connect to many different exchanges like a classic DSP. Similarly, Right Media might help publishers sell their inventory, and even offer them tools to set rules and controls around what bidders are allowed, and at what price, but it won’t take an algorithmic approach to optimizing for revenue. It would be a conflict of interest to run the auction and optimize publisher revenue, and a paradox to optimize publisher revenue and advertiser spend from the same platform.

    Many other players facilitate RTB connections to both the buy and sell side, for example, Appnexus is another company that can serve both sides of the house, but isn’t a SSP or DSP in the classic sense. As you navigate this space, sometimes it’s helpful to ask these companies how they make money – do they sell services to buyers, or sellers, or both? Do they make a transaction fee regardless of clearing price, or a revenue share on the clearing price? Based on the answers to those questions, you can often figure out how the company has positioned themselves in the RTB ecosystem.

    Hope that helps –

    Ben

15. Thanks Ben, it was very helpful!!

16. I’m why curious SSP123 “runs one last piece of javascript that forces user123 to call out to a handful of regular bidders” as the last task rather than the first task? It would seem that registering SSPcookie123 with DSP456 would be the first thing to do so that the relationship would be established before the bidding began. Am I missing something?

17. Hi Ken,

    The reason this last script runs is for the benefit of the overall marketplace. While you are correct that SSPcookie123 has to be synced with DSPcookie456 before the DSP would bid for that user, that syncing does not take place before an impression the DSP would actually bid on. Meaning, the marketplace effectively burns one request per unsynced user to establish the relationship between systems. There’s not enough time to sync the user and then make a bid, it can only be one or the other.

    Because of that, SSPs and DSPs have a major financial incentive to sync users outside of auctions, and keep them in sync. That’s why they run this last script, which has the sole purpose of syncing cookie identities between systems. That way, the user is synced between 5, 10, 15, or more systems simultaneously so that for the next impression, the relationship is already established between systems for that user. This is important, because there are many types of bidders out there, some that bid on lots of impressions, and some that bid on just a few. The difference is that the DSPs that buy few impressions may be willing to pay the most, because they are looking for very specific users. If they only had the opportunity to sync users with supply sources for the impressions that they had the opportunity to bid on, the would have reduced reach, and therefore every party in the market would suffer, except for maybe the big DSPs that bid often but pay lower prices.

    Hope that clarifies –

    Ben

18. Hi Ben, great article. However, it looks like publishers (in this case the shopping cart page) have to add a pixel for every single DSP behind the exchange? Isn’t that inefficient for the publishers since they now need to learn about the tags for these different DSP’s? Moreover, is the publisher supposed to know about all the DSP’s sitting behind the exchange? Thanks.

19. Hi Posharma,

    Actually no; through cookie syncing scripts, a single tag can actually fire calls to many different systems. Thus, through a single tag, a user may receive 10 or more cookies from different DSPs. That’s only if the publisher wants this to happen though, for example if they wanted to target a user on the exchange, or sell that data to other bidders. Otherwise, publishers are likely to see this as a form of data leakage.

    Hope that helps –

    Ben

20. Hi

    In the process described above, does the SSP also know that its user 123, has the DSP cookie 789..and hence is able to make a note for future transactions? Since impressions always happen at the SSP side, isn’t it important for SSP’s to know and detect the match before sending bid requests to DSPs in order to minimize wastage?

21. Hi Shuba,

    The first statement you made is correct – the SSP can store the match table of what ID on its side matches which ID on the DSP side. But the second part isn’t as accurate; typically the SSP is simply sending its own cookie ID in the bid request to each DSP, which it expects has synced its ID (user 123) to their own (DSP cookie 789), rather than try to lookup the DSP’s ID and send the DSP their own ID in a bid request.

    So 123 gets sent to every bidder, not 789. This simplifies things for the SSP; they just know if a user is synced (and therefore worth more), they don’t have to do the dynamic operation of finding and injecting a unique ID per bid request per DSP integration.

    Hope that helps –

    Ben

22. Great article. Does this work effectively on mobile? Specifically, iOS is blocking 3rd party cookies by default which it seems would prevent the synching and tracking from happening correctly on those devices at least.

23. Hi Kurt,

    While the process runs as described in mobile, I would say that no, it does not work effectively. You’ve hit the nail on the head with iOS’s policy of blocking 3rd party cookies by default, which throws a wrench into this process. In fact, in mobile there is a whole set of companies that are working on what we call the ‘persistent ID problem’, usually by relying on device IDs created by the OS (IDFA for iOS, Advertiser ID for Android) or creating a synthetic or server side cookie. Device IDs are great, but they are only readable by mobile applications, and not a solution for mobile web traffic.

    But what exactly is a synthetic or server side cookie, you ask? Well, this gets into another set of questions on how those things work, and I’d refer you there to Gavin Dunaway’s truly excellent piece on AdMonsters on deterministic (I put a cookie that has a unique serial number on your machine that I can read again as long as you don’t delete it) vs. probabalistic (I have a supercomputer that compiles lots of disparate attributes about your device, like language, font size, screen resolution, carrier, location, IP, server clock variance, etc. that creates enough entropy between you and other users to effectively create a unique ID I can read) IDs. You might also think to look up AdTruth, who I would say was a pioneer in the synthetic ID space before being acquired by Experian last year.

    It’s an interesting topic in the industry, and one that’s still a moving target I would say.

    Hope that helps –

    Ben

24. Ben,

    Great article! However, I am a bit puzzled by this
    “If user123 had to call 10 DSPs, wait for those DSPs to cookie their machine, write the matching SSP id into their database, and then bid, it would dramatically slow down the entire auction process for everyone.”

    How would DSPs know what to bid on the user impression if they don’t know whether the user’s attributes?

    Do they just bid on the user the first time just to get the SSP cookie ID to have their match tables updated? You also mentioned that the user is forced to DSP’s ad server only after a winning bidder is determined. So, the first time DSPs have just bid blindly. Am I right?

25. Hi Amit,

    The DSPs likely would not bid on users for which they do not have cookied, unless they are buying on a contextual basis. The cookie sync scripts are what allow all the DSPs to write those cookies independent of the auction process. So as users navigate the web, they’re naturally exposed to the sync scripts, which identify them to DSPs, and enable the DSP to bid on them shortly afterwards.

    DSPs don’t bid blindly or just see users they’ve bid on because the cookie sync script which runs after every auction exposes new (and existing) users to their servers outside the auction.

    Hope that makes sense!
    Ben

26. Hi Ben,

    Thanks for the great article!

    The OpenRTB API Specification document is also interesting. Is there any documentation available, or can you give any details on the initial set up between a DSP and SSP? Once it is agreed that a PMP deal will take place, what are the initial steps to make this happen? Is it a case of sharing cookie IDs? What would each party do with these IDs?

27. Thanks Karen,

    The cookie sync process is more of a logistics thing that the SSP and DSP would have in place as a matter of doing business as a programmatic platform. In other words, you should worry if your DSP doesn’t have an identity sync in place with the major SSPs, and vice versa. That’s a table-stakes component of these companies. One of the companies (probably the SSP) would agree to store what’s called a match table on their platform, which is just a big database that has the SSP’s ID in one column and the DSP’s ID in the other column. Then, when the SSP sees an impression for a given user ID, they look up the DSP’s ID for that same user and pass the DSP’s own ID in the bid request to that platform. If the DSP were to host the match table on their side, the SSP would send the SSP ID in the bid request and the DSP would just do the same lookup / translation process on their side.

    This process enables the buying & selling process between the platforms, whether the goal is to transact in a private marketplace (PMP), the open exchange, or a private deal. Think of it as part of the infrastructure vs. a feature that you turn on and off.

    Hope that helps!
    Ben

28. Great Article Ben,

    As DSP’s are trying to increase the percentage of synced users on getting bid calls, and while they are integrated with many different exchanges, are you familiar with ways on syncing across exchanges/DMPs?
    My thought was around chaining of sync process such as the sync is done, the DMP/Exchange redirects back to the DSP so the DSP can continue the sync with other partners. Does that paradigm happens anywhere? Are you familiar with other ways of increasing the match rate other than syncs initiated by both parties?

    Thanks
    Shahar

29. Hi Shahar,

    Yes, chained redirects do happen, though I would say that is a problem for ad tech to solve, and not something to be encouraged. The reason being is that as you add 4th, 5th, 6th, and Nth party redirects you essentially abuse the user experience, slow down their browsing, and expose the user to all kinds of technology that the parties who really own that session (the publisher and user) never wanted or intended. I think these kinds of unrestricted syncing processes are a big reason for the rise in ad blocking software, because pixel calls have just gotten out of hand.

    In my view, a more responsible approach would be for exchanges to throttle the sync process between their partners with frequency caps in place. In other words, it’s senseless to sync a user multiple times per day and most exchanges see a given user quite a lot; I’d guess 25 – 50 times a day. When I worked to stand up an audience extension product at a publisher (retargeting 1st party audience on an exchange) I want to say that with a $10 bid an unlimited budget I could reach the average user something like 1,000 – 1,200 times a month. So there’s plenty of frequency to go around, it’s just not allocated very well.

    Usually, match rate issues can’t be solved with increasing the sync frequency, but rather point to more fundamental problems. This is especially true with offline to online syncs, which rely on a clearing house that uses PII as key between systems. If you have a bad match rate, you just may not have enough PII. Or, you might have an experience that people consume heavily from a work computer but then don’t use much for casual web surfing, meaning those users simply aren’t reachable on the exchange.

    Hope that helps!
    Ben

30. Hi Ben

    Great Article
    I would like to ask about this statement
    “After SSP123 selects a winning bidder though, it runs one last piece of javascript that forces user123 to call out to a handful of regular bidders, including DSP456. In that redirect, using a query string, the SSP passes its cookie ID on user123 (SSPcookieXYZ)”

    I would to ask if it is possible for the opposite to happen e.g. DSP runs the one last piece of javascript to call the different SSPs to perform cookie syncing.

    If that is the case, how did the winning bid is determined? By the DSP? Because i observed that the DSP send the cookie syncing script instead of SSP. I do not understand how did the DSP knows the winning bid.

    Ginger

31. Hi Ginger,

    Sure; DSPs, DMPs, SSPs, and lots of platforms can kick off cookie syncing scripts. A common setup would be that an SSP kicks off a cookie sync with five or ten DSPs, and those DSPs might in turn piggyback user syncs to DMPs used by their clients.

    This user identity sync is entirely independent of the auction though, so it doesn’t matter in terms of notifying the DSP that it won the impression. Rather, when the DSP bids, it returns a creative tag to the SSP as part of its response which has a tracking call embedded within it. If that tracking call (called a trackback) is called by a user’s browser, then the DSP knows it won that impression.

    Hope that makes sense!
    Ben

32. Hi Ben

    Great explanation, it helps me to understand how it works better.
    Does it mean that DSP, SSP and DMP apis must be within the same website or domain for cookie-syncing to work?

    How does the creative tag and a tracking call look like?

    Ginger

33. Great article Ben.
    I’m interested in knowing a couple of things:

    Firstly, could you answer Clive Page’s question, which i have reprinted below?

    ”
    Clive Page
    September 11, 2012 at 4:48 am
    Hi Ben,

    What other information can be passed via an SSP ID to the DSP to add value in the bidding process. From your description, the cookie syncing only supports a binary decision from the DSP as to whether or not there is a DSP cookie on the users machine – yes or no. It is commonly referenced within the industry that publishers have a wealth of data points on their users, and the onus should be on the publishers to expose this data with a view to better monetizing their sites. With the above definition, all of the information used as the basis for the bidding decision is on the advertiser side; through the retargeting pixel. Is there any other information that can be passed via the SSP cookie which would give the bidders greater insight into the user and their behaviour, so for example; the segment IDs (and segment definitions) to which the user belongs as classified by the publisher or the SSP.”

    Secondly,
    I want to know that if I am a publisher, what technology do i need to have on my website to be part track all the information that i can give to an SSP ?. Do i just need to have a pixel or drop a cookie on every user that visits my website or do i have to allow the SSP to drop it’s cookies on the users that visit my website? Also, is there any information i can withold or would the SSP have access to all the information on my website once they place their trackers?

    Finally, is there any way I can also get access to the SSP’s cookie pool, if I want to advertise to new users that have been to other relevant/competing websites ?

    Thanks!
    Harry

34. Hi Harry,

    Not sure how I missed that one – in terms of passing data to the DSP, there’s lots of ways to do that, but it’s a separate process from cookie syncing. Rather, you’d do this in the bid request. I’d recommend you take a look at sections 3.2.15 thru 3.2.17 of the OpenRTB 2.4 spec here: http://www.iab.com/wp-content/uploads/2016/01/OpenRTB-API-Specification-Version-2-4-DRAFT.pdf

    There are dedicated and predefined keyvalues for age and gender, as well as a generic keyvalue parameter the publisher could use to pass whatever information it wanted. This also allows for segment data to be passed. That said, in practice I would say these keys are rarely ever used for a few reasons. First, advertisers don’t need publisher to pass them 3rd party data sets, as the advertiser can integrate with those themselves, and for likely a better rate since they are a buyer. Secondly, if a publisher has valuable 1st party data they want to make available to buyers, they’ll typically do that through setting up a deal ID, which will stand in place for perhaps a host of data elements. By using a deal ID, it allows the publisher to more easily control the commercial terms of using that data, and to clearly explain what the data means, where it comes from, and so forth which the buyer might not understand if it was simply present in the request. This is covered in section 3.2.20.

    To your second question, you may need to pass additional information to the SSP if you want to add data to your bid requests. Certainly you’d need the SSP’s tag on page, but you might also need some JavaScript to pick up your content section ID for example, or pass user information. Then, you’d typically setup a deal ID in your SSP’s UI based on the data you’re passing over to it. There’s no other special technology you need per se, though if you wanted to pass user data it could benefit you to have a data management platform. Your SSP would only have access to the information you choose to pass it, though you would want to pay attention to your transparency settings on how you are represented to buyers on the exchange. What I mean is, if your site URLs are always structured as harryswebsite.com/contentsectionID, then if you pass the full ID it might not be very difficult for a buyer to target just one content section vs. another, and that will work against you if you are trying to create separate and premium deals for each content section.

    To your third question, typically no – you might be able to use a DSP for this purpose. You’d have to buy media on those competitor sites first, then you could retarget them on other sites. This could be difficult though if your competitors are blocking you, which they are likely to do. The SSP / DSP wouldn’t maintain data segments that were so specific as “user went to X domain” that I would imagine they’d make available to you.

    Hope that helps –
    Ben

35. Hi Ben,

    Firstly, great article and thanks for all the speedy and detailed responses. I have a couple of basic questions about cookies and cookie syncing

    1) As an advertiser, can I use my 1st party cookie to tracking browsing behavior of my website visitors outside my website? If yes, can I use this to create rich user profiles and then send them more targeted messages on owned media? If not, how can 3rd party cookies track such browsing?

    2) How do 3rd party data providers such as Eyota or Lotame cookie sync with Ad exchanges / DSP’s? Is there some piggybacking at the end of the script they use to drop a cookie to the user’s browsers via major publishers?

    Thanks, Vivek

36. Hi Vivek,

    Thanks – will try to help.

    1. Yes, assuming you buy media on those other websites. That is, your 1st party cookie is set on the user’s device, and because it can only be read by your server, you need that user to make a request to your server from those other websites. The easiest way to practically do that is to run a retargeting media campaign against those users, serve them an ad, and force them to call your website in the process through a tracking pixel. You can then use this information to further segment & target users. 3rd party cookies essentially track users for “free” because someone else is paying for the media, or they are part of the transaction process.

    2. Yes, they compel users to execute a cookie sync with exchanges / DSPs as part of their core JavaScript, commonly called a piggyback script. The DSPs / Exchanges could also kick off the cookie syncing process on their end through the same process.

    Hope that helps –

    Ben

37. The naming convention used to identify each component in the equation is horrible..

38. Thanks for feedback Dan; might you suggest a better approach I could use?

39. Hi Ben,

    Great articles, really enjoyed reading them as they give a sense of detailed technical descriptions with high level understanding.

    1. Is the SSP cookie remains on the user forever? is the DSP cookie remains forever?
    2. Cookie syncing is done every X days between SSP’s and DSP’s , or every time DSP gets an unknown user it request a piggyback execution? i’ve read in DoubleClick documentation that Cookie matching should expire after 2 weeks or so, does that mean the SSP cookie gets deleted or ..? (any more details on this process would be great) –
    3. How can we start targeting users if we only have their PII’s? (Emails, phones, etc)
    4. How do we start with behavior targeting ? it requires tracking the user bids for a long period of time right? (isn’t that a problem with cookie matching expiry etc.. ?)

40. Thanks Chuck –

    1. Theoretically speaking, yes – the cookie expiration date for general user ID cookies in ad tech is typically set years out. But in practice, most users delete their cookies within a fairly short timeframe so the vast majority of cookies are dead within a month.
    2. Cookie syncing needs to happen on an ongoing basis because users delete their cookies and break the sync – that’s what that DoubleClick comment is referring to. Usersyncs aren’t really that smart and usually happen once per user session per domain per platform. So if you were on cnn.com, you’d see lots of platforms trying to sync you, but if you stayed on the site for many pageviews eventually that process would stop as you’d be synced with all platforms. But then if you moved to nytimes.com, you’d see the process start all over again.
    3. You can work with a match provider that will sync your PII data to cookie data – companies like LiveRamp / Experian provide this service. You might find this article helpful: http://www.adopsinsider.com/data-management-platform/data-management-part-iv-syncing-offline-data-to-your-dmp/
    4. You can leverage 3rd party data for behavioral targeting (where the user is in a segment because of something they did outside your site), or you can work with a data management platform to start segmenting users on your own site. Popular platforms for this include Krux (owned by Salesforce), Lotame, BlueKai (owned by Oracle), Adobe, etc. Google Adwords also offers user segmentation for free, and then you can retarget those users through their ad network: https://support.google.com/adwords/answer/2454064 You might also be interested to use Facebook’s free Custom Audience tool, which lets you create remarketing lists using PII like email addresses: https://www.facebook.com/business/a/custom-audiences

    Hope that helps!

41. Thanks for all the info ben!

    To clarify:
    SSP’s will not delete their cookie every X days? So it means that they leave it as much as possible? or is it deleted after few weeks?
    What about exchanges?

42. Pingback: Mgid Cookie Matching Guide – MGID HelpDesk

Comments are closed.