PRODUCT
Follow

This document describes the ad campaign serving, processing, and reporting methodologies implemented in the Sizmek Ad Server.

This document is reviewed annually by the Media Rating Council (MRC) and reflects the most up-to-date information. Sizmek receives an MRC Accreditation upon a successful MRC review (audit).

Click here for a downloadable version of this document.

What Does MRC Accreditation Mean?

Ad Impression processing and reporting by the Sizmek Ad Server, a system operated and maintained by Sizmek, has been accredited by the Media Rating Council (MRC) since April 14, 2008 and is audited annually.

To merit MRC accreditation, the system:

In addition to sizable annual audit charges, Sizmek provides office and file space for MRC auditors, as well as considerable staff and computer time involved in various aspects of these inspections. For further information about MRC’s accreditation and auditing procedures, contact:

George W. Ivie

Executive Director

Media Rating Council, Inc.

420 Lexington Avenue, Suite 343 New York, NY 10170

Processes Not Covered by MRC Audit

Certain aspects of impression processing are outside Sizmek control because they rely on customer entry and Internet site-set parameters to deliver and process impressions. For example, 3rd party ad serving organizations do not contain the full end-to-end ad serving process by design.

It is important to recognize aspects of the process that are not under Sizmek platform control and therefore not addressed by the MRC’s audit and accreditation process. The following list describes the limitations of the accreditation process.

  • Data entered by publishers or agencies for the purpose of campaign set up and configuration. This data has not been subject to audit; users rely on the internal controls surrounding this process at the organization to ensure the accuracy of this data.

  • The choice and timing around the use of specific services external to the Sizmek Ad Server. These include Geographical Targeting and Front-end Cache Busting.

  • 3rd party-developed creative content authored by agencies or organizations outside of the Sizmek Ad Server.

  • Site-set functionality, such as the use of auto-refresh, frames, or other page organization functions, administration, and controls surrounding handling of pop-up blockers and interstitials that can all impact ad delivery.

Sizmek Ad Server

The Sizmek Ad Server is an integrated collection of tools for end-to-end campaign management. The suite empowers digital marketers to command campaign strategy, cross-channel implementation, and results reporting.

Sizmek combines powerful planning, buying, creative management, delivery, and trafficking. Together with tracking capabilities, analytics, and metrics, the Sizmek Ad Server unleashes the full power of digital advertising.

Sizmek Data Centers

The Sizmek Ad Server is a robust and fully-redundant system. Sizmek has data centers across the globe with a large number of servers. The data centers are located in Los Angeles, New Jersey, Amsterdam, Singapore, Japan and China.

Data_Center_infographic_border.png

Sizmek Server Architecture

This figure illustrates the communication process between the Client code and the Sizmek servers.

-Servers_Architecture_in_a_Nutshel.png
  • The Display Server holds all files that are static in character (for example, scripts and resources). The Bursting Server handles all actions that require decision making (for example, deciding whether a user should see an ad based on the frequency capping limit that was set for the ad).

  • To allow scalability and redundancy, Sizmek uses multiple servers for each of the server types and multiple data centers.

  • Sizmek uses Content Delivery Networks (CDN), such as Akamai, to serve static content.

  • Akamai provides a distributed computing platform with thousands of servers in many countries around the world. Akamai optimizes the connection to its servers by routing each user to the closest server.

  • CDN infrastructure is not used for Bursting Servers. Instead, there are multiple Bursting Servers that are located in different sites around the world.

Client to Server Flow

Note

Note: In most cases, instead of implementing a 302 redirect response, a JavaScript (JS) code that performs the call to the display server is sent. For cases in which the client has no support for JS or JS is disabled, a 302 redirect response is used instead.

The Publisher ad server is loaded with a 3rd party ad tag. When the publisher ad server selects that ad campaign, it issues a redirect to the 3rd party ad tag. The 3rd party ad server in turn, redirects the browser (such as using a 302 or returning a JS) to Sizmek, which houses the Commercial Break.

This figure illustrates the role of the Sizmek Ad Server as a 3rd party ad server.

