Seasonal prompts and AI visibility: keep seasonal buying questions apart from your always-on set

To track seasonal buying questions without distorting your always-on numbers, put them in their own segment: give every seasonal prompt a dedicated tag, write down the dates the season starts and ends, and compare each season only with the same season (or a documented pre-season period), never with an arbitrary neighbouring month. Keep the always-on set as a separate, steady group. If you pool the two, your headline trend can move because the mix of questions changed, not because AI engines changed what they say about you.

In short

• A seasonal prompt is a question whose relevance rises and falls with the calendar. Its answers are not comparable with an always-on prompt's answers, or with the same prompt in the off-season.
• Tag seasonal prompts so that a tag filter or breakdown separates them from the always-on set.
• Decide the season's start date, end date and comparison period before the season opens, and write them down.
• Compare a season with the same season a year earlier, or with a pre-season reading of the same prompts, not with an arbitrary neighbouring month.
• Read the seasonal segment on its own numbers, and check the sample size before you read a rate.

What is a seasonal prompt, and why does it break a trend?

A seasonal prompt is a tracked question that only matters, or matters far more, during part of the year: a compliance deadline, a budgeting round, a holiday, a procurement cycle. An always-on prompt is one whose relevance does not depend on the calendar.

The trouble is composition. A brand visibility number is a share of analysed answers, so it reflects which questions you asked as much as how engines answered them. When a seasonal batch of prompts joins the pool, the average moves even if every individual answer stayed the same. The Prompts page describes a prompt as a full question stored as its own row that DiscoveredBy actually runs against the engines you track. Adding prompts changes which answers your metrics are calculated from.

There is a second possible effect. The engines' answers to a seasonal question may themselves shift in season. We cannot tell you that they do, or by how much, and this post does not claim it. What you can do is compare any change you see against the right baseline.

Enlarge image

How do you tell seasonal prompts from always-on prompts?

Ask whether you would still want this question answered in the quietest month of the year. If yes, it is probably always-on. If the honest answer is "only around a deadline, an event or a buying cycle," it is seasonal.

Use these tests as a first pass, then record your decision in the calendar below.

• The question names an event, date, deadline or holiday.
• Your own sales or web data shows the topic clustering in certain weeks.
• The buying trigger is external and repeats every year (a filing date, a regulatory cycle, a fiscal year start).
• The question would look odd to a buyer outside the window.

Some prompts sit between the two. Keep a borderline prompt in the always-on set and note it, because moving prompts between segments later changes the population of both. If you review your whole list, audit your prompt list before adding more prompts covers that pass.

Which product features do you need?

Three product features carry this method: tags, pause and resume, and the Explorer. The docs describe each of them, and nothing here assumes a dedicated "seasonal" feature.

Tags. A tag is a short, project-scoped label you attach to a prompt. You can create one from the settings screen or by typing a new name in the prompt editor, and you can filter by tag on the screens that take the filter bar. The docs describe create and delete but no rename, so pick the name carefully. See Tags and keywords. The Explorer has a tag dimension too, so you can break a metric down by tag or filter to one.

Pause and resume. Pausing a prompt stops its future scheduled runs while preserving its history and country targets, and activating it resumes them. Resuming checks your plan's available prompt slots, and paused prompts do not use one. Owners and editors can do both in bulk from the Prompts list (Prompts, Organize a selection). Depending on your plan, the slot count may decide how many seasonal prompts you can run at once; see plans and limits.

The Explorer. It builds a chart from a project's collected answers with a window, a time grain, filters, breakdowns and a comparison. The Explorer page lists what it can and cannot do, and the details below come from it.

The docs describe no per-prompt schedule, so a season's start and end are dates you keep in your own calendar and act on by hand. A prompt is scheduled by the platform's daily job as long as the project, the prompt and the target are all active.

How do you build the seasonal segment?

Build it in five steps, in this order.

