On March 31, Twitter open-sourced its recommendation algorithm. It turns out to be a standard engagement prediction algorithm of the kind most major platforms use; I explained how these algorithms work in a recent essay. The source code release makes for an interesting case study of social media transparency. Let’s talk about what the code does and doesn’t reveal, from the perspective of trying to understand information propagation and algorithmic amplification on social media.
What’s not in Twitter’s code release
Recommendation algorithms, including Twitter’s, use machine learning. How to rank tweets is not directly specified in the code, but rather learned by models from Twitter’s data on how users engaged with tweets in the past. Twitter can’t release those models or the data needed to train them because it would violate users’ privacy. That means we can’t run these models to see how they rank and recommend tweets. So we can’t actually use the code to understand why a certain tweet was (or wasn’t) recommended to a specific user, or why certain content tends to be amplified (or suppressed). This is an inherent limitation of code transparency on any social media platform.
What Twitter did release is code that is used to train the models, given suitable data. Twitter suggests training them on simulated data. While that would be a valuable exercise for engineers learning how to build high-performance recommender systems, it is of limited value for those of us who want to understand information propagation on social media.
Further, when it comes to trust and safety classifiers—machine learning models to detect tweets that violate Twitter’s policies—even the training code is missing for most categories of policy violations, due to a worry that it can be used to game the system. (Twitter says it will consider releasing more code in this area in the future.) This is a significant omission, because more and more, content that is classified as borderline policy-violating is silently algorithmically downranked (“shadowbanned”) rather than taken down. This has created a major transparency problem.
To me, the most important thing that Twitter revealed is the formula that specifies how different types of engagement (likes, retweets, replies, etc.) are weighed relative to each other. I’ll discuss the formula itself in a second. But first, I want to note that the formula isn’t actually in the code! That’s because it needs to be tweaked frequently and so is stored separately from the code, which is relatively static. Twitter had to separately publish it. This again shows the limits of code transparency.
The code does reveal one important fact, which is that Twitter Blue subscribers get a boost in reach—although, again, Twitter could have simply announced this instead of burying it in the code. (The Twitter Blue webpage does advertise that replies by Blue users are prioritized, but doesn’t mention the boost for regular tweets, which seems much more significant.)
How much of a boost? The scores given to tweets from Blue subscribers get multiplied by 2x–4x in the ranking formula. But it would be completely incorrect to interpret this as a 2x–4x increase in reach. Scores in the ranking formula aren’t interpretable. The way score impacts reach is through a complex user-algorithm feedback loop. The boost in reach for Blue subscribers could be less than 2x or more than 4x: It depends on the user and the tweet. Only Twitter knows, provided they’ve A/B tested it. You can probably see where I’m going with this: Yet again, the code doesn’t tell us the types of things we want to know.
The release of the engagement formula is a big deal
This is the first time a major social media platform has published its engagement calculation formula. Here it is:
To calculate the predicted engagement score of a user with a tweet, the algorithm first calculates each of the probabilities on the left column using machine learned models, multiplies the probabilities by the corresponding weights, and adds them up. Tweets with higher predicted engagement are ranked higher in the feed. (There is a lot more that goes on, but this is the core of it. For the rest of the details, see this excellent explainer by Igor Brigadir and Vicky Boykis. To learn about engagement optimization in general, see my guide to recommendation algorithms.)
The engagement formula is useful both to learn about the overall behavior of the system and for individuals to learn how to control their feed. To be clear, it is far from being sufficient for either purpose. Still, here are examples of the kinds of things that can be learned from it. It appears that Twitter doesn’t use implicit action predictions (such as whether the user will dwell over the tweet, that is, pause on that tweet while scrolling). That’s good: Optimizing for implicit actions will lead to the amplification of trashy content that people can’t help rubbernecking even if they’d never retweet or otherwise actively engage with it. Another significant thing the formula tells us is that the predicted probability of negative feedback (e.g., “not interested in this tweet”) has a high weight. That’s also good: It means you can make your feed better by spending a bit of time teaching the algorithm what you don’t want. It would be far better for platforms to provide more explicit and intuitive controls, but negative feedback is still better than nothing.
Platforms tend to tweak the weights in their ranking formulas frequently, so the table above will only remain useful if Twitter keeps it updated. Interestingly, the file on GitHub has already been updated once since the release of the code. (The table shows the new version.)
One potential risk from open-sourcing is that this information can be used to game the system to amplify some content (or users) and suppress others. It is too early to tell if Twitter’s code release will make this easier. In principle, the gaming risk is not an argument against transparency: There are methods to detect gaming as well as to tweak recommendation algorithms to be more resistant to gaming. Of course, with Twitter having let go of so many engineers, this is easier said than done.
Beyond Twitter: Lessons for transparency
Recommender systems that optimize for engagement follow a well-known template. When a platform implements such a system, releasing the code isn’t that revealing, except to those interested in the technical details. To those interested in the effects of the algorithm, three things are important. The first is the way the algorithms are configured: the signals that are used as input, the way that engagement is defined, and so on. This information should be considered an essential element of transparency, and can be released independently of the code. The second is the machine learned models which, unfortunately, generally can’t be released due to privacy concerns. The third is the feedback loop between users and the algorithm. Understanding this requires extensive research and experiments. Of course, Twitter under Musk fired the algorithmic transparency team and recently essentially shut down even the minimal observational research that was possible through its API. But more broadly, the auditing requirements of the Digital Services Act bring some hope, as do voluntary industry-academia collaborations.
Further reading
- Priyanjana Bengani, Jonathan Stray, and Luke Thorburn describe a menu of recommender transparency options, divided into user-specific documentation, system-level documentation, data, code, and research.
Data is much more important than code here: In general, two models trained on the same data but with different algorithms will behave much more similarly than two models trained on different data with the same algorithm. That’s because the training data contains the patterns in user behavior that algorithms mine and use when recommending new content.
I’ve focused on the “heavy ranker” step of the sourcing and ranking pipeline under the assumption that it has the biggest effect on the overall algorithm.
Arvind Narayanan was the Knight Institute visiting senior research scientist for 2022-2023.