Guest Post: Common Scenarios and Causes--Part 2 of the Ad-Serving Discrepancies Series

This is part 2 of our guest post from from Geoffrey Katz from Razorfish, New York. Geoffrey has over ten years of digital marketing experience with expertise in ad serving technologies. He has worked at Razorfish’s flagship New York office since 2007 as the Director of Advertising services, leading the Campaign Management and Ad Operations teams to execute the display media campaigns for the agency.

He was previously the Director of Product Management at Mediaplex, managing the product roadmap for a third party ad server. Prior to that, he spent many years developing commercial software products.

Geoffrey has a B.A. in Computer Science from New York University.

In the first article of this series, we recommended some steps that you can take to investigate (and, we hope, resolve!) ad-serving discrepancies. In this article, we’ll review some common scenarios and possible causes of discrepancies. By understanding the underlying causes, you can resolve issues more effectively.

The following are seven discrepancy scenarios and their possible causes:

Scenario 1: Publisher impression counts are much higher than Atlas’ counts.

• Possible causes
  • An ad-verification vendor detects unsafe content and blocks an Atlas tag from firing. The publisher will have counted the impression before the ad verification detected a problem.
  • Ad placement is served on a content-heavy webpage served only to mobile users. Latency caused by the mobile data network could result in slow page loads and users moving to another webpage before the Atlas tag fires.
  • The publisher is not cache-busting Atlas tags, causing Atlas not to be called on every ad request. When serving an ad, Atlas returns instructions to the browser not to cache the ad request. However, there might be instances where some browsers or proxy servers cache the request anyway. The only way to prevent this is to have the publisher append a random number to the ad tag on each request. The browser will then request a new copy from Atlas each time the Atlas tag is loaded.

Scenario 2: Atlas didn’t start tracking impressions or clicks until the middle of the flight.

• Possible causes
  • If third-party rich media is used, the rich media provider served without inserting Atlas impression trackers or click redirects.
  • The publisher served creative directly and didn’t add Atlas impression trackers or click redirects.
  • The Atlas tags were sent late to the publisher, and the publisher ran tags from a different placement.

Scenario 3: Publisher impression counts are a multiple of Atlas counts.

• Possible causes
  • The publisher placed the Atlas tag in multiple places on the same webpage, causing the tag to fire several times on the page. Per industry measurement standards, Atlas filters out suspicious activity. In this case, Atlas might have filtered out the duplicate impressions while the publisher might not have.

Scenario 4: Neither Atlas nor the publisher is tracking clicks. (This isn’t necessarily a discrepancy, but might be an ad serving problem.)

• Possible causes
  • The click redirect URL is too long. The maximum URL length on Internet Explorer is 2,083 characters. This limit currently applies to all Internet Explorer versions. Other browsers do not have this limit. For example, Firefox can handle URLs with over 100,000 characters. The limitation applies to the publisher click redirect and the Atlas click redirect combined—the total cannot exceed 2,083 characters.
  • For a Flash ad, the click redirect URL (publisher plus Atlas) is appended to the Flash URL, once for each clickTag variable. For example, if there are three clickTag variables (clickTag1, clickTag2, and clickTag3), the length of the publisher redirect combined with the Atlas redirect might exceed the 2,083-character limit. When this happens, the Flash ad might not appear in the browser even though both the publisher and Atlas count the impression.
    • Note: This can be an intermittent problem. For any given impression, the publisher click redirect can be a different length, depending on the number of intermediaries involved in serving the ad. Intermediaries can be ad networks and ad exchanges, all of which can track the click.
  • The Flash ad is using a hardcoded landing page URL instead of the clickTag Flash variable that contains the publisher and Atlas click redirects.
  • The Flash ad is expecting a different spelling or capitalization of clickTag and uses a hardcoded landing page URL when its clickTag variable is empty.

Scenario 5: Atlas is tracking much higher impressions than the publisher. Publisher counts are naturally five to 10 percent higher than advertiser counts because publishers serve and count first. If Atlas is recording higher counts, there is likely a configuration issue.

• Possible causes
  • If publisher click counts are similarly lower than Atlas’ click counts, it’s likely that the publisher is serving the Atlas tags from multiple publisher placements. More evidence would be that the publisher counts are on pace for delivering in full. Publishers using the Atlas Impression Exchange can quickly reveal this.
  • If click counts are nearly identical in both systems, then there might be a more complex problem. In this case, it can be helpful to use a web-tracing tool as the ad is served to see what Atlas tags fire when the page is loaded.

Scenario 6: There appears to be no activity in the Atlas reports, but the publisher says the tag is live.

• Possible cause
  • The placements might be hidden in the Atlas reports. Check the placement settings in the Atlas Media Console.

Scenario 7: Atlas click counts nearly match publisher impression counts, and Atlas impression counts are very low.

• Possible cause
  • The publisher or third-party rich media vendor implemented the Atlas impression tracker in the click redirect and the Atlas click redirect in the impression tracker.