Description of Methodology

SUMMARY

Within the scope of this document are all systems and processes which Mode Media has audited as per both Interactive Advertising Bureau (IAB) and Media Ratings Council (MRC) guidelines.

 

WHAT’S INCLUDED

This Description of Methodology covers the following Mode Media technology:

 

  • The Adapt Ad Server
  • Splash, Mode Media’s rich media platform
  • Adapt Network Services (Mode Media’s publisher network management technology)
  • The Adapt Insider (Self Serve Publisher tools for publisher partners)
  • Mode Media’s trafficking and ad operations processes, and the reports generated for end users.

 
The numbers and measurements outlined in this Description of Methodology relate to online display, rich media, and video advertising impressions, as well as viewable impression measurement.

 
These advertising impressions described in this Description of Methodology may be generated by the delivery of standard and rich media ad units, including Flash creatives, image creatives, and expandable units, both hosted by Mode Media and delivered through third-party ad servers.

 

WHAT’S NOT INCLUDED

This Description of Methodology does not cover click measurement or added value metrics, relating to user engagement and interaction, other than viewable impression measurement.

 

MEASUREMENT METHODOLOGY

Overview

Impression measurements are based on actual measurement as all valid impressions are counted. As a result, there are no statistical projections or estimates utilized.

 
Adapt Delivery Methodology

Mode Media delivers ads on browser based devices that support JavaScript. The delivery mechanism leverages the platform independent client-server capabilities of the JavaScript platform, through which a third party web site can point to Mode Media servers to download the snippets of code that will display the ad.

 
The ad selection process is initiated via a <script src=”…”></script> tag that must be included anywhere inside the template of a page where an advertisement is desired.

 
Example:

<script language="JavaScript" src="http://www2.glam.com/app/site/affiliate/viewChannelModule.act?mName=viewAdJs&affiliateId=999&sz=728x90"></script>

 
Each ad placement requires its own <script> tag and triggers ad selection and data logging processes that are independent from any other ad tags on the page. This means that while the targeting capabilities of the Adapt ad server allow for delivery of roadblocks or other types of coordination between the ad units contained within a page, the mechanics of each ad call follow a stateless procedure for the ad selection and logging.

 
From the client/server protocol perspective, the selection of an ad triggers the following events:

 

  • The client computer executes the html directive <script src=”…”> to load a snippet of JavaScript from Mode Media’s network of servers
  • The data center with that is the closest to the client computer receives the request and validates the authenticity of the ad call
  • The Ad Request Load Balancer sends the request to one of the many servers available in the data center
  • Once a valid ad has been selected, the contents of the creative are converted into JavaScript directives and sent back to the browser
  • Once the Ad Server verifies that the client computer has received the response, all of the information related to the ad call is saved in a local log file. Adapt’s log processing facility downloads logs from all servers on the network every five minutes.

 
The logging mechanism described above constitutes an “ad selection time server side” logging process and is the general methodology followed to log information on all ad calls. For high availability purposes, an alternate client-side methodology is followed in case of a system malfunction that leads to unresponsive servers. Such process is described below.

 
The Adapt Ad server is designed as a multi-tier system with various components of its architecture residing in distributed data centers and content delivery networks. Each ad call is given a maximum amount of time to respond. In case a data center becomes unresponsive during an ad request call, the system automatically tries to fulfill it from a different location. Once the allotted time has passed, the code triggered from the client computer concludes that the request has failed and falls back to an alternative ad selection system written in JavaScript that runs 100% client-side. This alternative server-less system resides on one JavaScript file that is downloaded from a highly available content delivery network. In this case, once an ad has been selected, the client side code will log the impression by issuing an http request pointing to a pixel and sending all the parameters required to identify the ad selected. The web server that delivers the pixel records the call on standard weblogs. Adapt’s log processing facility downloads logs from all failover servers on the network hourly.

 
Each request is cache busted using a unique random number generator that is set on the client computer. That variable is sent in the request as a key value pair with the ‘ord’ name. Once the request reaches the Adapt network, it also receives an Edge Unique Request Id (euid) that is a function of the timestamp, ip address, user agent and a random number and that will become the unique identifier of the request within the network. The ord and the euid are used by subsequent de-duplication process to ensure that each ad displayed is only counted once.

 
In addition to this, the Adapt servers respond using cache-control headers to inform the browser that the request is not to be cached. See example below:

 

