FAQ

How to Use

  • What values can be passed as the Supply Type (kv24 parameter in the tag)?

    • Acceptable hardcoded KV24 values include: Desktop, Desktop_Video, Desktop_Native, Mobile_Web, Mobile_Web_Video, Mobile_Web_Native, Mobile_InApp, Mobile_InApp_Video, Mobile_InApp_Native, Email_Display, Email_Video, Desktop_Native, Mobile_Web_Native

  • Is there just one login for multiple users?

    • Yes. However, only two users can login at the same time.

  • Can I use a JavaScript pixel for mobile app?

    • No. We recommend using a 1x1.

  • If a client sets the JavaScript in HTML, how do they then organize the parameters of the JavaScript?

    • We will generate the tags based on the macros provided by the DSP, each parameter in the tag is predefined of what data it can accept.

  • Is there some differences in the use of JavaScript in terms of native, video, or other environments?

    • JavaScript is provided for display, and 1x1 is provided for video and native.

  • How does Pixalate define a user session? When would a session begin and end?

    • We define a session based on cookies so this is the period of time (often less than a day) that is characterized by the same session cookie when available.

Reporting

  • What time zone does the platform report on?

    • The reports listed under ‘Fraud Reports’ are only available un UTC. The reports listed under 'Reports' (aka. main reports) are in UTC by default. However, this can be updated to either EST or PST by selecting the buttons at the top right under account name.

  • Why are the fraud reports not showing any data for today?

    • The reports listed under ‘Fraud Reports’ are processed only once per day in UTC. However, the reports listed under 'Reports' (aka. main reports) have a 6 hour delay, updating every hour.

  • Is reporting customizable?

    • Yes. Our Analytics and Media Ratings Terminal products are highly customizable.

  • Do you support alerts, and are your alerts customizable?

    • You can create customizable reports, based on your data, that can be scheduled to be sent to any email address (delivery reports, IVT reports, etc). We have a standard IVT/viewability report sent out daily from our system.

  • Do you offer scheduled reports?

    • Yes, for post-bid.

  • What measurement metrics do you support?

    • Impressions, Clicks, Conversions, IVT (GIVT, SIVT), Viewability for display, various campaign level metrics.

  • When using the Report API, what do the "isAsync" and "isLargeDataSet" parameters set?

    • If isAsync=true parameter is specified, then the response is returned immediately, while the service continues to process the report asynchronously. The report will not be available for download until processing has completed. While processing asynchronously, a request to retrieve the report using the response URL will return an HTTP status code Not Found (404). Once asynchronous processing has completed, the report is returned as normal.

      • If asynchronous processing of a report fails because of an invalid query, the report using the response URL will return an HTTP status code Bad Request (400).

      • For all other errors a request to retrieve the report using the response URL will return an HTTP status code Internal Service Error (500).

      • When using isAsync=true, client systems should poll the response URL until the report is available, or a non 404 HTTP status code is returned.

    • If isLargeResultSet=true parameter is specified, then processing is handled identically as if the isAsync parameter is set to true. However, the returned CSV file contains a single column with each row being a URL to a CSV file that contains part of the data.

      • Note that large result sets that include an "ORDER BY" clause may cause an HTTP status code Bad Request (400) to be returned. Try removing the "ORDER BY" clause or using the limit parameter to reduce the result set size. Also, extremely large result sets may require the use of the isAsync, or isLargeResultSet parameters.'

  • What times does data in reports and dashboard update?

    • The processing of IVT data depends on the type:

      • Real-time: General IVT (GIVT) - Data center and IAB crawlers specifically

      • 12 hours: Other advanced General IVT (GIVT) and Sophisticated Invalid Traffic (SIVT)

    • In terms of publishing the data:

      • Real-time: IVT for GIVT (data center and IAB crawlers specifically) is available in the API

      • Hourly: Estimated IVT is published hourly in the dashboard and reports

      • Daily after 12:00 AM UTC: Estimated hourly IVT is reconciled into actual IVT and published in the dashboard and reports

    • To account for longer data processing times, it is recommended to pull the previous day's data ~4 hours after 12:00AM UTC.

Viewability

  • Do Pixalate viewability numbers include IVT?
    • Pixalate Net Viewability numbers exclude IVT.
  • Can viewability be recorded if a 1x1 pixel is used?
    •  No.
  • Do you provide video viewability?
    • No. However, we provide display viewability that can detect a video player's viewability.

