How the analyst track works
Eight sessions, Python and SQL, on real rows. Tonight is the map. Session 2 conforms three marketplace exports to one schema. Session 3 is the identity gate: which join keys survive the marketplaces' masking, and at which grain. Session 4 writes the per-minute event spec for a live channel, and session 5 turns Stop, Hold, Love, Buy into code. Session 6 follows content through a tagged archive to creator yield. Session 7 writes the metric registry as code. Session 8 is the bench, where the identity ladder and the roadmap sequencer run in your browser on real Olist orders. The stand-in data throughout is the public Olist dataset: real Brazilian marketplace orders, anonymised, which the pages split and mask to look like three marketplace exports. The split and masking are constructed; the orders, and who placed them, are real.
★ What you walk out with tonight. A seven-domain estate map with an obtainability word on every domain, a registry in Python that declares each table's domain and grain and checks the grain against the data, and the habit that saves the most time on an enabler's estate: asking "can we get it, at what grain" before "what could we do with it".
Seven domains, drawn around the work
6 min liveGroup the estate by the work that produces it, not by the system it sits in. Serai's work falls into seven domains, and each one has a different owner, a different source and a different answer to the only question that matters on day one: how much of it can we actually have?
LiveThe seven, and what each one is for4 min▶
| Domain | What is in it | Where it comes from | The decision it serves |
|---|---|---|---|
| 1 · Buyers and service | Masked buyer on each order, chat threads, reviews | Marketplace order and chat APIs, review pages | Service quality, stated objections before purchase |
| 2 · Brands and stores | Contracts, fee terms, store health, decoration versions | Serai's own CRM and store audits | Which store needs attention, what each brand costs to serve |
| 3 · Catalogue and listings | Master SKU, each platform's listing id, content per listing | Serai's catalogue tool, mapped to each platform | The same SKU across platforms, one screen |
| 4 · Orders, fees, settlement | Orders, lines, returns, platform fees, payouts | Marketplace order and finance APIs | Everything with money in it. The spine |
| 5 · Ads and traffic | Spend, creatives, rejections, store traffic | Ad platform APIs; platform traffic reports | Bid, pacing, creative, what to stop spending on |
| 6 · Content and live streams | Asset archive, stream recordings, per-minute events | Serai's studio; platform live dashboards | Which content converts, which host sells |
| 7 · Creators and affiliates | Creator ids, attributed and settled GMV, commissions | Affiliate reports, Serai's network roster | Which creator actually sells, where |
The grouping is this track's own, chosen because each domain has one owner inside an enabler. Your estate may split one or merge two; what matters is that every table you hold belongs to exactly one, and that the domain says who to ask when it breaks.
Self-studyWhy "by the work" and not "by the source system"3 min▶
A map by source system (Platform A, Platform B, the ad manager, the studio drive) is the natural first draft and the wrong one. It puts the same idea in three places, one per marketplace, and it makes "orders" look like three problems when it is one domain with three feeds. Worse, it hides the question of ownership: nobody at Serai owns "Platform A", but somebody owns the catalogue and somebody owns customer service.
By the work, each domain has one owner and one conformed schema, and the three marketplaces become a column called platform. That column is what makes any comparison across them possible, and session 2 builds it.
The buyer is the least obtainable domain, on all three. Public integrator documentation reports that Shopee removes buyer names and phone numbers from orders while keeping the address for fulfilment, that Lazada masks buyer name, phone and address in its seller centre and exports from January 2026 and in its Open Platform API from July 2026, and that TikTok Shop desensitises recipient name and phone when its own logistics ship the order. Seller-delivered orders are the exception on the last two. All three are reported, from integrators' public notes, because the seller centres themselves sit behind a login. Session 3 measures what that does to a join.
Obtainability, not existence
5 min liveEvery domain "exists". The buyer exists, the platform's discovery funnel exists, the minute a viewer left a stream exists. What a roadmap needs is whether you can have it, in what shape, and what it costs to ask. Five words cover every case, and writing one of them on every row of the estate map ends most arguments before they start.
LiveHow to tell partial from full, in one query3 min▶
"Full" and "partial" are easy to claim and easy to check. Take a week of one store's orders from the API and the same week from the seller centre's own summary. If the counts and the GMV agree to the order, the feed is full for that store. If the API returns orders but the seller centre shows traffic, impressions or buyer behaviour the API does not, that behaviour is partial: you can see it on a screen and cannot pipe it anywhere.
Write the test and its date next to the word. A "full" written in January without a test is a hope, and marketplace APIs change their fields every quarter.
Self-studyThis is the playbook's data gate, applied to an enabler2 min▶
The five words are a finer version of the three states taught in the playbook's data gate session (held, held partly, not held). Owned and full are "held"; partial is "held partly"; gated and closed split "not held" into the one you can ask for and the one you cannot. The split matters for an enabler because so much of its estate sits in other companies' systems, and "not held" hides whether the next step is a permission request or a dead end.
Two chains carry most of the value
4 min liveThe domains are not independent projects. Most of what brands will pay for hangs off two chains, and every link in each chain has to exist before the next one means anything. Both chains start in domains Serai fully owns or fully receives, which is the best news on the whole map.
LiveWhy the middle link is the one to fund3 min▶
Orders arrive complete; the regional read is what brands entering a new market will pay for. Between them sits the master SKU mapping: one Serai id per product, mapped to each platform's listing id. Nobody asks for it by name and nothing works without it. Session 2 builds it, session 3 measures what happens when a few percent of listings are missing from it.
On the content chain the middle link is the tag: a persistent id on every asset Serai produces, carried into the listing or the stream, so a later order can be joined back to the asset that sold it. The platforms do not hand back content-level performance in a form you can pipe; the tag is how an enabler builds its own. Session 6 follows it end to end.
Self-studyA chain that does not exist: the single customer view3 min▶
Most enabler strategies draw a third chain: buyers across platforms to one customer, to lifetime value, to cross-platform retargeting. It starts on a closed row. Without a shared identifier and without the raw phone, there is no join key, and the leader track's session 4 explains why that makes the single customer view impossible rather than hard. The bench in session 8 measures it: on real orders, no combination of the keys the exports leave lifts the true match rate past 23.3 percent at customer grain, while Serai's own store id scores 100 percent at store grain.
Write it on the map anyway, marked closed. The most useful line in an estate map is sometimes the one that stops two years of work before it starts.
The estate registry, on seven real tables
★ 22 min · everyone buildsOlist ships seven core tables. Place each one in a domain, declare its grain, and let the data check the declaration. Every number printed below is what the code prints on the public dataset; if yours differs, check the file version first.
Get the data and count the tables. The no-login route is kagglehub. Run from a scratch folder, not inside a repo, so the CSVs do not end up committed.
Write the registry: domain, grain, obtainability, owner. One dictionary, in one file, read by everything later. The grain is a list of columns that should identify a row; write down what you believe before you look.
Let the data check every grain. A declared grain that has duplicates is a wrong belief, and every join built on it will fan out silently.
Fix the one that failed, and write down why. 814 review ids repeat. Look before you drop: 789 review ids are attached to more than one order, so a review is one piece of text filed against several orders. The honest grain is the pair.
Print the coverage by domain, including the empty ones. The empty domains belong in the output. A registry that lists only what you have makes the gaps invisible, and the gaps are where the roadmap's risks live.
Keep the registry in one file and import it. Session 2 reads it to conform the exports, session 7 extends it into the metric registry. Two scripts with their own copy of the grain are two sources of truth, and they will disagree the week somebody fixes one.
Before session 2
30 min- Write the seven-domain map for an estate you work on. Put one obtainability word on every row, and a date and a test next to every "full".
- Run the grain check on three tables you use every week. Most people find at least one declared key with duplicates; bring the count and the reason.
- Find the master product id in your estate, if there is one. If each marketplace's listing id is used directly in reports, write down how many reports would break if a listing were re-created.
- Mark the closed rows on your map and write, next to each, the use case somebody has already proposed on top of it.
Three questions
Clear all three and Analyst session 1 gets stamped in your passport.
1 · Why group the estate by the work that produces the data rather than by source system?
By source, "orders" is three problems; by the work, it is one domain with three feeds and a platform column. That column is what makes any cross-platform comparison possible, and the owner is who you call when it breaks.
2 · Chat access is available on one marketplace only if you apply for it. Which word goes on that row?
Gated and closed are both "not held" today, and they call for opposite next steps. Gated means ask in week one. Closed means stop, and write it down so nobody spends a year on it.
3 · The grain check reports 814 duplicate review ids. What is the right move?
A duplicate on a declared grain is a wrong belief about the data, not dirt. Dropping rows would lose real order-to-review links; the pair has zero duplicates, so the grain is the pair, with the reason written next to it.
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 1 cheat sheet · pin this
You have the map and the registry. Session 2 splits the real Olist orders into three marketplace-style exports, each with its own column names, id formats and masking, and conforms them back into one order schema with a platform column and two mapping tables Serai owns. It is the least glamorous session on the track and the one every later number stands on.