Overview

This article details the Impression and Viewability measurement processes employed by Flashtalking for Desktop, Mobile Web, Mobile App, and CTV environments, including a general description of our measurement methodology, filtration, and reporting processes. These processes apply to both standard display ads and rich ads, and to video ads (except where noted).  Metrics labeled as “Protected,” including Impressions, Viewable, and SIVT, are subject to the procedures and disclosures in Protected's Description of Methodology.  Protected's Viewability procedures and disclosures can be found here.

Introduction

Flashtalking is a media-independent ad serving, measurement, and verification technology company, providing best-in-class digital advertising products, service, and support for online advertisers, key media buying and creative agencies.

Our products lead the agency ad server and media verification markets and facilitate the management, delivery, and measurement of all forms of digital advertising across desktop, mobile, and CTV.  Core aspects include display (including standard ads, dynamic, rich media, HTML5 & mobile), video, search, social and affiliates.

For MRC accreditation, this document focuses solely on standard Display ads and rich ads (including expand, heavy, page takeover and roadblocks) and Video ads in Desktop, Mobile Web, and Mobile App environments.  Metrics provided through our “Protected” verification offerings, including Viewability, CTV Video Impressions, and SIVT are also MRC accredited when requested through ad server Reporting, and further described in Protected's Description of Methodology and Viewability DOM.  All other metrics are out of scope.

 

Note on MRC Accreditations

• Display & Video Ads Requested and Impressions Rendered in Desktop, Mobile Web, and Mobile App*
• Protected-measured SIVT and Viewability for Display & Video Impressions in Desktop, Mobile Web, and Mobile App ads served by Flashtalking
• Protected-measured Video Impressions and SIVT in CTV ads served by Flashtalking

All metrics are net of invalid traffic except for those explicitly flagged as “unfiltered,” which may include impressions that are later flagged as invalid. 
*CTV Impressions reported by the Ad Server are only MRC-accredited where measured by Protected Media.  Protected's MRC-accredited Impression, Viewability, and SIVT metrics can also be pulled directly from Protected's reporting, subject to Protected's Description of Methodology and Viewability DOM.

Creative and Campaign Creation

As Flashtalking provides an ad-serving platform, we do not have direct control over the premise of client-initiated counting. We provide publishers with instructions for proper implementation of the ad tags and also assist the publishers with the integration of their creative; however, proper implementation is the responsibility of the publishers.

Users may utilize the interfaces to insert and preview creative, as well as set creative delivery preferences; therefore, the platform user can maintain control over the order entry and campaign management procedures. Flashtalking maintains instructional guides as part of their online help tool and Campaign Managers assist publishers with issues related to ad tag implementation.

Ad Measurement

The IAB guidelines state that:

"A Rendered Impression across all display marketing channels is the measurement of responses from an ad delivery system to an ad request from the user's browser, which is filtered for invalid traffic and is recorded at a point as late as possible in the process of delivery of the creative material to the user's browser. The ad must be loaded and at minimum begin to render in order to count it as a valid rendered impression."

Valid Display Impressions

In response to the ad tags being requested by a user, the Flashtalking ad server platform selects, then delivers the ad content (or third party tag) to the user that will lead to the rendering of the advertisement. This initial response to an ad tag firing is tracked as Ads Requested based on a "count on decision" methodology. For valid Impressions Rendered, Flashtalking utilizes a client-initiated "count on render" ad measurement methodology, in which an ad impression is counted once the ad has begun to “paint on the page.” The delivery and measurement of the ad content is JavaScript-dependent.

Where JavaScript is not available, a fallback image is delivered by way of the <NOSCRIPT> construct. The image is returned by the ad call so it is counted as an Ad Requested on the decision, but since JavaScript is not available, rendering cannot be measured.

Valid Video Impressions

After a video ad tag is initially fired, the request is tracked as Ads Requested based on a "count on download" methodology. Subsequently, an Impression for a Video ad served through VAST is counted after the creative is post-buffer and has begun to play. Flashtalking provisions the player to fire an Ad Rendered event pixel after the player declares a “Video Start.”

If the impression event is inhibited by the publisher, or the video was not started, the Impression will not be counted by Flashtalking, only the initial Ad Requested will be tracked. Impression delivery is subjected to robust initial and ongoing quality control as well as data analytics exercises to ensure compliant measurement and to monitor for potential changes and errors.

