Every other Thursday is a post for paid subscribers about whatever’s on Randy’s mind at the moment and are more exploratory/off-the-cuff in nature.
It’s only been two days since my Unity post, and news keeps piling on as they struggle to do damage control. Bloomberg reported (stupid paywall) that they’re considering a revenue cap of 4% on fees for games that make over $1 million, and won’t be counting previous game installs for the new qualification thresholds. There’s also mention that the install count will be “self-reported”, which sorta hints to me that they also want training data to pull the same shenanigans in the future.
While all this was happening, some people asked me a good question — How does Unity know and enforce the revenue share? How does anyone out there enforce any kind of revenue share?
The world is a very very big place, so I don’t know all the ways that different entities write and enforce revenue sharing agreements. But I’ve seen a couple, and it’s a pretty interesting thing to ponder over. People in tech often think that every problem they solve is some newfangled thing, but splitting revenue is an ancient idea, and it seems that various industries have developed business practices around them.
So first, for the small indies game segment that I’m familiar with, a lot of the rev shares with a developer are often handled by a publisher because the money flows through the publisher to the dev. The publisher is the entity that is usually managing all the store contracts, the distribution, and marketing details. As part of that work, they usually receive money from those retailers (which send one payment for all of the publisher’s games being sold). The publisher then portions out money to the developers appropriately, take out whatever the agreed upon deductible items are, like the publisher’s cut and assorted costs, and then cut a check out to the developer. That check often comes with some kind of invoice that gives a breakdown of how many copies of a game were sold, at what price (which can differ by region/sales), and a time period.
Now, I’m sure you’re thinking that the developer has no way of verifying the truth of the publisher’s numbers. And to some extent, you’re right. No matter how much “proof” a publisher might offer up, from screenshots to pictures of invoices from retailers, all of that could potentially be fabricated. Even in the most hostile and distrustful situations that involve trying to catch the other in a lie, there’s some trust involved to keep business running. The only viable alternative is to accuse the publisher of fraud/breach of contract, and go through full legal discovery.
But what about other places?
Once I was working with a friend who was opening up a franchise dessert shop. There, I had the opportunity to see two other revenue sharing models.
First, there was the revenue sharing model between of the franchisor and franchisee. The franchisee signed a contract to pay a certain percentage of sales revenue to the franchisor in exchange for being able to operate the franchise. How was this enforced? The franchisor contractually required that all franchises use the same point-of-sale service. All the franchises were sub-accounts of the main franchisor account. That meant that every transaction that crossed the register was visible to the central franchise office. Franchise fees would be calculated off reports generated from that PoS system.
The only way to cheat such a system would be to secretly accept payment via some other method and have it not touch the central payment system. Imagine them sneakily taking cash orders on the side to save on that fee.
But even that way of cheating isn’t perfect. Since the franchises also have to purchase certain special ingredients from the central office for trademark menu items, a large gap between official sales numbers and ingredient consumption would look suspicious and probably trigger some kind of investigation. The amount of work involved in maintaining such a fraud wouldn’t really be worth the couple of percentage points of extra profit for the owners. So it just wasn’t worth the trouble to work around, which is about all you can really want out of a verification/compliance system.
The other revenue share model I encountered on that project was from the commercial real estate aspect. A lot of people don’t realize that renting out a retail location is typically not a fixed fee like your apartment rent. It’s usually structured as a kind of revenue share. On the specific contract I saw, the rent was $XXX for the first million in gross sales. After the first million, rent was 8% of top line gross sales from the store. If you did the math, it worked out to mean that they consistently wanted 8% of revenue, but demanded a chunk of it up front as a minimum even if the store wasn’t selling a single item.
Verification was done by requiring that the tenant would regularly submit their financial records to the owner for inspection and invoicing purposes. Cheating under this sort of system largely falls under “keeping two sets of (accounting) books”. Have one book where sales is lower to share for reporting purposes to mislead people, while keeping a different set for the internal owners. It’s a classic, well-known technique because this sort of revenue sharing has been done for ages. It’s even done for tax fraud because that’s also a form of “revenue sharing” with the government.
The technique works because there’s an certain level of trust that such records are accurate. Even the IRS largely takes your filings at face value and tries to corroborate the information with filings from counterparties like one company reporting paying a contractor $900 and the same contractor reports they had received $900. If the perpetrators are good at controlling the recording of finances, they can keep up the illusion for a very long time because things “look about right”. But all it takes is some mistake somewhere to throw a few red flags up, trigger an audit, and unravel the whole thing. It could be a mistake in the accounting/recordkeeping part, but it could also be a mistake of allowing someone who knows too much to blow the whistle to the authorities.
So ultimately, a lot of these systems still rely on an significant element of trust between parties. There’s a mechanism of punishment via various forms of contract and fraud laws which raises the risk of cheating, but some people are still willing to take the risk. And some of those people still get away with stuff every day. But all it takes is the wrong kind of slip-up that draws the wrong kind of attention, and it can all implode very quickly.
I’m sure there are tons of other examples that I simply don’t know about. These aren’t even super sophisticated financial crimes. The difficulty lies in the execution. Which teaches us that when we design such systems, you can’t completely rule out trust, you just have to make it difficult to completely hide the fraud. It definitely makes for interesting design problems.