Jibunu has integrated with CleanID to provide additional data quality services. CleanID is a respondent fingerprinting and fraud detection service that can be added to a survey. More information can be found at: https://www.opinionroute.com/cleanid/.
CleanID’s proprietary algorithm works with your survey, evaluating every device for fraud. It’s continually at work, looking at the hundreds of device and network data points available from each respondent. This intensive monitoring looks for patterns and gets smarter over time.
CleanID focuses on the characteristics of the device. Clean ID uses a combination of 6 different persistent techniques to identify a browser’s device id. Each device is tagged with a deviceID once the call is completed.
CleanID is not enabled on any survey unless requested. To have CleanID enabled on a study, notify the Project Manager. Please note that there are additional costs associated with adding CleanID to a survey. Contact the Project Manager for more details.
Options incude:
- Store the data with no other action taken (default)
- Terminate the respondent based on the result
- Our standard recommendation is allow any score between 0-25 to continue onto the survey/data collection. 26+ would be terminated as higher risk.
- If terminating based on CleanID, Jibunu will also terminate the respondent if the API call is not able to complete for any reason.
Clean ID Data Fields and Values
The following data points are captured from Clean ID and stored in the data file.
Top Level Data
Column Label | Description |
TransactionId | Unique identifier to describe the transaction (unique for that API and client). |
DeviceId | A globally unique identifier for the device. This identifier as well as other characteristics are used to track duplicates. |
Flag Summary
Column Label | Description |
AdBlocker | If TRUE, the device has an adblocker detected. NOTE: This is the only flag that by itself does not increase the score regarding any points towards criticality. |
FlagBlock | If TRUE, CleanID has been blocked by the device in some way. CleanID is not able to get the typical amount of information from that device. We are still able to identify the device for deduplication and we are also still able to see that device’s history along with a reduced set of data regarding their connection type and some device characteristics. NOTE: The existence of an Adblocker could be the reason why ‘FlagBlock’ is tripped. The severity/actions taken by that AdBlocker could be set to an aggressive setting to ‘not run any javascript’ |
FlagWebCrawler | If TRUE, this indicates that an identified Internet bot that is nefarious or has no intention of survey participation has been found. Note: These bots may be good for other purposes, such as indexing the contents of websites such as search engine web crawlers to provide the most up-to-date information available on the web (i.e., Googlebot). |
FlagDataIntegrity | If TRUE, Serious and Sophisticated Device Description and Connection data inconsistencies were found that are more serious than normal User Environment Inconsistencies. |
FlagUserEnvironment | If TRUE, Device, Connection and Software abnormalities within the participant’s digital environment (which they used to connect to your survey) were found. This flag is tripped when bots are found (scripts, local source), malware, or human-based activity that is correlated to fraud. |
FlagDataCenter | If TRUE, this device is coming from a datacenter which is not logically possible for a non-fraudulent survey taking intention. |
FlagTrafficOrigin | If TRUE, this device is coming from a fraudulent or questionable site of origin such as a dark web indicator, TOR network, explicit site/network, or identified fraudulent hosting provider. |
FlagIPIntegrity | If TRUE, the IP address has been compromised and used to generate fraudulent traffic, blacklisted or has bad data integrity based on historical data of known nefarious origins. |
FlagSpoofing | If TRUE, the device has changed aspects of their digital identity or system settings to represent themselves as a legitimate participant. |
FlagTimeZone | If TRUE, the comparision of the IP address’s time zone is different than that of the device. If the input parameter “GeoRestrictionEnabled” is TRUE, then this flag is TRUE if the times are not exactly the same. Otherwise, a TRUE for this flag means the time zone difference is greater than 4 hours. |
FlagVelocity | If TRUE, the device has been seen on the same survey more than 10 times on the same survey. Once triggered, the Ruleset Result will trigger to ‘Bad’. |
FlagCountry | If TRUE, this flag indicates that the country based on the IP address does not match one of the countries specified as input through the “Countries” input parameter. NOTE: This flag requires both the input parameter “Countries” and “GeoRestrictionEnabled” to have input specified. |
RulesetResult | If Good, transaction passes aside from any GeoRestriction offense based on ‘GeoRestrictionEnabled’ being set to ‘Yes’. If set to ‘No’ and RulesetResult=’Good’, score=0 If Warn and ‘In, we evaluate which ‘Flag…..’ offenses and how many. This status would be considered ‘questionnable’. If Bad, the score will be above the recommended thresholds (20, 25, 30) and depending on how many flags tripped, the score increases |
InvalidTrafficType | Device/connection-based type of fraud has been identified. Most survey participants come from digital advertising. As a broad classification, there are two types of device/connection survey-based fraud; GIVT-General Invalid Traffic and SIVT-Sophisticated Invalid Traffic. It is important to clarify ‘invalid’ to be ‘invalid’ for current intent. While both are ‘invalid’ regarding human traffic, there is a real difference in how they exploit the internet infrastructure. SIVT is Sophisticated Invalid Traffic. This type of invalid traffic is most likely a human configuring/manipulating their environment. SIVT consists of more difficult to detect situations that require advanced analytics, multi-point corroboration/coordination, significant human intervention, etc., to analyze and identify. GIVT is General Invalid Traffic. This consists of traffic identified through routine means of filtration executed through application of lists or with other standardized parameter checks. Examples of GIVT include: Known data-center traffic. Bots and spiders or other crawlers. Activity-based filtration. |
Result Data
Column Label | Description |
TimeStamp | Date and time stamp for when the transaction was processed. |
Version | The current release index for CleanID that was used on the transaction. |
TransactionId | Unique identifier to describe the transaction (unique for that API and client). |
Score | The device’s evaluation score. |
ORScore | The ORScore is a value from 0-100 calculating a risk score based on the average of ‘Score’, Status of the surveys taken (Complete or QC) and Frequency. This evaluation is structured the same as the ‘Score’ where anything greater than 25 is bad. This score is based on several other score inputs: the device’s transactional score, “Score” the contextual frequency scores, “DailyFrequencyScore” and “WeeklyFrequencyScore” the QCRate based on both the PanelistId and device’s ID This should be considered the overall score for that transaction as it takes into consideration all known scores and data points. |
Duplicate | If TRUE, this device or panelistID has already been processed for this particular EventId. |
IsMobile | If TRUE, this indicates if the device’s primary data connection is wireless and the device is designed to operate mostly by battery power (e.g. mobile phone, smartphone or tablet). This property does not indicate if the device is a mobile phone or not. Laptops are not classified as mobile devices under this definition and so ‘IsMobile’ will be ‘False’ |
DeviceId | A globally unique identifier for the device. This identifier as well as other characteristics are used to track duplicates. |
Score | This is the numeric score, from 0-100, based on the transactional device information. 0 represents no risk, where 100 represents fraud. The default recommended threshold for this score is 25, so any scores over 25 should be blocked from the survey environment |
DuplicateId | The TransactionId of the original record that was found as a duplicate. |
DuplicateReason | Description of the type of duplicate identified. Those options are: -A record already exists for this device -A record already exists for this PanelistId -A record already exists for this device on event XXXXX -A record already exists for this panelist on event YYYY |
DuplicateRequestId | The RequestId from the original transaction that was identified as a duplicate. |
DuplicateEventId | The EventId that the duplicate was found under is returned in this variable. |
DuplicateTimeStamp | The date and time that the transaction took place originally that the duplicate was matched against. |
DailyFrequencyScore | A numerical 0-100 score that is based on the number of times the device and/or PanelistId has been seen by any CleanID transaction in the past 24 hours since that transaction |
WeeklyFrequencyScore | A numerical 0-100 score that is based on the number of times the device and/or PanelistId has been seen by any CleanID transaction in the past 7 days since that transaction. |
OverallFrequency | Total number of times that the device and/or PanelistId has been seen by any CleanID transaction. |
ORScore | This is the numerical score taking into consideration both the device’s transactional score and the contextual data for this device and or PanelistId. The context takes into consideration the following: -Daily frequency scoring -Weekly frequency scoring -QC rate |
Updated 11/27/24