learn-ship-ecommerce-enabler-with-phoebe / Analyst session 8 of 8
Ship It: Social Commerce Enablers · Analyst session 8 of 8

The enabler bench

Two panels, both computed in your browser. The first takes 8,614 real orders from the public Olist dataset, splits them into three marketplace-style exports and masks each one the way the marketplaces are reported to, then scores whatever join keys you pick against the real customer, store and SKU ids it has hidden. The second sequences ten use cases for Serai Commerce from one assumptions block you can edit, and a use case that needs a grain the first panel could not join is built and earns nothing. Every number on this page is one the bench prints.

🔴 Capstone Analysts and data leads Anyone sequencing an enabler roadmap 45 min
0-3 · Welcome 3-14 · What the bench measures 14-40 · Build-along: both panels 40-45 · Q&A
Part 0

Where we end up

Sessions 2 and 3 built the exports and the identity gate by hand; sessions 5 to 7 put numbers on the work an enabler does. This page runs both halves of the argument on one screen. The orders are real: which customer placed each one, the zip and city on it, the store and SKU on every line. What is constructed is said on the widget: the three-way split, the synthetic names and phones behind each real customer (Olist publishes neither), each export's masking, the few listings missing from Serai's SKU table, and every figure in the roadmap's assumptions block.

🎫 Clear all three quiz questions to stamp your passport measured = counted from real rows modelled = computed from stated assumptions ★ Build-along = run the bench yourself

★ What you walk out with tonight. A measured answer to the question every enabler strategy skips: at which grain can you actually join the marketplaces? On real orders, the customer stops at a 23.3 percent true match rate and Serai's own store id holds at 100. And a sequenced roadmap whose payback you can defend, including the one input that would make the pricing-first roadmap right.

Part 1 · covers what the bench computes and how it can fail

A match rate that can report zero

5 min live

A match rate is only worth reading if a wrong key can drive it down. The bench counts pairs: two rows that truly belong to the same customer (or store, or SKU) are a true pair; two rows your key puts together are a predicted pair. The score punishes both failures at once.

FROM REAL ORDERS TO ONE SCORE the split and masking are constructed · the orders and who placed them are real 8,614 real orders 8,333 customers 3.0% repeat A · 3,935 orders keeps zip and city B · 2,912 orders keeps neither C · 1,767 orders phone, address if seller-shipped your keys group rows predicted true pairs correct = overlap TP rate = TP / (P + T - TP) Miss real links and T grows past TP. Invent false ones and P does. Either way the rate falls. Masking modelled on public reports: name as first letter, ***, last letter, and the last two phone digits, on every export.
🔍 Click to zoom - the overlap over the union, so a key that links everything scores as badly as a key that links nothing
LiveWhy pairs, and why the union3 min▶

A match is a claim that two rows are the same thing. So the unit of scoring is the pair: every two rows your key groups together is a claim, every two rows that share a hidden real id is the truth. Three counts come out: predicted pairs P, true pairs T, and correct pairs TP, the claims that were true.

Recall (TP / T) alone rewards a key that joins everything: masked name finds all 339 real customer pairs in the sample, and also claims 2,370,747 false ones. Precision (TP / P) alone rewards a key that joins almost nothing. TP / (P + T - TP) is the share of correct pairs among all pairs that are either true or claimed, the Jaccard index of the two sets. It is high only when a key finds the real links and invents almost none.

LiveThe break button, and why every bench needs one2 min▶

Press "Break it" and the bench shuffles the hidden ids across rows, with a fixed seed. The keys are untouched; only the truth is scrambled. If the score measured matching, every grain must collapse, and it does: the best any combination reaches falls to 0.0 percent at customer grain, 0.4 percent at store grain and 0.0 percent at SKU grain. If a grain had held up under the shuffle, the bench would have been measuring the shape of the data, not the join.

Self-studyWhat the sample does and does not represent3 min▶

The sample keeps Olist's real repeat rate: 250 of the 2,801 customers who bought more than once, and 8,083 one-time buyers, the real ratio of 2,801 to 90,557. That ratio matters, because false pairs are made by strangers who collide on a key, and a sample stuffed with repeat buyers would flatter every weak key.

One honest limit points the other way. False pairs grow with the square of the number of rows and true pairs grow roughly with the count, so at 8,614 orders the fragment keys look better than they would on an enabler's full order history. Treat the customer-grain results as a ceiling.

Build-along · the bench

Both panels, computed in front of you

★ 26 min · the main event

Work panel 1 top to bottom with the rungs below, then panel 2. Say out loud what changed before you move to the next rung. The bench recomputes every number from the rows each time you click.

Rung 1, customer grain, masked name only. This is the default. It finds every real link (100.0 percent) and claims 2,370,747 false ones against 339 right ones. True match rate 0.0 percent. Sixty-three distinct masked names cover 8,333 people.