X-Glam-AdId : 5000003866
X-Glam-Euid : 29b96cf52179b41a0f500b9aa360ebeb
X-Powered-By : GlamAdapt/ASE/1.5
Vary : Accept-Encoding
Content-Encoding : gzip
Expires : Mon, 27 Sep 2010 16:52:53 GMT
Cache-Control : max-age=0, no-cache, no-store
Pragma : no-cache
Date : Mon, 27 Sep 2010 16:52:53 GMT
Content-Length : 3881

 
We acknowledge the possibility that some requests may yet be cached, but we do not believe this caching has a material effect on impression counts.

 
Logging Method and Frequency: Mode Media uses geo-distributed HTTP servers to capture all ad requests/transactions in real time.

 
Types of Data Collected and Contents of Log Files: Log files contain all necessary information for identifying the following with regard to the Ad/Event Transaction: Date/Time, Geo Information, IP address, Ad/Creative identifiers, Affiliate/Publisher Identifiers, User Session information, User Agent information, and Referring URL. In addition, some metrics and statistics are collected for internal analysis in order to help improve the Ad Serving Experience.

 
Frequency of Retrieval and Processing: Mode Media retrieves each log type every five minutes from its pool of ad servers. A collection process then pushes these logs to a centralized location where they are available for import. Log processing daemons import log files as they become available.

 
A nightly ETL process performs additional validation of the imported data and makes it available to Mode Media’s reporting systems.

 
Measurement Limitations and Other Disclosures: The following situations may limit Mode Media’s data collection and measurement.

 
Ad Blocking Techniques and Pop-up Blockers: Ad blocking techniques or software that prevent any requests to the Adapt platform will have no impact on the impression measurement as this situation will prevent both the ad request and the measurement, resulting in an accurate count of zero impressions.

 
However, certain ad blocking tools also allow users to block images based on dimensions, such as standard advertising image sizes or one-by-one images (pixels), which may result in overcounting of impressions if the tools identify the pixel size of the image subsequently returned as matching a defined ad size, and suppress it from being displayed.

 
The client computer may have a pop-up or pop-under blocker installed. In such scenario, a call to Adapt that successfully counted an ad impression may result in the user not seeing the ad.This will not result in a Qualified Ad Impression.

 
Caching: The MRC Minimum Standards and the IAB Guidelines require the use of cache-busting techniques (HTTP header controls or random number assignment techniques). Caching of content at the browser level or at a network or proxy level can cause undercounting of traffic as the content may be served to the browser from the cache without any interaction with the measurement servers.

 
To minimize undercounting due to caching, Mode utilizes a unique string approach as each measurement event contains a UID specific to the impression, and a unique MD5 hash via a combination of user IP address, timestamp (to the second), and a randomly generated alphanumeric string. Therefore, an event would have to be transmitted in the same second, containing the same UID (which by design should be unique) with the same randomly generated alphanumeric string and measurement data to be the same URL as another request in the cache.

 
Cache busting (unique identification) is accomplished via a combination of two methods, which, together, guarantee that a request’s uniqueness is properly represented.

 
Client side:

Every page load contains unique, client-side JavaScript randomly generated alphanumeric parameter of varying length. When there is more than one ad tag on a page, each ad request will utilize the same randomly generated number to identify that the requests occurred on the same page load. Each individual ad request is then identified by a sequence number used to track the number of requests, as well as order of those requests, from a given page load. These two values combined provide the client side uniqueness for each request. For clicks, these values are used to associate a given click with a specific impression.

 
Server side:

Mode generates a unique MD5 hash via a combination of user IP address, timestamp, and a randomly generated alphanumeric string. This value is used to further uniquely identify a given ad request. It is also used at the log-level to properly remove any potential duplicate entries.

 
Non-PC Devices with Full Browser Capabilities: In response to ad requests originating from non-PC devices, the Adapt platform will select and deliver advertising content the same as PC devices. This process is also JavaScript dependent. Additionally, Flash ad requests originating from a non-PC device without Flash support will not be counted or delivered.

 
For certain mobile devices in Japan, ad requests are delivered through a custom ad tag specific to those devices, allowing proper detection of mobile device characteristics.

 
Creative Formats: There are some creative formats (mostly rich media) that may not render in an end user’s browser due to software, technical or configuration set up issues. Mode requires the upload and identification of backup creative assets (such as images), for all creatives — to be delivered when an end user’s browser does not support Flash, or any other platform required in the delivery of the rich media version of the ad.

 
Domain-based Ad Blockers: The client computer may have a Domain-based Ad Blocker installed. In this case, the ad call to Adapt will not occur and therefore no ad will be logged nor viewed by the end user.

 
JavaScript Disabled browsers:Certain older browsers and non-PC devices may not support JavaScript, and users may disable the JavaScript function on newer browsers disallowing JavaScript programs and scripts from executing. The Mode measurement process is JavaScript dependent. For users that do not have JavaScript enabled, no advertising will be delivered or counted nor viewed by the end user (that is, it will result in a correct measurement of count of zero). Users can still be ‘tagged’ for further targeting by using 1×1 pixel beacons.

 
Non Flash-enabled Browsers:Certain browsers and non-PC devices may not support Flash, which is an interactive format used for the delivery of the advertising content. In these situations the ad impression would be recorded once the Flash ad has been loaded on the browser. For users that have Flash disabled or a non-Flash browser, an image creative would be loaded and an impression would not be recorded.

 
Flash ads are detected and passed as a parameter, and the corresponding parameter is then utilized by the ad selection engine to deliver the appropriate creative asset. A third-party tracker is used to track the load of the Flash content on the web page, and can be vetted through Adapt’s query tool.

 
Additionally, Mode provides an alternate counting option to advertisers. The alternate method allows advertisers to load Flash content from the Adapt platform and allows the implementation of third-party Flash loading.

 
Image Rendering Disabled: If the user disables image rendering, the browser will not render standard images. However, the ad tag is a JavaScript formatted tag. It is not identified as an image call at the time of the initial request, and therefore the browser would make the ad request, the ad server would select and record the ad, and the browser would subsequently be directed to retrieve or make an image call and, given the settings, would not render the ad. Counting occurs upon the ad server receiving and processing the ad call, and prior to the browser receiving the returned ad creative request for the image file, which in this configuration the browser will not request or display.

 
Abandonment Disclosure: The IAB Guidelines require impressions be “recorded at a point as late as possible in the process of delivery… to the user’s browser”. The Adapt platform’s primary counting methodology records ad impressions when the ad server receives the ad request from the browser and selects an ad, but prior to delivery of the selected ad content. In certain situations, this could cause overstatement if the user abandons the web page after the Adapt platform ad tag was acted on and the impression was counted but prior to delivery of the ad content. Ad servers are given a minimal time to respond to a request. However, Mode is not able to control the user’s browser session. It is assumed that some abandonment may occur prior to the recording of an ad impression.

 
Auto Refresh: Automatically refreshing pages use HTML programming code to automatically reload the user’s browser with an updated web page after a specified time interval. The two distinct methods of auto-refresh are user initiated and site initiated. User initiated refresh is a situation where the user has the option to enable auto-refresh for a specific page, and to choose an interval for refresh activity, or where the refresh is initiated only by user action. Whereas, using site-initiated auto-refresh, a web page can automatically reload itself without the involvement of the user. This potentially results in ad impressions that meet the viewability definitions, but are automatically served to a page/browser that is not in use by a human user at that time. The MRC Minimum Standard A.1 (reduction of bias) and MRC Minimum Standard A.2 (quality control) require that sites using an auto-refresh command need to study its impact on reported results (e.g., page impressions). If deemed material, the traffic should be identified and reported separately (i.e., estimates with and without refresh activity).

 
Mode Media does not have direct control over publisher’s site-initiated auto refresh, and does not have the ability to determine if publishers are fully reporting and disclosing the utilization of auto-refresh. As such, the utilization of site-initiated auto-refresh is maintained by the publisher and is outside of Mode Media’s control. Even so, all Mode Media publisher site traffic is audited and monitored for material scenarios which may result from this practice, though it is not forbidden. In the event that the site practice proves to be problematic, they are contacted and the nature of their refreshes is reviewed.

 
Known Limitations

Adapt’s ability to detect viewability has the following known limitations. Adapt is unable to determine viewability when:

 

  • the browser is located off the monitor.
  • a non-browser application is covering the ad.
  • the browser does not support the Page Visibility API.
  • the ad is loaded in an iframe without an iframe busterFiltration Methodology.

 

FILTRATION METHODOLOGY

