Documentation sections

JS challenge and scoring

An intermediate browser check in cloaking: which signals are collected, how the decision is made and what the visitor gets.

The JS challenge is the second stage of cloaking: a visitor who passed the server checks first gets an intermediate page, and only after the browser is evaluated do they get the offer or the landing page. The check is turned on by the JS challenge (behavior + headless detection) («JS-челлендж (поведение + headless-детект)») checkbox on the campaign's Cloaking («Клоака») tab.

When the challenge is triggered

A click gets the challenge when all of the following are true:

  • cloaking is turned on in the campaign and the JS challenge (behavior + headless detection) checkbox is selected;
  • the click passed the server checks: it is not a bot and matches by click ID, country, device and connection type;
  • the selected stream returns an address or a page.

A click filtered out by the server checks never reaches the challenge and immediately gets the “white” stream.

The visitor sees a blank page with the tab title “Loading…”. For about a second the page collects signals, sends them to the tracker and goes to the address from the response. If there is no response or the response has no address, the page sends the signals again — up to three attempts in total. A visitor with JavaScript turned off stays on the blank page and goes no further.

The click is recorded in the statistics of the selected stream before the check. Returning after the challenge does not create a second click. The click of a visitor who failed the challenge stays in that stream's statistics.

Collected signals

From the browser:

  • the navigator.webdriver automation flag;
  • the number of browser languages and the number of plugins;
  • the number of CPU cores and the amount of memory;
  • the screen width and height;
  • touch support;
  • the time zone;
  • the graphics card name;
  • actions on the page: mouse or pointer movement, touch, scrolling, a key press, the mouse wheel;
  • the time from opening the page to sending the response;
  • the device fingerprint.

From the first request to the campaign link: the device type by User-Agent, the connection type from the IP2Proxy database, the presence of the Accept-Language and Sec-CH-UA headers, and the country and time zone by IP.

Scores and reason codes

Each triggered signal adds points. When the total reaches the threshold, the visit is treated as a bot. In the click window the total is shown in the Scoring («Скоринг») line, and the codes of the triggered signals in the Reasons («Причины») line. The Details («Детали») line starts with the total and the threshold, separated by a slash.

Any one of these signals is enough for the visit to be treated as a bot:

Reason codeWhen it is triggered
no_jsThe response came without the mark that the page script ran. Other signals are not evaluated
webdriverThe browser reported that it is controlled by an automation tool
software_gpuThe graphics card is software or virtual: SwiftShader, llvmpipe, Mesa OffScreen, VirtualBox, VMware, Microsoft Basic Render
no_screenThe screen width or height is zero

The other signals make a visit a bot only in combination with each other:

Reason codeWhen it is triggered
tiny_screenA very small screen width or height
mobile_ua_desktop_screenThe User-Agent is mobile, but the screen is as wide as a desktop one
desktop_ua_mobile_screenThe User-Agent is desktop, but the screen is narrow and supports touch
mobile_no_touchThe User-Agent is mobile, but there is no touch support
no_languagesThe browser language list is empty
no_coresThe browser did not report the number of CPU cores
no_timezoneThe browser did not report the time zone
no_interactionThere were no actions on the page, and the response came almost immediately after the page opened
no_accept_languageThe request to the campaign link has no Accept-Language header
no_client_hintsThe request to the campaign link has no Sec-CH-UA header, and the User-Agent is not mobile
datacenterThe connection goes through a proxy, VPN or Tor while the Block proxy / VPN / Tor («Блокировать прокси / VPN / Tor») checkbox is cleared. Data center addresses, and clicks when the checkbox is selected, are filtered out earlier, by the server checks

A phone or tablet User-Agent counts as mobile.

Two more codes make a visit a bot regardless of the total score:

Reason codeWhen it is triggered
timezone_mismatchThe browser time zone differs from the time zone by IP
device_fp_other_countryA device with this fingerprint has already visited from another country

Time zone matching