Rung 2, add masked phone. Name plus the last two digits: still 100.0 percent of real links found, false links down to 23,589, rate 1.4 percent. Two fragments multiply their buckets and still collide constantly.

Rung 3, add city + zip. Now the key is never wrong: zero false links. It is also silent on every Platform B order and most of Platform C, so it finds 19.2 percent of real links. Rate 19.2 percent. Precision bought with recall, exactly.

Rung 4, swap city + zip for store id, and look at the best gauge. Masked name, masked phone and store id is the best of all 127 combinations at customer grain: 23.3 percent, finding 29.2 percent of real links with 86 false ones. The gauge says gate shut. Tick hashed phone on its own: 0.0 percent, because the 265 orders that carried a raw phone never include two from the same person. A hash needs the raw value.

Rung 5, switch the grain to Store, then SKU, with store id or SKU ticked. Store id at store grain: 100.0 percent. SKU at SKU grain: 97.5 percent, 17,033 of 17,474 real pairs, zero false. The missing 2.5 percent is 219 lines on listings absent from Serai's SKU table. Both keys are Serai's own, which is why they hold.

Rung 6, press Break it. Every gauge falls: customer 0.0, store 0.4, SKU 0.0 percent. Leave it on and look at panel 2: nine of the ten use cases are now blocked and the hours-first order ends at -$510,867. Only customer service reply drafts, which needs no join, survives. Restore the ids before the next step.

Rung 7, panel 2, the four orders. Hours removed first: $1,372,287 net to Serai after eight quarters, payback in quarter 4. Brand intelligence first: $1,415,738, quarter 3. Single customer view first: $613,747, quarter 6, because its 16 build weeks buy a use case the gate blocks. Pricing optimisation first: $860,315, quarter 6, with $7,310,769 of GMV added for the brands.

Rung 8, find the crossover. Open the assumptions block. Set Serai's GMV-linked fee to 0.06 and pricing optimisation's GMV uplift to 0.06, then compare the orders: pricing first now prints $1,900,438 against $1,612,656 for hours first. The anti-lever is an anti-lever for a business paid mostly in fees. Reset to defaults when you are done.

Part 2 · covers what the identity ladder finds

The customer collapses, the store holds

4 min live

Four results worth taking into a meeting, all measured. Each one is a fact about real orders under a constructed but realistic masking, and each one can be reproduced by anyone with the dataset and the Python reference.

TRUE MATCH RATE, BY KEY AND GRAIN measured on the bench · bar length = rate · dashed line = the 90% gate customer · masked name customer · name + phone customer · + city and zip customer · best of 127 store · store id SKU · SKU 0.0% 100% of links found, 2,370,747 false 1.4% 100% found, 23,589 false 19.2% never wrong, silent on B 23.3% name + phone + store id gate 90% The two bars that clear the gate use keys Serai owns. None of the four customer bars gets near it.
🔍 Click to zoom - the gap between the fourth bar and the fifth is the whole of leader session 4, measured
LiveFour results, and what each one licenses you to say4 min▶
  1. No key combination gets the customer past 23.3 percent. Masked fragments either collide (masked phone finds every real link and 370,684 false ones) or go silent (name, phone and zip is never wrong and finds 19.2 percent). You can say: "on realistic masking, a cross-platform customer join is a guess, not a key."
  2. The hashed phone links nothing. 265 orders carried a raw phone and no two were the same person. You can say: "hashing is not a workaround for masking; it needs the value that was masked."
  3. Serai's own keys hold. Store id 100.0 percent, SKU 97.5 percent. You can say: "the cross-platform view is real at store and SKU grain, today, on our own portfolio."
  4. Owning a key means maintaining it. The 2.5 percent SKU gap is 219 lines on listings missing from the mapping table. You can say: "the mapping table is an owned asset with an owner and a weekly check", which is analyst session 2's job.

For record linkage done properly, with field weights and blocking on millions of rows, see the entity resolution course. The bench asks a narrower question: does a key exist at all.

Self-studyWhy order id links nothing, and why that is a test2 min▶

Order id is unique per order, so at customer grain it claims no pairs and scores 0.0 percent, which is correct: two orders never share one. At store and SKU grain it links the lines inside one order, a handful of true pairs, and scores 0.9 and 7.7 percent. A key that should score near zero and does is the cheapest sanity check a bench has, the same idea as the break button in miniature.

Part 3 · covers what the sequencer finds

Big for the brand, slow for Serai

4 min live

The sequencer is modelled, not measured: every figure comes from the assumptions block and every one is constructed. What it does honestly is carry the logic of leader session 2 through the arithmetic, including the gate from panel 1, so an argument about order becomes an argument about inputs you can see.

