Self-regulating contest disputes: This project is an example of the impact an elegant solution can have on a complex problem. That problem, in this case, is human nature.
ArtistCreate Background
ArtistCreate is a music collaboration platform that allows musicians to connect and create music together. One feature of ArtistCreate is a contest, where the contest holder(usually a vocalist) can request an original song. They can then run a contest where musicians from around the world can enter and compete to work with the contest holder. At the end of the contest, the contest holder gets the copyright to the song they select as the winner, and the Artist who wins the contest receives a cash prize.
Disputes
As with many collaboration tools, ensuring that the artwork submitted on the platform does not infringe on copyright can be difficult. Sometimes copyright infringement is obvious, in which case, ArtistCreate can have their Artist Support team remove the submission from the contest and either ban or suspend the Artist who submitted the track in violation. But most reported tracks fall into a grey area. This means Artist Support often has to make judgement calls on what is and is not copyright infringement. As such, Disputes were created as a way for the Artist community to report tracks that they believed were in violation.
How it works
Once an Artist's work is reported, a dispute is created. The reported Artist is notified of the dispute and has a decision to make.
A. If the artist believes they may be in violation, they can concede to the dispute and remove the reported track voluntarily. If they choose this option, the dispute is not reviewed by Artist Support and the Artist faces no concequences. This is done to help manage the workload of Artist Support, as there can often be hundreds of reported tracks each week, and processing disputes is only one of many responsibilities Artist Support has on their plate.
B. If the artist believes they are not in violation, they can challenge the dispute. Artist Support then reviews the reported track. If Artist Support deems the reported track is in violation of copyright, the track is removed and the Artist may be suspended or banned. If the track is deemed not to be in violation, the track is left up and the reported Artist faces no consequences.
Problem statement
Some "less ethical" Artists have figured out a way to use the Dispute system to their advantage. They've begun over-reporting tracks in contests they themselves are participating in, in hopes that some or all of the reported Artists will voluntarily remove their tracks for fear that they could be suspended or banned. This, in effect, eliminates competition and give the reporting Artist a better change of winning the contest.
Ideation
As I began to explore this problem and possible solutions, a few things became clear:
1. The solution cannot create additional manual work for the Artist Support team. Artist Support is stretched thin as it is, and trading one task for another would not be a satisfactory outcome.
2. The solution cannot punish Artists for reporting legitimate, or even borderline copyright infringement. The Dispute system solves a real problem, so to undo that work would be a non-starter.
3. The solution needs to be easily understood by the Artist community. If the system is too complex or confusing, the Artist community will most likely to seek clarification via emails to Artist Support. Some clarification emails are to be expected, but we can limit that surge with clear communications and an intuitive, easily digestable system.
Analogy
As I started to think of possible solutions to this problem, an analogy came to mind. Youtube had similar issues with copyright infringement, and implemented several systems to combat copyright abuse. One of those measures was "Copyright Strikes". To keep it short, if a creator is found to be in copyright violation, they can get a strike against their account. On the first strike, the user is forced to watch a video that details the rules of copyright. The user then has to take what amounts to a quiz to ensure the user understands the copyright rules. On a 3rd strike, the user's account is terminated and they are prohibited from starting another account.
Strike system
The strike system is interesting because it's relatively forgiving. If you get a strike, it serves as a warning. Only when you display a pattern of habitual violation will you face consequences. And because you've been warned, the user cannot claim ignorance of the rules. Ultimately, the strike system is viable because it teaches the community to regulate itself.
Analytics
After speaking with a data analyst at ArtistCreate, we discovered that of only 11% of reporting Artists have reported 3+ times. But reports from that small group make up 86% of all reported tracks. Now many of the Artists in that group are not exploiting the Dispute system. Some Artists are just vigiliant against copyright infringement, and work hard to catch it and call it out. But it's safe to assume that a subtantial amount of bad faith reporters fall into that small group of Artists who report at high volume.
Even just creating a trigger to notify reporting Artists of the strike system (and possible consequences for bad faith reports) could have a significant effect in curtailing over-reporting. Estimates are a reduction in total disputes of between 70-75% overall. That's huge.
Defining consequences
When deciding on the consequences for 3 strikes, it's important to remember one of our guidelines for this system is to avoid creating more work for Artist Support. So instead of banning or suspending Artist accounts, a more balanced consequence would be to revoke reporting privileges for 30 days. Crucially, this wouldn't interfere with the Artist's ability to create music and earn on the platform.
Perhaps on a 2nd or 3rd violation, the Artist may have reporting privileges revoked indefinitely, but we can consider that during a second phase of this rollout.
Minimum Viable Product
1. Initial "strike system" message explaining the the rules and implementation
2. Automated messages to reporting Artist when dispute is marked as "allowed" highlighting copyright guidelines, and 30 day suspension of reporting privileges on 3rd strike
3. Partner with Engineering to create strike tracking on the backend for each Artists admin account
4. Partner with Engineering to create a 30 day suspension of reporting privileges that is automatically trigger on a 3rd strike
Prototyping
Initial "strike system" message
The initial message to Artists trigger when an Artist clicks to begin a report after the MVP roll out. The tone of the message is friendly and concise. It explains why this system has been implemented, how it works, and provides links to help articles for more information. This message is supported by an informational email (sent out a week before rollout).
Automated strike messages
There is slight variation across the 1st, 2nd and 3rd strike messages. All are friendly and focus the Artist towards the copyright guidelines help article. One the 2nd message, we remind the Artist that their reporting privileges will be disabled with a 3rd strike. On the 3rd message, we remind the Artist that the rest of their account will not be effected.
Engineering
Tracking strikes for each Artist and building the trigger to disable track reporting privileges are the final 2 steps in creating this MVP. Engineering will be required to execute both of these tasks. Once completed, we're ready to roll this out to our user base and begin testing.
Validation
To validate whether or not this initiative is successful we can look for a significant drop in total number of Disputes created, month over month. We should also keep an eye on an increase in volume of emails to Artist Support. If this solution does prove successful, the main indicator or that success will be a drastically reduced workload for Artist Support, freeing them up to focus that energy on new tasks.
Conclusion
I learned a lot through the course of this initiative. It's a balancing act when you're looking to implement new features, and it's important to take it slow and acknowledge that small changes to one part of a process can have unseen ramifications somewhere else. Although I did not have a chance to test this solution, I expect some fine tuning would be needed. I would love the opportunity to face that challenge head on and iterate as needed.
Disclaimer
This project has been modified in observance with a Non-Disclosure Agreement. Some elements such as the company name "ArtistCreate" are fictious for presentation purposes.