Adapt implements several mechanisms to identify unwanted activity and remove it from the aggregates that expose data to the business. These filtration techniques include:

 

  • Logging data discrepancy issues in our internal tracking system
  • Identifying the browser’s agent as non-human-originated traffic before the ad selection is made, and not responding with a paid-for ad
  • Identifying Invalid or incomplete requests that will be rejected from ad selection
  • Identifying Internal or test traffic, generated by Mode Media users during Quality Assurance procedures

 
Mode Media applies all possible automated and manual means in order to discard unwanted activity; however, due to the nature of the technology environment in which Adapt serves ad requests, it is unlikely that all invalid activity can be excluded from the final reported results.

 
Adapt ad impressions are filtered during the logging, import and aggregation process for non-human traffic, internal traffic and invalid events.

 
Non-Human Traffic: During the ad request and logging process, both the IP address of the request, as well as the User Agent involved in the request are captured. This information is used to identify the nature of the request during the recording and serving of the impression, as well as the classification of the impression after the fact. If a request is made by a known or unknown Robot (an application used to index or test a site containing Ads) – it is flagged as such before it hits an ad server. In the event that the ad request is made by a robot, the request to the ad server captures that fact, and an ad intended for non-human traffic is selected and served. The list of known robots used to make this determination is the IAB International Robot and Spider List. The list of known browsers used to make this determination is the IAB International Known Browser Type List.

 
Invalid request: In some situations the ad server is unable to understand or record an ad request in its entirety. Requests which are incomplete and lack the minimum information in order to accurately identify the request are rejected.

 
Activity-Based Filtration: Internal audits are performed on all incoming ad traffic. Any material activity that has been identified as being incorrect either due to setup or technology issues, or has been identified as suspicious due to the nature of events will be investigated further and removed pending outcome of investigation. If a particular site is found to have such traffic, it will be identified and blocked from ad serving until the situation is resolved.

 
Internal Testing Traffic: All material or automated testing is either performed with a known robot agent, or against ads specifically set up and identified as Test Ads. This traffic is filtered passively as part of the reporting process.

 
Internal Traffic: All traffic that has been identified as internal due to the IP address of the request is filtered from the final reporting to Publishers as well as Advertisers. Some traffic generated on internal IP addresses will result in the normal selection of an ad, though the amount of traffic generated in this category is small enough to not have a material impact on standard discrepancies at the advertiser or publisher level. Note that we do not identify traffic initiated by our clients or partners, as such, those impressions are not filtered from the final reporting to our Publishers or Advertisers.

 
De-Duplication: In the event that the first request to an ad server does not result in an ad selection within internally determined time thresholds, the ad request is made to a second machine. If the second request also does not return quickly enough a default non-paid ad is served. As part of the daily aggregation of the impression data, each of these impressions (which are identified as the same Edge Unique Request Id) which are not the final served impression are discarded from the reporting aggregate. See ‘Measurement Methodology’ above.

 
All ad impression requests that are not invalid are recorded. Based on the reporting need or methodology as described above they may or may not be filtered. Any filtration, however, is performed as a function of the reporting process as these impressions, with the exception of duplicate requests, are not discarded outright.

 

VIEWABILITY METHODOLOGY

Adapt InView

The intent of Adapt InView is to determine whether ad content which has been delivered by Adapt to a requesting web page is actually visible to a viewer of the web page. Adapt InView uses geometry, the dimensions of the ad unit, the ad placement on the web page, ad unit display time, and the browser focus to determine ad viewability.

 
For Adapt to count an ad impression as an InView ad impression certain criteria must be met:

 

When an Ad is delivered and at least 50% or more appears within the visible viewport of an end user’s browser window dimensions on an in focus web page for at least one second at any time, a “Qualified Ad Impression” is reported.

 
The Adapt InView component makes use of the available DOM APIs to determine the position of the ad unit in relation to the page and the browser viewport. It then determines the percentage of themaximum possible ad in-view (Figure 1) which is viewable. If this is equal to or above 50% (the threshold) the ad unit is considered to be “in view”.

 
GlamAdapt InView

 
Figure 1 – The blue box represents the browser viewport; the orange box represents the ad creative

 
It also makes use of the PageVisibility API on browsers that support it , which stops the inview timer when the user switches to another tab or minimizes the browser.

 
The script checks the viewability status of the ad creative every 100ms and relies on the Metrics API to report the events to the reporting backend.

