Your First Steam Summer Sale Wishlist Decay Triage Worksheet - One Evening in 2026

The June-July 2026 Steam Summer Sale is the moment when a wishlist graph can look dead even when it is behaving normally. June Next Fest intent has had time to cool, sale browsing shifts attention toward games that are already buyable, and a small team can easily compare an October-style demo spike with a July sale day and conclude that its store page has failed. That conclusion often leads to the expensive wrong move: discounting a future release to chase an audience that cannot buy yet, or promising a content update before the evidence says the game—not the offer—is the limiting factor.

This worksheet gives you a disciplined alternative. In one evening, export the relevant Steamworks Marketing data, calculate a comparable daily wishlist-decay rate, put the result into a GREEN, YELLOW, or RED band, and choose the next small action. The outcome is not a prediction of revenue. It is a record of what you saw, what you decided, and what would make you reverse that decision.

Who this is for: a first-time Steam developer who needs a plain first path, plus a producer or developer who needs a reviewable evidence file beside a release checklist. Time: 90 minutes for the first pass, then 10 minutes per daily refresh. Result: a committed summer_sale_wishlist_decay_receipt_v1.json, D1-D6 gates, and one clearly owned lane: discount investigation or content-update investigation.

This is deliberately different from the daily V1-V6 ratio work in 16 Free Steam Daily Export and Wishlist Velocity Tools for Post-Fest Follow-Through. That post owns a post-fest daily velocity tool stack. It is also not the post-Next-Fest wishlist plateau diagnostic playbook, which owns hypothesis branches after a sustained plateau; not the hour-one demo funnel snapshot, which owns fest-hour clicks; not the February refund spike worksheet, which owns refund percentage; and not a July signup-compression trend report. This page owns a single seasonal decision: classify Summer Sale wishlist decay before you change price positioning or development scope.

Why this matters now - Summer Sale and Next Fest intent are adjacent but not interchangeable

The Summer Sale changes what a player can do immediately. During a festival, a visitor may wishlist a promising unreleased game after trying a demo. During a major sale, many visitors are comparing discounted games they can purchase now. A lower wishlist count or a lower wishlist-per-visit rate can therefore be a context shift, not proof that your capsule, trailer, tags, or demo suddenly stopped working.

That does not make the number irrelevant. It makes comparison discipline essential. A team that sees one low day and immediately discounts an already released title may sacrifice margin without discovering whether the page needs clearer sale messaging. A team with an unreleased game can make an even worse mistake by treating sale browsing as a reason to over-discount later, when the visitors were never close to the same decision as the festival audience.

Start with the official source, not a reconstructed dashboard. Steamworks documents its marketing reporting surfaces in the Steamworks Marketing documentation. The labels and available export controls can evolve, so record the report name, date range, timezone, and download filename in your receipt rather than relying on a screenshot alone.

The purpose of the worksheet is modest:

1. Compare like-for-like calendar buckets.
2. Measure decay from a declared reference day.
3. Check whether visits, wishlists, and store readiness tell the same story.
4. Put a reversible action into the correct lane.
5. Stop before a weak signal turns into a large roadmap commitment.

The beginner path - do the first pass without analytics software

You need access to Steamworks, a spreadsheet application, your current store-page build notes, and 90 uninterrupted minutes. You do not need an attribution platform, paid analytics, or a forecast model.

Create a folder such as release-evidence/marketing/summer-sale-2026/. Save untouched exports in raw/, calculations in derived/, and the final JSON receipt at the folder root. Keeping the raw export matters: a team should be able to rerun the worksheet next week without asking whether someone copied a value incorrectly.

Use these terms consistently:

• Daily wishlists: the change in wishlists reported for the selected day, not your all-time total.
• Daily visits: store-page visits for the same reporting day and timezone.
• Wishlist rate: daily wishlists divided by daily visits. It is a diagnostic ratio, not a promise of sales.
• Reference day: a normal, declared day used to calculate decay. Do not quietly replace it after a result looks inconvenient.
• Decay rate: (reference wishlist rate - current wishlist rate) / reference wishlist rate.
• Lane: the small category of work you can investigate next—discount or content update. A lane is not approval to ship a price change or a feature.

If the reference rate is zero, stop. A division by zero does not mean “RED”; it means the sample cannot support this worksheet. Choose a different comparable day or use an absolute-count review with a documented limitation.

Export evening path from Steamworks Marketing

Steamworks screens can change, but the sequence should remain recognizable. Open your app in Steamworks, go to the Marketing or reporting area documented for your partner account, and locate the report that exposes store traffic and wishlist activity at daily granularity. Do not export a broad lifetime graph if it cannot be aligned to daily dates.