A video publisher certification program is in place to ensure that publishers are firing off the impression event when the ad has been loaded and at minimum begins to render, meaning: After the initiation of the stream, post-buffering, when the ad itself begins to appear on the user’s device (begins to play). When possible, Video Publishers will be certified by Flashtalking based on a visual QA of a Flashtalking tag to ensure that the Impression metric fires off after the video has buffered and begun to play in the client player. If a test page is not available, publishers will need to self-report that they fire the impression event in accordance with the MRC & IAB Guidelines. Discrepancy checks will be performed on live inventory. Publishers who pass the testing will be considered, “Certified for MRC” and reviewed annually to account for any changes. Only impressions fired from players designated as Certified for MRC can be included in an MRC-accredited metric.

Flashtalking tracks all ads independently, including ads associated with “Companion” campaigns. All Video Ads go through the same GIVT checks as Display Ads. Protected Video Impressions in CTV go through Protected’s GIVT and SIVT procedures.  Video duration quartiles are not currently MRC-accredited.

Caching

To minimize under-counting due to caching, the ad serving platform employs a mechanism designed to trigger a cache flush, which results in any content in the file being ignored and automatically retrieving a new copy, as well as random numbers being appended to the requests. In line with the IAB guidelines, we use the HTTP cache-control response headers 'cache-control', 'pragma' and 'expiry'.

In cases where the creative is not capable of displaying, for example, due to an out of date browser, an alt image is served instead.

All measured impressions are census-based and not sampled.

Pre-fetch and Pre-rendering

Flashtalking does not fire Display impression rendered or viewability events while a page is in a pre-fetched or pre-rendered state. Pre-fetching may cause an Ads Requested “Count on Decision” event to fire, but the ad will not be counted as an Impression Rendered, or measured for viewability, until it has been rendered on the page. Standard rules apply to pre-rendered pages, utilizing the Page Visibility API to determine if the ad is being loaded on a pre-rendered page and waiting until the page enters a visible state before rendering the ad.

 

Recognized Limitations

It is recognized that there are some situations, out of our control, that may result in the under or over-counting of ad impressions. These cases are hard to quantify and are not considered to be at a level to warrant specific action. Such situations could include:

Ad blocking software

Ad blocking software may be implemented that could potentially result in the under or over-counting of impressions, depending on the configuration of the software and what it is designed to block. Flashtalking is unable to determine when ad blocking software is being used by a client device.

Pop-up blockers

As Flashtalking’s ads are called from a parent tag on a page, they are unlikely to be affected by pop up blockers. However, we are unable to prevent 3rd parties from implementing our ads within a pop-up and are unable to determine when an ad is being served in a pop-up. In the unusual instance that a pop-up blocker does prevent an ad from rendering, no Impression Rendered or Viewability events will fire.

Latency

Video impressions are counted based on the direct signal of render events from publisher players. Any latency in the firing of our event pixels due to player performance or Internet network bandwidth is outside Flashtalking’s control but will not impact the accuracy of collected metrics.

Purchased Traffic 

Flashtalking uses automated techniques to report traffic identified as being from a "purchased" source.  Any traffic not designated as being "purchased" should be considered to be from an "undetermined" source.

Auto-Refresh 

If an ad is auto-refreshed it will re-initialize the Ad Request, fire the standard Impression Rendered event again, reinitialize ad visibility, and begin recording again for a new Viewability determination. Removal of suspicious auto page refresh events is handled in the same way as standard impressions by activity-based filtration at processing time.  Flashtalking is unable to determine directly if an ad has been auto-refreshed.  Flashtalking implemented a tag that enables the identification of auto-refresh scenarios when supported by the publisher. Our UI allows for reporting segregation based on the "refreshedAd" metric. We recommend that publishers adopt this parameter to enhance reporting accuracy moving forward.

Video Continuous Play

The IAB has given guidance to the Digital Video industry to deliver information like Continuous Play via macros within the VAST ad request, but Flashtalking has found that adoption for this method is low. Flashtalking encourages the use of this parameter and will continue to receive and report on these signals when provided.

In-stream Video Placements

The IAB has given guidance to the Digital Video industry to deliver information like video ad placement macros (pre-roll, mid-roll, post-roll) within the VAST ad request but Flashtalking has found that adoption for this method is low.  We encourage the publishers to use this macro and when publishers begin to report ad placement information, we will enable the collection of the necessary signals to provide such reporting.

