Work / Story 4 of 5
Turning winner interviews into audience research
Three questions that made every interview useful for marketing, and a way to use application data without exposing anyone.
The problem
Interviews only served to pick a winner, and the brand still did not know why students choose a country or a university, or what nearly stops them.
What I did
I rebuilt the interview around three questions (why this country, why this university, what nearly stopped you), and wrote a script that summarises application data into counts only, inside the company's own Microsoft 365 system, so no individual data ever leaves it.
The result
One interview now feeds three things: the winner story, social content and a cycle-end audience brief. Individual data stays put; only totals come out.
B. Context
During my digital marketing internship at educations.com (March to August 2026), finalist interviews existed to select a winner. The brand needed something the interviews were not producing: a structured picture of why students choose a country and a university, and what nearly stops them. Over the same period the team’s focus was moving from lead volume towards qualified demand, which raised the value of audience insight. The scholarship application data held that insight, but any use beyond running the scholarship raises purpose questions that belong to Legal and the data protection officer.
C. The problem
Interviews produced stories for winner articles but no comparable signal across cycles. Finalist response rates were low, which looked like a screening problem but was not. Application data could not be exported to a personal device, and on my final day I had browser-only access to company systems. Any audience brief had to be produced inside the tenant, without row-level data leaving it, and without turning applicant data into anything that acts on an individual.
D. My role and the team
I co-conducted finalist interviews with my line manager across cycles. The five-dimension evaluation framework was set by my supervisor; I built the evaluation workbook and applied the framework to score and compare candidates. I redesigned the winner interview so answers could serve as market research, not only as a scoring input, and I worked through the reasoning that low finalist response reflected a volume problem at that stage of the funnel, recommending over-inviting at the finalist stage. On my final working day I built and ran the audience brief method myself; the screening handover already covered the scripts, so I completed this analysis before my access ended.
E. Key decisions
-
Decision: Redesign the winner interview around three fixed questions (why this country, why this university, what nearly stopped you) instead of adding a separate research survey. Why: A new survey would add a second consent event and a new collection step; a redesigned interview draws the finalist story and a market signal from one conversation applicants had already agreed to. Alternative I rejected: A standalone post-decision survey sent to winners only, which would miss non-winning finalists and add friction late in the funnel.
-
Decision: Diagnose the low interview response rate as a volume problem at the finalist stage, and respond by over-inviting rather than tightening the screening bar. Why: The pattern pointed to drop-off between invitation and response, not to weak candidates reaching that stage. Alternative I rejected: Tightening Round 1 eligibility, which would change who qualified for reasons unrelated to the funnel problem.
-
Decision: Keep every output from applicant data aggregate-only: counts, bucketed distributions and a small number of cross-tabs, with a minimum cell size and complementary suppression so a hidden cell cannot be recovered by subtraction. Why: Aggregates answer the audience questions without acting on any individual, and a single suppressed cell in a row with a visible total is not hidden at all. Alternative I rejected: Person-level segmentation or lead scoring, any join with web or CRM data, and a minimum group size alone, which was my first version until I checked the cross-tabs.
-
Decision: Run the analysis as an Office Script (TypeScript) inside the Microsoft 365 tenant, reading only the columns it needs. Why: The script reads the header row first, loads only matched columns, and a guard drops identity, contact and free-text columns even if a keyword match errs. No file lands on a personal device. Alternative I rejected: Downloading exports to a personal computer, or pasting data into external tools.
-
Decision: Finish the method and hand it over on my final day rather than leave it to a successor. Why: A documented data boundary, a runnable script and a brief template survive a handover; a half-finished analysis does not. Alternative I rejected: Leaving raw working notes and an untested idea.
F. What I built or produced
- A three-question interview core, with each answer routed to three outputs: winner story, social content, cycle-end audience brief.
- A five-dimension evaluation framework with evidence mapping and a bilingual evaluation workbook (English decision-support file, separate internal working notes).
- An execution plan defining the data boundary: view-only access in the browser, processing inside the tenant, only aggregate numbers and short phrases crossing out.
- An Office Script that outputs distributions, bucketed bands and three cross-tabs with no row or column totals, plus a diagnostics block listing which columns were matched and how many were read.
- An audience brief format with per-function sections and a how-to-repeat section.
- A short note accompanying the brief stating what the safeguards do and do not establish: they reduce identification risk; they do not decide whether the analysis falls within an approved purpose, which is for Legal and the data protection officer.
- A proposal for an optional, purpose-labelled question block on future application forms, kept out of screening files.
G. Result
- The execution plan, the script and the audience brief were completed on my final day and left with the team.
- The brief design covers view categories only: origin markets, destination countries, subject demand, journey stage, discovery channel and phrase-level language patterns from sampled essays. No value derived from applicant data appears in this case and none will be added to any later version.
- Interview insights fed the published winner articles and the social content cut from them.
- The durable result is a repeatable method: a successor can run the same script each cycle and produce a comparable brief.
H. What I would do differently
- Fix the interview questions before the first campaign, so every cycle produces comparable answers instead of retrofitting comparability later.
- Freeze a brief template with the same tables in the same order each cycle, so movement between cycles is visible without rework.
- Bring the data protection officer in at design time rather than at handover. A short written description of the planned aggregation, thresholds and columns would have turned a late open question into an early written answer.
I. Evidence assets
- Interview question set and its routing to three outputs: Anonymised description, Tier B (my method).
- Data boundary and suppression logic diagram, redrawn without internal content: Anonymised diagram, Tier B.
- Published winner articles on educations.com: Public link, Tier A.
- Public scholarship terms and privacy policy pages that frame the purpose limits: Public link, Tier A.
- The audience brief, the Office Script source, the execution plan document and the evaluation workbook: Tier C, not shown.
J. Keywords
Audience insight; Voice of the customer; Market research; Funnel diagnostics; Qualified demand; Data minimisation; Privacy by design; Office Scripts; TypeScript; Microsoft 365 automation; Higher education marketing; Stakeholder handover