Step 1 - define the reporting window before downloading

Write the sale window and your comparison window at the top of the worksheet. A useful first window is:

• seven days before the sale or the specific sale beat you are reviewing;
• the first three comparable sale days;
• the current day through the most recent complete reporting day.

Avoid a partial day. If you export at 16:00 local time and compare it to completed midnight-to-midnight days, the apparent decline is manufactured by the clock. Either use completed days only or label the partial day and exclude it from a gate.

Step 2 - export the source reports

Download the relevant daily marketing or traffic report as CSV if Steamworks offers that format. If it offers a date-filtered report plus a graphical view, save both: the CSV is the calculation source, while a dated screenshot can explain a known event such as a feature, a creator video, or a store-page update.

Name exports predictably:

steamworks-marketing-2026-07-14-complete-days.csv
steamworks-store-traffic-2026-07-14-complete-days.csv
steamworks-marketing-2026-07-14-view.png

Write the account timezone into notes.md. Do not merge data from a local-time spreadsheet with a UTC export until you have checked day boundaries.

Step 3 - build the smallest useful derived table

Create these columns:

In a spreadsheet, if visits are in B2 and wishlists are in C2, the rate is =IFERROR(C2/B2,""). If the reference rate is in $D$2, the decay is =IFERROR(($D$2-D3)/$D$2,""). Format the two ratio columns as percentages. Do not round the underlying values before classifying bands.

Step 4 - add context events, not opinions

In the Notes column, log only things that could change interpretation: a store-page trailer replacement, a patch, a creator post, a feature, a broken demo, a weekend boundary, or a reporting outage. “Feels quiet” is not an event. If an event is suspected but unconfirmed, write unverified rather than turning it into an explanation.

Step 5 - save a receipt before debating fixes

At the end of the evening, file the receipt template below. The receipt forces the team to say what was measured, which gates passed, which lane is active, and when it will look again. That is more useful than a message saying the graph “seems bad.”

Printable decay-band table - classify the rate, then inspect the sample

Print this table or put it in the first tab of the worksheet. These bands are operational defaults, not Steam policy and not universal performance benchmarks. They classify the change versus your own declared reference, which makes them usable for a small game with dozens of visits and a larger game with thousands.

Use a minimum sample note beside the table. With very low counts, one extra wishlist can move the rate dramatically. For example, a change from two wishlists out of 40 visits to one out of 40 is a 50% rate decline, but it is only one person of movement. Classify it RED provisionally, then write low-volume review and require a second complete comparable day before any action.

A practical comparison rule

Compare weekday with weekday when possible. Friday sale traffic often differs from Tuesday traffic. Compare days at the same stage of a promotion rather than comparing a Monday after a festival with the first evening of a sale. If no comparable day exists, retain the result but lower the confidence in the receipt; do not pretend the calendar mismatch disappeared.

D1-D6 evidence gates - the developer path

The beginner path tells you how to calculate the result. These gates make the result reviewable by someone who was not in the room.

The important wording is “exactly one.” A YELLOW row might make both a discount test and a content refresh sound sensible. Running them together prevents you from learning which change mattered. Choose the lower-risk investigation first, document why, and leave the other lane inactive.

Receipt template - summer_sale_wishlist_decay_receipt_v1.json

{
  "schema": "summer_sale_wishlist_decay_receipt_v1",
  "generated_at_utc": "2026-07-14T18:30:00Z",
  "sale_context": "Steam Summer Sale 2026",
  "timezone": "America/Los_Angeles",
  "raw_exports": [
    "release-evidence/marketing/summer-sale-2026/raw/steamworks-marketing-2026-07-14-complete-days.csv",
    "release-evidence/marketing/summer-sale-2026/raw/steamworks-store-traffic-2026-07-14-complete-days.csv"
  ],
  "derived_table": "release-evidence/marketing/summer-sale-2026/derived/wishlist-decay.csv",
  "reference_date": "2026-07-10",
  "reference_wishlist_rate": 0.04,
  "current_complete_date": "2026-07-13",
  "current_wishlist_rate": 0.0271,
  "decay_rate": 0.3225,
  "decay_band": "YELLOW",
  "low_volume_review": false,
  "context_events": ["Summer Sale browsing window", "No confirmed store-page change"],
  "gates": {
    "D1": "GREEN",
    "D2": "GREEN",
    "D3": "GREEN",
    "D4": "GREEN",
    "D5": "GREEN",
    "D6": "PENDING"
  },
  "active_lane": "content_update_investigation",
  "inactive_lane": "discount_investigation",
  "owner": "marketing-owner",
  "next_review_utc": "2026-07-15T18:00:00Z",
  "stop_rule": "Stop content investigation if the next two comparable complete days return to GREEN without a store change.",
  "wishlist_decay_triage_ok": false
}

