In the article below, we will take a closer look at the setup JSTDS filters in the campaigns.
Please note: JSTDS filters are available in campaign and ad inventory settings. Here we will talk about the operation of filters using campaign examples. The process of setting them up is similar for ad inventories.
JSTDS filters are tools that help determine the quality of traffic and identify its characteristics. These actions are aimed at optimizing the advertiser’s campaigns and publisher’s ad inventories.
First, let’s consider the features of the landing page for traffic quality control for a better understanding of the filters’ purpose.
A test landing page allows you to control the quality of the publisher’s traffic. It is a page with a message stating that the user will be redirected to the site after his browser passes the test. The landing page looks like the Cloudflare service’s test page to minimize cases in which users close the landing page during the test.
Traffic from publishers is divided into small segments based on the UTM Source + device bundle. The system selects 1% of visitors to check in each segment.
During the display of the landing page, the user is checked against a number of parameters. You can find them in the Quality tab of the campaign or ad inventory settings (White/Blacklists and Filtering blocks):
1. First of all, the system analyzes the possibility to load a tracking pixel. If the download fails, then the traffic will get the value NOEXECUTED. The filter signals that this is bot traffic.
Please note: the rule about using 1% of traffic during the test has an exception. This is a NOEXECUTED filter. If the landing page is loaded, but the pixel does not work, the system will not take into account this impression in a sample based on 1%. For example, when the impression in the 1% test segment ends at the NOEXECUTED stage, the system will take another part of the traffic for analysis.
2. If the impression passes the NOEXECUTED check, the rest of the filters will enable: WEBVIEW, IFRAME, UNFOCUS, NOSCREEN, SMALL, HIDE TAB, NO JS, NO FLASH, NO MOVE, MIS USER, MIS IP, PROXY, MIS REF, and HIDDENLINK.
Analysis time does not exceed 2.5 seconds. NO MOVE checks if the user moved the mouse during the demonstration of the landing page. The filter is used for desktop devices only.
An attempt to redirect a user to one of the real campaigns occurs after 2.5 seconds or earlier if the check ends faster. If the redirect fails, you will see it in the Lost column. The Mis column shows the number of impressions blocked by JSTDS filters.
When you collaborate with DSP advertisers, keep in mind that traffic passing through the test landing page loses the HTTP referer. Note that the system checks only 1% of the traffic from each UTM Source + device segment. Therefore, the loss should not affect the work with the DSP advertiser under normal conditions.
You can learn more about the quality control of the advertiser’s campaigns and publisher ad inventories using the Quality tab in the relevant materials (coming soon).
Let’s return to the JSTDS filters. You can find them in the Filters for traffic sources block. Their names are identical to the settings located in the Quality tab. There are 4 categories of filters:
Let us remind you that traffic from publishers is divided into small segments. The system takes 1% for the check. For example, if you have a traffic source (UTM Source + device), which will show that more than 50% of the checked section does not work with one of the JSTDS filters, you can block or leave it. In such situations, we call this blocking of traffic filtering by probability.
You can set filters for the following parameters:
Actual impression blocking is available in the last block Basic data about user. To do this, tick the box Block impression.
Filtering by probability works during the matching. The probability of error is estimated in advance. If the probability is higher than the established threshold, the campaign will not participate in the auction.
Actual impression blocking, unlike limits by probability, occurs when a user is redirected to promotional material. If the user information does not match what the information claimed in the ad request, the user will be redirected to the publisher’s trafficback. When redirection is not possible, the platform searches for an alternative campaign to demonstrate to the user. But this can lead to traffic loss.
Let’s take a look at the following example of using filters. Let’s say there is a campaign that shouldn’t receive bot traffic. Therefore, in the BOT DETECTED column, you must select one of the settings Block if ... The percentage of the analyzed segment depends on how much you want to get rid of such traffic.
However, you can create a campaign for unsolicited traffic, and send there all bot traffic. So it will not “spoil” the statistics.
Or you will find an offer that can bring money on bot traffic. In this case, select the setting Allow, if … The campaign will receive traffic with bots only.
Below you can find guidelines for setting filters for specific offers, promotional materials, or campaign types. Go to the section Filtering traffic sources, to do this. You can place tighter restrictions later, if necessary.
Guidelines for CPA campaigns
Guidelines for Directlink campaign with buying traffic from SSP
Guidelines for CPI campaigns (Target URL with the “File” type)
Guidelines for Push campaigns
Guidelines for Directlink \ Popunder campaigns with strict requirements for checking referrer
Guidelines for Directlink \ Popunder campaigns without referrer checking requirements
Let’s summarize the material: