Secure your business from login to chargeback
Stop fraud, break down data silos, and lower friction with Sift.
- Achieve up to 285% ROI
- Increase user acceptance rates up to 99%
- Drop time spent on manual review up to 80%
After you send in user data, Sift will immediately start assessing your users for risk. You can improve these risk scores by sending feedback about the specific abuse you face. There are a couple ways to do this:
Once you’ve completed all the steps in the Getting Started Guide, you’ll be sending us continuous feedback to keep improving your scores in real time, catching bad users as soon as they appear. For more information on this, see the third section in the Getting Started Guide.
The goal of a Feedback-Only Workflow is to teach you how to create a Workflow in Sift and provide feedback on users through manual review. At the end of this tutorial, you’ll have a Workflow that looks something like this:
This will work by adding each user that meets the criteria of your Workflow to a Sift Review Queue so that you and your fraud team can log into Sift and go through the queue, giving your feedback on whether or not the user appears risky. No real business actions will be taken in your system since this Workflow is only designed to give Sift feedback.
Note: It isn’t necessary to review every risky user. The goal is to give us feedback on a subset of your users in order to more quickly identify and customize our risk scores to your specific fraud.
Feedback-Only Workflows are ideal for people who want to get a sense of how Workflows work without making any code changes in their backend. They are also ideal for people who are passively evaluating Sift's risk scores for a period of time before fully integrating automated Decisions.
You must have integrated with our Events API, which sends data to Sift in order to populate the Review Queues associated with the new Workflow.
First step in creating a Workflow is to determine which key event you want to have trigger the Workflow evaluation. If you already have fraud processes set up, you'll already know when you queue or block users based on risk. Some common examples are:
It should look like this:
Since the goal of the Feedback-Only Workflow is to review highly scored users and tell Sift whether we are accurately identifying your fraudsters, your Decisions should be pretty simple:
The next choice is the category of Decision. There are three available categories:
In this case both of the new Decisions are neither Accept nor Block. So they will both be categorized as "Watch".
Because the goal is to simply give feedback, there is no need to set up webhooks on these Decisions or do any further integration.
The last choice to make is whether you want to make these new decision accessible in Explore. Because these Decisions are designed to be part of a Workflow we are going to allow these Decisions to be taken only through Review Queues.
Our decisions should include this information:
It should look like this:
Every business will have a different threshold that they are comfortable with based on their priorities. At first pick a high score to filter out any good users. If there are too many users scored high you don’t have to review all the users in the review queue. If there are too few you can lower the score threshold to include more orders in the criteria.
You can get a sense of meaningful thresholds from Explore before you pick your initial criteria. In our example we're going to pick a threshold of 75.
It should look like this:
The key aspects of a Review Queue are:
Timeout: Timeout specifies how long a user can wait for an analyst to make a decision in the queue. When a user hits the timeout, the Timeout Decision will automatically be taken on that user. You should set the length of your timeout based on how often you’ll be logging into Sift to go through these queues.
Timeout Decision: Users that are left in the queue for longer than the timeout specified will have the Timeout Decision applied to them. The Timeout Decision helps you clarify what you want to have happen to users when the queue is over-loaded (i.e. do you default to accept or reject?). But for our feedback goals, we don’t mind if a user times out, we just want to make it clear what the user’s status is to other analysts in the console. So we suggest making a Decision like “Skipped”, meaning the user was risky enough to warrant review, but no analyst made a decision on them.
Decisions Available in the Queue: In this case, the analysts only need decisions that tell Sift whether the analyst believes the user is good, bad, or skipped (unsure).
It should look like this:
The last step is to make your workflow live and to add the action for all users that don't match any Route.
It should look like this:
Now, as you send user events that trigger this Workflow, you can go to the Review Tab and view users coming in for review.
It should look like this:
Stop fraud, break down data silos, and lower friction with Sift.