Set wishlist_decay_triage_ok to true only after D1-D6 are GREEN and the matching BUILD_RECEIPT field is updated. A receipt can honestly contain YELLOW or RED data; the boolean says the triage process is complete, not that the graph is healthy.

Choose the right lane - discount investigation versus content-update investigation

The lane is a question to test, not a conclusion.

Discount investigation lane

Use this lane when the product is purchasable, the store page is stable, the rate is in YELLOW or RED across two comparable completed days, and there is a plausible offer or pricing question you can investigate without changing several other variables. For a released game, inspect the discount’s eligibility, timing, regional implications, current price positioning, and whether a planned sale beat has a coherent store-page message.

For an unreleased game, “discount investigation” is usually a planning note, not a button to press. Do not use a Summer Sale curve to invent a launch discount. Instead, record the hypothesis: perhaps the sale audience is highly price-aware, or perhaps the page needs a clearer future value proposition. Validate that later with relevant launch-period evidence.

Discount lane stop rules

• Stop immediately if the game is not eligible, not released, or the only evidence is one partial or low-volume day.
• Stop if a content, demo, checkout, or store-page defect is confirmed. Fix the defect before interpreting price response.
• Stop if a second comparable day returns GREEN. Record “no action” as the result.
• Stop if the proposed change has no isolated measurement window. A discount started with a trailer replacement cannot teach you about price.
• Stop if the investigation would violate your existing pricing plan or requires a rushed promise to players.

The lane output should be a brief decision memo, not an automatic discount. “No discount recommended; revisit at next planned event” is a valid, often valuable result.

Content-update investigation lane

Use this lane when the decline aligns with a confirmed product or communication issue: a broken demo path, outdated screenshots, a trailer that no longer represents the build, unclear controller or language information, a known crash, or a high-intent page question that the current page fails to answer. This lane may produce a store-page edit, a small patch, or a scoped content update—but only after the issue is observable.

Start with the cheapest credible fix. A revised short description, a corrected demo note, or a current screenshot can be more diagnostic than a multi-week feature. The Thursday build receipt row-review ritual is a useful companion when you need to make a store-facing change traceable to a tested build.

Content-update lane stop rules

• Stop if the only evidence is a seasonal decay band and there is no confirmed page, build, or message problem.
• Stop if the proposed update cannot be linked to a specific hypothesis and a measurable check.
• Stop if the update expands beyond a small, reviewable scope before the next comparison day.
• Stop if the next two comparable days return GREEN without an update. The apparent issue may have been normal sale variation.
• Stop if a build regression or incomplete smoke test would make the update riskier than the signal warrants.

The lane output is an issue card with a hypothesis, a minimal change, a validation date, and a rollback condition. It is not “make more content.”

Scenarios A-G - how to use the worksheet without guessing

Scenario A - GREEN decay after a busy sale weekend

Your reference rate is 3.8%. Saturday is 3.2%, a 15.8% decay, and visits are higher than normal. D1-D4 pass. Nothing on the page changed.

Classify GREEN. Continue daily recording and do not open either lane. Higher traffic with a modestly softer rate can be normal audience mixing during a sale. Your next action is the scheduled review, not a discount proposal.

Scenario B - YELLOW rate with incomplete-day data

At 15:00, today’s rate is down 30%. Yesterday and the reference day are complete, but today is not.

Mark the row partial, set D1 to PENDING for this comparison, and do not classify the partial row as a lane trigger. Export tomorrow after the reporting day closes. This is the most common avoidable false alarm.

Scenario C - RED but tiny volume

The rate falls from 5% to 2.5%, which is a 50% decline, but that means two wishlists instead of four from 80 visits.

Use RED as a visibility flag, not a price decision. Set low_volume_review: true, require a second comparable complete day, and look for a known traffic-source change. Your receipt should say the percentage moved sharply but the absolute sample is small.

Scenario D - YELLOW decay after a trailer replacement

The rate declines 34% on two comparable complete days. The only logged event is a new trailer published on the store page.

Select the content-update investigation lane. Do not discount simultaneously. Verify whether the first 10 seconds still state genre, player promise, and current gameplay. Preserve the prior asset and define a rollback or alternate cut. The result might be that the trailer was not causal, but the test remains interpretable.

Scenario E - RED decay with a broken demo launch button

Support reports and your own clean-account test confirm that the demo path is unavailable or misleading. The graph is RED.

