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.
★ 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.
A match rate that can report zero
5 min liveA 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.
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.
Both panels, computed in front of you
★ 26 min · the main eventWork 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.
The customer collapses, the store holds
4 min liveFour 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.
LiveFour results, and what each one licenses you to say4 min▶
- 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."
- 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."
- 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."
- 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.
Big for the brand, slow for Serai
4 min liveThe 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.
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.
After the track
30 min- 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.
- 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.
- 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.
- 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.
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.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map.
Analyst session 8 cheat sheet · pin this
That is the end of the analyst track. If you have not done the leader track, start at Leader session 1: the same argument without code, ending in a one-page roadmap and a metric registry a chief financial officer would sign. If you have, put the bench's two gate results and your own crossover on that page, and the roadmap is finished.