Matching always works when the challenge is turned on; it has no separate checkbox. The tracker compares the UTC offset of the browser time zone with that of the time zone the geo database detected by IP. A difference of more than an hour gives the timezone_mismatch reason.

If the geo database did not return a time zone for the IP or the browser did not report one, no mismatch is counted. Both time zone values are shown in the click window in the Details line.

Device fingerprint

This check is turned on by the Device fingerprint (anti-moderation) («Фингерпринт устройства (анти-модерация)») checkbox on the Cloaking tab. It is available only when the JS challenge is selected.

  • The fingerprint is calculated from the screen size and color depth, the number of cores, the amount of memory, the time zone, the graphics card, the languages, the platform and the number of touch points.
  • On the first visit the tracker remembers the country the device came from.
  • If a device with the same fingerprint comes from another country, the visit gets the device_fp_other_country reason and is treated as a bot, even when the total score is below the threshold. The remembered country does not change.
  • The record is kept for 30 days. Each visit from the same country extends this period.
Warning.

The fingerprint memory is shared by all campaigns of the installation that have the fingerprint turned on. A device that visited from one country in one such campaign will be filtered out when it visits from another country in any of them, as long as the record is kept.

What the visitor gets

A human visitor returns to the campaign address and gets the response of the same stream, with the same offer and landing page that are recorded in the click statistics. The service parameter _cp is added to the return address. The tracker strips it: it does not get into the click parameters, the statistics or the landing page.

A bot gets the response of the final stream:

  • if the stream action gives a redirect address, the browser goes to it right away;
  • the exception is a stream with the Offer («Оффер») action where at least one offer has a click cap. Its address is not chosen in advance: the browser returns to the campaign address, and the offer is chosen at that moment. A place in the cap is taken only by a visitor who got the offer, not every time the check is shown;
  • in other cases the browser returns to the campaign address and gets the stream response: HTML, text, 404 or an empty response;
  • if there is no suitable final stream, the response is 404.

A bot does not get the offer or the landing page of the target stream.

Time limits

WhatLimit
Accepting the browser response after the intermediate page is served5 minutes
Returning to the campaign address after the check2 minutes, once
The cloaking decision in the click window7 days
Device fingerprint memory30 days from the last visit from the same country

Opening the return address again, or following it later than 2 minutes, counts as a new click and goes through the check again.

If the tracker could not start the check

If the tracker could not save the data for the check, the intermediate page is not shown, and the visitor does not get the offer or the landing page of the target stream. They immediately get the response of the final stream: a redirect, HTML, text, 404, an empty response or a handoff to another campaign. If there is no suitable final stream or its action is a funnel, the response is 404.

In the click window the result is “sent to white” («завёрнут на whitepage»), the stage is “server checks” («серверные проверки»), the Reasons line has the challenge_unavailable code, and there is no Scoring line.

Where to see the result

  1. Open the campaign and click Statistics («Статистика»).
  2. Go to the Click log («Лог кликов») tab.
  3. Click the click row.

The challenge decision is shown in the Cloaking section of the window that opens:

  • Result («Результат») — “passed to money” («прошёл на money») or “sent to white”. The value “sent to JS check” («отправлен на JS-проверку») means that the browser has not responded yet or never responded.
  • Stage («Этап») — “JS check (behavior/fingerprint)” («JS-проверка (поведение/фингерпринт)»), if the decision was made by the challenge.
  • Scoring — the total score and the outcome: “human” («живой») or “bot” («бот»).
  • Reasons — the codes of the triggered signals, separated by commas.
  • Details — the total and the threshold, the time zone by IP and the browser time zone, the fingerprint check result and the main signals.

The Cloaking grouping and the Cloaking (passed) («Клоака (прошёл)») filter in reports reflect only the server checks: a click that failed the challenge still counts as passed there. The other lines of the click window and the entries of the Traffic («Трафик») log are covered on Diagnostics: why a click went to “white”.

Updated Need help? ↗