Tip rate was flat for years. A flat dollar moved it 20%.

The platform ran on tips. The tip ask was a percentage. The rate hadn’t moved in years.

Donations go to the cause in full; the platform is funded by an optional tip added at checkout. The ask was a percentage slider with a default in the mid-teens. Tip rate — the share of donors who left anything — had been flat through several redesigns of the checkout.

Everyone had a theory. The default was too high. The default was too low. The ask came at the wrong moment. Donors didn’t understand where the money went. None of the theories had been tested against each other, and the team had one engineer for the surface.

Is the amount the problem — or does a percentage read as a tax, and a dollar as a contribution?

Three hypotheses were on the table: the amount was wrong, the moment was wrong, or the framing was wrong. I put framing first for two reasons. It was the cheapest to test with one engineer. And the existing data pointed at it: tip rate fell as donation size rose. A percentage scales with the gift, so a generous donor sees the biggest tip. If amount were the whole story, the drop should be smooth. It wasn’t — it stepped.

The prediction, written before the test: if framing is the problem, flat-dollar options will raise tip rate without lowering average tip amount — the same money reads differently. If amount is the problem, rate rises only where the dollar options are cheaper than the old percentage default.

Segment by gift size. Test one bucket. Read it properly before touching the rest.

I split donors into four gift buckets and ran flat-dollar options against the percentage default in one of them. The $20–40 bucket had the volume to read a result in weeks and the widest gap between what the percentage asked and what donors actually left.

Ship flat-dollar for $20–40 first. Everything else became a v2 hypothesis, not launch scope.

The bucket cleared significance in the first read. I recommended shipping it to 100% of that segment and holding the other three buckets as explicit, written hypotheses — each with the number that would confirm or kill it — rather than extrapolating.

One engineer, about two weeks of build. The segmentation logic that decided which donors saw which ask became the skeleton for the recommendation engine in v2.

+18% in the first bucket. +20% overall once the ask was sized per segment. The $1M is a projection.

Average tip amount held — the rate moved, the money per tipper didn’t fall — which is what the framing hypothesis predicted and the amount hypothesis didn’t. Donation size was unchanged, so the tip wasn’t cannibalising the cause.

I brought a restaurant prior to a donation checkout.

My starting assumption was that mid-teens percentages would feel normal because tipping culture had normalised them. That’s true at a restaurant, where the percentage is on a service you received. Here the percentage sat on money meant for someone else. Donors read it as the platform taking a cut of the cause. The data corrected the prior in week two; I should have questioned it in week zero.

I also assumed the four buckets would respond in the same direction. They didn’t, which is why the other three stayed hypotheses instead of becoming launch scope.

The second pass turned the segmentation into a tip recommendation engine: gift size plus the behavioural signals that predicted tipping, used to size the default per donor. That is what took the programme from +18% in one bucket to +20% across the treated segments, and it laid the groundwork for the team’s move to ML. The $0–20 bucket and the timing of the ask are the two hypotheses still open.