In 2008, Richard Thaler and Cass Sunstein needed an example simple enough to explain the whole of economic theory from a single application. They used a cafeteria menu.

By moving the fruit to eye level and sending the fries to the periphery, they demonstrated that a slightly adjusted environment could convince thousands of students to make healthier choices. No one is stopped from choosing fries and the fries-loving student still chooses fries. But the undecided student chooses the apple, simply because it is now right in front of him.

In 2017, Thaler was awarded the Nobel Prize in Economics for his body of work, including the development of “The Nudge Theory” with Sunstein. In the years that followed, product teams building mobile applications have taken to referring to any call-to-action on-screen as a nudge.

There are two requirements for a nudge to work reliably. The user should have an apparent desire for the thing they are being nudged toward, and the nudge should appear at the moment when this desire is at its peak.

The first requirement ensures the user has a mental model of the target action, meaning they understand roughly what they are supposed to do. The second requirement serves to remove any extraneous context, ensuring the nudge does not fail due to poor timing.

A checkout confirmation modal shown straight after launching the application will fail miserably as a nudge. The desire to checkout is non-existent at the launch moment, and the context of the action has little to do with the action itself. A tooltip shown after a specific number of unsuccessful attempts to checkout after viewing the cart, however, is a nudge. It has the desired behavior and the right timing.

In the example with Duolingo, the product team has effectively used the framing of an existing streak as a reference point for the next level of engagement. The players who saw streak-based progress notifications increased their retention by roughly the same size as the control group, while the group shown the gain-based notifications saw a far smaller increase.

By framing the progress update as a loss rather than a gain, the notification convinced a large segment of users to stay engaged with the product. It did so by appealing to their psychological need to avoid losses. Loss aversion is useful in streak-based systems because the streak has value and the user has already invested effort into maintaining it.

The same approach used incorrectly fails to persuade the user. An artificial reference point fails to stimulate the desire for progress, and thus a gain-based prompt loses effectiveness.

Once an effective prompt is discovered, it is tempting to use it repeatedly. Once the initial engagement boost has been discovered, the team has an incentive to repeat and scale the finding. It explains the sudden appearance of dozens of notification banners in a single mobile session. However, three poorly timed nudges in a single interaction begin to make the user feel annoyed.

After the third nudge in a single session, the user has already begun to develop an adverse emotional response to the notification. The frustration is no longer targeted at a single prompt, but the entire product. The next time the product asks for an action too soon after the previous request, the user is likely to dismiss the prompt altogether, regardless of its context.

All following prompts in the session will also be subject to the same scrutiny, with the user’s emotions coloring their perception of each nudge.

A detailed breakdown of the nudge from the article, including the four categories and six formats, is provided in the blog post, along with the examples from five industries and 12 use cases.

We shipped a free API Rate Limit Tester to the tools page. Point it at any endpoint and set your request count and concurrency. Then start the run. It tracks 429 responses separately from other failures, so you can see exactly where an API's rate limit kicks in instead of guessing from a support doc.

Response times and throughput update live, alongside a full status code breakdown. There's a CORS proxy field for APIs that block direct browser calls, and export to JSON or CSV once the run finishes. Everything runs client side. Your endpoint and headers never leave your browser, and neither does the request body.

Useful for finding an API's real rate limit before you build around it, or confirming your retry logic actually fires when a 429 hits.

Try it free → API Rate Limit Tester