Graph Feature for
DataVisor's Feature Platform
Intro
Graph features provide a way for customers to build complex features that are based on graph engineering - a technique to store and compute relationships across a network of nodes. Today many commonly used products such as search, page rank, AI-based Q&A uses various graph feature engineering techniques.
PROJECT YEAR
PROJECT GOALS
DESIGNER
CLIENT
Feature Research
Low Fid & High Fid
Mockups
Parinitha Marnekar
DataVisor
2022
Problem
In the fraud detection space, supporting graph feature engineering is nascent. DataVisor’s plan to support graph feature engineering should meet the market needs for building complex detection logic efficiently and strengthen its market leader position in innovation in the fraud and risk management space.
Solution
We will have two new operator categories: Relationship, and Graph. Both categories will be supported by graph engineering. Relationships will target less technical users with a more natural business-terms-based UI limited to three degrees of relationship. The graph will target more technical users and allow any number of degrees with a graphical user interface that resembles a graph with nodes and edges.
TECH STACK USED
BALSAMIQ
FIGMA
JIRA
Understanding the Requirements
Building the relationship feature required a lot of back and forth with the Product team - The Product Manager, the UI team, and the back-end Engg team. It was important for us to first lay out what is needed to build this feature.
BUILDING A RELATIONSHIP
Users will be able to build relationships between 4 entities. The first is the source (origin) and the last is the destination (target). The user will be able to choose event types specific to each entity. eg. card_number.
Once the user chooses the source entity from a dropdown list, they can choose the destination entity. This should be different from the source entity or an error message will pop up.
The user has the option to add another entity to the end. If the user adds another entity, this second entity becomes an intermediate entity while the last one (the third) becomes the destination.
CONFIGURING THE RELATIONSHIP
The user will need to configure the relationship by selecting the Operator. We will support All, Last, First, LastN, FirstN. If the user selects All, LastN, or FirstN, they will need to specify the limit.
By default the option “Only unique values will be included” is selected. But the user can unselect it.
The option “Return empty if the actual count is greater than___” allows the user to enter a top value beyond which the relationship would be considered too common to have any significance, for example, Gmail domain. The user can enter an integer. If the actual value is greater than the user-specified value, the feature will be set to Empty.
The user can also specify the time window and conditions here.
If the operator is First or Last, the Time Window option will be removed by default.
BUILDING AN EXAMPLE
To understand how the user can build the relationship between features, we constructed an example below.
We assumed that the user will want to build and 3 hop relationship with the source as card_number and the destination as the snn of all users who have the same master_account_id and phone_number.
This relationship can only be built in a step-by-step manner. This means the user will have to think through the entire flow before building the relationship.
In phase 2, we will make the entities moveable so that the user can move the entities around to create the flow he/she wants without having to delete the entities and re-build them.
Project Objective
An easy and convenient way to build relationships between 2 or more entities and to get a source to destination list.
BUILDING LOW FIDELITY MOCK-UPS OF THE DESIGN
The initial low-fidelity mockups were built in conjunction with the Product Managers and CPO. This gave me a good outline to create in-depth designs keeping the design system in mind.
ITERATION #1
In this iteration, we got a lot of good feedback from the Engg and Product teams.
-
One of the major feedback was that the selection boxes do not seem connected to the entities.
-
Also, the layout seems a bit misleading since we have to configure the relationship and not the entity itself.
-
Giving an option to add filters
-
All this feedback was taken to create more iterations.
ITERATION #2
This iteration had some great feedback as well
-
One of the major ones was if the user will be able to relate the build relationship section to the configure relationships section. It is possible that the user will not know that they will need to configure the relationship. Building it another way may help the user relate it better. We looked into creating it as a tab feature. See final design below.
FINAL DESIGN
.png)
This is the final mock of the design. As you can see, the tab feature works really well here. The user can toggle between tabs as they configure the relationships between entities.
NEXT STEPS
The next step in the design process is to design how the page will look once the relationship feature is created. The user should be able to export lists, nodes, paths or link properties. Below is the preliminary design of how it might look.
Learnings from the Project
The design process for this project required a lot of research as the concept was very new to the fraud space. There was not much competitive research to be done but we did look at the concept being used in other products and used our learnings in building this new feature in the Feature Platform.
The feedback process was closely followed to allow all teams to bring forth their concerns about the design so that the feature can be built with all the feedback in mind. This feature will have a lot of improvements in the future through similar iterative processes.