Publisher2.gif

Sizmek Ad Formats

  • Tracking: Placements that track serving data when Sizmek is not the ad server. This enables an account to have consolidated trafficking and reporting within Sizmek. Tracking types can be clicks only, or impressions and clicks.

  • Standard Banner: A Standard Banner consists of an image that loads together with the page. This includes HTML5 basic ad, image only, and Flash, if applicable.

  • Rich Media: Any ad that is created with advanced technologies, such as HTML, scripting languages, video, or audio.

    • Rich Media/Polite Banner

    • Expandable Banner

    • Under these two categories (Polite Banner or Expandable Banner) various creative RM formats exist

  • In-Stream Video: A video ad served inside a video player.

    • VAST

    • VPAID

Aggregated Reports

Agency aggregation reports are designed for in-depth analysis and can be generated during or at the end of a campaign. The reporting system processes information every few minutes. The data is available to end users within three hours.

  • Data can be aggregated in different dimensions and provide different types of metrics.

  • Users can set up reports dynamically by dragging and dropping the designated dimensions and metrics.

  • The data can also be aggregated by a date resolution (for example, hourly, daily, weekly, monthly), with flexible time zones, and by the currency (for revenue and cost metrics).

  • Reports can be run in different currencies and with different attribution models based on the selections during setup.

  • Reports can be filtered by conversion activity and site, and scheduled for periodic delivery or be run as ad-hoc reports.

Dimensions

  • Account

  • Ad

  • Advertiser

  • Brand

  • Browser

  • Campaign

  • Conversion Activity

  • Custom Fields

  • Custom Interactions

  • Device

  • Geo

  • Package

  • Placement

  • Site

  • Target Audience

  • Version

Metrics

Metric Family

Description

Conversions

Tracks conversion information including Conversion Revenue, Total Conversions, and Post-Click conversions.

Cost

Tracks cost of ad including ROI, Total Media Cost, and Average Cost per Action.

Custom Interactions

Tracks user engagement. Types include click-through, user action counter, automatic event counter, and timer.

Delivery

Measures delivery performance.

Engagement

Measures user engagement performance.

Unique Reach

Provides audience reach data like unique impressions, unique clicks, and average frequency.

Video

Measures duration and percentage of an ad that the end user viewed.

Viewability

Measures how much of an ad's surface area was viewed and for how long. For expanding ads, only the anchor unit is measured.

For ads, Sizmek records impressions, clicks, and interactions for all ad types. In addition, we collect conversion activities and site activities using our Tag Manager. Sizmek is MRC-certified for the following metrics:

  • For desktop, mobile web, and mobile In-App display and video:

    • Impressions (Net and Gross)

    • Clicks (Net and Gross)

  • For desktop display and video:

    • Unique (Unique Impressions, Average Frequency)

    • Viewability metrics: (Total Viewable Impressions (IAB), Viewable Impressions Rate (IAB), Recordable Impressions, Recordable Impressions Rate, Non-Viewable Impressions (IAB), Non-Viewable Percentage (Total Served), Non-Recordable Impressions, Non-Recordable Impressions Rate)

There are additional metrics that are measured by Sizmek ads, such as interactions and conversions. These metrics are tracked by tag managers and are not accredited by MRC.

Counting

Certain types of technologies and/or user settings within the browser may impact the counting process. For example, if JavaScript is disabled. In this case, a default image will display (for banner ads only).

  • For cases in which users disabled image-rendering in the browser, the ad display might be affected. For example, for an HTML5 ad, background and text will be visible, but images will be missing. Ad impressions will be counted, although the ad was only partially displayed. Image-only ads will not be displayed, and an impression will not be counted.

  • PopUp Blockers: It is possible that there will be an under counting of ad impressions due to pop-up blockers; however, this is under the control of Publishers and is outside the scope of Sizmek.

  • Auto-refresh: Auto-refresh pages are under the control of Publishers and cannot be automatically identified by Sizmek. Clients can flag a placement that they know is being served to an auto-refresh page. This setting allows Sizmek to segregate auto-refresh impressions in reporting.