Video Auto-Play and Forced Duration

The IAB has given guidance to the Digital Video industry to deliver information like Auto-Play, Auto-Refresh, and Forced Duration via macros within the VAST ad request but Flashtalking has found that adoption for this method is low. Flashtalking will continue to receive and report on these signals when provided.

Video Player Inactivity Rules

Although Flashtalking is currently unable to determine directly when the user is "Inactive" or when the device is idle or powered off, we are able to collect data from publishers when provided that would inform a set of practical Inactivity Rules. We encourage publishers to utilize macro “Time Since Engaged” for us to ingest situations of inactivity. Flashtalking is currently creating a metric within our user interface. 

Related to Protected metrics reported by Flashtalking, please refer to the Protected’s Description of Methodology for how the associating service measures and reports situations of inactivity.

CTV/OTT TV Off

Flashtalking is unable to determine when a TV is off because measurement requires a direct connection to the device, and is not currently supported by the VAST standard.

Safari Pre-Loading

Due to changes to Safari’s predictive navigation feature, there is a potential risk of over-counting the “Impressions Rendered” metric. For instance, when a Safari user pastes a URL for a previously visited site, the browser may attempt to predict the complete URL based on browsing history and pre-load the page and ads in full to enhance navigation speed. Please note that ads are not double-counted if the pre-loaded page is eventually displayed to the user. Flashtalking previously implemented a fix for Safari pre-loading in Q1 2021. Subsequent updates to Safari's page visibility API in September 2022 compromised the effectiveness of this solution. We’re currently investigating the situation and have determined this is a limited case affecting less than 2% of Gross Unfiltered Rendered Impressions. Please contact your Flashtalking account representative with any questions.

Data Accumulation and Editing

Both the initial ad requests and the event tracking pixels are logged by the servers. We utilize multiple servers to provide sufficient capacity, and each of the servers maintains its own log files, which are copied and processed on an ongoing basis. No real-time log file reformatting is performed by the servers.  Log files of events determined by Protected are processed hourly.

A combination of automated and manual processes and controls are employed to retrieve and determine the completeness of each file processed. These include checks to determine if each was processed exactly once, checks for corrupt files based on the unique key naming convention used for the log files and data consistency checks.

Note regarding the Protected integration

“Protected” metrics in the Flashtalking reporting suite reflect Protected's assessment of Flashtalking-served ad impressions, rather than a duplication of Protected’s reported metrics available through its own UI. Therefore, when Protected's tag is fired along with the ad serve tag, small differences in Gross Impression volumes between the two parties may occur if Protected tracks additional calls to its platform beyond those specifically associated with Flashtalking-served ads. Examples of such cases could include multiple post-ad fires of the same Protected tag which will be matched to a single Impression within the Flashtalking ad server, or tags potentially being cached and re-fired by certain Video players depending on their setups.  Flashtalking and Protected employ a number of processing monitors to ensure that data collected is reporting accurately through both platforms and such discrepancies are typically immaterial anomalies within 0.1% of total impressions.  That said, while they are expected, Flashtalking and Protected will investigate and attempt to explain material differences in reported impressions should any be noted.

At a campaign reporting level, as with other third-party verification partners, Protected total campaign metrics may differ significantly from metrics reported by the ad server.  Such differences can be due to a number of typical causes, including partial/sampled tagging of campaigns, differentiated handling of tags by browsers or certain publishers, and effects from publisher blocking or users' ad blocking tools.  There is also the potential for Protected Media to report additional GIVT due to Protected's advanced verification methodologies and detection techniques.

Log file retrievals and processing

The following is a brief description of the items logged and their use in the process:

• IP Address: The Internet Protocol (IP) address represents the address of the user making the request. This is used in the filtering process, including the identification of non-human activity.
• User-Agent: A text string provided by the browser contains certain information about the browser, such as type and version.
• Event Time: Date and time the impression event was logged by the server (stored as UTC).
• Request: The specific request to the logging server, including the identifying information relating to the content selected by the ad server such as:
  • Site Address: Identifies the associated publisher site calling for the ad placement
  • Campaign ID: Identifies the respective campaign
  • Placement ID: Identifies the respective placement
  • Creative ID: Identifies the respective creative
  • GUID: Global User Identification (from a cookie or created by the system if no cookie exists)
  • Event type: Event type code identifying the nature of the recorded event (the type of impression event, click and so on)

