Analysis pipeline

How collection runs: daily dispatch, batched scrape jobs, callback ingest, reconciliation and rollup.

A run is one pass of your prompt set across the collected engines. This page explains how that work is scheduled and executed, because it determines how quickly your dashboard reflects reality.

The schedule

JobWhenWhat it does
Daily enqueue01:00 UTCCreates the day's scrape jobs for every active prompt × engine
Daily submit01:02 UTCSubmits the queued batch to the scraper
Hourly enqueue / submitEvery hour, at :00 and :02Picks up prompts added since the last pass, and anything the daily run missed
ReconcileEvery 5 minutesChases jobs that were submitted but never called back

Adding a prompt does not mean waiting until tomorrow: the hourly pass picks it up, and the Prompts tab polls while a prompt is analyzing so the row resolves while you are still looking at it.

How a result becomes a number

enqueue → submit batch → scraper runs the real UI → callback with the payload
                                                          │
                                                    ingest-results
                                                          │
              normalize (text, citations, fan-out, surface metadata)
                                                          │
                        deterministic mention extraction (local, no model)
                                                          │
                                  rollup into daily metrics, on ingest

The rollup happens on ingest, not on a timer. That was a deliberate fix: a timed rollup meant dashboards could sit on stale figures while fresh answers were already in the database. Now each ingested answer updates the day's metrics for its engine as it lands, so a tab refreshed mid-run shows the run's progress.

Batching and retries

Work is submitted in batches rather than one job at a time, and each engine has its own concurrency allowance.

Failures are expected at this volume and handled explicitly:

  • Rate-limited batches are retried rather than dropped — losing a rate-limit response used to mean losing the day for that batch.
  • Jobs that never call back are picked up by the reconciliation sweep.
  • A capture that fails to parse is recorded as a failed parse, not as an absence of your brand. This matters: silently treating a broken capture as "not mentioned" would bias every metric downward.

Freshness expectations

EventReflected in the dashboard
New prompt addedWithin the hour, then continuously as answers land
Daily runOvernight, from 01:00 UTC
Content you shippedDays — engines must re-crawl before answers change

The last row is the one to keep in mind. Collection is fast; search infrastructure is not. A page fixed today may not change answers for a week or more, and no measurement tool can shorten that. Judge content work on a fortnight.

Sampling and confidence

Each prompt is run more than once per day per engine, which is what makes a confidence interval possible. Roughly two answers per prompt per day accumulate into a 30-day window of around 60 answers for a single prompt — a Wilson band about 22 points wide, which is too loose to act on. Four prompts on the same subject give around 240 answers and a band near 11 points.

That arithmetic is why prompt allocation works the way it does: depth per subject is fixed and the number of subjects is the variable. Three products measured properly beat six measured badly. See Prompts.

Cost control

Each result carries a recorded cost, so spend is measured rather than estimated. Two properties of the collection model matter commercially:

  • Failed jobs are not billed, so retries are free.
  • Every prompt runs every day. There is no hot/warm cadence quietly downgrading half your prompt set to weekly — a cheaper design that was considered and rejected, because a stale reading is worse than no reading.

The prompt mix you choose sets the daily scrape volume directly: total prompts × three engines, stated in the interface before you commit to it.

Stage two: enrichment

A second pass reads collected answers and extracts what they claim about you — strengths, weaknesses and misconceptions — feeding Brand Perception. It runs off the critical path, so mention-based metrics never wait for it.

Three properties are worth knowing, because they are what make its output trustworthy:

  • Every claim carries a verbatim span from the answer it came from, and the read path drops any claim whose evidence does not literally appear in that answer. An invented theme never reaches a screen.
  • One answer per call. Batching is cheaper and was rejected: claims bleed between answers, and the evidence check then discards claims that are true but attributed to the wrong source — correct information thrown away, with the discard looking like a hallucination.
  • Idempotent. Re-running refines existing themes rather than duplicating them.

Per-mention sentiment and recommendation-strength scoring is a separate pass and is not yet running. See Product status.