Home / Recipes / Compare how two markets covered the same event
Worked queryCompare how two markets covered the same event
/search in semantic mode. The parameters matter less
than the reasoning behind them, so that is most of what is below.
The request
GET /search?q=<event>&mode=semantic&language=<a>&from=…&to=…
GET /search?q=<event>&mode=semantic&language=<b>&from=…&to=…Why these parameters
The one recipe here that deliberately does not collapse to stories. When you are studying how framing differs, the individual articles are your data and clustering destroys exactly what you are trying to measure. Run one query per language over an identical window so the comparison is like for like.
The obvious approach, and why it loses
The obvious approach is one query with both languages included and a comparison drawn from the mixed result set. It collapses the only structure that matters: you can no longer tell whether a theme appearing more often reflects a market's framing or simply that market having more indexed outlets. The other shortcut, collapsing to stories and comparing cluster counts, answers a different question — how many events were covered — when the question here is how each event was written about. Two separate un-collapsed queries over identical windows keeps the unit of analysis explicit, which is the part a reviewer will ask about.
When it returns too much, or too little
Too much means the window is wide enough to include several events, and the comparison then mixes framing differences with agenda differences. Narrow to the event. Too little in one of the two markets is a finding rather than a problem, and the temptation to widen only that side is the single most common way this analysis goes wrong — hold the windows identical even when one comes back nearly empty. If volumes differ by an order of magnitude, normalise against each market's total output over the same window before comparing anything, and say so when you report it.
How you would know it is working
Test the method on a case where the answer is already known — an event whose coverage difference between two markets has been documented — and see whether your procedure reproduces it. If it does not, the problem is usually the outlet set rather than the retrieval. Then run the same comparison on a neutral event that should show no difference; anything the method finds there is your noise floor, and any real finding needs to clear it. Both steps take an afternoon and they are what separate a comparison you can publish from one that will not survive a question about press size.
When this is the wrong tool
Comparison across markets is the analysis most likely to produce a confident wrong answer, because so many things differ at once. Press size, publication rhythm, syndication density and editorial convention all vary by market, and any of them can produce a difference that looks substantive and is structural. Normalise for press size before comparing volume, hold windows and outlet sets constant, and be sceptical of any finding that survives only one framing. This recipe is also not suitable for automated monitoring — it needs a person deciding what the comparison means, and a scheduled version of it will produce a time series whose movements are mostly artefacts.
Running it for real
Response fields, failure modes, adaptations and scheduling cost: Compare how two markets covered the same event, in the docs.