Mixpo Inc.'s Disclosure for Ad Reporting Standards

What are non-human transactions?

Activity that cannot be attributed to direct human Internet action is considered to be non-human. Automated programs designed to request pages, follow links, and catalog Internet content are often referred to as spiders/robots and are a major contributor to non-human activity. Mixpo utilizes the IAB Robot and Spider list to identify and filter this traffic from reports because it is not considered valid for billing purposes.

What processes does Mixpo use to identify and filter non-human transactions?

To identify and filter (exclude) invalid impressions—including, but not limited to, non-human click activity and suspected impression fraud—Mixpo employs techniques based on identifiers, activity, and patterns found in web log data. However, because user identification and intent cannot always be known or discerned by publishers, advertisers, or their respective agents, it is unlikely that all invalid impression activity can be identified and excluded from the reported results.

• User-Agent Filters: The User-Agent Filter evaluates the user-agent string of the requesting application in real-time. The user-agent string contains information about the type and version of the browser or other application making the request. If the user-agent matches one on the filter list, that request is filtered from reporting, but not raw logs. The filter list contains information from a list of known robots listed in the IAB's user-agent block list. Mixpo also filters on known user-agents that have demonstrated non-human behavior.
• SmartPlayer Technology: The SmartPlayer Technology (hereafter referred to as "the player") evaluates the payload of the requesting application and determines if the requestor is human or non-human by examining specific flags used by bots, spiders, and non-human traffic.
• Client Browser Information: Browser information such as user-agent data is used for analysis. We normalize large data-sets and then examine for trends and other oddities which might signal fraudulent activities.
• Repeat/rapid impressions: Rapid requests can signify robotic or non-commercial intent behavior. Mixpo treats all impression data as unique impressions regardless of timing of said impressions. Since Mixpo provides the content of the ad units, and not necessarily the inventory over which the ads are ran, it is up to the client and publisher/network partners to determine inconsistencies with impression data. However, Mixpo provides data insights and alerts clients to any abnormal behavior so that it may be investigated immediately for possible fraudulent activity.  
• External filter list: Mixpo uses the IAB Robot and Spider list to exclude any data from those properties/domains/IP's within the list.
• Click filtering: Following IAB guidelines, Mixpo also filters out suspected invalid clicks.
   

What types of data adjustments are made and why?

In accordance with IAB Guidelines, Mixpo has implemented measures to reasonably assure that data is reviewed and edited correctly. The editing process is performed in multiple steps of the data processing cycle.

First, during advertising delivery, the ad delivery system reviews each request against the IAB Spider and Bot Database List to determine if the request is performed by a robot known to be identified by the IAB. If a robot is detected, no ad delivery is recorded, nor measured. Raw data logs are kept and available for review only by Mixpo employees.

Second, within the processing pipeline, each ad request includes a Globally Unique Identifier (GUID) and unique View ID to ensure pertinent information is logged and is able to map to a valid impression.

What is the ad processing methodology Mixpo uses to process data after the ad is served?

The Mixpo player processes a variety of logs and events that contain advertisement delivery data. Logs go through several steps; each contributes its analysis and filtering to the data. The different steps are:

• Log files are sent from the player to the raw database.
• The logs are then scrubbed against blacklist information.
• Processing scripts transfer data from the raw database to a client facing Data Management System (DMS) database.
• Ad data is stored in DMS in two locations:
  • "View commercial analytics" scrubbed of blacklist data for public consumption.
  • "View non-commercial analytics" contains blacklisted data, and is employee access only.
• DMS provides a client-friendly web-based reporting UI and outputs a variety of (including, but not limited to) daily, weekly, monthly, reports.

All log files contain the GUID and View ID which are used as a pair of unique identifiers to associate all log files fired from an ads activity to the Mixpo raw database. Using the two unique identifiers, all activity can be attributed to their respective impression.

Using the IAB blacklist, log files are then flagged as either bot/spider activity, in-house activity, or valid impression data. All log files are sent to DMS for client consumption.

