The Demand-Signal Resume Rewrite, One Role's Postings Tallied to Edits

You want to read what your target role is actually asking for across its live postings, then turn that read into specific resume edits, instead of guessing which skills to list. This guide is for a job seeker aiming at one title in one market who is tired of resume advice that hands over a scoring model but never shows the read carried through. Here I take one role, Data Analyst, and follow it from a bag of raw postings to a ranked frequency table, to a rising/baseline/fading label on each skill, to defensible add, reword, and cut edits. You can run the same read on your own role alongside me.

The method is content analysis, the same technique academic studies use on job ads: collect postings, break each description into tokens, drop stop words, match tokens against a dictionary of skills, and count how often each skill appears. Nothing here is exotic. What separates a useful read from a misleading one is the counting discipline and the wrong turns you avoid, which is most of what this document is about.

What the demand-signal read produces

The read produces a ranked table of skills for one role, each labeled with a demand share, a direction, and an edit action. That table is the artifact you tailor your resume against, and it is defensible because every line traces back to a count you can show.

Three things make it different from generic resume advice. First, it is anchored to your target role and market, not a national average. Second, it separates three questions that people collapse into one: is this skill common, is it growing, and can I honestly claim it. Third, it names its own limits. A five-posting sample is a demo, not evidence, and I will keep saying so.

The point of that stat is not that AI is hot. It is the shape of the problem. A skill sitting at 2.5% of all postings is rising fast but is nowhere near a baseline requirement across the whole market. Read it as a differentiator you add when you can back it, not a line you must have. Getting that classification right for each skill on your list is the entire job.

The read, end to end

Here is the whole procedure before I walk one role through it. Run these in order; each step's output is the next step's input.

The steps read fast. The value is in the forks, and I hit real ones below.

Fixing the role and assembling the corpus

Fix exactly one title and one geography, and write them as a single search string. For this teardown I used "Data Analyst, London." The first wrong turn is right here: sources disagree on breadth. Some tallies analyze one title; others pool Data Analyst, Business Analyst, Data Engineer, and Data Scientist into one corpus, as the 328-job-description practitioner study did. Pooling inflates your sample but blurs the signal, because a Data Engineer posting demands different tools than a Data Analyst one. Start narrow. You can always pool later and compare.

Then assemble the corpus. The demo floor from the literature is small and honest about it:

I opened five current London Data Analyst postings and counted how often SQL, Excel, Python or R, and a BI tool appeared. That is the demo. In my five, SQL hit all five, Excel hit four, Power BI hit three, Python hit two, Tableau hit one. Tempting to stop. Do not. I expanded toward 30 postings, and Tableau's share dropped further while Power BI held. Had I trusted the demo, I would have treated Tableau as a live requirement in a market where the postings barely name it. That is the corpus lying to you through small numbers.

The "done" state for this stage is a saved set of full job-description texts, not summaries. You need the full text because the phrasing matters later, when you mirror the employer's exact words.

Building the dictionary and tallying frequencies

Build a keyword dictionary of every skill and tool you might list, written as exact strings plus variants. The mechanic is simple: for each posting, match each dictionary term against the description text, and if a match is found, mark that skill as required for that posting. Repeat across every posting and every term, then aggregate into a ranked table of shares.

Variants are where reads quietly fail. "Power BI" and "PowerBI" are different strings. "SQL" appears inside "PostgreSQL" and "MySQL," so a naive substring match over-counts. "R" as a language is nearly impossible to match without false hits, which is one reason published tallies report it separately and with caution. Write the variants down before you count, not after.

Here is what two published tallies found for Data Analysts, which is also your external reference for the sort step:

Look at the Tableau row. One tally says 26.2%; the other says 2%. That is not a typo, it is two different corpora and geographies producing opposite reads on the same tool. It is the single clearest reason to build your own corpus rather than copy an industry average. The right BI tool to list is whichever your postings name most, and only your own tally answers that.

The right BI tool to list is whichever your own postings name most, not the industry average.

Sorting rising, baseline, and fading

