Navigation

Description of Methodology (DOM)

  • Updated

Purpose

IMPORTANT: Following Mediaocean’s acquisition of the Innovid ad server in early 2025, we are currently transitioning to unify our brand under the Innovid name. Note that this is strictly a brand update; the procedures and methodologies detailed in this document remain accurate and fully effective. Our MRC Accreditation remains unchanged for the legacy Flashtalking service (now externally branded as Innovid). While this document may still reference the Flashtalking name, it is part of our broader effort to unify our identity under the Innovid brand.

This article details the Impression and Viewability measurement processes used by Innovid across Desktop, Mobile Web, Mobile App, and CTV environments, including a general description of our measurement methodology, filtering, and reporting. These processes apply to standard display, rich, and 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 are available here.

Overview

We are a media-independent ad-servicing, measurement, and verification technology company, providing best-in-class digital advertising products, services, and support for online advertisers and 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), as well as 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.

MRC accreditations

The following metrics are MRC Accredited when requested in a Device report:

  • 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 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 (now externally branded as Innovid) provides an ad-serving platform, we do not have direct control over the premise of client-initiated counting. We provide publishers with instructions for the proper implementation of ad tags and assist with integrating their creative; however, proper implementation remains the publishers' responsibility.

Users can use the interfaces to insert and preview creative and set creative delivery preferences, thereby maintaining control over order entry and campaign management. We maintain instructional guides in our online help tool, and Campaign Managers assist publishers with ad tag implementation issues.

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 a user request for ad tags, the ad server platform selects and delivers the ad content (or third-party tag) that will render the advertisement. This initial response to an ad tag firing is tracked as "Ads Requested" using a "count on decision" methodology. For valid Impressions Rendered, we utilize 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" using a "count on download" methodology. Subsequently, an Impression for a Video ad served through VAST is counted once the creative has post-buffered and begun to play. We provision 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, we will not count the Impression; only the initial Ad Requested will be tracked. Impression delivery is subject to robust initial and ongoing quality control, as well as data analytics, to ensure compliance and 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 a 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 (Innovid) through a visual QA of our tag to ensure that the Impression metric fires 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 will be reviewed annually to reflect any changes. Only impressions fired from players designated as Certified for MRC can be included in an MRC-accredited metric.

We track 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 undercounting due to caching, the ad-serving platform employs a mechanism that triggers a cache flush, causing any cached content to be ignored and a new copy to be retrieved, and it also appends random numbers to 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

Display impression rendered or viewability events are not fired 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, using the Page Visibility API to detect when the ad is loaded on a pre-rendered page and to wait until the page enters a visible state before rendering the ad.

Recognized limitations

It is recognized that situations beyond our control may result in under- or overcounting of ad impressions. These cases are difficult to quantify and are not considered at a level that warrants specific action. Such situations could include:

Ad-blocking software

Ad-blocking software may be implemented, which could result in under- or overcounting of impressions, depending on its configuration and the content it is designed to block. We cannot determine whether ad-blocking software is being used on a client device.

Pop-up blockers

As our ads are called from a parent tag on a page, they are unlikely to be affected by pop-up blockers. However, we cannot prevent 3rd parties from serving our ads in pop-ups, nor can we determine when an ad is served in one. In the unusual instance that a pop-up blocker prevents an ad from rendering, no Impression Rendered or Viewability events will fire.

Disabling images

Users may configure their browsers to disable images. Browsers do not signal when images are disabled, so this may cause ad requests to be counted if the browser does not suppress them. 

Latency

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

Purchased traffic 

Automated techniques are used to report traffic 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, re-initialize ad visibility, and resume recording for a new Viewability determination. Removal of suspicious auto-page-refresh events is handled the same way as standard impressions: via activity-based filtering during processing. We cannot directly determine whether an ad has been auto-refreshed.

Our platform has implemented a tag that identifies auto-refresh scenarios when publisher support is available. The UI now enables reporting segmentation via the refreshedAd metric. We recommend that publishers adopt this parameter to ensure higher reporting accuracy moving forward.

Video continuous play

The IAB has issued guidance to the Digital Video industry to deliver information such as Continuous Play via macros within the VAST ad request, but we have found that adoption of this method is low. We encourage the use of this parameter and will continue to receive and report on these signals as they are provided.

In-stream video placements

The IAB has issued guidance to the Digital Video industry to include information such as video ad placement macros (pre-roll, mid-roll, post-roll) in the VAST ad request, but we have found that adoption of this method is low.  We encourage publishers to use this macro, and once they begin reporting ad placement information, we will enable the collection of the necessary signals to support such reporting.

Video auto-play and forced duration

The IAB has issued guidance to the Digital Video industry on delivering information such as Auto-Play, Auto-Refresh, and Forced Duration via macros within the VAST ad request, but we have found that adoption of this method is low. We will continue to receive and report on these signals as they are provided.

Video player inactivity rules

While our platform cannot natively determine when a user is 'Inactive' or when a device is idle or powered off, we can utilize publisher-provided data to establish practical Inactivity Rules. We encourage publishers to implement the 'Time Since Engaged' macro to help detect this type of traffic. A corresponding reporting metric is also being created in the UI. 

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

CTV/OTT TV Off

Due to current limitations in the VAST standard, which does not support a direct device connection for power-state detection, our system cannot identify when a TV has been turned off during ad delivery.

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 full URL from browsing history and pre-load the page and its ads to improve navigation speed. Please note that ads are not double-counted if the pre-loaded page is eventually displayed to the user. We 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. Contact your 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 use multiple servers to provide sufficient capacity, and each server maintains its own log files, which are continuously copied and processed. 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 is used to retrieve and verify the completeness of each processed file. These include checks to ensure each was processed exactly once, checks for corrupt files based on the log files' unique-key naming convention, and checks for data consistency.