There are eight InView events reported:

 

  • “timer: inview” This is a timer event that is started each time the ad unit is “in view” and stopped when it goes out of view. It fires immediately once the unit is considered “in view” and does not wait for it to be “qualified” (see below). This includes a count of how many times it has been activated per ad impression.
  • “in-view:impression” This is a counter event and fires one time per session when at least 50% of the ad unit comes into view for over 1 second. This event is only fired once per session.
  • “in-view:qualified” This is a counter event and fires each time when at least 50% of the ad unit comes into view for over 1 second. If the unit comes into view multiple times, for more than 1 second, this event will fire multiple times.
  • “in-view:init” This event is sent if it is determined that we can send a confirmed “in view” event when the ad unit is “in view”.

 
If the browser does not support the Page Visibility API or the ad is loaded in an iframe without an iframe buster, then a suffix of “-unconfirmed” is appended to the event name. So the events in these circumstances would be:

 

  • “timer:inview-unconfirmed”
  • “in-view-unconfirmed:impression”
  • “in-view-unconfirmed:qualified”
  • “in-view-unconfirmed:init”

 
In the case where the browser does not support the Page Visibility API, we are only reporting on the visibility of the ad in relation to the browser viewport, it does not take into account tab or browser visibility.

 
When an ad is located in an iframe without an iframe buster we only report on visibility based on the tab/browser visibility (where available).

 
The event reporting to the backend is controlled by the Metrics API. The initial event fires almost immediately (within 20 ms) after the tracking call is placed. This is the same for both timer and counter events. The timer event starts off updating the backend relatively often then decays as the duration increases.

 
Browser Window Position and User Display Screen Area

A browser window, when reduced from a “Maximized” state, may be moved by the user in three directions: left, right and down. In the event that a portion of the browser window area is moved outside of the end user’s display screen area, a delivered ad residing on the web page in that browser window may no longer be visible to the user in the visible view port.

 
With Mode, when an ad has rendered and reported as a view if the browser window is moved so that less than 50% of the ad is within the user’s screen display area, in view time counting is paused. When at least 50% of the ad is moved back within the user’s display screen area, view time counting resumes.

 
If a web page is requested while a portion of the browser window is positioned outside the user’s display screen area, and a Mode ad unit is on the web page requested, if less than 50% of the ad unit is within the user’s display screen area, the ad will be requested, and the request will be reported, the ad will render, and ad rendered will be reported, but an ad view will not be reported and the view time counter will not start until at least 50% of the ad unit is moved within the user’s display screen window area.

 

KEY DEFINITIONS

Described below are key definitions to understanding Adapt InView methodology.

 
Ad Impression

When an ad unit is within the visible viewport or partially within the visible viewport of an end user’s browser window dimensions on an in focus web page the ad content is requested. When the content is fully loaded and delivered an “ad impression” is reported.

 
Qualified Ad Impression

A Qualified Ad impression is recorded when an ad is delivered by Adapt (counted per the methodology outlined in the earlier sections of this Description of Methodology) and 50% or more of the ad unit is visible for over 1 second. Only 1 qualified ad impression is recorded per session even if the ad unit goes in and out of view multiple times.

 
Ad In-View Time

The length of time that an ad is displayed and within a visible viewport of a browser window on an in focus web page. The timer is started each time the ad unit is in view, and stopped when it goes out of view.

 
Ad In-View time is recorded immediately once the unit is considered “in view” and does not wait for it to be “qualified” (see above). This includes a count of how many times it has been activated per ad impression.

 
Web Page Focus

A web page is considered in focus when it is

 

  • the primary window open on a user’s screen/visible viewport and
  • unobstructed by any other application window.

 

VIEWABILITY DETECTION SCENARIOS

Screen Savers

Adapt has the ability to determine in-focus events affected by the initiation of the user’s screensaver application, which is initiated with the web page containing the designated ad placement as the last in-focus application. In this situation the web page may be constructed to auto-refresh the ad content to generate a ‘new’ ad instance and associated measurement events while the screensaver is initiated.

 
Multiple Display Monitors

Adapt has the capability to determine the impact of the transaction and recording of the viewable event in situations where the measured content is placed on a secondary monitor.

 
Multiple Browser Tabs

Adapt has the capability to determine in-focus events affected through the simultaneous generation of multiple browser tabs. For example, configuring the browser to open specific web page content within multiple browser tabs to determine if the “in focus” content was recorded (when considered in “view”) and the “out of focus” content was not recorded.

 
Hidden Browser Windows