The bot/spider and in-house activity is only available in the "view non-commercial analytics" view of DMS, and is only viewable by Mixpo employees. All other data is viewable in the "view commercial analytics" view (which is active by default for all clients).

The most granular level of ad data in DMS that is available to clients is daily logs, with the highest level of data is multi-yearly.

Mixpo retains hourly data in an employee-only available format for approximately 90 days. After this time period this data is only available via hard copy backups.

How does Mixpo notify its clients of customer impacting issues?

Identification of an issue can come from several sources within Mixpo. For example, there are systems in Mixpo which are constantly monitored and/or administered by the Engineering team, and various IT operations teams, for the purpose of maintaining overall system health.

Escalation and Notification

The scope and effect of each issue are used to determine its severity. When an issue is identified, the following process is followed:

• Issue Identification: Issues can be identified via customers or via internal teams (engineering, sales teams, service teams, or other internal teams). Once identified, internal notifications are drafted by the support team and sent to the sales and service teams notifying them of a potential issue.
• Discovery: The issue is escalated to support teams and engineering teams to investigate and quantify the issue.
• Resolution and Notification: Once a root cause is identified and the proper impact analysis has been completed, issue resolution and communication plans are formulated. If the issue is deemed to be material, an external communication plan is drafted. This ensures that affected customers are notified directly of the issue regarding any impact to their account, and issue resolution plans. If the issue is deemed to be immaterial, the communication will be sent to internal sales and service teams. Those teams will follow up with their respective customers if appropriate.

What cache busting techniques does Mixpo use?

To minimize undercounting due to caching, Mixpo uses HTTP caching headers which are set to discourage caching by browsers and proxy servers. Mixpo does not use random strings on ad requests delivered by Mixpo as the response is not cached by the browser or proxy server due to the HTTP headers.

Mixpo supports cache busting techniques employed by other ad serving companies for tracking pixels, as long as the other company provides a recognized token to be replaced with a Mixpo macro that will insert a random string. The cache busting string is randomly generated by system which ensures that the string is not cached because it is different for every ad call.

What time zone does Mixpo use to produce a measurement report?

Mixpo ad delivery times are only provided in Pacific time.

What methodology does Mixpo use for accumulating ad serving data?

Mixpo's ad delivery mechanism is consistent with IAB guidelines which require the use of a client-initiated ad counting methodology. The “client” refers to an Internet user's browser. The browser calls the ad request and receives instructions for the ad content. An impression count occurs once the Mixpo container.xml file is loaded.

What practices or circumstances, which may have an adverse effect on counts, are outside of Mixpo's control?

Mixpo is obligated to fulfill every request received for an ad, but has no control over the practices which may affect the count and/or value of the impression data. For example, if an ad tag is altered by a trafficker so it points to a creative that does not exist, Mixpo will count the request. Similarly if a user deletes and/or modifies the ad creative, this could result in lack of recorded impressions. Users are warned prior to deleting an ad unit from the system and must perform a secondary action to confirm their intent.

Mixpo provides an ad tag to be ran across any network, publisher, or site. The site quality, code, and page setup could have an impact on ad delivery.

How does Mixpo track companion ad units?

All impressions for companion banners for Mixpo are rolled into the impression of the in-stream unit. Third party trackers are allowed to track impressions as an optional component, but Mixpo does not separate companion ad impressions from the in-stream unit it is associated with.

What are the parameters that Mixpo uses for auto play in-stream units?

Auto play ads are available through the Mixpo platform. Auto play is dictated by the publisher's site, and whether or not they are permitted. Mixpo defers to the publishers ad specifications as to whether or not an auto play ad is allowed, and the trafficker must adhere to the publishers specifications prior to trafficking the ad tag.

How much performance data does Mixpo retain?

Mixpo keeps ad performance data available for reporting and API access for approximately three years. Data that is older than three years is archived in cold storage.