What the platforms let you bank

Here is the reported record, platform by platform, in the words the sources use.

• Shopee removes buyer names and phone numbers from orders, and keeps the address so that the seller can still match the order for fulfilment. It applies to all sellers, whether they use Seller Centre, the app or a third-party vendor's software (reported).
• Lazada masks buyer name, address and phone in Seller Center order details, CSV and Excel exports and printed receipts from 12 January 2026, and in its Open Platform API order data from 1 July 2026. Seller-delivered orders keep full details, and seller-delivered merchants can apply for an unmasking exemption (reported).
• TikTok Shop desensitises the recipient's name and phone when platform logistics ship the order. It is desensitisation, not encryption: there is no decrypt call (reported).

In an enabler's warehouse that means an order row with a store, a SKU, a price, a time, and a buyer field that says something like F***l with a phone reduced to its last two digits (that is how the bench renders it, constructed; each platform's own format sits behind the login). You can count orders, sum GMV, rank SKUs and compare stores. You cannot tell whether the F***l who bought on one marketplace on Monday is the F***l who bought on another on Thursday. Sixty-three distinct masked names cover all 8,333 people in the bench's sample.

Somebody in the room will suggest it: "we do not need the phone, just a hash of it; hash it on every platform and join on the hash." A hash is a fingerprint of a value. It lets two systems agree that they hold the same phone number without either showing it. What it cannot do is fingerprint a value that never arrived. Hash "..47" on three platforms and you get the same hash for every buyer whose phone ends in 47.

The bench tests exactly this. In its sample, 265 orders were shipped by the seller and so carried the raw phone and address (constructed, modelled on the seller-delivered exception). Hashing those phones and joining on the hash linked zero pairs: no two of the 265 were the same person, and every other order had no raw value to hash. You can say it in one line: "hashing is not a workaround for masking; it needs the value that was masked."

Read the three rows together and one pattern is plain: in the reported record, every change runs towards less buyer data reaching the seller, never more. Lazada alone moved twice in 2026, first for its seller centre and exports, then for its API. Each platform keeps a different amount, and each has a narrow exception tied to who delivers the parcel.

That is as far as the evidence goes. Nothing read for this page says what any platform will do next, and a roadmap should not pretend to know. The honest planning stance is to build nothing that needs the buyer's identity, treat the seller-delivered exceptions as a narrow slice rather than a door, and put a dated re-check of the masking rules on the feasibility list with an owner's name next to it.

Three numbers carry the whole argument, and each has a sentence you can say out loud.

• 23.3 percent is the best any combination of the keys reaches at customer grain: masked name plus masked phone plus store id, finding 29.2 percent of the real links with 86 false ones. "Our best customer join is wrong more often than it is complete."
• Masked phone alone finds 100 percent of real links, and 370,684 false ones. This is the number that fools people, because "it finds every match" is true. "A key that finds everyone finds everyone else too."
• 100.0 and 97.5 percent: store id at store grain, SKU at SKU grain. "Across platforms, our stores and our products join; our buyers do not."

The phrase to hold on to is impossible, not hard. Hard problems get better with more engineering: better matching, more features, a smarter model. This one has no shared identifier and no raw value to hash, so there is nothing for the engineering to work on. The methods that do link records without a shared key belong to the entity resolution course; the bench shows why they have almost nothing to hold here. And note the honest limit the bench prints: with 8,614 orders the fragments look better than they would at Serai's scale, because false pairs grow with the square of the row count and true pairs only with the count.

Drop the customer and look at what is left, because it is a lot. Serai runs 48 brand stores on three marketplaces in four markets (constructed). Every store has a Serai store id and every listing maps to a Serai master SKU. That means one screen can show the same SKU, on three platforms, in four markets: its price, its sell-through, its return rate, its content, its ad spend, week by week, for Serai's own portfolio.

No single marketplace can show a brand that picture, because each sees only itself. No brand can build it easily, because it would need the same mapping work across every store. It is the real cross-platform moat, and it sits exactly where the bench says the joins hold. Session 5 builds its first product on it.

Look again at the 2.5 percent. SKU grain does not score 100 because 219 lines in the sample sit on listings missing from Serai's mapping table (the missing listings are constructed; the orders are real). Nobody broke anything. A brand launched a variant, a store manager listed it, and nobody added it to the table.

That is what owning a key means. The platforms will never maintain Serai's master SKU; Serai has to. So the feasibility list does not stop at "owned": it names who owns the mapping table and when it is checked. A weekly count of unmapped lines, with a name next to it, is the whole control. Without it, the 97.5 drifts down one launch at a time and the cross-platform view quietly starts under-reporting the newest products, which are the ones brands ask about.

The scale comes from analyst session 1, and it is a finer cut of the three states in the playbook's data gate session, which is where the gate itself is taught.

Gated and closed are both "we do not have it today", and they call for opposite moves. Mixing them up is the most expensive mistake on the list: treat a gated row as closed and you give up a product for want of an email; treat a closed row as gated and you fund a two-year project waiting for a yes that cannot come.

Session 5's most valuable idea is a cross-platform benchmark: how a category performs across three marketplaces and four markets, drawn from what Serai sees running 48 stores. Every number in it comes from data that one platform or one brand handed Serai to do a job. Whether it can be reused to sell something else is not a question the data team answers, and it is not one to answer at launch.

So the feasibility list gives that line a commercial owner (constructed: Serai's head of partnerships) and a date in the first month, for the conversation with the marketplaces' partner teams and the brands. It might end in a yes, a yes with conditions, or a no. All three are cheaper in month one than in month nine.

A leader does not need to read platform terms like a lawyer. They need a list: each thing the roadmap depends on, the obtainability word, who owns finding out, and the date it was last checked. When a line carries a product the business is betting real money on, the owner takes it to counsel to confirm, and the list records that it was confirmed and when.

That is the whole method. It keeps the question where a leader can act on it, in feasibility: can we get it, at what grain, and what would asking cost. It keeps interpretation where it belongs, with the people qualified to give it.