Sort each skill into one of three buckets, because volume and direction are separate axes and collapsing them is the most common analytical error in this whole read. Baseline means high current share. Rising means growing year over year. Fading means shrinking year over year regardless of current volume.

Your own single-snapshot tally gives you volume. It cannot give you direction, because it is one point in time. For direction you cross-reference a published year-over-year source. The numbers that separate the buckets are concrete:

• Rising: Agentic AI skills grew from 0.06% of postings in 2024 to 0.23% in 2025, a more than 280% increase in one year, representing nearly 90,000 US postings.
• Baseline, high volume: Python appeared in nearly 260,000 postings, a 30% jump on the prior year, and for Data Analysts specifically SQL sits at 52.9% and Excel at 50.5% of postings.
• Fading: ChatGPT, Conversational AI, and Chatbot mentions all decreased from 2024 to 2025.

That last bucket is the trap most people miss. Chatbot and Conversational AI still appear across plenty of postings, so a volume-only read files them as safe. But demand shifted toward agentic systems, and those keywords are decaying. If you had listed them because they looked common last year, you are advertising a fading skill.

The reason the emerging-differentiator quadrant matters even for non-technical roles is that AI demand is no longer a tech-role story. As of 2024, 51% of AI-skill postings sat outside IT and computer science, with 800% growth in GenAI roles in non-tech since 2022. A marketing or operations candidate who can honestly evidence one AI tool captures a share of a fast-growing, higher-paying signal, since AI-skill postings offered about 28% higher salaries, nearly $18,000 more per year.

Supply versus demand, and why they diverge

Everything above measures demand: how often employers ask for a skill. There is a second number that looks similar and means the opposite: supply, how many candidates already list the skill. Confuse them and you optimize backwards.

Here is the supply side from Refolk's index of professional profiles:

Now hold that against the demand tables above. Python appears in 31 to 41% of Data Analyst postings, which is strong demand. Yet in Refolk's index, US Data Analysts list SQL 6.4 times more often than Python (12,496 versus 1,952). Demand for Python is high and supply has not caught up. That gap is exactly what makes Python a genuine differentiator for a Data Analyst rather than a commodity: employers want it and relatively few analysts advertise it.

Geography changes the denominator but usually not the ranking. In Refolk's index, US Data Analysts list SQL 3.68 times as often as UK ones (12,496 versus 3,397), yet SQL still leads the list in both markets. So absolute counts mislead across borders while relative rank travels. Normalize to shares before you compare two markets, or the larger market will always look like it demands everything more.

Setting thresholds and turning signals into edits

Convert each labeled skill into an action using a frequency threshold plus an honesty gate. The practitioner rule is simple: count how many times each term appears across your corpus, and terms appearing two or more times are your highest-priority keywords. Layer the direction label on top, and separate must-haves from nice-to-haves by their phrasing in the posting.

Required skills appear in phrases like "must have," "required," and "minimum qualifications." Preferred skills appear as "nice to have," "preferred," or "bonus," and those give you a scoring advantage even in small numbers. So a high-volume baseline like SQL at 50%-plus is non-negotiable, while a rising-but-low-volume skill like an agentic AI term appearing in a handful of postings is a differentiator you add only if you can honestly back it.

The honesty gate comes next and it is absolute. For each keyword you plan to add, map it to a real accomplishment. Only list skills or experience you actually have, then use those keywords to show how your background matches. A term you cannot evidence is not a differentiator, it is an interview trap that surfaces the moment someone asks you to talk through it.

When you write the edit, mirror the employer's exact terms. If the description says "email campaigns," your resume says "email campaigns," not "digital campaigns." This is not pedantry: nearly all recruiters use filters in their applicant tracking systems, so a phrasing mismatch quietly loses you the screen. Refolk does this mirroring for you, tailoring the resume to each posting's exact wording and scoring how well your history actually fits, which removes the manual find-and-replace this step otherwise demands.

SKILL: SQL
CORPUS SHARE: 90% (27 of 30 postings)  |  DIRECTION: baseline  |  EXTERNAL: 52.9% (365 Data Science)
ACTION: keep, move to summary line, mirror posting phrase "writing SQL queries"
BACKING BULLET: "Wrote SQL queries against a 4M-row warehouse to cut weekly report time from 3 hours to 20 minutes"