Ad Types

  • Do you support the delivery of image banners (e.g. 320x50)?
    • Yes, we have a 1x1 pixel and a JavaScript tag that can support this.
  • Do you support the delivery of image animation creatives (e.g. expandable banners)?
    • Yes, we have a 1x1 pixel and a JavaScript tag that can support this.
  • Do you support the delivery of video interstitials?
    • Yes, we have a 1x1 pixel and a JavaScript tag that can support this.
  • Do you support the delivery of native ads?
    • Yes, we have a 1x1 pixel and a JavaScript tag that can support this.
  • Do you support the delivery of custom creative templates?
    • Yes, we have a 1x1 pixel and a JavaScript tag that can support this.

Click-Tracking

  •  What does highCTR IVT type mean?

    • The “highCTR” IVT type characterizes traffic associated with domains or apps demonstrating high Click Through Rates (CTR) at the creative level. In other words, for a given publisher, only the creatives that generate anomalous CTRs will be flagged as IVT. This can flag user-side IVT such as crawlers clicking on a given creative repeatedly, or publisher-side IVT such as creative manipulation with the intent to inflate click through rates. 

  • How is highCTR IVT type identified?

    • For a given client, highCTR is identified as the proportion of traffic that belongs to a given creative that has been manipulated publisher-side or being targeted user-size in order to generate very large click through rates, either intentionally or as a byproduct of some other invalid activity. The main precondition for such determination is that both click and impression tracking have been enabled at the creative level. The thresholds used correspond to a combination of dynamic thresholds within a range of acceptable values (i.e. 2% - 10%). Creatives with less than 2% are not considered for analysis by this IVT type and creatives with more than 10% will be flagged deterministically. The region in between will be flagged depending on the dynamic baselines detected for that given client.

When sampling is used to decide what traffic to send to Pixalate, it is highly recommended that the same sampling method is used for both impressions and clicks in order to avoid false classifications. For example, if 10% of the impressions are sampled for the given publisher+creative while 20% of the clicks are sampled for the same publisher+creative, the perceived CTR can be twice as much compared to the real one, since the sampling rate of clicks is double the sampling rate of impressions.

DElisted From the App StorE (DEFASE)

  • What is the defaseApp IVT Type?

    • The IVT type called “defasedApp” characterizes traffic seen from apps that were available for download through one of the two major app stores (namely Google Play and iTunes) over the last 12 months but got delisted and currently are not available any more. 

  • What does DEFASE stand for?

    • DEFASE stands for DElisted From the App StorE. 

  • Why is a defasedApp IVT?

    • In general, apps can be delisted for various reasons, including publisher level fraud, malware, adware, availability of backdoors for fraudsters to leverage bad SDKs, or simply because the developer decided to delist an app. In addition, it is also possible for an app to be delisted for other reasons such as copyright violations. So, clearly, not all delisted apps generate necessarily IVT. For this, Pixalate collects information about the behavior of a delisted app prior of it being delisted, and based on that, decides if an app should be flagged as IVT because it poses significant risks to the advertising ecosystem. 

  • Can a DEFASED apps be flagged for other IVT reasons?

    • Yes. Pixalate analyzes the traffic seen from an app using various models that check for certain types of IVT patterns. An app does not have to be flagged as 100% defasedApp if it gets delisted. On the contrary, Pixalate will try to label the traffic behind a delisted app using its other IVT types first (i.e. using higher IVT priorities) such that more light is shed on the invalid activity generated by the app. 

  • Are there any data feeds that can protect us from “defasedApps”?

    • Yes. Pixalate has developed two datafeeds related to delisted apps:

      • A data feed containing all the removed apps from Google Play and iTunes store within the last 6 months. The friendly name for this data feed is “Defase App List”.

      • A data feed containing all the apps removed from Google Play and iTunes store within the last 6 months, which have generated impressions in the last 2 weeks and which also have shown evidence of suspicious or invalid behavior. The friendly name for this data feed is “Defase App Blocklist”.

    • Based on the above definitions, the first list can contain apps that do not have ads or do not have impressions at all, but nevertheless they can be useful if proactively blocked to avoid being manipulated for IVT in the future. 

    • The second list contains apps that have been seen generating impressions and in general should be treated as IVT and be blocked. Note: Pixalate has developed algorithms to detect and exclude from the second list potential cases of removed apps that should not be blocked and treated as IVT because their removal was likely not related to IVT. Examples of such apps include cases removed temporarily due to legal issues, that are usually put back in the app store a few days or weeks later.

  • For how long an app can be delisted from the app stores?

    • An app can be delisted for various reasons, and in many cases some removals are permanent. However, there are cases of apps that have been added back a few weeks after their removal (e.g. due to a malicious SDK causing problems to the app until it gets uninstalled). This means that when someone uses a DEFASE data feed, he/she needs to make sure that the latest daily copy has been downloaded, since Pixalate’s backend has been designed to check on a daily basis if delisted apps are still delisted, and if new apps have been delisted, and update the data feeds accordingly.