The listing book made money this quarter and the desk wants to talk about the names. The question that should be asked first is duller and much more useful. Would a portfolio that mechanically traded every eligible listing event, with the same sizing rule and the same holding period, have made roughly the same money?
If yes, the desk has been long a market-wide effect and the name-picking was decoration. If no, there is selection skill and it can be sized, monitored and defended. Nobody can tell which one from a P and L, and the difference determines whether the strategy scales, survives a change of personnel, or belongs in the book at all.
The question a review will actually ask
Two versions of the same performance get treated identically until someone forces the decomposition.
In the first, listing events in the period generally produced positive returns and the desk traded a subset of them. Performance is event exposure. It will persist while the effect persists, it does not depend on anyone in particular, and it will disappear when the effect does, probably without warning.
In the second, listing events in the period were roughly a coin flip and the desk's chosen subset materially outperformed the full set. That is selection, it is attributable to a process, and the interesting follow-up is whether the process is written down or lives in one person's head.
The review question is not "did we make money", it is "which of these two happened, and what is your evidence". You need a benchmark portfolio to answer it, and the desk almost certainly does not have one, because nobody builds a benchmark for a strategy that is working.
Building the eligible universe the desk does not have

The benchmark portfolio has four specifications and all four have to be fixed before you look at any returns.
Eligibility. Which events would the strategy have been permitted to trade. Venue set, market type, minimum liquidity, chain coverage, anything your mandate excludes. Write the rule as a filter over the population, apply it identically to the traded and untraded events, and use values as they stood at the event rather than current ones. Applying a current liquidity filter selects the events that went well and destroys the benchmark before you start.
Sizing. Equal weight across eligible events is the correct default because it contains no information. If your live book sizes by conviction, the difference between equal weight and your actual weights is itself a term in the decomposition and you want it isolated rather than baked in.
Holding rule. One mechanical rule applied to every event. Same entry offset from the event stamp, same exit, no discretion. If the live book exits discretionarily, that discretion is a term too.
Costs. The benchmark pays realistic costs, including impact at the size the rule implies. A costless benchmark makes every real strategy look bad and the comparison becomes meaningless.
The decomposition, term by term
With the benchmark built, the book's return splits into four pieces that sum back to the total.
Event beta is the return of the equal-weighted eligible-universe portfolio under the mechanical rule, net of costs. This is what you would have earned by showing up and trading everything. If it is most of the book's return, that is the finding.
Selection is the return of an equal-weighted portfolio of the events you actually traded, under the same mechanical rule, minus event beta. It isolates one thing only, whether the names you chose were better than the average eligible name, holding sizing and timing constant.
Weighting is your actual weights under the mechanical rule, minus the equal-weighted version of the same names. This answers whether conviction sizing helped. It is very often negative, and it is worth knowing, because a desk with real selection skill and inverted sizing is a fixable problem rather than a doomed one.
Execution and timing is the realised book minus everything above. Your actual entry and exit against the mechanical rule's, including slippage, partial fills and the trades that were skipped because nobody was at the desk. This term is where the honest bad news usually is.
Report all four with the number of events behind each. A selection term of two hundred basis points across nine events is not a finding, it is one or two names. The event count is what separates a result from an anecdote, and it should sit next to every term rather than in a footnote.
The two ways this decomposition still lies
The first is universe construction, and it is the failure mode that survives everything else. If the eligible universe is assembled retrospectively from a live feed, it can quietly exclude events on tokens that subsequently died, were removed, or had their rows revised. Every one of those exclusions lifts the benchmark, which makes selection look worse than it was, or lifts both in a way that flatters the whole strategy depending on which side the missing events fell.
The fix is an append-only universe file captured daily, with an event's fields frozen as of the event date and a status field that only ever transitions forward. If you do not have one, say so in the attribution write-up. An attribution with a stated universe caveat is a professional document. One that silently assumes the feed is a historical record is not.
The second is that selection and execution are correlated, which makes the terms less independent than the arithmetic implies. The events a desk chooses to trade tend to be the ones it can get filled in, and the ones it can get filled in tend to be more liquid, and more liquid events behave differently from the population. So part of what shows up as selection skill is really liquidity preference. Test it by re-running the selection term with the eligible universe restricted to events above the same liquidity threshold as your traded set. If selection collapses, you have a liquidity tilt rather than a name-picking edge. That is not nothing, but it is a different thing, it scales differently, and it should be described accurately.
The number to carry forward
Publish the selection term as a running series rather than a quarterly one-off, with its event count, computed the same way every period, and put it in the strategy document next to the capacity estimate.
That series is what makes the strategy reviewable. If the event beta term is large and the selection term hovers near zero across many periods, the desk is a beta harvester and should be resourced, sized and eventually retired as one, which is a perfectly respectable thing to be as long as everyone knows. If the selection term is consistently positive across a large enough event count to mean something, that is the part worth protecting, worth documenting as a process, and worth defending when a bad quarter arrives and someone asks whether the whole thing was luck.