In ad tech, different participants need to count events - impressions, clicks, conversions, etc. For example, when TripleLift is given a managed service campaign, we need to know that we delivered all the impressions we said we'd deliver. An agency might take us at our word, but it's standard to use a third party impression tracker, generally in the form of 1x1 image pixels or javascript that does something more sophisticated. Some of the additional features include verification of the inventory quality, assurances about the quality of the traffic, and verification that the frequency caps per user are respected. Advertiser-side impression trackers include companies like Sizmek, DFA (doubleclick for advertisers), and more.

Discrepancies arise for a number of reasons. The simplest example is if there's an adserver and an impression tracker called sequentially. The adserver would be called first by the browser. At this point, the adserver would generally increment its impression count. Then the browser would send a request to the impression tracker server, which would increment its impression count. In a perfect world, they would line up 1 to 1. In my experience, this has never happened in ad tech. First, the impression tracking pixel might never get called by the browser - perhaps because the user navigated away before it was called, or because the browser crashed, or basically anything between when the first and second call were made.


Often, discrepancies are a lot more subtle. For example, if an impression tracker requires a user to have only seen 3 of fewer ads in a given day, the user must have a ID for the company doing the tracking. In mobile or safari, for example, there are situations where one company would have an ID and can increment counters etc against that ID (because, for example, a user has clicked on ad for that company and were cookieable on a click-tracking page), while the other cannot generate a persistent ID. It's very difficult to resolve these discrepancies while also allowing the targeting of mobile users.

Browsers and websites may interfere with the ideal execution of an ad call. The unfortunate truth is that the same exact javascript is not actually run exactly the same across the major browsers, and across platforms. This means that something that "works" on chrome may introduce major discrepancies in safari, or vice-versa. Part of the reason is that browsers try to be friendly to developers and guess if the buggy code that was written can be "fixed" in a few different ways, so the fixing of broken or invalid code may result in pixels being fired in one browser, but not another. This broken code may be part of the website or in the ad tech.

The biggest reason that discrepancies matter is payment. Agencies may determine that they will only pay based on what their adserver records. So we could say we've served 1,000,000 ads, but if they only see 200,000, then we only get paid 1/5 of what we thought. So we've built a number of tools to constantly evaluate what 3rd party adservers are saying, try to identify areas of discrepancies as quickly as possibly, and either correct or don't serve where these discrepancies are intolerably high.

This was a very high-level overview. There are dozens of reasons for discrepancies, and the biggest problem is that time we find one, it's generally a unique reason, and often on some combination of device, browser, operating system and placement. It's what makes these issues particularly pernicious.