1. Create a dedicated tag for each season, named so it sorts and reads well, such as season-year-end-audit. Use one tag per season, not one "seasonal" tag for everything, so each season stays separable.
2. Attach the tag to the seasonal prompts only. Do not also attach your always-on cohort tag to them. The Explorer counts a prompt once under each of its tags, so tag rows overlap and do not add up to the total.
3. Write the dates: pre-season start, season start, season end, review date.
4. Start collecting before the season opens. This gives you a pre-season reading of the same prompts, which is your fallback comparison if you have no history from last year.
5. Pause the prompts after the season ends, and record the date. Their history stays, and the Explorer still counts paused prompts that have answers in the window. Pausing also changes the mix of prompts that are running, and the docs warn that alerts comparing a window before a pause with one after it can react to that change of mix rather than to anything the engines did.

A note on timing. The daily job enqueues one run per active prompt target on each engine that target runs on, so a target gets about one scheduled answer per day per engine (a run started on demand can add more). A short season yields a small sample, so check the observation count before you read any rate.

The docs mark any rate or position built from fewer than 30 observations as provisional. They also say that the sample is too small to read as settled (Metrics defined). Suppose a four-week season has a dozen prompts, each with one target (one country, the General audience, one language) on a single engine. The daily job alone would give about 336 answers (12 prompts times 28 days), and fewer if any run fails or is not yet analysed; a season with three prompts would top out at about 84. Do that sum before you promise anyone a seasonal figure. Adding countries, cities or engines adds observations but also splits them, so read each cut on its own count.

Which comparison period is fair for a season?

The fair comparison is the same prompts in the same season a year earlier, and where that does not exist, the same prompts in a pre-season period of equal length that you defined before the season opened. Do not compare a peak-season window with whichever month happens to come before it.

The Explorer offers Previous period (the same number of days immediately before the window) and Last year (both ends moved back 364 days so weekdays and ISO weeks line up). For a seasonal segment:

• Last year is the natural choice for a season that ran last year, provided the prompts were running then. If the season's dates move from year to year, set the windows on the actual season dates rather than on the calendar weeks. A row that had answers only in the earlier period has no row in the result, and prompts that were not yet tracked have no earlier answers to compare with.
• Previous period is a pre-season comparison only if the previous period is your pre-season window. Set a custom start and end (a custom window can be up to 366 days, ending yesterday or earlier) rather than trusting the 7, 28 or 90 day presets to fall on your season's edges.
• With a comparison on, the change is shown in percentage points for a rate. It is empty when either side has no value.

Also check who was collecting. A comparison uses the engines you select in both periods. If you added an engine between the two seasons, pooled results include it on one side only. Break the result down by engine, or filter to one, to compare like with like. For a related discipline, see use a fixed prompt cohort for month-to-month comparisons.

The seasonal monitoring calendar (copyable)

Fill in one row per season. Keep it with your reporting notes so the next reader can see what was running and when.

A plain-text version to paste into a doc:

SEASON: <name>
TAG: <tag>
PROMPTS: <count> | COUNTRIES/CITIES: <list> | ENGINES: <list>
PRE-SEASON: <start> to <end>
SEASON: <start> to <end>
COMPARE WITH: <same season last year: dates> OR <pre-season window: dates>
PAUSE ON: <date>   REVIEW ON: <date>
CHANGES DURING SEASON: <date, what changed>
OBSERVATIONS AT REVIEW: <analysed answers in the seasonal window> (provisional if under 30)
NOTES: <text>

Worked example: Quillstone's year-end audit season

Quillstone sells document-review software to legal and compliance teams. Its always-on set covers everyday questions, such as which tools review contracts. It also adds a seasonal set of prompts about year-end audit document review, tagged season-year-end-audit, that it starts before the season opens and pauses when the season ends.

Suppose that in an off-season month the always-on set produced 40 analysed answers and Quillstone was named in 16 of them, which is 40.0%. In the peak month the always-on set did the same, 16 of 40. The seasonal set produced 30 analysed answers in the peak window and Quillstone was named in 6, which is 20.0%.

The pooled headline fell from 40.0% to 31.4%, an apparent drop of 8.6 points, yet the always-on figure did not move. The change came from adding a group of questions where Quillstone starts lower. Reporting only the pooled figure would have raised a false alarm.

Now the seasonal segment on its own. Last year, in the same season window, the seasonal prompts produced 30 analysed answers and Quillstone was named in 4, which is 13.3%. This year it is 6 of 30, or 20.0%, so the Last year comparison shows +6.7 percentage points. Both windows have 30 observations, so neither is marked provisional, though a sample of 30 answers is still small. The result is a lead to investigate, not evidence that any change Quillstone made caused it.

