If you ask me to point out the one thing that clients continuously bring up as a concern when it comes to DMP then I will tell you: Match Rates. It is a sensitive topic because it is one where it is rarely discussed in the sales or implementation cycle but comes to life during activation. Here is a sample of questions that clients have posed to me on Match Rates over the past few years:

“My segments in the DMP has over 1 MM cookies but when I mapped these segment to my 3 DSPs, each DSP is showing a different number and none of them is close to what the DMP is reporting. Where is all the data going?”

“When I map my segment from the DMP to a DSP, I only see 30% match rate. Why?”

“If Match rates are so bad, why can’t I just onboard my segments directly to the DSP?”

“Why can’t the DMP/DSP enhance their match rate?”

“Vendors are telling me that they have high match rates with my DMP but why do I only see 30% of my audiences available when mapped to them?”

And the list goes on. All of these are valid questions.

In order for me to answer these questions, I had to go through the painful process of validating all this. Few years back I had a client who was ready to pull the plug on a DMP because of the match rate issue. I am not kidding when I say that this is a nightmare. Luckily, I was able to convince the client to allow me to dig into this process further and come back with an analysis on why these match rates are so low or better off explain why they are not low. After working with over half a dozen of DSPs, product managers from the DMP and the DSP worlds and various clients, I was able to come up with a comprehensive list explaining the mystery behind Match Rates. I summarized my findings in these top four points:

1. Apples and Oranges

This is probably the first thing that your DMP vendor will say: “You are comparing apples to oranges and these numbers will never match.” There is a great deal of truth to this but if I have to guess what your follow-up question would be, it will be something like: “Yes, I understand that and I anticipate a 5-10% discrepancy but why am I seeing 50 – 60%?”

Oh well, you are both right.

Reporting criteria varies from one system to another and especially across DSPs. The criteria I am referencing could be one of many things:

  1. TTL: The cookie’s time to live window. Some DMPs sets the cookie’s time-life to be 120 days while some DSPs set it at 30 days. You can’t expect this to be the same or remotely close when comparing different technologies. As this varies across solutions then this will impact how solutions will count or ignore certain cookies.
  2. Active Cookies: Some DSPs only report on cookies that are associated with a live campaign when it comes to reporting. Others only report on cookies that they have seen in the past in a campaign– this means brand new cookies that come through a client website will not be reported on unless they also overlapped with an active campaign. Yes, this is actually a very common case.
  3. Delay in reporting: My favorite one of all. If we go back to the basics of audience sharing between a DMP and DSP, it is the idea of the DMP sending a batch of cookies (Server side, browser side, incremental or full refresh) to the DSP and then the DSP is ingesting the data and eventually reporting on them. This takes time and sometimes it takes 2 – 3 days so comparing the numbers in DMP on August 1st vs the numbers in DSP on that same exact day makes no sense. Given that integrations vary from one DSP to another then comparing on a day level is definitely not going to match up.
  4. Historical Data: This is a situation where you have a segment that you built in the DMP for a while and it has been collecting data for a very long time but you recently mapped it to a DSP (or you recently enabled this DSP as a partner/destination). Two things might happen here: 1) Not all integrations send historical data. On the contrary, a good number of integrations only enable new cookies and devices based on when the segment was mapped. 2) If the DSP is recently enabled for the client, then this means the ID Syncs (AAM lingo) or User Match Pixels (Krux lingo) was recently enabled and hence any historical data might not have an ID match between the DMP and the DSP and hence will not be transferred.

2. 1st Party vs 3rd Party Segments

I hope it is not a surprise to expect that match rates vary with the type of audience segment and the source of data that defines this segment. Let’s consider 3 types of segments:

  1. Segment with 1st party data based on site behavior

    This is a segment based on site activity such as registration, booking, order or referral. This means that a visitor needs to be on the site to qualify for this segment. This will have the highest match rate because this means that the visitor will trigger an ID Sync/User Match between the DMP and the DSP when they visit the site leading to a higher chance of a match.

  2. Segment with 1st party data based on on-boarded data

    We are still dealing with 1st party data but this time it is based on data on-boarded into the DMP via a file (either through data on-boarder or based on customer ID). This one is tricky because someone could qualify for this segment but they haven’t been on the site for a long time and never had an ID Sync/User Match with the DSP. In this case, their cookie will not be sent to the DSP.

  3. Segment with 3rd party data

    The most unpredictable of all. You are purchasing data from the DMP with no guarantee whether this data matches to the DSP or not. It is a similar issue to the previous point but the impact can be much higher in magnitude. My advice, don’t test match rates with 3rd party data.

3. Integration Type

We touched on this in the previous sections but this is a very important differentiator. The most preferred integration between a DMP and a DSP is a real-time server to server and backed up with a weekly full refresh FTP/s3 transfer. This type of integration guarantees that real time data is being transferred and any historical data is kept up to date. Unfortunately, not all DSPs support this type of integration. Some integrate based on a file upload (daily, weekly) while others rely on a pixel call or a transfer via a cookie. Different type of integration means that different types of data will be sent. For example, if the integration is based on a pixel call then this will require the visitor to be on the client’s property (website or app) for this data to be transferred. This is ok for site level segments but how about 3rd party segments? This will become an issue.

4. Safari Effect

Integrations between DMPs and DSPs rely on an ID Sync/User Match between both vendors. In order for this type of handshake to happen, we rely on 3rd party cookies in the visitor’s browser. In situations where the 3rd party cookies are disabled then the ID Matching fails and these audiences become ghosts. Unfortunately, this is what happens with Safari. Safari browser doesn’t support 3rd party cookies, it actually barely supports 1st party. In this case, you always need to account for at least 30% of your devices to be stale and not make it from the DMP to the DSP and hence why you rarely would see a match rate in the 90 percentiles. Salesforce DMP (Krux) highlights this well in their Partner Management UI:
Safari Match Rates

My secret formula

Given all the above discrepancies, how can we guarantee that our match rates are not delusional and in reality, the DMP is a vendor you can put your trust in? It is actually fairly simple but it takes some coordination and close attention to detail. I went through this process and the outcome was this secret formula that I want to share with you. Here is my recommendation on testing the match rate properly:

  1. Create a fresh segment based on 1st party site data. In Adobe Audience Manager, create the trait and the segment on the same day. In Salesforce DMP, add a new variable to the data layer to create a new attribute to build a segment from. It is important that this segment is new and has no historical data
  2. As soon as the segment is created, map it to destination/partner
  3. Choose a partner that uses a real-time HTTP or daily FTP/s3 transfer
  4. Don’t compare the reporting in the DMP with the reporting on the partner side
  5. Instead, work closely with the partner to extract the files they receive before they ingest into their reporting
  6. Get a daily count of the instances that the mapped segment exists in the file transferred to the partner
  7. Accounting for when the file was transferred and the segment count then you can compare those numbers to those in the DMP reporting
  8. Track these numbers for a full 7 days and watch how these numbers track closely together

I hope this will turn your nightmares into happy dreams about the DMP. Otherwise, just reach out to me and I will be happy to take a look at your issue more closely.

Jerry Helou, Ph.D.

Linkedin Icon

Jerry Helou, Ph.D.

Jerry Helou leads the Digital Experience Architecture practice at Softcrylic. He helps our clients accomplish advanced digital experiences and strategic business goals by implementing and leveraging multi-solution architecture.

Start typing and press Enter to search