Submit a request
 
PRODUCT
Privacy Policy |  AAS Advertising Policy | Terms of Use
Cookie Preference
✖

Amazon Ad Server will be sunset in Q4 2024, please visit this page (AAS offboarding information) for offboarding support resources and sunset FAQs. Details shared on that page represent the most up to date information in the Help Center, if you find disparate information in other resources please default to the information in the AAS offboarding information page accordingly.

Please note that on October 1, 2024, the ability to create new campaigns, placements, and tag managers will be disabled.

Follow
Last Update:
  viewable by end users
  editable by agents

Overview

Traditionally, for display ads, Amazon reported impressions when the ad started rendering on the user device. The on-render measuring approach did not consider whether the ad container was visible to the user within the device screen viewport. Amazon employed the on-render impressions reporting in both web browsers and mobile apps (in-app) servings.

The advertising industry recognizes the need to move away from the on-render to visibility-based impressions. However, digital, especially mobile, devices do not natively offer mechanisms that allow for affirmative visibility computations. MRAID narrowed the in-app verification capacities gaps, but it cannot address every in-app serving scenario.

New Mobile In-App Display Ads Impressions Counting Methodology

AAS mobile in-app impression counting methodology for display ads has changed. In addition to identifying the moment ad renders on the page, the new algorithm accounts for ad container visibility. AAS scripts report in-app impressions when the app displays at least one ad's pixel on the device screen.

The changes apply to the servings in the apps that support either MRAID or OM SDK. When servings occur in the apps that do not engage either MRAID or OMID, the display ads continue reporting impressions on-render.

  • Improper implementation of tags and cache-busters

  • Differences in the definition of an impression/click

  • Differences in filtering methodologies for invalid impressions or clicks

  • Invalid comparisons of reports

Before you begin testing, verify that both reports:

  • Cover the same date range, using the same time zone.

  • Include the same line items or ads.

  • Exclude unfilled impressions, as these can inflate Ad Manager numbers.

  • Differences between 3rd party reports.

  • When an ad server delivers line items that are hosted by a 3rd party, reporting discrepancies between the two systems occur, and it is common to see campaign variances of up to 10%.

Effect of New Methodology on Reporting Impressions

AAS Tracking Tag Implementation

To track events accurately, make sure that click-trackers and other macros are implemented properly. Contact your creative developer, advertiser, or 3rd party customer representative for guidance.

Latency

Lag between an initial line item request and the appearance of the creative can lead to differences in counts. For example, a user often navigates away after the browser receives the 3rd party's line-item request but before the AAS ad renders on users' devices. Or, a user may click on a link, but navigate elsewhere before the landing page has completely loaded.

Network connection and server reliability

A 3rd party ad server may fail briefly, or encounter an issue that prevents it from logging an impression.

Ad blockers

Ad-blocking software can prevent a tracker from firing and users may have a customized allow list/deny list that can cause only one ad server to count.

Low impression goals

A small numerical discrepancy can cause a high-percentage discrepancy if the line item delivered few total impressions. For example, if you have a campaign delivering 100 impressions per day, a single-day discrepancy of 30 impressions leads to a single-day discrepancy of 30%, even though the actual number of missed impressions is low.

Passbacks and calls to other 3rd party servers

Each 3rd party ad server can lead to campaign variances of up to 20%. If one 3rd party server points to yet another 3rd party server, the expected discrepancy increases.

Note

Note: Commonly accepted discrepancy rates vary from 10% on Display to 20% on Mobile environments. Global Support will check and provide analysis in all discrepancy cases that are more than 10%. If reports display desktop environments with less than 10% and mobile environments less than 20%, the discrepancy is declared as commonly accepted.

AAS Global Support works with agencies and does not initiate troubleshooting discrepancies directly from publishers or non-customers. They can work closely with publishers under organized meetings and tests through agencies or internal Customer Success teams to resolve identified discrepancies.

Effect of New Methodology on Amazon and Publishers Reports

There are five types of publishers. For each publisher type, the expected outcomes for mobile in-app display impressions will vary in the following ways.

 

  • Publisher daily delivery data broken down by placement

  • AAS placement ID/the trafficked tags

  • Live page (or a test page that mimics the live implementation) that allows Support to view and test the implementation

  • Technical contact information for the publisher or application experiencing the discrepancy

  • Ad server of the site

  • Time zone of the reports

  • Counting methodology of the 3rd party or site - how they define impression, click, or conversion

Please provide this information in the Discrepancy Worksheet and contact your Customer Success Manager or our support team (support@sizmek.com).

Was this article helpful?
4 out of 4 found this helpful
Have more questions? Submit a request

Comments