An end user’s browser window can be created as a hidden (invisible) window. The hidden window can be made visible, hidden back, or destroyed.

 
Adapt will determine when any web page is not in focus and will not request, load, and deliver an ad, therefore hidden browser windows have no effect on measurement.

 

RICH MEDIA

Splash, Mode Media’s proprietary rich media platform, delivers rich media advertising, and the associated engagement metrics on that advertising.

 
Specifically, per industry norms, Splash requires the upload and identification of backup creative assets (such as images), for all creatives — to be delivered when a user’s browser does not support Flash, or any other platform required in the delivery of the rich media version of the ad.

 
Impression for the ads delivered by Splash, on the Adapt ad serving platform, will be counted by Adapt, in terms of auditable impression data.

 

DATA REPORTING

Mode Media reports data to advertisers and publishers. The level of reporting currently varies between Publishers and Advertisers.

 
Publishers: Mode Media provides relatively real time data access to the Publishers. The Publishers have access daily to the latest traffic and revenue data. The data is considered to be preliminary until the close of the billing period, at which point the data is finalized. The preliminary data may be updated up until the time it is finalized.

 
Advertisers: Mode Media reports monthly for financial and billing purposes, with the invoice being the primary/official mechanism for reporting. This cycle provides additional time and information accumulation for these processes prior to data being finalized.

 
Reporting Overview: The reporting tools are setup to run against the Reporting Aggregates generated by the ETL process. The reports are setup to run on different frequencies, depending upon the aggregate table in use and the purpose of the individual reports. The results returned by the reports are available in multiple formats, depending on the reporting interface.

 
Adapt Impressions reports are available in the following formats: CSV, XLS, and XML. Splash impression reports are available in the following formats: XLS. Insider Publisher Revenue reports are available in the following formats: PDF, HTML, and XLS. Insider Publisher Traffic reports are available in the following formats: CSV.

 
In addition to regularly scheduled reports, additional ad-hoc queries can be run. This methodology is commonly used for analyzing custom date ranges.

 
Report Filters, Flags, and Data Dimensions: The reporting data analytics have the ability to filter the report data based upon multiple key dimensions. For example, reports can be setup to automatically filter the aggregate data based upon Internal IP flag or the Agent Type. Alternatively, the data analytics may use these flags within the reports, as is the case with Audit reports designed to track Internal IP and Agent Types. Overall, the reporting infrastructure has the ability to report against a wide range of pertinent data dimensions. Besides Internal IP and Agent Types, these data dimension include ads, sites, Impressions, Clicks, Click Through Rate (CTR), Unique Visitors, Date ranges, various ad and site level attributes, and internal data tracking values. While Mode may filter and report on various metrics, display, rich media, and video ad impressions (including viewable impression measurement) are the only MRC accredited metrics.

 
Reporting Periods: Data analytics is setup to run reports against several common date ranges based on EST. The most common ones are:

 

  • Daily – shows yesterday’s data (12 am – 11:59 pm).
  • Monthly – data for month-to-date through yesterday.
  • End of Month (EOM) – End of Month reporting covers the prior full month.
  • Weekly – the past 7 days of data, covering through yesterday.
  • Hourly – allows for review of our hourly processing.

 
Reporting Options: Adapt offers the following reporting options via these interfaces:

 

  • Insider: Financial Statement: On screen, PDF
  • Insider: Other Reports: On screen, CSV, XLS
  • Adapt: On screen, CSV, XLS, XML
  • Splash: XLS

 
Mode Media performs regularly scheduled audits to detect any discrepancies in reported data. Mode Media reviews each data irregularity and takes appropriate corrective action when necessary.

 
Revised impression metrics will be reported when significant excluded or invalid activity is detected for a campaign after initial reporting but within 180 days.

 
Mode Media follows these steps when previously reported data needs to be corrected or reissued:

 

  • Logging data discrepancy issues in our internal tracking system
  • Communication by Account Management to impacted parties indicating the nature of the data discrepancy, the cause, and resolution via appropriate front-end user tool or via e-mail.

 
All electronic records are archived for 24 months.

 
Reporting Material Changes to Mode Media’s Measurement Methodology: Clients will be notified in writing or via email of Mode Media’s intentions to change our measurement methodology. Clients will be notified at least 30 days in advance of the change in measurement methodology.

 

Welcome to Glam.com
We noticed that you're visiting from .
Would you like to view our Glam Media
site or stay here?
 
stay here