Use-case

This guide is written for online travel agencies (OTAs), airlines, hotels, train operators, car rental companies, and others to use as they begin integration. Use the Sift platform to get a clear view of good and bad users in order to reduce fraud as well as checkout friction.

Sending Data to Sift

Send User Activity
Send Key User Events
User creates an account
You interact with a payment gateway
  • Send a $transaction event for each payment gateway interaction, as well as each other payment method accepted for the order (e.g. points).
  • When a payment gateway informs you of a chargeback, send a fraud label.
User purchases a reservation
  • When a user purchases a reservation, send a $create_order event, taking advatage of all '$items' fields you can, such as:
    • '$category' : e.g. 'flight' / 'hotel' / 'car_rental' / 'train'
    • '$brand' : e.g. 'United Airlines' / 'Holiday Inn' / 'Enterprise' / 'Amtrak'
    • '$product_title' : 'First class' (ticket class, etc.)
  • Send custom fields on the $create_order to capture differences between users and reservations. For example:
    • 'website_brand' : e.g. 'hotelsrightnow.com', 'airplanestomorrow.com' (if you operate multiple brands)
    • 'site_language' : e.g. 'ES', 'FR', 'PR' (if you operate in multiple languages)
    • 'order_source' : e.g 'web' / 'iOS' / 'Android'

    • If you offer Flight reservations:

    • flight_days_to_departure: number of days as an integer from when the order is placed to when the flight departure date is. Booking with departure within 24 hours will have value of 0. Optionally use flight_hours_to_departure if more appropriate.
    • flight_duration: in hours for total travel time as an integer.
    • flight_route: send the departure and final arrival airport codes for the route, e.g. SFO:MAD, in $create_order.
    • flight_departure_time: A unix timestamp in milliseconds representing the departure date and time
    • flight_departure_day: Send a three letter string representing the day of week (e.g. mon, tue , wed).
    • flight_departure_hour: Send an integer between 0 and 23 for the hour of departure as an integer.
    • flight_departure_week: Send an integer between 0 and 51 representing the week of the year of the flight to help capture seasonal trends
    • flight_departure_country: if you offer both domestic and international travel, US, ES etc.
    • flight_destination_country: if you offer both domestic and international travel, UK, MX etc.
    • flight_country_pair: If you offer both domestic and international travel, send the departure and arrival country as a pair, e.g., US:UK.
    • flight_departure_airport: The IATA 3 letter airport code for the departure airport.
    • flight_arrival_airport: The IATA 3 letter airport code for the arrival airport.
    • flight_num_segments: Total segments for the trip as an integer. A one-way direct flight will have value of 1.

    If you offer Train reservations:

    • train_days_to_departure: number of days as an integer from when the order is placed to when the train departure time is. Booking with departure within 24 hours will have value of 0. Optionally use train_hours_to_departure if more appropriate.
    • train_duration: in hours for total travel time as an integer
    • train_route: send the departure and final arrival station codes (or names) for the route in $create_order, e.g. Fenchurch:Liverpool
    • train_departure_time: A unix timestamp in seconds or milliseconds representing the departure date and time
    • train_departure_day: Send a three letter string representing the day of week (e.g. mon, tue, wed).
    • train_departure_hour: Send an integer between 0 and 23 for the hour of departure as an integer.
    • train_departure_week: Send an integer between 0 and 51 representing the week of the year of the train departure to help capture seasonal trends.
    • train_departure_country: If you offer both domestic and international travel, US, ES, etc.
    • train_arrival_country: If you offer both domestic and international travel, UK, MX etc.
    • train_country_pair: If you offer both domestic and international travel, send the departure and arrival country as a pair FR:UK.
    • train_arrival_station: station code or name
    • train_departure_station: station code or name

    If you offer car rentals:

    • days_to_rental: the days as an integer from when the order is placed to when the rental pickup day is. Same day booking will have value of 0.
    • rental_duration: in days for total time vehicle is booked.
    • rental_pickup_time: A unix timestamp in seconds or milliseconds representing the pickup date and time
    • rental_pickup_airport: if the pickup is at an airport, then send the IATA 3 letter airport code
    • age_group : 'under 21' / '21-25' / '25+'
    • purchased_insurance e.g.: liability only, liability + collision, personal chauffeur

    If you offer hotel reservations:

    • hotel_rating: 5-star, 4-star, etc.
    • hotel_checkin_airport: if the hotel is at an airport, then send the IATA 3 letter airport code
    • hotel_duration: The number of days the reservation is for
    • days_to_checkin: Number of days as integer from order date to hotel check-in day. Same day bookings will have a value of 0.
    • hotel_address_city
