Learn how your product interacts with Two Hat’s Community Sift content moderation platform in three simple steps.
Built with developers in mind, you don’t have to install anything to get started with Two Hat’s Community Sift. Instead, we provide you with an access key and a secure RESTful API, where you send the user id and their message to the Two Hat’s Community Sift server in a simple JSON request via HTTPS.
Two Hat’s Community Sift processes incoming user-generated messages in real-time. The system evaluates messages on a sliding scale of risk and attaches labels like topic(s) (e.g. bullying, sexting, personal information) where applicable. Our system also tracks and adjusts user reputation based on chat behavior, meaning a user’s reputation will influence whether they gain or lose trust in the system. You can configure Two Hat’s Community Sift to change a user’s filtration levels automatically as they move between trusted or untrusted states. Each instance is set up to match the policies, terms, and rules of your company.
You decide what to do next. We return all messages with their assigned risks and topics, enabling you to make a data-driven decision about what to do with the message and how to manage the user.
We send results back as TRUE (recommended action: allow) or FALSE (recommended action: reject) in accordance with your settings, and attach any necessary events like flooding, muting, banning, or trust level changes.
Two Hat’s Community Sift returns this data in a clean JSON format via secure HTTPS. Your servers just have to process the response and take appropriate action. You are in control, and you decide what happens next.
We have done (almost) all the work, so there are just a few things you should have in place to help the setup process.
We use a standard REST-based interface. You should use a standard REST library for your server and implement the commands against it. Some key elements to should look for:
We can roll out Two Hat’s Community Sift over a period that best suits your needs. This way you can budget your dev resources against sprint cycles:
Step 1: Enable ability to make REST calls using any standard library with user_id, message, channel_id
Step 2: Enable ability to say when users join/leave a chat room (if applicable)
Step 3: If a message is inappropriate, enable the potential to drop it, replace it, or take intelligent action with the user (such as warning or sanctioning them)