This is not primarily a marketing or price question. Select content-update investigation, treat the storefront issue as a release-blocking defect, fix and smoke-test it, then annotate the receipt with the repair window. Do not discount to compensate for a broken funnel.

Scenario F - GREEN rate but a large absolute wishlist drop

Visits decline from 10,000 to 3,000 and wishlists decline proportionally, leaving the rate nearly unchanged.

Your decay worksheet is GREEN because conversion behavior is stable. The separate question is traffic acquisition. Do not misuse a rate triage to diagnose a distribution problem. Run the sale-week store-response ladder in 5-Day Summer Sale Store Response Ritual Challenge (S1–S5, summer_sale_store_ok) and Resource #46 for outreach/asset-check tools; keep the evidence categories separate.

Scenario G - RED after June Next Fest adjacency

Your team compares a July sale day to an October-style Next Fest demo day and sees RED. Visits are lower, the remaining visitors are sale browsers, and no current defect exists.

Fail D2. The reference is not comparable. Replace it with a non-fest, pre-sale complete weekday or a matched sale-stage day, document the discarded comparison, and rerun the calculation. This scenario is why the worksheet exists: it stops a false “dead wishlist curve” from turning into an unnecessary October-intent discount strategy.

Proof table - what a completed one-evening review looks like

Use a proof table in the pull request, planning document, or release review. It allows a developer, producer, or collaborator to check the conclusion without reopening every browser tab.

For a team using a build artifact, add one of these fields to the relevant BUILD_RECEIPT:

{
  "summer_sale_decay_ok": true,
  "wishlist_decay_triage_ok": true,
  "summer_sale_wishlist_decay_receipt": "release-evidence/marketing/summer-sale-2026/summer_sale_wishlist_decay_receipt_v1.json"
}

Choose one boolean as the canonical project convention and keep the other only if another automated check requires it. The path is important: it ties a human marketing decision to a durable evidence record without pretending that marketing analysis is a build test.

verify_summer_sale_wishlist_decay.sh sketch

You can begin with a manual spreadsheet and still gain value from the gates. When the team is ready, this shell sketch checks the receipt shape and the most important process claims. Adapt paths and validation rules to your repository; it is intentionally not a substitute for reading the source export.

#!/usr/bin/env bash
set -euo pipefail

receipt="release-evidence/marketing/summer-sale-2026/summer_sale_wishlist_decay_receipt_v1.json"
build_receipt="BUILD_RECEIPT.json"

test -f "$receipt"
jq -e '
  .schema == "summer_sale_wishlist_decay_receipt_v1" and
  (.raw_exports | length >= 1) and
  (.reference_wishlist_rate > 0) and
  (.current_wishlist_rate >= 0) and
  (.decay_band | IN("GREEN", "YELLOW", "RED")) and
  (.gates.D1 == "GREEN") and
  (.gates.D2 == "GREEN") and
  (.gates.D3 == "GREEN") and
  (.gates.D4 == "GREEN") and
  (.gates.D5 == "GREEN") and
  (.gates.D6 == "GREEN") and
  (.active_lane | IN("discount_investigation", "content_update_investigation", "none")) and
  (.wishlist_decay_triage_ok == true)
' "$receipt" >/dev/null

jq -e --arg receipt "$receipt" '
  (.summer_sale_decay_ok == true or .wishlist_decay_triage_ok == true) and
  .summer_sale_wishlist_decay_receipt == $receipt
' "$build_receipt" >/dev/null

echo "Summer Sale wishlist decay receipt passes D1-D6."

Two cautions matter. First, the script can confirm that a JSON claim exists; it cannot prove the Steamworks export was interpreted correctly. Second, do not force wishlist_decay_triage_ok: true merely so automation turns green. If the team has not completed D6, the truthful status is PENDING and the script should fail.

Common mistakes that make seasonal decay look worse than it is

Using a festival day as the baseline. Festival visitors and sale visitors may have different immediate choices. Mark the mismatch and select a comparable reference.

Comparing a partial day with a completed day. This is a clock problem, not a demand signal. Exclude partial rows from gates.

Treating a percentage as a sufficient sample. A RED percentage with one or two additional wishlists needs a low-volume review, not a rushed decision.

Changing multiple inputs. A discount, trailer replacement, creator beat, patch, and capsule revision started together create a story, not evidence.

Calling a roadmap item a content update. A content lane should begin with the smallest change that tests a confirmed store or build problem. A new feature can wait until the hypothesis earns it.

Calling all decline a pricing problem. Price can matter, but it cannot repair misleading screenshots, a broken demo, or a badly matched reference period.

A 10-minute daily follow-through after the first evening

Once the first receipt exists, daily maintenance should be short:

1. Wait for a complete reporting day.
2. Export or append the new Steamworks data using the same timezone.
3. Recalculate rate and decay against the unchanged reference.
4. Add only factual context events.
5. Update the receipt if the band, lane, or stop rule changes.
6. Review the active lane only at its declared checkpoint unless a confirmed defect appears.

That rhythm avoids a common operational trap: the team sees a graph every hour, changes its opinion every hour, and never gives any defined comparison time to exist.

Key takeaways

• Steam Summer Sale wishlist decay is a triage signal, not a revenue forecast.
• July 2026 sale browsing and June Next Fest intent are adjacent contexts, not interchangeable baselines.
• Export daily Steamworks Marketing and traffic data for complete reporting days only.
• Calculate wishlist rate from raw daily wishlists divided by daily visits.
• Calculate decay against a declared comparable reference; do not replace the reference after seeing the result.
• Use GREEN below 20%, YELLOW from 20% to under 45%, and RED at 45% or more for two comparable complete days.
• Treat RED with tiny counts as a low-volume review, not immediate proof of a broken store page.
• D1-D6 make the conclusion reproducible: source, reference, math, band, lane, and BUILD_RECEIPT parity.
• Activate exactly one lane—discount investigation or content-update investigation—so the next test remains interpretable.
• Stop a discount lane when eligibility, sample quality, or a confirmed product defect makes price the wrong question.
• Stop a content-update lane when there is no confirmed page or build issue, or when comparable days return GREEN without a change.
• Set summer_sale_decay_ok or wishlist_decay_triage_ok only when the evidence receipt and BUILD_RECEIPT agree.

FAQ

What is a normal Steam Summer Sale wishlist decay rate?

There is no universal normal percentage because game genres, traffic sources, price states, and sample sizes differ. Use the GREEN/YELLOW/RED bands as internal operating thresholds against your own declared reference. The important question is whether the comparison is complete, comparable, and reproducible—not whether another game’s rate looks better.

Should I discount my game when wishlists fall during the Steam Summer Sale?

Not from one graph alone. First confirm two comparable complete days, check for store or demo defects, and isolate the hypothesis. For unreleased games, a current sale curve usually cannot justify a future launch discount. For released games, the discount lane should end in a documented decision, not an automatic price cut.

Where do I export wishlist and traffic data in Steamworks?

Use the Marketing and reporting surfaces available for your app in Steamworks, following the current Steamworks Marketing documentation. Record the exact report name, date window, timezone, and filename in your receipt because partner reporting labels and exports can change.

Is wishlist rate the same as conversion rate?

In this worksheet, wishlist rate means daily wishlists divided by daily store visits. It is a simple proxy that helps compare days consistently. It is not a complete sales conversion model, and it should not replace deeper source, demo, refund, or purchase analysis.

What if my game has too little traffic for daily rates?

Keep recording the raw counts, flag low_volume_review, and require more than one comparable day before choosing a lane. You can also use a longer rolling window, but document that change and apply it consistently. Do not let a denominator of 20 visitors create a large strategic reaction.

Related reads

• 5-Day Summer Sale Store Response Ritual Challenge for hub posts, screenshot parity, and S1–S5 store-ops gates (summer_sale_store_ok)—cousin to this rate triage.
• 16 Free Steam Daily Export and Wishlist Velocity Tools for Post-Fest Follow-Through for the separate daily velocity stack and V1-V6 receipt.
• Post-Next-Fest Wishlist Plateau - A 2026 Diagnostic Playbook for Small Teams for sustained-plateau hypothesis branches after this seasonal triage is complete.
• Your First Hour-One Demo Funnel Snapshot CSV - Steam Wishlist Clicks One Evening 2026 for festival-hour funnel evidence rather than July decay.
• February Fest Refund Spike Threshold Worksheet - Wishlist Converts Demo 2026 when the question is refund percentage, not wishlist-rate decay.
• Thursday Build Receipt Row Review Ritual - Ten Minutes After Wednesday Smoke for making an evidence-backed store or build change reviewable.

Closing

A flat July graph does not tell you to panic, discount, or build a new feature. It tells you to ask whether you are comparing the right days and whether a rate change has enough evidence to deserve action. Run the worksheet once, save the raw export and summer_sale_wishlist_decay_receipt_v1.json, and give one lane a bounded test with a stop rule.

That is the useful discipline during the Summer Sale: preserve your pricing and roadmap options until the evidence can distinguish normal seasonal decay from a real store or product problem. Bookmark this worksheet for the next complete reporting day, then carry the signed receipt into the 5-Day Summer Sale Store Response Ritual Challenge—rates and hub truth stay separate receipts.