Use when you have to report assistant visibility without dressing it up as rank tracking.
citation-share-reporting.md
You are building a reporting frame for visibility in assistant answers. You are not forecasting traffic or revenue.
The frozen prompt set and how often each prompt is run: {{TRACKED_PROMPTS}}
Logged results, one row per run: assistant, prompt, named or not, cited or not, URL cited: {{RESULTS_LOG}}
Who reads the report and what they decide with it: {{STAKEHOLDER}}
Period being reported: {{REPORTING_PERIOD}}
Produce:
1. Definitions for mention rate, citation rate, cited URL concentration, competitor share and position within the answer. For each, the exact calculation over {{RESULTS_LOG}} and one line on what it cannot tell you.
2. A table for {{REPORTING_PERIOD}}: | Metric | This period | Previous period | Change | Runs behind it | Larger than run to run variation? |
3. Three sentences written for {{STAKEHOLDER}} saying what moved and what it does not prove.
4. A "do not report" list: numbers that look impressive and mean nothing.
Constraints:
- Calculate only from {{RESULTS_LOG}}. Where a metric needs runs that are missing, say what to start logging rather than estimating it.
- Put the run count beside every rate. Never present one run as a trend.
- Do not credit a change to our work unless {{TRACKED_PROMPTS}} was identical across both periods.
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
When should I build a reporting frame rather than report the numbers?
When someone upstairs wants a figure for assistant visibility and the temptation is to present it as rank tracking. This builds the frame, not the data. Run it once you have a few periods logged, then reuse the definitions each month rather than regenerating them and quietly changing the maths.
What do I need in front of me?
A frozen prompt set with its run schedule, and a log with one row per run recording assistant, prompt, whether you were named, whether you were cited and which URL. Metrics are calculated only from {{RESULTS_LOG}}, so a missing column returns advice on what to start logging instead of an estimate.
What comes back, and which column protects me?
Metric definitions with their exact calculation and what each cannot tell you, a period comparison table, three sentences written for your stakeholder, and a do not report list. The column asking whether a change exceeds run to run variation is what stops normal fluctuation being presented as a result.
What is the mistake that costs me?
Crediting a rise to work you shipped. The prompt withholds that unless {{TRACKED_PROMPTS}} was identical across both periods, and rightly so, since assistants change their answers unprompted. Put the run count beside every rate, and never present a single run as a trend however good it looks.