Resolving 3rd Party Discrepancies

What are Discrepancies?

As a standard practice in interactive advertising, advertisers and publishers maintain independent ad servers to manage their campaigns.  There are number of reasons and efficiencies each party gains with this approach, but since each party counts an impression at a slightly different point in the delivery of an ad (publishers count at the ad request, advertisers count when the ad is delivered), the reporting from either system never matches the other.  This difference is called a 3rd party discrepancy, and unfortunately, they’re a fact of life in digital advertising.  While you can take steps to minimize discrepancies to a certain extent, at the end of the day you’re just going to have to put up with them as a cost of doing business.

Generally speaking though, discrepancies between your local ad server and a 3rd party ad server shouldn’t exceed 5 – 10%. Every now and again however you’ll find a particular campaign that skyrockets into the 30% territory or more.  In those cases, you really need to look into the campaign and try to correct the problem.  Below are some initial steps to take to try and resolve large discrepancies. Integrate this process into your Ad Ops group and you should be able to address a majority of the problem tags you encounter.

Validate Your Reporting

The obvious first step is to make sure you really and truly have a problem.  One of the most common reasons people think they have a discrepancy problem is because they haven’t pulled the reports themselves, or are otherwise missing data.  You can save yourself time and headache by taking this step first.

To ensure that you are looking at the exact same tags over the exact same time period in both systems, re-pull the reporting yourself.  If there is indeed a problem, look in your local server to see if those are the only tags running at the placement level.  Sometimes advertiser will rotate tags from multiple 3rd parties in the same publisher placement, perhaps one tag from a rich media vendor and another standard creative from their primary ad server, and the only reason it seems like there is a large discrepancy is because the reports are incomplete, and only include one party.

Similarly, some advertisers like to serve ad tags from a rich media vendor like Pointroll, but track those impressions in their primary ad server, like DFA.  In those cases, the DFA tracking code is often appended on the back of the rich media party, creating what is known as a 4th party relationship. 4th parties tend to have roughly double the discrepancy rate as 3rd parties, so most publishers require that billing be done against the 3rd party, whatever it is, even if advertisers also want to use a 4th party.  Billing groups and sales planning organizations frequently miss this subtlety and may pull a report from the wrong party.

If everything still checks out, you’ll want to get a daily breakdown of impressions from the local ad servers as well as the 3rd party, which may help you pinpoint the start of the problem.  For those unfamiliar with how to do this, I created a guide some time ago on how to pull daily reports from 3rd party ad servers you may find helpful.  If you find that the discrepancy suddenly increases at some point during the campaign, check the audit trail in your local server to see if a trafficker updated the tags, or perhaps changed something that would impact the tracking.

Validate the Ad Tags

Still looking for an answer?  The next step is to ensure that you have the same tags running in your local server as the 3rd party, and there are no additional missing tags on either side.  The best way to do this is to match the ad IDs between systems.  The ad id is the unique identifier at the most granular level available.  The id varies between systems, but is typically a 9 or 12-digit number, one you can identify in the ad call itself, visible within the editable ad code on the tag in your local server, and a column you should be able to pull into a 3rd party report.  Make sure that you are tracking impressions in the 3rd party for every ID you have in your local server.

Measure the File Size

If you still haven’t been able to identify a clear issue, the problem might come down to latency, that is, the latency between how long it takes a file to load and how long a user might stay on a page.  If a file is especially large, or “heavy”, in the hundreds of KB, for example, it may take so long to load on the page that users move on to the next page before it can finish rendering on the page.  Measure the file size and check it against your ad spec.  For some extremely large ads that contain video or other rich assets, a technique called a ‘polite download’ is often used.  A polite download embeds the impression tracking piece of the ad on small file that loads with the page, and then loads the heavy content after the fact.  In some cases however advertisers may mistakenly put the view tag, or impression tracking segment in the delayed piece, raising the discrepancy rate considerably.

Validate the Cache Buster is in Place

Another potential problem with 3rd party ad serving is that modern browsers may try and cache the ad material or code, preventing a new, unique call from the browser to the 3rd party.  To combat this problem, ad servers use a dynamic piece of code, usually a unique number, to force a new call to the 3rd party, called a cache buster.  Both the publisher and the marketer have separate cache busters in place; the publisher has one to ensure that the same ad tag on the same page generates a new call, and the marketer has one to ensure that their specific ad always generates a fresh call.  At times, the marketer’s trafficking team will forget to add the cache buster, and the publisher’s trafficking team won’t check for it as part of their QA.  If the marketer’s cache buster isn’t in place though, a fresh call is only made to the publisher, not the marketer, which can often cause large discrepancies between systems.

Unfortunately, inserting the cache buster on the 3rd party tag is usually a manual process, and done through a short code called a ‘macro’.  The macro is a small line of code that allows traffickers to simply cut and paste a single word or handful of characters instead of the entire segment of JavaScript that actually does the work of generating the unique value.  The most commonly used macro is from the DFA system, and is simply %n, or %%cachebuster%%.  If either segment is missing, this is most likely the problem.  Missing cache buster macros are particularly common in flash files, where they need to be embedded in the code.

Validate Intermediaries

Finally, if all else fails, look to see if there are any other intermediaries or 4th parties involved in the ad call that have the power to block the ad call between systems.  For example, ad verification systems like DoubleVerify and AdSafe both have products that quickly look at aspects of the ad call, such as geography or page content, and if they see something they don’t like, have the power to stop the ad from loading on the page.  This most certainly causes an increased discrepancy, but the good news here is that you can often get some type of reporting or information from the verification company on why or on what pages the block happened.

If none of those paths work, you last option is to submit a case to the 3rd party in question, but frankly, this rarely yields any productive results.  The better option is to work directly with the marketer to get new tags, and try again.

Leave a Reply

Your email address will not be published. Required fields are marked *