SERAI'S RUNNING TOTAL, TWO ORDERS modelled from the default assumptions block · y = 0 is the dashed line Q1 Q3 Q5 Q7 Q8 $0 $1.4M hours first $1,372,287 pricing first $860,315 pays back Q4 pays back Q6 pricing first adds $7,310,769 of GMV, 3.9x hours first, and most of it is the brands' money Same ten use cases, same squad, same eight quarters. Only the order differs.
🔍 Click to zoom - the red line is the roadmap that wins the GMV slide and loses the margin one
LiveThree findings, and the one the bench refuses to rank4 min▶
  • Pricing first returns $511,972 less to Serai and pays back two quarters later, while adding 3.9 times the GMV. Per live week it is worth $992.62 to Serai and $69,230.77 in GMV to the brands; Serai sees 2 percent of that GMV. It pays the brand.
  • The single customer view first costs 16 build weeks and returns nothing, because its grain did not clear the gate. The order ends at $613,747, the lowest of the four.
  • Break the identity ladder and nine of ten use cases stop. Hours first falls to -$510,867. An enabler roadmap rests on its joins more than on its models.
  • Hours first and brand intelligence first are within 3.2 percent ($1,372,287 against $1,415,738). The gap is made of attach revenue the assumptions block stipulates, so the bench does not rank one above the other. The case for hours first is certainty: it needs nobody's permission and no buyer, which leader session 5 builds on.
Self-studyWhen pricing first is the right answer3 min▶

The anti-lever carries its own limit, and the bench shows it. Raise Serai's GMV-linked fee to 6 percent and the pricing uplift to 6 percent, and pricing first overtakes hours first, $1,900,438 against $1,612,656. At a 10 percent share it wins from a 4 percent uplift. An enabler paid mostly as a share of GMV is a different business, and for that business the order flips.

This is the playbook's sequencing rule made visible in a single input, and it carries the playbook's status: a working heuristic, uncited, which the bench demonstrates on invented numbers and does not prove about any real company.

Homework

After the track

30 min
  1. Run the same pair scoring on your own three exports: count true pairs by the id you trust and score your best customer key. Write the number next to the single customer view on your roadmap.
  2. Replace the assumptions block with your own team sizes and fee split, one line at a time, and write down which input moved the order the most.
  3. Find your crossover: the GMV-linked fee share at which pricing first would win for your business. If it is below your real share, your roadmap should start somewhere else.
  4. Take the leader track's one-page roadmap and put the bench's two gate results on it: the grain that holds and the grain that does not.
Check yourself

Three questions

Clear all three and Analyst session 8 gets stamped in your passport.

1 · Masked name finds 100 percent of the real customer links. Why does it score 0.0 percent?

Sixty-three masked names cover 8,333 people, so the key puts strangers together constantly. Recall alone would call it perfect; the union in the denominator is what makes a key that joins everything score as badly as one that joins nothing.

2 · The break button shuffles the hidden ids. What does it prove when every grain falls to near zero?

The keys do not change when the ids are shuffled; only the truth does. A grain that held up under the shuffle would mean the bench was rewarding something other than matching. Nothing holds: customer 0.0, store 0.4, SKU 0.0 percent.

3 · Under the default assumptions, pricing optimisation first adds the most GMV of any order and returns the least to Serai after the single customer view. What would make it the right first move?

Pricing's value lands in the brand's GMV, and Serai sees only its share. Raise the share and the same GMV becomes Serai's margin. The anti-lever is an anti-lever for a fee-based enabler; D overstates it, which is its own kind of error.

Sources covered

What this session teaches, and where it came from

✓Pair-based scoring of a join: recall, precision and the Jaccard rateComputed in the browser and in the Python reference; both print the same counts to the pair
✓The identity ladder on real ordersBrazilian E-Commerce Public Dataset by Olist, Kaggle, CC BY-NC-SA 4.0; split, masking, names and phones constructed and labelled on the widget
◐Marketplace buyer masking patternsReported, from public integrator documentation for Shopee, Lazada and TikTok Shop; the bench's masking is modelled on them, not copied from any platform's API
✓Sequencing by hours removed, with a data gateApplies the playbook's revenue-model rule and its data gate; every figure in the assumptions block is constructed
◐Probabilistic record linkageNot taught here; the entity resolution course owns field weights, blocking and clerical review

Every fact on this page, and its verification tier, is recorded in the course's source map.

Analyst session 8 cheat sheet · pin this

Score pairs, over the unionTP / (P + T - TP). A key that joins everything scores like one that joins nothing.
Customer grain: 23.3% at bestMasked fragments collide or go silent. A guess, not a key.
Your own keys holdStore id 100.0%, SKU 97.5%. The gap is unmapped listings: maintain the table.
A hash needs the raw value265 raw phones, zero links. Hashing is not a way round masking.
Break itShuffle the truth; every grain must fall. If one holds, the bench measures shape.
Pricing pays the brand$7.3M of GMV, $511,972 less to Serai. Until the GMV share is large.