Note

Note: These scenarios may affect reporting too.

Cache Busting

The Sizmek Ad Server utilizes both header controls and random numbers to minimize the impact of caching. Specifically, Sizmek uses a random number string in the ad tags and HTTP header controls on the Sizmek bursting servers including expiry, cache-control, and pragma headers.

Here is an example of a tag with a random number:

https://bs.serving-sys.com/Serving/adServer.bs?c=28&cn=display&pli=1073742020&w=300&h=250&ord=577398.6581925632&z=0

In the header, Sizmek sets the cache-control to no-cache, no-store.

Default Image Impressions

A default image is required for each banner ad that is created in the system. In certain cases, the Sizmek Ad Server displays the default image instead of the primary asset to ensure that the user experience remains positive and that the page structure is not affected. These cases include:

  • HTML5 ads running on old browsers that do not support HTML5.

  • Cases in which end users disable JavaScript processing.

    Note

    Note: Impressions that are served when JavaScript is disabled are counted as Count on render and not Count on download.

  • Regardless of the reason, if an expandable ad cannot expand, Sizmek displays the default image.

  • For flash ads only, Sizmek uses special scripts to detect the Flash player on the local machine. In cases for which Flash Player is not installed or on browsers that do not support this technology.

  • Sizmek serves the default image in case of a hard-stop, when the placement reaches its ordered units (impressions or clicks) or crosses the placement date range. These impressions are called hard-stop impressions.

In terms of reporting, Sizmek distinguishes between default image impressions, standard impressions, and hard-stop impressions.

Video Impression Start Methods

Sizmek video ads start playing either automatically or by user activation, depending on the settings chosen by a creative developer.

Video ads of In-Stream formats are played by publisher players which are not controlled by Sizmek. For this reason, all In-Stream video starts are classified and counted as automatic starts. For the ad formats other than In-Stream, the rate of auto-plays is currently estimated at around 7% of the total number of video starts.

Sizmek reports provide an option to quantify video start events by their start methods.

Limitations

  • Sizmek tracks auto-play and click-to-play metrics only for display ads or In-Stream interactive ads.

  • Sizmek does not measure continuous play or user inactivity.

Viewability Metrics

The Sizmek Ad Server determines ad viewability. The Viewable Impressions, Non-viewable Impressions, Recordable Impressions, and Non-recordable Impressions metrics are accredited by the Media Rating Council.

General Viewability

  • Every ad is tracked with a separate request, regardless of the number of Sizmek Ad Server ads reside on the same web page.

  • Measurement polling takes snapshots of observations every 100ms for viewable display impressions and 200ms for viewable video impressions.

  • An ad is considered viewable even if the user has a secondary monitor.

  • Video viewability metrics can be defined according to the user's thresholds.

Viewability in the Browser

  • Sizmek Ad Server detects if an ad is loaded in a visible browser tab (in-focus) or a hidden browser tab (out-of-focus). Ads are considered viewable if they are in in-focus tabs only.

  • If the browser is not in-focus (for example, the user is using another app), the ad is not counted as visible, even if it is not covered or hidden.

  • When the ad is on a different tab over the same browser page, it is considered in-focus.

  • When determining if an ad is viewable, Sizmek Ad Server considers:

    • Viewable browser space and position (for example, X% viewable)

    • Off-Monitor location

    • Above/Below the fold positioning

    • Page scrolling (either by keyboard or mouse)

    • iFrame hosting: size, nesting, and cross-domain issues

  • Sizmek Ad Server can detect if the browser configuration cannot render images; any impression over that browser is reported as non-recordable.

Non-Viewable Ads

  • On-Top applications may hide an ad. In this case, the Sizmek Ad Server considers this ad falsely viewable.

  • An ad is considered non-viewable if the user minimized the browser window before the ad was rendered.

