Skip to content

Reduction of the Datapoint Missing Block Reason

In most cases the datapoint missing block reason is a false positive, meaning no fraud has occurred but FraudStop has blocked the transaction. This page explains why we must block these transactions and how the number of false positives can be reduced.

What is "Datapoint Missing"?

When the FraudStop script loads it collects hundreds of datapoints about the device and browser that it will use to make a validation decision, these datapoints are packaged together and sent in a single request. If this request fails for any reason, then it is repeated once.

The datapoint missing block reason is triggered when FraudStop has not received this datapoint request from the handset at the time that the validation API is called. It is necessary for FraudStop to block the transaction in this scenario otherwise it would be trivial for fraudsters to bypass FraudStop by simply blocking this communication.

Causes

There are many potential causes for the datapoint missing block:

  1. Poor internet connection - Slow internet can cause the user to navigate off the page (click subscribe/continue) before the datapoints have arrived on FraudStop servers.
  2. Slow phone performance - Although much work has been done to optimise the FraudStop script, if the phone performance is degraded (for example if the phone is overheating) then this can still increase the time taken for the datapoints to be collected and allow the user to navigate off the page before they have arrived on FraudStop servers.
  3. Very quick navigation - If the user clicks the subscribe/continue button as soon as the page loads then the datapoints may not be sent. This happens often in testing where the tester will not read the terms and conditions or pricing and knows where to click in advance.
  4. Implementation issue - Loading the script late or requesting validation early can cause this issue.
  5. Fraud - We see a large number of cases of definite fraud triggering this block reason (and not for any of the reasons above).
  6. Incorrect referrer policy - If no referrer policy is set then some browsers default to sending no referrer information in the headers. This is not compatible with API version 1.

Most cases are caused by a combination of the first 3 causes.

Solutions

  1. Prevent navigation off the page until the monitoring snippet responds with a success message.
  2. Fix any implementation issues.
  3. Switch to API version 2.
  4. Use a single page application to delay the validation.
  5. If using APIv1 then ensure the referrer policy is correctly configured.

Implement the Monitoring Snippet

The snippet below can be used to monitor the progress on FraudStop's checks. If the page only allows the user to navigate away if !# statusCode === 201 then this will reduce the number of instances of datapoint missing. When implemented correctly this has the potential to remove datapoint missing as a block reason entirely.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
  EmpelloInterface.onFraudStopLoaded(function (statusCode) {
    if (statusCode === 101) {
      // main JS loaded successfully
    }
    else if (statusCode === 201) {
      // Checks completed, journey can continue
    }
    else if (statusCode === 202) {
      // There was an error
    }
    else if (statusCode === 203) {
      // The JS function timed out
    }
  });

We suggest you do not prevent the user from clicking the button in the event that they click the button before !# statusCode === 201. Instead allow the user to click the button and display a loading icon until !# statusCode === 201.

Fix Implementation Issues

If the datapoint missing percentage is very high (50+% of all clicks blocked for this reason), then this is the most likely reason for the blocks. To fix this ensure the following:

  1. That the script is loaded when the payment page first loads (do not load at a later point in the transaction on the same page).
  2. The FraudStop script is placed first in the <head> section.
  3. That the validation API is not called before the user has confirmed subscription or navigated off the page.

Switch to API Version 2

API version 2 allows the FraudStop script to be delivered upon page load, this gives the browser more time to perform the checks and send the datapoints. Additionally, API version 2 removes the need to register URLs and merchants/services simplifying the process.

More information about API version 2 can be found here. If you are using API version 1 and wish to move to version 2 please speak to your account manager.

Use a Single Page Application

This method may not be suitable in all scenarios, but it should prevent the majority of datapoint missing blocks. If the website (including content) is built as a single page application then you may allow the user to progress to the content immediately after clicking the button but before the monitoring script has returned !# statusCode === 201. The user is charged in an asynchronous manner, only once the script has completed and only if validation is true and the transaction successful. If either the validation or transaction fails, then the user would begin to be denied access to the content.

This method is seamless for users but has the disadvantage of potentially allowing a user to access content for free for a short period as well as additional complexity.

Configure the Referrer Policy

See here for information on how to configure the referrer policy correctly.