Audience research
Part of Platform audience research that keeps seven buyer populations separate
Platform buyer personas as evidence summaries you can retire, not characters you polish
Build ecommerce platform buyer personas as traceable evidence summaries with defined samples, dates, contradictions and limits, never fictional certainty.
Platform buyer personas are evidence summaries for a specific platform decision, not polished characters. Each one names an operating role, a current task and an observed constraint inside a dated sample. A fictional name, portrait and backstory add apparent certainty without evidence.
The method suits buyers shortlisting Shopify, WooCommerce, BigCommerce, Adobe Commerce and EKM, and the agencies running that research. No personas or buyer findings are reported here. What follows produces bounded summaries after authorised research.
What to take away
- A persona is an evidence summary for a platform decision, not a polished character with a fictional name.
- Give each persona a functional label that describes the task, not a person.
- Put the platform shortlist and the decision date on the card, so a Shopify review is not reused for a move to Adobe Commerce.
- Attach a visible evidence card with decision scope, sample, fieldwork, evidence, variation, limits and owner.
- Keep observation and interpretation apart, and record what participants did before drawing conclusions.
- Retire personas when evidence ages, the task changes or later sessions contradict the pattern.
Give the persona a functional label
Use a label that describes the task, not a person: "Shopify merchant reconciling refunds", "WooCommerce operator preparing a VAT export file", "marketplace seller assembling catalogue evidence for Amazon". Keep merchant buyers, staff users, marketplace sellers, adult consumers and suppliers in separate records.
A trade counter user raising a quotation in EKM is a different record from a Shopify Plus buyer approving purchase orders. A supplier logging a delivery dispute belongs in its own file too.
The Government Service Manual advises teams to turn assumptions into research questions and develop profiles from what they learn in its research-planning guidance. A stakeholder's imagined customer is therefore an assumption, not a persona finding. Write the shortlist and the decision date next to the label.
Attach a visible evidence card
Every persona needs these fields:
Persona evidence card fields
- Decision scopeshortlist and decision date
- Populationrole and eligibility rule
- Sampleframe, invitations, completed cases
- Fieldworkdates, method, instrument version
- Evidencerepeated task with source references
- Variationcontradictory cases and missing groups
- Limitswhat the study cannot generalise
Field / Required entry
- Decision scope
- merchant, operation, platform shortlist (for example Shopify, BigCommerce, WooCommerce) and decision date
- Population
- role and observable eligibility rule
- Sample
- frame, invitations, eligible and completed cases
- Fieldwork
- dates, method and instrument version
- Evidence
- repeated task, event or constraint, with source references such as a screen, ticket or invoice
- Variation
- contradictory cases and missing groups
- Limits
- what the study cannot generalise
- Owner
- researcher and next review date
If a pattern appeared in only part of a purposive sample, state the count and denominator for that sample. Do not convert it into an England percentage. Record missing responses rather than assigning the most plausible answer.
A repeated hunt for the export button in the WooCommerce admin covers only the participants who ran that export task. It says nothing about merchants who never export, on WooCommerce or anywhere else.
Keep observation and interpretation apart
First record what a participant did or said about a recent event. Then write the researcher's interpretation. A final field can state the proposed procurement implication. GOV.UK's session-analysis method separates observations from findings and recommends collaborative analysis to reduce individual bias.
Platform cost evidence pack
- £1,600–£2,000/monthShopify Plus typical quote
- Tens of thousands/yearAdobe Commerce licence
- £5–£40/monthWooCommerce hosting
- ~£30/monthBigCommerce Standard plan
Observation vs interpretation vs implication
Observation
- What was recorded
- Participant failed export task
- Source
- Session notes
- Claim strength
- Direct event
- Can it prove platform lacks feature?
- No
Interpretation
- What was recorded
- Researcher reads difficulty
- Source
- Researcher analysis
- Claim strength
- Bias-prone
- Can it prove platform lacks feature?
- No
Procurement implication
- What was recorded
- Buyer may need product evidence
- Source
- Vendor docs or trial
- Claim strength
- Decision-dependent
- Can it prove platform lacks feature?
- No
For example, an authorised participant may fail to locate an export control in a defined task. The observation does not establish that the platform lacks export, that every user will struggle or that migration is required.
Those are separate claims needing product evidence, more research or a buyer decision. Product evidence comes from vendor documentation, a paid trial or a sandbox in Shopify or BigCommerce. It does not come from the persona.
Record vendor cost in the same evidence pack. As of 2026, Shopify Plus is typically quoted from around £1,600 to £2,000 a month, and Adobe Commerce licences typically run to tens of thousands of pounds a year.
WooCommerce is free, with hosting typically £5 to £40 a month. BigCommerce publishes a Standard plan around £30 a month, with quote-based pricing above it.
Do not fill gaps with identity clues
Exclude names, stock portraits and inferred age. Leave out ethnicity, health, disability and turnover. Authority and technical confidence are not persona fields either.
A postcode can indicate an address in the sample, not a person's needs or an organisation's size. Device data from Google Analytics 4 describes an observed configuration, not skill.
Collect only data needed for the stated decision. The ICO's research processing guidance requires a lawful basis and a separate condition where special-category data is necessary. Ethical participation consent does not automatically supply that lawful basis.
When reporting, remove direct identifiers and control indirect combinations that could expose a small merchant or staff member. GOV.UK's participant-privacy guidance recommends anonymised extracts where possible and restricted sharing where identification remains possible.
Retire personas rather than polishing them
Version the card and link it to authorised notes, not copied profiles. Retire it when the contract or platform route changes. Retire it when the task changes, the evidence ages beyond the decision window, the sample cannot be traced or later sessions contradict the pattern.
Retire or keep the persona?
Has the contract, platform route or task changed?
Retire and version the card
Keep and review at next date
If the evidence is weak, leave the item in an assumptions register with a new research question.
Platform routes move. A persona built for a WooCommerce shop with two plugins can survive a move to Shopify, but only if the task and constraint survived the migration. A card from a 2023 BigCommerce review should not steer a 2026 decision without new fieldwork.
Keep the card in the same repository as the research, whether that is Notion, Confluence, Dovetail or a shared drive.
The persona should help a buyer specify a task, test or support route. It must not choose a supplier, predict demand or imply that a handful of participants represent England.
Before you act
- Label the persona by operating role and task.
- Put the platform shortlist and decision date on the card.
- Attach a visible evidence card with required fields.
- Separate observation from interpretation and procurement implication.
- Exclude names, portraits and inferred identity clues.
- Version the card and link it to authorised notes.
- Retire the persona when evidence ages or is contradicted.
Common questions
What should a buyer persona contain to be useful for a platform decision?
It should identify an operating role, current task and observed constraint within a dated sample. It needs a functional label and a visible evidence card covering decision scope, population, sample, fieldwork, evidence, variation, limits and owner. Name the platform shortlist and the decision date too. A fictional name, portrait and backstory add apparent certainty without evidence.
How should researchers handle observation and interpretation in a persona?
First record what a participant did or said about a recent event. Then write the researcher's interpretation. A final field can state the proposed procurement implication. GOV.UK's session-analysis method separates observations from findings and recommends collaborative analysis to reduce individual bias. The observation does not establish broader claims.
When should a persona be retired rather than polished?
Retire it when the contract, platform route or task changes, evidence ages beyond the decision window, the sample cannot be traced, or later sessions contradict the pattern. If the evidence is weak, leave the item in an assumptions register with a new research question. Version the card and link it to authorised notes.