Limitations

  • In general, In-Stream video formats are not supported and will be categorized as non-recordable, except VPAID In-Stream video format.

  • Non-recordable impressions will also be generated in the following cases:

    • Unsupported platforms or browsers

    • When JavaScript is disabled

    • For Cross-Domain iFrames, Sizmek uses IntersectionObserver API to detect ad viewability.

  • Mobile viewability is limited due to various device behaviors and may result in inaccurate duration measurements.

    • Some devices do not send a blur event when moving to a new page.

    • Some devices pause JavaScript execution on a page when moving to a new page or going out of focus.

  • Sometimes, Safari on Mac Mavericks sends multiple impression requests on a single tag, affecting the reported ratio of recordable impressions. This is actually a bug of the browser. The situation is volatile and tends to happen more frequently in a just-opened browser. In testing this scenario, Sizmek discovered that this multiple-impressions problem disappeared when we went to the test pages after viewing few other pages.

Click Metrics

Sizmek click measurement is accredited by the Media Rating Council.

Calculating Clicks

  • Sizmek Ad Server calculates and determines the click or click-through measurement, which is defined as a measurement of a user-initiated action on an ad element, that usually causes an HTTP 302 redirect to another location. This action transfers the user from a Publisher site to an Advertiser site.

  • To calculate clicks, Sizmek Ad Server uses one-click-per-impression (not the multi-click-per-impression method).

Processing Clicks

  • Any user activity beyond the bounds of the advertisement does not lead to the initiation of a click transaction.

  • Each recorded click transaction has a unique identifier assigned to it.

  • In case of 3rd party click tracking, Sizmek calls the 3rd party URL on the first click only (in case of multiple clicks).

Mobile In-Application

In-app measurement is performed using client-side impression counting, initiated after the ad has started rendering on the client device. This methodology is carried out by the Sizmek client scripts, and is adhered to regardless of SDK type.

In order to count valid impressions in-app, the application must support an MRAID-compliant SDK. Otherwise, ad serving may not be possible for that app.

The in-app and mobile web tags are different tags, and are generated through different types of placements on the Sizmek Ad Server. When it should be served in-app, it is trafficked to in-app placements.

When producing reports, you can report based the Environment attribute to distinguish between in-app, web, and not set. Not set is either for non-mobile or mobile that is not recognized.

Note

Limitation: Sizmek does not provide support for offline ad serving within mobile in-application environments.

User Recognition

Sizmek maintains a table with advertiser device IDs and user IDs; this table reflects a history of user IDs retrieved from advertiser device IDs or saved in browser cache. This table is the ID table.

The following list illustrates the steps that Sizmek uses to recognize users on devices or in browser windows.

Note

Note: Sizmek does not save any information about users who opt-out of this process.

  • If there is an advertiser device ID (for devices such as tablets, smart TVs, and dongles) present on the call to Sizmek servers (using the advertising ID tokens), Sizmek can look up the user ID in the ID table and use it to recognize the user.

  • Otherwise, if there is a Sizmek cookie on the page, Sizmek retrieves the user ID from the cookie and uses it to recognize the user.

  • Otherwise, Sizmek retrieves the user ID from the device/app caching, if it exists. For example, an app on a mobile device might allow Sizmek to save the user ID in the cache, which Sizmek will use to recognize the user.

  • Otherwise, Sizmek creates a new user ID and does the following:

    • If an advertiser device ID exists, Sizmek inserts the new user ID, with the corresponding device ID, into the ID table.

    • If the environment supports cookies, Sizmek sets the new user ID in a Sizmek cookie.

    • If an app cache is available, Sizmek saves the new user ID in that cache for later use.

Log Files Collection and Quality Control Procedures

The Sizmek Log Files Collection Procedure is a solution for gathering ad impression log files and other log files from our various remote data centers.

To collect log file data, a smart agent resides in each of the Sizmek bursting/activity servers and acts periodically according to predefined rules.

The agent packages (ZIP) and transfers the log files from the ECS into to S3, where it is processed by transformer and on to ESP.

During the different steps of the log files collection procedures, the following control procedure exists:

  • ECS Monitoring: A scheduled task runs every 30 minutes and monitors the agent activity. The monitoring task searches for files with creation dates older than 30 minutes. If such file exists, the monitoring utility writes an error alert, with a proper description, into the event log.

