After two drinks, plenty of founders will tell you the same story: "We crossed a million DAU. By rights we should be rich by now." Then they open the dashboard and the revenue line is basically flat.
I've seen that movie maybe twenty times. A utility app, a content app, something with real eyeballs on it — and a monetization engine that looks like it was bolted on with duct tape. The instinct is always the same: drop an H5 page in there, link out to some affiliate or a third-party checkout, and call it "commerce." Then nothing happens, because H5 never intended to close that loop for you.
The leak you can't see on a dashboard
Here's the thing nobody puts in the pitch deck. When you embed a third-party H5 to "sell something," the user taps in, gets bounced to a checkout that isn't yours, pays someone else, and closes the tab. You captured the eyeball. You captured nothing else. The transaction — and the data, and the relationship — lives with the third party. Your app is a hallway people walk through to get to someone else's store.
A mini-program flips that. It runs inside your own runtime: same login, same wallet, same notification channel you control. The sale happens in your house. The receipt, the re-engagement, the next offer — all of it stays with you. That's the whole game for a traffic app. Not "can I show them a product," but "can I own the transaction."
Why H5 kills conversion (and you'll blame everything else)
Mostly speed. Every H5 open fetches assets, spins, waits for scripts. On a checkout flow that's deadly — people bail at the first stutter. Then there's the trust tax: a web page inside your app that suddenly asks for a card number looks like phishing to a normal human. They close it. You blame the creative. It was the container.
Mini-programs preload and use native components. The checkout feels like it belongs to your app, because it does. Completion rates that were embarrassing on H5 stop being embarrassing.
Where the money actually goes
| Where the money goes | Mini-program (host runtime) | H5 (WebView page) |
|---|---|---|
| The transaction | Closes inside your app, you own it | Bounces to a third-party checkout, you don't |
| The user data | Stays in your runtime | Sits with the third party |
| Re-engagement | Host message center recalls them | Cut off on close; you don't know who they were |
| Compounding | Every service lifts ARPU | One hundred links stay one hundred links |
A hundred links is not a business
The brutal part: even when H5 "works," it doesn't compound. Each page is an isolated island. You can embed a hundred of them and you still have a hundred islands — no catalog, no quality control, no cut. The user sees a menu of strangers.
A mini-program catalog is the opposite. Third parties build on your runtime; you set the rules, take the share, police the experience. Every new service makes your existing users more valuable — more reasons to open the app, more surfaces to convert, higher ARPU. It compounds. H5 shows a storefront; a catalog builds a mall that's yours.
What super-apps figured out a decade ago
Go look at what the big Asian super-apps actually did. They didn't "embed websites." They built a runtime and let thousands of merchants run inside it, taking a slice of every transaction. That's where the valuation came from — not the eyeballs, the commerce layer on top of the eyeballs. A traffic app that only sells attention is renting its audience. A traffic app with a runtime is selling the shelf space, forever.
One honest limit
If your goal is a one-time campaign — drive traffic, convert once, forget — H5 is fine and cheap. This whole argument is for apps that want the user to come back and spend again. For those, the container has to be a runtime, because revenue only compounds when the transaction is yours.
You don't have a traffic problem. You have a "the money leaves before it's yours" problem.
