How to create a buyer persona from customer data

Start a buyer persona with the offer, the person evaluating it, and the decision they need to make. For a scraping tool, you could study an SEO agency lead deciding whether to try a public web collection tool on a client research project. If a technical lead checks access and a director approves the expense, record those roles separately. Confirm who actually does each job.

Use your ideal customer profile, or ICP, to choose which customers or organizations to study. The buyer persona then explains how a person within that group evaluates one offer. If an attribute such as company size affects your ability to serve a customer, it belongs in the ICP. If an attribute such as the need to show sources to a client changes the proof the person expects, it belongs in the buyer persona.

Build a buyer persona from decisions people can describe. Talk to recent buyers, people who picked another option, and people who postponed the decision. Start with “Take me back to when you first decided to look for a solution.” Ask what they were doing at the time, what they tried next, who joined the decision, and which concerns they still had after seeing a demo or sample.

Compare those accounts with authorized sales notes, support questions, or survey answers. Keep identifiable customer records in approved research systems and share only the de-identified excerpts needed for the persona. A sales note can show that someone asked about a feature. Ask the buyer what made that question matter before you treat it as a purchase criterion. If you start with public discussions or reviews, save the URL and the date, capture the relevant passage, and label the contributor’s role only when they state it. For a local business example, open the recorded Google Maps review sample. Check the listing, capture date, and how many reviews were collected before using a comment to shape an interview question.

In a November 7, 2026 Google Maps capture for Formula Roofing and Remodeling, MCP Scraper requested five reviews and collected five from one listing. The example review in the public capture receipt praises the experience from start to finish. The published excerpt leaves the reviewer’s role, roofing service and reason for hiring unknown. Ask a recent buyer, “What did you check before choosing a roofer, and what happened after you hired them?” If they describe good communication only after hiring, keep it as delivery feedback. Record it as a buying criterion only when the buyer explains how it influenced the choice.

MCP Scraper can help you read selected public pages as part of this research. Use search to find relevant discussions, then extract the specific pages you need to inspect. In our November 7, 2026 API-key test, MCP Scraper extracted a public documentation page and returned its expected URL and the heading “Understanding MCP servers.” Use the first-use walkthrough to repeat the check. The search results versus page extraction guide explains how to choose the collection step. The test covered one public page. Confirm that each capture includes the passage you plan to use.

For each buyer persona evidence row, record the source, date, decision context, stated role, what the person said or did, and your interpretation. Then add the question you would ask to check the interpretation. You can do this in a spreadsheet with one row per decision record.

Check an interview claim against a behavior you can observe in authorized records. For example, if an evaluator says an export sample helped them choose a scraper, look for the sample view before a trial started. If you only have channel analytics, compare where visitors drop off or continue, but keep those totals separate from the individual interview. A sample view can confirm the sequence when the records can be linked. Ask the buyer what the sample helped them decide before you record it as a reason for choosing.

If three comments repeat one account of a decision, count one decision record. If a different buyer needed broad coverage to deliver the work, keep that case. The contrast can tell you when a proof point matters and when another matters more. Give stronger wording to a pattern only when the evidence supports it. Leave the size of the audience open unless you have data that can measure it.

A one-page buyer persona should give your team enough context to write or revise a message for one buyer. Fill these fields from your evidence rows.

• Offer and role. Name what the person is evaluating and what part of the decision they own.
• Trigger and job. Describe the event that prompted the search and the result they need to deliver.
• Alternatives. Record what they already use or could keep using, including a manual workflow.
• Objection and consequence. State what could stop the purchase and why it matters to their work.
• Required proof. Name the sample, demo, terms, or evidence that would help answer the objection.
• Next message and unknowns. Write the message you want to test, link to its evidence, and list any questions you still need to ask.

Keep the brief dated. If you update an interpretation after a buyer conversation, retain the underlying source and note what changed. If the team will need to revisit selected public captures for a future brief, the Memory Vault guide shows how to save and retrieve source evidence deliberately.

Here is a provisional buyer persona for a digital agency evaluating a public web collection tool. In the market analysis discussion, the author reported scraping every search result and running into access, speed, and cost problems. In the job-posting discussion, the author wanted job postings from a list of domains and reported that their first workflow was slow and expensive. Ask which sources and fields an evaluator needs. The agency role and purchase criteria below are hypotheses to check with actual evaluators.

See what this proof can look like in the recorded search-to-source example. It shows one source URL and a freshness condition the search snippet left out. Before showing the sample, ask: “Think about the last time you evaluated a scraper for a real brief. What did you check before deciding whether to try it, and what was still missing?” Record what the evaluator checked and why it mattered.

Use a buyer persona to make one testable messaging decision. If evaluators hesitate because they cannot verify where a claim came from, put a sample result next to the trial link. Include the source URL, one checked excerpt, and the limit of the sample. Ask an evaluator to find the original passage and describe what evidence they would still need before trying the workflow.

Ask what would stop the trial even after the evaluator checks the source. If their brief needs coverage across every target, record that as a separate requirement. Test a defined source list before leading with the one-page sample. Keep the proof preference provisional until you know which check affects the trial decision.

If you can run a controlled test, define the audience and what you will measure before changing the page. For this example, you could measure how often qualified evaluators open the sample and then start a trial. Keep other changes separate where practical and record the dates. If you have only a few interviews, use their responses to refine the wording and look for exceptions. Update the persona when new evidence changes the decision you expected the buyer to make.

Evaluator: An agency researcher evaluating a scraper for a real client brief.
Single change: Show the same trial message with and without the linked search-to-source example.
Observe: Can the evaluator find the original passage? What would still prevent a trial?
Decision rule: If source coverage remains the objection, test a defined list of sources before changing the message.
Result: Unmeasured.