Event Log Monitoring

The event log is monitored by R&D to debug and understand statuses for the hardware and software systems. These statuses include performance, CPU, memory, network, and software performance.

System Monitoring

The central management system monitors these areas for Sizmek Ad Server:

  • Service performance and availability

  • SSL expiration

  • URLs test

Additional monitoring tools track these areas 24 hours a day, seven days a week:

  • System health, which includes CPU/memory/disk usage

  • Service and ports

  • System performance

The deployment group receives daily status reports (which are checked) and alert notifications (which can happen at any time and which are dealt with immediately).

Filtration System

Sizmek filters clicks and impressions according to the MRC Guidelines for IVT filtration. The filtered rate and thresholds are revised periodically to adjust to evolving industry changes and traffic properties.

Note

Backward Looking Assessment: When introducing new filters or updating existing filters, Sizmek assesses material impact of the filter on all campaigns 14 days backward from the moment detecting the new threat. If a significant impact is detected (over 5%), it will be communicated to clients prior to activation.

The Sizmek Ad Server filters traffic as follows:

Type of Traffic

Sizmek filters...

GIVT

Traffic that does not originate from known browser types (non-browser user-agent header).

Traffic that comes from unknown user agents, black-listed user agents, or unknown browsers.

Known dangerous or fraudulent sources, based on specifically-identified blocking lists.

Blacklists of IP addresses for known fraudulent sources provided by 3rd parties, such as IAB.

Speed of transactions: Speed-based abnormal activity (for example, a click that happened too close to the impression time).

User activity that occur suspiciously close to the beginning of a user session.

Repeat transactions: Multiple, identical transactions with the same session or sessions that look identical or resemble one another in a suspicious manner.

Abnormally large number of very similar sessions that indicate a pattern of automatic behavior, as from a script.

Interval testing: Identifying patterns of intervals between activities (for example, impressions from the same IP every x minutes).

A user found to be active in an abnormally large number of intervals during the day. Human users typically have a standard time in which they are active and will not be active during the whole day.

Outlier identification: Identifying abnormal activity with regard to the baseline of the general traffic.

Count clicks and impressions to determine abnormal number of traffic during a short period of time.

Missing values: Calls with missing fields (for example, missing user agent or missing placement ID).

Traffic missing User Agent, account ID, or placement ID, which are crucial to serving.

Transaction protocol verification: Need to finalize a list of supported transactions (for example, GET, PUT, POST).

HTTP calls that are not POST or GET.

Inconsistencies in transaction and browser/agent parameters.

Sessions that originate from users with inconsistent identifiers, such as Operating system, Devices, and Geo location, within a short time period or within the same session.

Traffic that originates from known data center IPs provided by Trustworthy Accountability Group (TAG)

Traffic that comes from IP addresses provided in the TAG Data Center list.

SIVT

Bots/Automatic behavior

Sizmek uses a designated AI model that is built daily and constantly tuned to keep up with bots' changing behaviors. This is done by identifying different behaviors of several different factors over a period of time.

Spoofed URLs

The Sizmek platform performs several checks and comparisons on the URL of the impression to evaluate if the URL is spoofed.

Spoofed events

Sizmek detects if an entire ad session or specific events were recorded and replayed to generate traffic. Different factors related to the ad session are evaluated by the system to identify if the session is a spoofed event.

Ad Stacking

Sizmek identifies cases in which the publisher places multiple ads on top of each other in a single ad placement; only the top-most ad is viewable.

Ad Injection

Zero Ads: Domain-based, pre-bid category.

Malware

Malware category: Domain-based, pre-bid category.

Geo falsification

Sizmek technology evaluates impressions that are masking their true geo location.

Fraudulent Apps

Fraudulent app category: App ID-based, pre-bid category.

Suspicious activity

Impressions that were redirected from a domain that Sizmek has classified as a Ghost Site.

Data Retention

The Sizmek retention policies are defined according to the data types that are available in each of the analytics tools.

