Datapoints and attributes

Datapoints and attributes are single units of data that you use to create rules. They work like variables. There are more than 500 predefined variables that you can choose from and combine to define your rule logic.

info

A datapoint is a key–value pair that represents a piece of information about a transaction. You send datapoints in an API request to represent a single transaction.

An attribute is also a key-value pair that represents a transaction. However, attributes become available as a result of the enrichment process. The enrichment process uses datapoints to make as many attributes available as possible with the incoming data.

You use both datapoints and attributes in rule writing.

Make sure to spend some time and get to know datapoints and attributes better. We designed Discover attributes with one goal in mind: help you get familiar with the building blocks of a rule and use their potential to create powerful logic to catch fraud.

Groups

Datapoints and attributes are arranged into meaningful groups based on their availability.

• Active attributes and datapoints are available for rule creation immediately. You are already sending these datapoints and the corresponding attributes are being calculated.
• Inactive attributes and datapoints are relevant for your business – but not available for rule creation yet. These are datapoints that you can start sending or attributes that you can activate if you start sending the data needed for their calculation.
• Other tab represents the attributes and datapoints not relevant for your business. For example, datapoints that do not belong to your industry or payment method.

Each tab contains items grouped semantically. Groups with extensive amount of data are subdivided further. A sub-group reflects an aspect of a transaction, for example:

• Customer identity
• Payment method
• Shipping address
• E-commerce account

The group Favorites lists the datapoints and attributes you added to favorites. To add an item to favorites, open it and mark the star icon in the upper-right corner.

Naming convention

The name reflects the contents of a datapoint or attribute. Think of a name as a transparent box that makes its contents visible and easy to find.

Names may be short or a bit longer depending on the complexity of an item. We divided each name into 2 or 3 parts and separated each part by a pipe sign |. This name design makes it easier for you to scan and grasp the meaning.

Generally, the names follow this pattern:

Relationship/Logic | Subject/location (Where to find the specifics?) | Specifics (What? When? How often?)

Some datapoints and attributes have a 2-part name. In this case, either the group or the subject part may be absent.

Search

Use one of the available options to find the datapoints or attribute you're looking for:

• Search for an item by name.
• Use the Suggestions tab to pick a keyword and a category.
• Check the Frequently used by you or Frequently used in your account tab. The latter aggregates data usage in your company. and Recently viewed items
• See your search history in Recently viewed.

If you select more than one keyword, Fraugster narrows down the results to show only the items that have all the selected keywords. Examples of keywords are Customer, Email, Shipping address.

Use the search logic operators to combine the search terms accordingly and find exactly what you're looking for.

A datapoint/attribute in detail

Select a datapoint or attribute to view its details. The details include the following information:

• A description.
• The data type it belongs to, for example INT or STRING.
• A list of values it accepts (if the data type is ENUM).
• The logic operators available for it.
• An example (if applicable).

Details include information on availability of every item. Find out whether you're already sending a datapoint, or what data is needed to calculate a specific attribute. Make sure you use only active items in rules, otherwise rules may not hit as expected.

Data types

Each datapoint or attribute has a specific data type. Types determine the set of values it can have.

The following types are available:

Type	Description	Example
string	A sequence of characters representing textual data.	"2662 Main Street"
int	A whole number without a fractional component. Can be positive, negative, or zero.	10117
float	A numeric value with floating decimal points.	19.99
boolean	A logical data type with values true or false.	true
date	The date part of an RFC3339-encoded UTC timestamp.	"2006-01-02Z"
timestamp	An RFC3339-encoded UTC timestamp.	"2009-11-10T23:00:00Z"
enum	A set of values of the same data type.	"DE", "IT", "FR"
pattern	A POSIX regular expression. Used with operators =~ and !=~.	\.*\
array	A set of values. Used with operators in and not in.	["com", "de", "eu"]
shopping_cart_item	An object representing an item in the shopping cart of the customer.	{"item_id": "DF42", "item_desc": "Belt"}
custom	An object that contains a collection of custom datapoints not directly managed by Fraugster. They become available for rule creation only if you send them to the Fraugster API.	{“test”: true, “n”: 42}

Please note: if an item is deprecated, the label appears next to it. We deprecate some variables and replace them with better equivalents as part of an ongoing maintenance effort. You continue to see deprecated items in Fraud Management SaaS, but they should not be used for rule creation. We encourage you to replace a deprecated item in a rule as soon as you can. A rule that uses deprecated variables notifies you accordingly with a dedicated banner.

Case sensitivity and undefined variables

By default, a comparison with a string variable is not case-sensitive. You can enforce case sensitivity by selecting the checkbox .

A comparison with a string that doesn't carry any value always evaluates to false.

In some scenarios it's useful to differentiate between two use cases:

• An item is missing a comparison value all together.
• An item has a value, and this value is empty.

You can achieve this comparison by using the values undefined and empty.

Examples:

• Customer email = undefined

This comparison performs when no customer email was provided at all.

• Customer email = empty

This comparison performs when the email was provided, but its value was empty.

Now that you've learned about rule components, you're ready to write your first rule.

1. Go to Rules and select + NEW RULE to start creating one.
2. In the Rule logic section, you can start creating your own rule from scratch, or create one from a template.

Go to Write rule logic to learn more.