Protected integration

Note to Reader: We have retained the legacy 'Flashtalking' nomenclature throughout this section to maintain alignment with our Protected Media integration and existing MRC accreditation. While we are transitioning our external branding to Innovid, we have retained the legacy terminology here to ensure consistency with our official certification status and avoid confusion.

“Protected” metrics in the Flashtalking reporting suite reflect Protected's assessment of Flashtalking-served ad impressions, rather than duplicating 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 include multiple post-ad fires of the same Protected tag being matched to a single Impression within the Flashtalking ad server, or tags being cached and re-fired by certain Video players depending on their configurations.

Flashtalking and Protected use multiple processing monitors to ensure that collected data is reported accurately across both platforms.  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's total campaign metrics may differ significantly from metrics reported by the ad server.  Such differences can be due to several common causes, including partial/sampled tagging across campaigns, differential handling of tags by browsers or certain publishers, and effects from publisher blocking or users' ad-blocking tools.  There is also potential for Protected Media to report additional GIVT through its advanced verification methodologies and detection techniques.

We offer Protected Media’s SIVT measurement to our clients. If clients would like property-level (e.g., domain, subdomain) reporting, log in to the Protected Media User Interface (UI).

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 that contains information about the browser, such as its 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 with the corresponding Flashtalking Ad Requested.

Other data events (outside the scope of the MRC audit), such as additional log event descriptors and optional parameters, may be captured to incorporate additional information into the log events.

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

Filtration procedures

There are several checks on impression data to reduce the impact of bias, distortion, and inaccuracy, using General Invalid Traffic techniques. These procedures include checking for:

Invalid events

We validate log file fields to verify that the data is syntactically correct and that required fields are present. When validation tests fail, 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: Processing requires that certain fields in the impression-rendered event be present, 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 matching known robot user-agent strings and to exclude activity from user agents not matching 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 list, an email alert is generated and sent to the monitoring team. These alerts also inform the team if the file has not been updated within a specified timeframe or if the fetch fails.

Robot Instruction Files (robot.txt) are also located in the root directories of 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 manually assessed to make the final decision to exclude further events associated with the offending GUID and/or IP address.

We provide separate metrics related to invalid ads:

  • Invalid Total Ads Requested
  • 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

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

Filtered impressions are considered material IVT if they exceed a minimum volume threshold and a set percentage of the campaign's gross ad requests, provided they are confirmed as Invalid Traffic after further investigation.

We review IVT policies, activity-based filtration thresholds, and documentation annually. We employ both automated and manual processes to monitor traffic for suspicious activity and flag it for investigation, based on analyses of volume, traffic sources, user agents, and patterns. 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 differ slightly from the ad server's. 
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 as coming from known servers and not otherwise determined to be IVT are segregated and labeled as “Unknown” and not included in Impression Rendered metrics. We do not determine whether such ads use Server Side Ad Insertion (SSAI).

IVT decision rate

The ad server's 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 to Device reports.

Internal traffic

Relative to the traffic volumes of live campaigns, the level of traffic from internal users at Innovid(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 throughout the day to generate aggregated event totals for each reporting criterion.

Reporting database

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

Data processing and software Quality Assurance

Capacity and processing controls

We employ automated monitoring tools to track CPU usage, disk space, bandwidth, and related metrics, and to trigger alerts when thresholds are exceeded. It also maintains automated procedures to verify that the logging server log files have been collected and processed. Certain data quality and integrity checks, primarily automated, are performed to assess data completeness and identify potential issues prior to reporting.

These checks and tools include:

  • Monitoring tools to determine that 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 titled ‘Campaign Manager Reports’. Within this tool, a user must select the ‘Device’ report type to generate MRC Accredited metrics. See Generating MRC-Accredited Metrics for more information. All other reporting access methods are out of scope.

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

Data in the reports may include counts of accredited ads requested and impressions rendered, as well as other metrics 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 dates and times in the reports are calculated based on the advertiser's time zone. We support all ISO Time Zones.

Date - Notation of dates is YYYY-MM-DD

Weeks: All weeks start on Monday and end on Sunday; weeks are numbered from 01 to 52 (ISO 8601).

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

Geo location

If permitted by a user’s browser or device, we may use data from a 3rd-party vendor to determine the user’s geo-location based on 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, our platform uses WURFL, an industry-standard tool trusted by leading global technology companies, including Google and Meta.WURFL provides a device description repository with over 57,000 devices and profiles developed over 15 years. Leveraging this tool lets us 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. When issues are identified, appropriate corrective actions are taken within 48 hours, where possible. Data issues will be deemed materially significant and require executive consideration for re-issuance if the number of affected impressions exceeds 50,000 and is greater than 5% of the impressions already attributed to the campaign in question. Notifications of data changes/re-issuances will be assessed based on the situation, impact, severity, duration, and related factors. Based on these findings, appropriate communication methods will be determined.

Business partner qualification

As part of a Business Partner Qualification process, we 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. 

Should our platform become aware of or suspect any material changes to the information relied upon during our Business Partner Qualification procedures, we will conduct an investigation and reassess the qualification to determine the viability of the ongoing relationship with that vendor or customer. Violations of our platform's Acceptable Use Policy (AUP) may result in 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 platform users an annual reminder of the IVT guidelines and expectations.

Additional disclosures

We rely on cloud providers, data centers, and content delivery networks (CDNs) to deliver ads and collect impression-level data necessary for user analysis and invalid traffic filtering. All of our primary services maintain an industry-standard ISO 27001 (Information Security Management) certification.

Last Updated on 2026-04-01
Last Reviewed on 2026-04-01

X