Event log files provided by “Protected” include a Flashtalking Impression ID which is used to associate Protected events to the corresponding Flashtalking Ad Requested.

Other data events (outside the scope of the MRC audit), such as further log event descriptors and optional parameters, may be captured as a means of incorporating additional information within the log events.

We maintain a Data Retention policy which outlines how long various data elements are stored.

Filtration procedures

Flashtalking carries out several checks on the impression data to reduce the effects of bias, distortion, and inaccuracy, using General Invalid Traffic techniques. These procedures include checking for:

Invalid events

Flashtalking validates log file fields to determine if data are of the correct syntax/type and certain required fields are present. In situations where validation tests fail, the individual log entries will be excluded from reported event counts. During the measurement process, certain entries are omitted from being recorded in the logs, as they represent situations in which the log entry indicates an unusable log entry such as:

• Errors- Entries in which the server did not understand the request and therefore assigned an error code status to the request as rejected

• Incomplete/corrupt log entries- The processing requires certain fields included in the impression rendered event to be found, complete and accurate. If any of these fields are missing or incorrect the log entry is rejected

Non-human traffic

In accordance with the MRC Minimum Standards and the IAB Guidelines, three approaches are applied to filtration:

Specific identification

A dual-pass specific identification approach is used to filter robotic activity on the front end, using the IAB Industry Robots list to remove log files with user agents listed as a known robot user agent string and excluding activity from user agents that do not match the IAB Industry Valid Browser list.

The rule engine obtains the IAB Industry Robots List and the IAB Valid Browser List using predefined fetching rules and checks for changes to these files every 24 hours. If an error occurs while obtaining or parsing either of the lists, an email alert is generated and sent to the monitoring team. These alerts also inform the team if the file has not updated within a specified timeframe or the fetch fails.

Robot Instruction Files (robot.txt) are also held within the root directories of the server domains.

During the filtration process, log items are marked for exclusion from reporting but maintained regardless of validity.

Activity Based Identification

The raw data is scanned on a daily basis to check for activity that may have been generated by automated systems (robots) and a daily data set is created, identified by the combination of IP address and GUID, of activity falling outside of specified thresholds on the following attributes:

• Clicks on viewable creative, which do not have a matching impression in the last seven days
• Max ad requests per hour
• Max clicks per hour
• Total clicks
• Total ad requests

This dataset is then assessed manually to make the final decision to exclude further events from the offending GUID and/or IP address.

Flashtalking provides six separate metrics related to invalid ads:

• Invalid Desktop Ads Requested
• Invalid Desktop Impressions Rendered
• Invalid Mobile Web Ads Requested
• Invalid Mobile Web Impressions Rendered
• Invalid Mobile App Ads Requested
• Invalid Mobile App Impressions Rendered

All are the count of ads flagged as invalid based on the above filters either after the asset has been requested but has not begun to render or after the asset has begun to render on the page.

Flashtalking considers filtered impressions to be material IVT if they exceed a minimum volume threshold and an established percentage of gross ads requested for the campaign, and are judged to be Invalid Traffic after further investigation.

Flashtalking annually reviews IVT policies, activity-based filtration thresholds, and documentation. We employ automatic and manual processes to monitor traffic for suspicious activity to flag for investigation, based on analysis accounting for volume, traffic source, user agents and pattern analysis. Our filtration process is MRC accredited and we conduct regular reviews to ensure thresholds and methodology remain relevant, accurate and up to date.

Note that “Protected” GIVT determinations, when provided, may be slightly different from the Flashtalking ad server GIVT determinations.  Protected GIVT and SIVT metrics are subject to the procedures and disclosures in Protected’s Description of Methodology.

Server Side Ad Serving

Ad Requests identified to be coming from known servers, and not otherwise determined to be IVT, are segregated and labeled as “Unknown” and not included in Impression Rendered metrics.  Flashtalking does not currently determine whether such ads involve Server Side Ad Insertion (SSAI) specifically.

IVT Decision Rate

Given Flashtalking's approach to detection of General Invalid Traffic, the ad server GIVT Decision Rate for Impressions Rendered is 100%.  Similarly, the Protected GIVT Decision Rate is also 100%.  The Decision Rate for Protected SIVT determinations is a metric that can be added in Device reports.

Internal traffic

Relative to the traffic volumes of live campaigns, the level of traffic from internal users at Flashtalking (predominantly due to initial live campaign testing), is considered negligible, so no action is taken to block these stats.