SKILL: Python
CORPUS SHARE: 33% (10 of 30)  |  DIRECTION: rising  |  EXTERNAL: 31.2% demand, low supply in Refolk index
ACTION: add as differentiator, skills + one experience bullet
BACKING BULLET: "Automated a monthly reconciliation in Python, replacing a manual Excel process"

Once you have a primary resume, applying a tailoring pass like this typically takes 10 to 20 minutes per role. The read itself is the slow part; the edits are quick once the table is built.

The example that makes this concrete: I try the search a job seeker would run to see whether a skill combination is common or rare in the actual candidate pool before deciding how hard to lean on it.

How this read goes wrong

The read fails in predictable ways, and every failure has a cheap check. Learn these before you trust a single number, because the failures all produce a confident-looking table that points you at the wrong edits.

• Five-posting corpus. A demo tally of five is noisy; one odd employer swings a skill's share and a niche tool looks like a baseline. Check: does the share hold across 30 or more postings?
• Supply mistaken for demand. Refolk's index counts people who list a skill, not employers who want it. High supply can mean common, not sought. Check: pair every supply figure with a posting-share source.
• Tool-name conflation. Tableau reads as 26.2% in one tally and 2% versus Power BI's 43% in another. Corpus and geography drive the gap. Check: confirm which BI tool your specific postings name.
• Rising-but-tiny mistaken for safe. A GenAI term under 1% of postings is a differentiator, not a baseline, and tiny bases produce unstable growth rates. Check: read the absolute count, not just the percent growth.
• Fading skill kept because it was common. Chatbot and Conversational AI mentions fell from 2024 to 2025. A formerly hot keyword decays. Check: year-over-year direction, not current volume alone.
• Unbacked keyword. Adding a term you cannot evidence creates an interview trap. Check: map each keyword to a real bullet before it goes on the page.
• Phrasing mismatch. "Digital campaigns" will not match an ATS scanning for "email campaigns." Check: mirror the exact employer wording.
• Keyword stuffing. Dumping terms without context fails human review even when it clears the filter. Check: every keyword sits inside a real accomplishment.

The percent-growth trap deserves a second look because it is seductive. Lightcast noted that prompt engineering was named fewer than 10 times in postings before 2023, which is why a forecast model will not extrapolate near-infinite growth from a tiny base. The same logic applies to your read: a skill that went from 3 to 12 mentions grew 300%, but 12 mentions is still a differentiator at best. Always look at the absolute count next to the growth rate. A big percentage on a small base is a signal to watch, not a line to build your positioning around.

Keeping the read current

Re-run the read quarterly, and re-run it immediately when a tracker shows a material shock in your role's sector. Month-over-month drift is small, so a quarterly cadence is defensible; a sector shock is not something you wait a quarter to react to.

The evidence for the cadence: the Indeed AI-mention share moved only +0.1 percentage points week over week but +3.1 points year over year as of one recent reading, and it reached a high of 4.2% at the end of 2025. Week to week, nothing you would act on. Year to year, a change big enough to reclassify a skill. That gap is why quarterly works and weekly is a waste of your time.

The exception is a documented sector shock. US software development postings rose about 15% since one major coding tool launched in early 2025, while overall postings fell 7%. If your target role sits in a sector that just moved like that, re-run now rather than waiting for the calendar. No formal per-resume re-run cadence is publicly established, so treat quarterly as a well-reasoned default, not a rule handed down from anywhere.

To keep the read cheap to repeat, save your dictionary and your baseline table. Next quarter you re-pull the corpus, re-tally against the same dictionary, and diff. The diff is where the story lives: a skill that jumped ten points, a tool that dropped off, a new term you had not seen. That diff, not the raw table, is what tells you whether to touch your resume again or leave it. The first read is an afternoon. Every read after that is an hour, and it is the difference between a resume tuned to what employers want and one tuned to what they wanted a year ago.