Sign in Start free

Honest Organic Forecasting

The standard method - keyword volume times an assumed position-one CTR - produces numbers that are wrong by an order of magnitude and destroys trust when the year closes. Organic has a long, variable lag and depends on things outside your control. A defensible forecast is built from your own historical response to your own work, with the assumptions stated so they can be argued with.

CATEGORY
Analytics & reporting
FORMAT
honest-organic-forecast.md
STEPS
6
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when asked to forecast organic traffic or revenue for a budget round or a business case.

The skill file

honest-organic-forecast.md
---
name: honest-organic-forecast
description: Use when asked to forecast organic traffic or revenue for a budget round or a business case.
---

# Honest Organic Forecasting

The standard method - keyword volume times an assumed position-one CTR - produces numbers that are wrong by an order of magnitude and destroys trust when the year closes. Organic has a long, variable lag and depends on things outside your control. A defensible forecast is built from your own historical response to your own work, with the assumptions stated so they can be argued with.

## What you need first

- at least 13 months of your own organic history
- historical lag between publishing or fixing and measurable movement on this site
- the delivery capacity you are actually committing to

## Method

1. Establish the baseline as a trend line, not last year's number. Forecast the incremental effect on top of the baseline and show both lines separately.
2. Derive lag empirically from your own site: take past batches of published or optimized pages and measure weeks to peak. New-domain lag and established-domain lag differ enough that borrowed benchmarks are useless.
3. Model in three cases and label them by assumption, not optimism. Say "assumes 8 pages a month shipped and no template regression", not "best case".
4. Tie the forecast to delivery volume so it fails visibly if delivery slips. A forecast that stays true when nothing ships is not a forecast.
5. Apply a decay assumption to existing content. Flat performance is a choice that costs effort; forecasting the baseline as flat and free is the most common inflation in these models.
6. Write down the three assumptions most likely to break it and the date each becomes checkable, then diarise those check dates.

## What this produces

A three-case forecast with stated assumptions, an empirical lag curve, and dated checkpoints for revision.

## Where this goes wrong

- Using third-party search volume as the input - it is smoothed, rounded and often out by a factor of two or more for anything below a few thousand a month
- Forecasting a straight line from a period that contained a one-off spike such as a viral post or a competitor outage
- Refusing to give any number when pressed, which does not read as rigour and simply hands the forecast to someone with less information

---

From the QuQi skill library - https://www.quqi.io/skills/honest-organic-forecast
Free to download · no account, no email

What you need first

  • at least 13 months of your own organic history
  • historical lag between publishing or fixing and measurable movement on this site
  • the delivery capacity you are actually committing to

Method

  1. 01 Establish the baseline as a trend line, not last year's number. Forecast the incremental effect on top of the baseline and show both lines separately.
  2. 02 Derive lag empirically from your own site: take past batches of published or optimized pages and measure weeks to peak. New-domain lag and established-domain lag differ enough that borrowed benchmarks are useless.
  3. 03 Model in three cases and label them by assumption, not optimism. Say "assumes 8 pages a month shipped and no template regression", not "best case".
  4. 04 Tie the forecast to delivery volume so it fails visibly if delivery slips. A forecast that stays true when nothing ships is not a forecast.
  5. 05 Apply a decay assumption to existing content. Flat performance is a choice that costs effort; forecasting the baseline as flat and free is the most common inflation in these models.
  6. 06 Write down the three assumptions most likely to break it and the date each becomes checkable, then diarise those check dates.

What this produces

A three-case forecast with stated assumptions, an empirical lag curve, and dated checkpoints for revision.

Where this goes wrong

  • Using third-party search volume as the input - it is smoothed, rounded and often out by a factor of two or more for anything below a few thousand a month
  • Forecasting a straight line from a period that contained a one-off spike such as a viral post or a competitor outage
  • Refusing to give any number when pressed, which does not read as rigour and simply hands the forecast to someone with less information

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/honest-organic-forecast/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When is this method right rather than search volume multiplied by an assumed position-one click-through rate?

Whenever the number will be used in a budget round or a business case. The volume times CTR method is routinely out by an order of magnitude, and the bill arrives when the year closes and nobody believes the next forecast. Building from your own site's historical response to your own work produces assumptions people can argue with in advance.

What do I need in hand before starting, and what happens if I start without it?

Thirteen months or more of your own organic history, past batches of published or fixed pages so you can measure weeks to peak on this site, and the delivery volume you are genuinely committing to. Borrowed lag benchmarks are useless because new-domain and established-domain lag differ sharply. With no delivery figure the forecast stays true when nothing ships, which makes it decorative.

What do I end up with, and which part of it actually gets used?

Three cases labelled by assumption rather than by optimism, a lag curve derived from your own data, and dated checkpoints for revision. The checkpoints are what gets used: each names an assumption and the date it becomes checkable, so a miss is traced to eight pages a month becoming three rather than argued about as a total.

What is the mistake that most often ruins this, and what does it cost?

Feeding third-party search volume in as the input. It is smoothed, rounded and often out by a factor of two or more below a few thousand searches a month, and every number downstream inherits that error. Forecasting the baseline as flat and free is the other common inflation, since holding existing content level already costs effort you have not budgeted.

More in Analytics & reporting