Summarized data

The logs are processed multiple times through the day, to generate aggregated event totals for each of the various reporting criteria.

Reporting Database

The reporting database is populated using the final aggregated database files. The database feeds the reporting applications.

Data Processing/Software Quality Assurance

Capacity and Processing Controls

Flashtalking employs automated monitoring tools to track CPU usage, disk space, usage, bandwidth, and so on, including automated alerts if certain thresholds are exceeded, as well as maintaining automated procedures to determine if the logging server log files have been collected and processed. Certain data quality and integrity checks, using primarily automated techniques, are maintained to assess the completeness of the data and to inspect the data for potential issues prior to reporting.

These checks and tools include:

• Monitoring tools to determine all logs have been received prior to processing
• Monitoring of new ad server log files written to the processing servers
• Cross-checking among data sets to determine if various data tables are consistent when aggregated to a common data set
• Monitoring and daily review of summary data provided by different data centers, for consistency of processing
• Manual checks performed for certain clients
• Trending of errors recorded in the log files

Reports

For MRC accreditation, we are focusing solely on reports generated by the Reports tool. All other reporting access methods are out of scope.

Reports containing rendered impression data are available electronically via the Reports interface. The interface enables the user to customize the data they wish to obtain either as a one-off, or a scheduled report.

Data in the reports can include the accredited ads requested and impression rendered counts, but also includes all other metrics, which are not currently MRC accredited, such as Clicks, Interactions and Spotlight data.

Processed reporting data is available up to 18 months after the campaign end date.

Date and Time

Date and time metrics within the reports are displayed in accordance with the international standard ISO 8601.

Time zones - The date and time within the reports are calculated based on the time zone set for the advertiser. Flashtalking supports all ISO Time Zones.

Date - Notation of dates is YYYY-MM-DD

Week - All weeks start on Monday and end on Sunday and the weeks are numbered week 01 - week 52 (ISO-8601).

Time - Notation of time of day is hh: mm: ss

Geo-Location

If permitted by a user’s browser or device, Flashtalking may utilize data from a 3rd-party vendor to determine the user’s geo-location by IP address. This "non-precise" geo-location data is used for creative personalization and campaign analytics, and not for the buying (“targeting”) of ad impression inventory.

Device Identification

For Device Identification, Flashtalking uses WURFL, an industry standard tool used by many of the largest internet companies, including Facebook and Google. WURFL provides a device description repository with over 57,000 devices and profiles developed over 15 years. Leveraging this tool enables Flashtalking to easily, efficiently, and accurately map new and existing devices. Learn more about WURFL's device classification and methodology.

Re-issuance of Data

We have automated and manual checks in place to monitor the processes that may affect reportable data. In the event of issues being identified, the appropriate corrective actions are taken within 48 hours, wherever possible. Data issues will be deemed to be materially significant and require executive consideration for re-issuance where the number of affected impressions is greater than 50,000 and greater than 5% of the number of impressions already attributed to the campaign in question. Notifications of data changes/re-issuances will be assessed depending on the situation, impact, severity, duration, etc. Based on these findings, appropriate communication methods will be determined.

Business Partner Qualification

As part of a Business Partner Qualification process, Flashtalking may review the credentials, credit, business history, industry presence, client references, independent certifications, and other factors, to determine whether to partner with vendors or begin relationships with new customers. If Flashtalking becomes aware of or suspects any material changes in the information relied on as part of our Business Partner Qualification procedures, Flashtalking will investigate and re-assess the qualification to determine whether to continue working with said vendor or customer. Violations of our platform Acceptable Use Policy (AUP) may lead to immediate termination of access.

New customers will be required to acknowledge Flashtalking's adherence to the provisions of the MRC's Invalid Traffic (IVT) Detection and Filtration Guidelines, and to commit to not knowingly purchase, sell, generate, or in any other manner monetize or facilitate Invalid Traffic. Flashtalking emails all active users of the platform an annual reminder of the IVT guidelines and expectations.

Additional Disclosures

Flashtalking relies on cloud providers, data centers, and content delivery networks (CDNs) for the delivery of ads and collection of impression-level data necessary for user analysis and invalid traffic filtration. All of our primary services maintain an industry-standard ISO 27001 (Information Security Management) certification.

Last Updated on 2024-9-27
Last Reviewed on 2023-12-12