Enlarge image

How do you read the seasonal segment in the Explorer?

Set brand visibility as the metric, break it down by tag, choose a custom window that matches your season dates, and set the comparison. Then read the observation count next to each row before you read the rate.

Some details from the Explorer page worth knowing here:

• Tags are today's tags. Intent, buying stage, theme, branding and tags are read from each prompt as it is classified now, including for its past answers. If you tag prompts after a season has run, the earlier answers appear under the tag as well. Every result carries a note saying so. It also means that removing a tag later changes the past view.
• Tag rows overlap. A prompt with several tags counts once under each, so do not sum the rows.
• A metric with no answers reads as no value, not zero. Do not fill a gap with 0%.
• Week grain and partial weeks. A weekly grain marks a week that falls only partly inside the window as partial, and a partial week keeps its earlier value but has no change. Align your season dates with whole weeks if you plan to chart it weekly.
• Off-season gaps. Paused prompts produce no new answers, so an off-season line is empty by design. Read what missing collection days do to a trend before you interpret a gap you did not plan.

If the project is new and has no history to compare with, see also how much history a new project needs before you interpret its results.

Common mistakes and what this method cannot tell you

• Pooling everything into one trend line. The composition problem above. Always show the segments separately, then pooled if you must, labelled.
• Comparing peak with an arbitrary neighbouring month. The difference mixes the season with whatever else changed. Use last year or a pre-season window you defined in advance, and remember that a pre-season comparison shows how the set moves into the season, not whether your own work changed anything.
• Changing the season's prompts mid-season. Adding or removing prompts changes the population. If you must, log it in the calendar and treat the readings before and after as separate.
• Leaving prompts running all year without a plan. They use slots when you may want them elsewhere. The Coverage tab (Prompt coverage) recommends which running prompts you could pause while what they see regularly stays covered; it does not know your calendar, so check it against your dates before you pause anything.
• Reading a small season as a verdict. A short season with few prompts gives a wide margin of doubt, and the provisional label is a floor, not a guarantee.
• Assuming a seasonal change is caused by your work. A rise or fall in a season is an observation of answers. It does not show why an engine produced them.

What this method cannot tell you: whether real buyers asked these questions in season, how much demand there was, or whether the engines' behaviour changes with the calendar. It gives a clean, comparable record; interpreting it still needs your own knowledge of the market.

Frequently asked questions

Should seasonal prompts go in the same project as my always-on prompts?

Usually yes. Keeping one project and separating the segments with tags lets you filter, break down and compare in a single place. Separate tags keep the segments apart. The Overview figures follow the filter bar, and the tag filter is applied inside every Overview query, so filter by a tag there or read the segments in the Explorer. What matters is that no report pools them without saying so.

Can I schedule a prompt to start and stop automatically?

The docs we relied on describe no per-prompt schedule. The platform runs each active prompt target once a day, and you start and stop a season by activating and pausing the prompts yourself. Put the dates in the calendar so nobody forgets.

Do paused seasonal prompts lose their history?

No. The docs say pausing stops future scheduled runs while preserving history and country targets, and the Explorer counts paused prompts that have answers in the window. Deleting a prompt is different: a deleted prompt's answers are gone.

What if I have no data from last year?

Use a pre-season window of the same prompts as your comparison, and say so in the report. It is a weaker comparison than the same season last year, because the pre-season and the season differ for reasons you cannot separate, but it is honest about what you have.

Which chart should I use for a season?

A table with the observation count beside every row is the safest starting point, then a bar chart by tag or a weekly line for the season window. The Explorer greys out a chart that cannot draw the current query and explains why.

Should I tag my always-on prompts too?

It helps. A tag for the always-on cohort makes the comparison symmetric: you can put both segments side by side in one breakdown, with each row's observation count visible.

Next step

Open your prompt list, tag the seasonal prompts, and fill in the first row of the calendar before the season starts. Then build the tag breakdown in the Explorer so the comparison is ready on the day you want it. You can start at app.discoveredby.ai.