Implementation worksheet · 6 min read
A Marketplace First-Transaction Activation Playbook
Run two separate playbooks with two separate activation definitions — first purchase for demand, first sale for supply — and add a rule most marketplaces skip: check the other side's state before messaging. Encouraging buyers into a category with no available supply produces a bad first experience and a seller who never appears; pushing sellers to list in a category with no demand produces a listing that never sells and a seller who leaves. The liquidity check belongs in the eligibility conditions for both sequences, which means marketplace lifecycle messaging cannot be designed one side at a time even though it almost always is.
Marketplace lifecycle programmes are usually built by whoever owns growth for one side. Each side's sequence is reasonable alone. Together they can actively work against each other, because the thing that makes a buyer's first transaction succeed is supply that exists right now, and no amount of buyer messaging creates it.
Put it into practice
1. Define activation separately for each side, in transaction terms
Demand: first completed purchase, not first search or first saved item. Supply: first completed sale, not first listing. Intermediate steps are useful signals and they are not activation, because a marketplace with listings and searches and no transactions has not activated anyone.
2. Gate demand messaging on available supply in that category
Before encouraging a buyer toward a category, check there is something to buy. A message driving someone to an empty category costs you the first impression that decides whether they come back, and the fix is one condition in the eligibility check.
3. Gate supply messaging on observed demand
Before pushing a seller to list in a category, check that buyers are looking there. A seller whose first listing gets no views concludes the marketplace does not work, and they are usually right about their category.
4. Make the first transaction as small as possible
The gap between signup and first transaction is the whole problem. Reduce it — a lower-commitment first purchase, a simpler first listing, fewer required fields before going live. Anything that shortens the path to one completed transaction beats anything that improves the tenth.
5. Message the other side when one side acts
A new listing in a category someone was searching is a genuinely useful notification. This is where marketplace lifecycle messaging earns its place, and it only works if both sides' state is available to the same system — which is the architectural reason these programmes are built separately and should not be.
6. Never promise supply or demand you cannot verify
'Buyers are waiting for listings like yours' is a claim you must be able to check. If you cannot, do not make it — an unverified liquidity promise is the marketplace equivalent of an overclaim, and sellers discover it within a week.
7. Handle the failed first transaction as its own path
A cancelled order, a seller who did not respond, a dispute. The user's first transaction failing needs a specific response, not the standard post-purchase sequence congratulating them. This is the highest-value and least-built path in most marketplace programmes.
Two playbooks, one liquidity check
Copy this structure into your review document and record your observed result for each row.
| Side | Activation | Gate before messaging | Failure path |
|---|---|---|---|
| Demand: browse nudge | first purchase | supply exists in category | empty category — do not send |
| Demand: abandoned cart | first purchase | item still available | item gone — different message |
| Demand: post-purchase | repeat purchase | — | order failed — recovery path |
| Supply: complete listing | first sale | demand observed in category | no demand — do not send |
| Supply: first listing live | first sale | — | no views after N days — advice, not congratulation |
| Supply: first sale | repeat sale | — | dispute — recovery path |
| Cross-side: new listing alert | — | matches a recent search | — |
| Cross-side: buyer waiting | — | verifiable demand only | — |
A failure worth checking
The buyer driven into an empty category. A well-built demand sequence encourages a new user toward a category the marketplace is trying to grow — which is exactly the category with the least supply. They arrive, find three stale listings, and form a judgement about the whole marketplace from it. The sequence performs well on click-through and the damage is in a metric nobody attributed to it. One liquidity condition in the eligibility check prevents the entire class.
Common questions
Which side should we focus on first?
Whichever is scarcer, which is usually supply early on. The honest test: if a hundred new buyers arrived tomorrow, could they all transact? If not, buyer acquisition is filling a bucket with a hole in it, and lifecycle messaging to buyers makes the hole more visible rather than smaller.
Is cross-side messaging worth the complexity?
It is the thing a marketplace can do that a single-sided product cannot, and it is genuinely useful when the match is real. The complexity is that both sides' state must be available to one system — which is worth it for the notification that says a listing matching a saved search just appeared, and not worth it for a generic newsletter.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.