Stop, Hold, Love, Buy as code

Buy is two ratios because a card can fail in two places: nobody taps it, or people tap it and do not buy. Its first denominator is not entries. Product card impressions fire every time a card is shown in the room, so a host who shows the card often gets more chances to be tapped, and the click rate grades what happened on each showing. Add to cart sits in the minute table too, and stays a diagnostic rather than a stage: it tells you where between the click and the order the sale died.

A completer, on Pasar Live, is a viewer who stays past minute 10. The rule is constructed for this story, and so is every rule like it on a real channel: somebody picked the minute. Hold then divides completers by room entries, every person who walked in, including the ones who left in the first ten seconds. That is the point of the ratio. Divide by the viewers still present at minute 10 instead and Hold becomes close to 100 percent by construction, because you have counted only the survivors.

The enabler's twist is that Serai scores many brands' streams on one sheet, and their streams do not look alike. A 30-minute flash sale and a three-hour brand night both meet the same minute-10 line, and that is fine as long as it is the same line for every stream and the sheet says so. The moment one brand team counts "stayed past 5 minutes" because its streams are short, Hold stops being comparable across brands and nobody can see it. Write the rule once, in the stage dictionary, and let every report import it.

A single "orders per live card impression" would be tidy and would grade the wrong people. It folds Stop into the result, so the host with the famous face wins before saying a word. That number is fair for the traffic team, who own the impression, and unfair for a brand's product expert, who owns the room.

Each stage divides by the count the previous team handed over. Traffic hands over impressions, the card turns them into entries, the host turns entries into completers and clicks, the product page turns clicks into orders. A denominator is a handover. Choosing one is choosing which team's output you start counting from, which is why the stage dictionary is a cross-team document before it is code.

• Ratio of sums, 0.96 percent, answers the channel's question: of every person who walked into a Pasar Live room Serai ran, how many ordered? It weights every stream by its entries, so the four platform rooms, holding 38,830 of the 45,720 entries, set most of the answer. Finance, the brand's quarterly review and anything that multiplies by traffic want this one.
• Mean of ratios, 1.71 percent, answers the typical stream's question: if you pick one of these eight streams, how does it tend to convert? Every stream gets one vote, whatever its size. A host coach planning next week, or a brand asking "what should a normal stream of ours do", wants this one.

The rule is short: say which, every time. Put "pooled" or "average of streams" in the column name, not in a footnote. The two can differ by almost a factor of two on the same eight rows, and the reader cannot tell from the number which one you meant.

Split the eight streams by host type and compute both averages inside each group. In the build-along below, the code prints the same value both ways for each type: platform 0.63 percent either way, brand 2.79 percent either way. Inside a host type the rooms are similar in size and in conversion, so the weighting hardly matters. The whole gap between 0.96 and 1.71 came from mixing two populations that behave differently.

That is the practical rule for a scorecard: pool with the ratio of sums, and pool within the groups that are meant to be compared, host type first. A channel-wide number is still worth printing for the channel's own question. It is not a benchmark for any host.

The ratio of sums can be captured by one room. Add a single platform stream with ten times S3's traffic to the table and the channel's conversion would sit almost exactly on that one stream's rate, whatever the other eight did. When one row dominates the denominator, a pooled number is mostly a report on that row.

The mean of ratios has the opposite weakness: a tiny room gets the same vote as a huge one. A hypothetical test stream with 40 entries and 3 orders would convert at 7.5 percent and pull the mean up on its own. The usual defence is a minimum room size for a stream to count in the mean, and that threshold is one more definition to write down once. Both failure modes are why the stage dictionary carries the aggregation rule next to the ratio. Breaking a metric into its parts to see which one moved is taught in the metric decomposition course.

Orders are entries times conversion. Entries come mostly from work the host did not do: the traffic push, the slot, the brand's following, the face on the card. S3 had the biggest room of the eight, 11,880 entries, and sold the most, 71 orders, while converting at 0.60 percent, the lowest on the table (S3 and S4 both print 0.60; S3 is lower in the third decimal). A GMV-only table books S3's host into prime slots, which makes the room bigger, which makes the GMV bigger. The loop feeds itself and never asks whether the host sold.

The North Star divides the room out. It is not "better" than orders; it answers a different question. Orders answer "which room made money", and the brand's finance team is right to ask it. The North Star answers "who turns a room into buyers", and that is the question a host scorecard exists for.

Serai sees what no single brand sees: many brands' streams on one channel. That is the value and the trap. A beauty brand's host and a kitchenware brand's host face different baskets, prices and buyers; a platform host and a brand host face different rooms. The practice for a fair host comparison:

1. Compare within host type and within brand first. Rank a brand's hosts against each other, then platform hosts against platform hosts.
2. Across brands, stay within a category, and pool with the ratio of sums inside it.
3. Never rank across host type, brand or category without saying so on the chart. "Across host types" is a legitimate view for the channel; it is not a verdict on a person.

Holding brand and category fixed properly, rather than by splitting the table, is a fixed-effects model and belongs to the live commerce analytics course linked at the top of the page.

A brand running its own streams sees its own rooms. Serai, running streams for 12 brands on Pasar Live (constructed), can tell a brand what a normal Hold looks like for a brand host in its category, which stage its host is losing, and which minute the room drained. That per-host scorecard, pooled within host type and category, with every stage's denominator on the sheet, is a service line, not a report. It is the "knowing" that the leader track prices.

It only sells if it survives the brand manager's first question: "why does my host rank seventh?" The answer has to be one sentence about a named ratio and a named comparison group, for example "your host's Hold is below the pooled Hold for brand hosts in your category, and here is the minute the room drained", and never "the model says so". Every scorecard row should carry its comparison group as a column. Benchmarks across brands also carry an obligation: show a brand only pooled figures from others, never another brand's own rows.