This table illustrates the retention policy for our analytic tools.

Analytics Tool Name

Description

Data Retention

Data Type

Report Builder

Main reporting tool that allows users to create customized, aggregating reports for a specific campaign, advertiser, or account.

3 years

Aggregated

API

Enables users to generate reports using Sizmek API capability.

3 years

Aggregated

Note

Notes:

  • Time Zone data is only available for the last three months. Time Zone data before that time is saved as the customer default Time Zone.

  • Hourly-level aggregation is available for last three months only.

Business Partner Qualification Process

To ensure business partners’ awareness and fulfillment of the IVT Guidelines, Sizmek engages in these broad areas:

  • Vet partners as legitimate businesses: Before beginning a commercial relationship with a business partner, Sizmek performs a basic level of due diligence, based on data points such as known address, tax ID, phone number, or other contact information, third party data reviews, and other customers, in order to verify that the partner is in fact a legal business entity.

  • Ensure awareness of guidelines: Before beginning a commercial relationship with a business partner, the Sizmek point of contact must verify that the partner is aware of IVT guidelines.

  • Vet whether partners are bad actors: Throughout the business relationship, Sizmek will periodically audit whether our partners are engaging in, facilitating, or supporting invalid traffic generation in any way. Examples of red flags include creating small campaigns and engaging in unusual patterns with partners or publishers who have been flagged for IVT.

  • Customers Representations: All Sizmek customers agree not to engage in fraudulent or illegal activities as part of our onboarding model and are bound by our Terms of Use, which will include a specific reference to IVT.

Sizmek uses the services of the following business partners in counting processes:

  • WURFL: Used for operating system and device identification.

  • Digital Element: Used for geo-location services.

Scope of Communication

  • Sizmek ensures that internal notifications are provided as necessary to foster awareness and clues to detecting invalid traffic (Internal Communication).

  • Sizmek communicates with industry leads in this area, specifically IAB staff, IAB TAG, and MRC staff (Industry Communication).

  • Sizmek communicates learning and best practices in a facilitated manner to other industry practitioners to encourage ecosystem improvements (External Partner Communication).

  • As necessary, Sizmek communicates to law enforcement and/or measurement service legal counsel on significant invalid traffic matters (Legal Communication).

Internal Communication

The Sizmek verification and data research team will communicate their findings internally through the Product Management team. This information will be sent to the Sales and Operations teams, so that they may share externally with clients, or use for internal education.

When there are instances that the Global Support team learns about unusual events, including clients concerned about invalid traffic (IVT) with their reports or their publisher’s reports, internal communication will follow. The Global Support team will then alert the appropriate Sales and Operations personnel, and will update the internal support Knowledge Base (KB).

Industry Communication

The Sizmek Product team and R&D representatives will be participating in the MRC and IAB forums. The Sizmek Product Marketing team has been involved in such discussions (MRC IVT) from the beginning. As Sizmek is an organization that provides many types of services to numerous advertising clients globally, it is imperative that we stay at the forefront of IVT discussions and contribute based on our experience and relevant field research (mainly around our Verification product findings and innovation).

External Partner Communication

The Sizmek Research team, responsible for verification and data, is tasked with providing ongoing findings to our organization that are relevant to the market, including but not limited to advertising performance, internet trends, fraud behavior, and IVT, with our organization. When appropriate, such findings are shared with the Product Marking and Product Management teams.

Legal Communication

The Sizmek legal department handles all legal aspects of Sizmek relationships. In cases that threaten our client’s business, partners’ business, or Sizmek business (such as unlawful or otherwise detrimental behavior that could cause substantial damages even following the necessary warnings given to the responsible party), legal steps may be taken to stop these activities and recover any damages that may have been incurred. Sizmek may report this activity to official law enforcement agencies, and pursue the responsible party for compensation.

In addition, the Sizmek legal department may find that information provided by the Sizmek data verification and research teams requires a report to law enforcement agencies. even if there is no direct implication to Sizmek or any of its clients or partners.

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

Comments