Additional Events

The following events can be sent to capture a more complete picture of users when applicable: $update_account, $login, $logout, $chargeback. When a user performs a search, you can send a custom event flight_search, hotel_search, etc.

Send Business Decisions

Whenever your automated systems or analysts take action, send those actions into Sift as Decision events. Actions range from positive (eg Approve Order), to neutral (Flag Account), to negative (Ban User). The key thing is that you should send all Actions you take to Sift, not just your negative actions.

Set up your Business Decisions

In order to send Decision events you'll first have to create the specific Decisions your business takes in the Sift Console. While we start all accounts out with a few generic Decisions, Decisions are fully customizable so you can create a Decision for every action that your business takes. Some examples of Decisions are:

  • Ban Account (Block Category Decision)
  • Cancel Order (Block Category Decision)
  • Flag for Additional Review (Watch Category Decision)
  • Approve User (Accept Category Decision)

See the Decisions tutorial for more context.

During your integration, you should send the Decisions that your business is currently making through any internal fraud engines or Manual Review processes to the Sift Decisions API. If you currently do not have in-house fraud logic or a manual review process, work with Sift to setup your initial Workflows within Sift's platform.

Get Started with Sift Scores

When you are initially integrating with Sift, your scores will be based on whatever data you’ve sent us. So if it is a brand new integration with no backfilled data, Sift will need a week or two of data to learn your unique fraud patterns. One of the key strengths of the Sift platform is that it consistently learns as you send more and more data to it. You should see a substantial increase in accuracy of your scores during these first weeks as you send more Decisions and User Events.

During this stage, you should be assessing your Sift Scores in the Sift Console and determining which actions you want to take for different score ranges. Since all businesses are different, finding your unique score thresholds that achieve your business goals is key.

To reduce the amount of time required in this initial learning phase, you can send a historical backfill so that Sift can learn about your user's fraud patterns.

Build Your Business Logic With Sift Scores

Now that you sending both user events and business decisions to Sift, you’re ready to start using Sift Scores in your business logic. At this point, you’ll have an understanding how scores correlate to different levels of risk. Based on the user’s risk score, you’ll set up different outcomes within your application (eg users with low score are automatically approved).

To build this logic, you'll want to evaluate a user's Sift Score at the key events where bad users can hurt your business or good users can have a more frictionless experience. You’ll likely be making this check at $create_order.

The two ways to use Sift Scores:

  • Create a Sift Workflow: Sift Workflows give you a powerful way to automate your Decisions without having to write business logic on your side. Workflows let you set up rules that gets evaluated whenever specified events occur. These rules enable you to route users to different outcomes based on Sift Score and other attributes of the user and transaction (eg User is from Canada, Order is greater than $500, and Sift Score is greater than 80). With Sift Workflows, you also get Sift Review Queues for fast, easy investigation so you won’t have to build your own queues. To learn more, see our Workflows documentation.
  • Build application logic in your system: You can synchronously request the Sift score of a user with any event you send to Sift. This score will take into consideration all data you’ve sent to Sift including the event you just sent. Sift Scores should only be requested at the key events where fraud or abuse occurs (eg ask for score when sending a Create Order event) To learn more, see our API documentation

Any questions? We're happy to talk it through.