Practical tools for better CPG decisions.
Quest
Structured tests, without the blank survey.
Quest ships the method already configured. Pick what you need to learn and it produces a correctly designed test, a participant experience that works on any phone, and an evidence package at the end.
A blank survey is the most expensive object in research.
Give a category manager an empty questionnaire builder and three things happen. The scale gets invented on the spot, the samples are not blinded, and the analysis at the end is a bar chart with no test behind it.
None of that is a software problem. It is a methodology problem, and it is why most small CPG tests produce a number nobody is willing to put in a deck.
Quest starts from the decision instead. You say what you need to know. It brings the design, the wording, the randomisation, the statistics and the limits.
Six families. One shape.
Different questions and different statistics, wrapped in the same five stages, so nothing new has to be learned per test.
Is the attribute at the right level, do people like it, and which of two samples wins. The core reformulation questions.
Concept testingScreen an idea before it costs anything, with a purchase intent scale that behaves the same way every time you use it.
SensoryBlinded samples, three digit codes, randomised presentation order, carried in the design rather than in a facilitator's memory.
PackagingHead to head pack comparison with forced choice and an optional no preference option, reported separately.
PricingSimple price acceptability at a small scale, with claim limits that stop the result being read as a demand curve.
Consumer feedbackLightweight open feedback that still arrives as structured rows with defined fields.
The security property is physical.
A Quest generates two artifacts. The participant file can write responses and nothing else. The manager file can read, merge, analyse and seal, and it carries its key encrypted.
You cannot leak the ability to read results by handing out the wrong file, because that capability is not inside it. Access is a capability, not a login.
Runs the instrument. Hand it out freely, print the QR, put it on a tablet at a sampling table. It cannot read a single response back.
Collects, merges, analyses, exports and seals the archive. The read key inside is encrypted with a passphrase, so the file alone is useless.
The record. Renders itself in any browser with no tooling, with the evidence JSON embedded inside it. You keep it. We do not need a copy.
Three positions, chosen deliberately.
| Mode | Data path | What it means for you |
|---|---|---|
| Local only Default | Stays on the device | Nothing to review, nothing to sign. Also the fallback when anything else fails. |
| Bring your own destination | Browser to your Sheet, Airtable, flow or endpoint | Data never transits our servers. A defensible statement rather than marketing language. |
| Surve hosted | Browser to our collection endpoint | Zero setup while the test runs. Retention is stated on the consent screen and responses expire. |
The rule is webhooks, not API keys. A webhook URL is a write-only capability by design and cannot return data. An API key sitting inside a participant file is a live credential handed to strangers.
The whole flow is on this site.
Configure a JAR test, generate it, answer it on a simulated phone, watch the results build, then download the real files.
One platform. Five specialized consoles.
Everything here runs in your browser on demo data. Pick the console that matches what you are trying to do, then open an instrument directly. Each console keeps its own work.
Connect with an expert from our network to tailor a solution that matches your business needs. The standard instruments stay free; customization is where the work happens.
When the instrument becomes a workflow.
The tools on this site are deliberately small. Sooner or later a useful test stops being an event and becomes something a team runs every month, feeding a system that already exists inside your business. That is the work.
A method your category needs that is not in the template library. Designed, implemented, validated against a reference statistical package and documented so it survives you leaving the room.
Getting evidence out of instruments and into somewhere durable. Power Automate, SharePoint, Dataverse, Excel, or a plain warehouse table with a schema that will not embarrass anyone.
Not another twenty tab report. A small number of models that answer the questions the business actually argues about, with the measures documented.
The unglamorous layer between a form, an approval and a system of record. Usually the difference between a process being followed and being ignored.
Your ERP, your syndicated data, your retailer portals and your instrument output, joined once, properly, with the join logic written down.
Where a study genuinely requires trained sensory panels or recruited consumers, that work is coordinated with specialists. The instrument and the evidence trail stay consistent.
The tools are the proposal.
There is no pitch deck stage. The free instruments on this site demonstrate the methodology, the engineering and the standard of evidence. If they are useful, the extension of them into your environment is a short conversation rather than a procurement exercise.
Assure
Readiness without the spreadsheet chaos.
Assure does not give regulatory advice and it is not a compliance robot. It is a structured way to find out what you are missing, in an order that makes sense, and to leave behind an evidence file that shows the assessment was done.
Collect. Validate. Route. Evidence.
Readiness work fails in the same place every time. The data exists, but it lives in four systems and two people's heads, and nobody can say what is missing without a week of chasing. Assure turns that into a short structured assessment with a score, a gap list and a next action.
Three working instruments.
Eight weighted questions about what you hold today, a readiness score and a prioritised gap list.
Open instrumentScreen demo nutrient inputs against illustrative thresholds and see where a review is likely needed.
Open instrumentFive weighted categories, one readiness position, and a clear view of what is actually blocking.
Open instrumentThese tools use fictional inputs to demonstrate a workflow. They do not interpret legislation and they are not a substitute for verifying current official requirements with the relevant authority or your own regulatory counsel.
An assessment is an artifact too.
There are no participants here, so there is no two file split. A single sealed file per assessment, dated and versioned.
Every answer, the weighting applied, the score derivation and the gaps identified. The kind of thing you want to be able to produce two years later.
The gap list is structured, so it can drive a Power Automate flow, a task list or a supplier data request without being retyped.
Signals
See what is changing before it becomes obvious.
Signals tracks movement in the categories you sell into and publishes it as evidence rather than opinion. Each signal states what changed, what the observation rests on, why it might matter, and what to investigate next.
A monitor, not a report.
Data becomes a signal.
A signal becomes a point of view.
The same pipeline that fills this dashboard produces the category reports, the newsletter and the published commentary. The human role is review and approval, not writing each post from a blank page.
The discipline that makes this defensible is the same one used everywhere else on this site. Interpretation is always separated from observation, and the evidence behind a claim travels with the claim.
Engage
Tailored digital engagement experiences for CPG.
Structured consumer participation, from a one question pulse to a branded game. Gamification is an experience layer, not the point.
One console, three ways to ask.
All three write the same evidence format, so a game and a questionnaire produce comparable, defined fields.
Quick surveys, multi-question questionnaires and polls. Defined scales, defined fields, and a stated limit on what the answers support.
- Quick Survey Live
- Multi-question Survey
- Poll
Quick reactions, preferences, comparisons and rankings. The instruments people actually finish while standing up.
- Quick Pulse Live
- Pick and Rank
- Swipe and Compare
Quizzes, puzzles, jigsaws, challenges and sweepstakes. Rewards and incentives drive participation; the data collection underneath stays structured.
- Quiz and Reveal
- Puzzle · Jigsaw · Challenge
- Sweepstakes with rewards
An experience layer, not an excuse.
A quiz gets more completions than a questionnaire. That is a real advantage and it is also where engagement work usually goes wrong: the mechanic starts driving the questions, and what comes back cannot be used for anything.
In Engage the instrument is designed first and the experience is wrapped around it. Rewards sit outside the response data, so an incentivised sample stays a labelled, usable dataset instead of a marketing list with opinions attached.
Two experiences run end to end today.
Quick Pulse and Quick Survey are live in the console, with the participant view, local collection and evidence export. The rest are specified and share the same engine.
Activate
Most sampling produces a headcount.
Activate is the field instrument. A QR code at a sampling table, a demo, a market stall or a store activation, answered on the participant's own phone, collected write-only, and sealed into an evidence archive at the end of the day.
A clipboard and a vague number.
Most sampling activations today produce two things: an approximate headcount and a rep's impression of how it went. Both disappear within a week, and neither survives a conversation with a retailer.
Turning that same afternoon into a governed dataset requires no facilities and no panel. It requires an instrument, a code on the table, and somewhere defensible for the answers to land.
Anywhere people are already standing.
Taste, then scan. The instrument runs on their phone, which removes the queue at your tablet.
In-aisle demos where the question is whether the pack, the price or the product is doing the work.
Where a brand already has attention and no way of recording what it learned.
Menu tests and limited-time offers, where the sample is naturally captive and the window is short.
The same instrument applies to events, foodservice, personal care, cultural venues and public consultation. Generality is a property to have, not a market to chase. It is built for CPG sampling, and an inbound from another sector is a gift rather than a strategy.
Methodology, made small enough to use.
Surve exists because the gap in CPG decision making is rarely a shortage of data or a shortage of intelligence. It is that the small, ordinary tests which would settle an argument in an afternoon are still treated as projects, so they never happen, and the decision gets made on instinct instead.
The value was never the software.
Anyone can generate a form. Modern AI can write the code for one in seconds, and will do it better every year. What it cannot do on your behalf is decide that a paired preference test with blinded three digit codes and randomised presentation order is the right instrument for the question, or state afterwards which claims the result will and will not support.
That is the layer Surve occupies. Methodology, structure, governance, evidence and orchestration. The intelligence layer stays with you, in whichever system you already trust.
Then take it into whatever intelligence system your organisation already uses.
What we hold ourselves to.
Every test implemented in a Surve instrument is validated against a reference statistical package and, where they exist, against published significance tables for that method. The test used is named in the evidence file.
Everything on this site runs on fictional data generated in your browser. It is marked as demo data wherever it appears, including inside the files you can export.
A result from twenty four people is a real result at that sample size and nothing more. Instruments say so explicitly, in the file, so the number cannot quietly grow legs on the way to a deck.
Assure structures readiness work and produces evidence of it. It does not interpret legislation, and it points you at the official requirement rather than restating it.
Participant identifiers are random values. IP addresses are never collected. Provenance is recorded with a station field, which answers the real question without creating an obligation.
The instrument index states what is live, what is specified and what is deliberately frozen. Nothing on this site claims a capability that does not exist yet.
Built from the inside of the category.
Surve comes out of years spent close to CPG measurement, retail data and the arguments that happen in line reviews. It is rooted in Canada, where a mid sized manufacturer carries the same evidence burden as a multinational with none of the research budget, and it is built to a standard that travels.
The engineering follows the same instinct. Small tools, open formats, files the client keeps, and infrastructure light enough that a useful instrument can exist without a platform being sold first.
What is specified,
and what is only an idea.
Being explicit about this is part of the method. A roadmap item is not a feature, and neither is worth pretending about.
Engage, Quest, Activate, Assure and Signals exist as working environments. Several instruments in each are interactive here, on demo data.
Every instrument named in a console is architecturally defined. The ones marked Specified have the design settled and the interface not yet built.
A consumer facing companion app, where participation history and rewards would live with the person rather than the brand. Recorded here as a concept only. It is not designed, not scheduled and not built.
Start with one small test.
It is the fastest way to see whether any of this is useful to you.
Quest Evidence Format 1.0
A published format is what turns a tool into a methodology. This is the structure every Surve instrument writes. It is versioned, self-describing and designed to be read correctly by a person, a spreadsheet or a language model with no product from us in the middle.
Why it is the only irreversible decision
A console can be rebuilt at any time. Files cannot. Every archive generated before a schema change is permanent, and if the format is missing something those files render poorly forever. So the format gets the care, and everything else can move fast.
Round trip
- JSON regenerates the HTML archive.
- JSON regenerates the CSV.
- CSV regenerates neither, which is the point.
The JSON is a superset of the CSV. The duplication is intentional and costs about twenty kilobytes, so each file stands alone for its own job.
Non-negotiables
- schema_version present in the very first file ever generated. Without it no later change is safe.
- Every rendering relevant field carried, not just the data, or regeneration is lossy.
- Boring, explicit field names. You will be reading them in three years.
- Compound extensions rather than custom ones. .quest.json and .quest.html stay openable everywhere and still read as ours.
Field reference
| Field | Type | Purpose |
|---|---|---|
| schema_version | string | Format version. Fixed at write time and never rewritten. |
| generated_at | ISO 8601 | When the archive was sealed. |
| instrument | object | Template type, version, the exact question wording and the scale definition. |
| design | object | Blinding, presentation order, sample coding, stations, participant target. |
| analysis | object | The named test, the null hypothesis, alpha, and how edge cases were handled. |
| results | object | Counts, statistics and the derived values shown in the archive. |
| interpretation | string | Plain language reading of the result, written out rather than implied. |
| claim_limits | array | What this result may and may not be used to say. |
| limitations | array | Design and sample constraints stated in the file, not in a footnote. |
| field_definitions | object | What every column in the response rows means. |
| responses | array | Every row that is also in the CSV, so the file stands alone. |
Surve Quest
Structured tests, without the blank survey.
How Surve thinks about CPG research.
Surve is not a form builder with a nicer theme. Every instrument is an established CPG practice, shipped already configured, with the analysis and the claim limits attached. This page is the thinking underneath the software.
Surve creates the instrument.
Your systems keep the intelligence.
Surve is not trying to be your analytics platform, your AI assistant or your data warehouse. It sits earlier than all of them. It makes sure the activity was designed properly, run properly and recorded in a structure that everything downstream can read.
Every Quest ends in CSV, JSON and a self-rendering archive. Structured so your team can continue the work in Excel, Power BI, ChatGPT, Copilot or your own analytics environment.
One idea.
One instrument.
One evidence trail.
Five stages, the same five every time. Learn one Surve instrument and you have learned all of them.
Pick the question you are trying to answer. Surve picks the method that answers it.
Name the samples, the attribute and the number of participants. Nothing else to decide.
A link or a QR code. Participants answer on their own phones in under ninety seconds.
Responses land where you chose. Local, your own destination, or hosted while the test runs.
Analysis, limits and raw rows, sealed into an archive you keep. The tool is disposable.
A spreadsheet forgets.
An evidence package does not.
Numbers alone lose the method that produced them. Six months later nobody remembers whether the samples were blinded, what the scale meant or what the result was allowed to support.
Every Surve instrument writes one self-describing file. Method, design, field definitions, analysis, limitations and claim boundaries travel with the data, so any person or model reading it later reads it correctly.
- Self-describing
Field definitions live inside the file. No data dictionary to lose.
- Reproducible
The JSON regenerates the human-readable archive and the CSV. The reverse is not true.
- Bounded
Claim limits are part of the output, not a policy page nobody reads.
Disposable instruments.
Permanent artifacts.
No accounts, no onboarding, no platform to adopt. A Surve tool is a governed calculator that hands everything back and forgets you were there.
The default mode keeps responses on the device. Nothing transits our servers unless you deliberately choose hosted collection.
Point a test at your own Google Sheet, Airtable base or Power Automate flow. It lands in your tenant, already approved by your IT team.
Method statement, consent language, retention and claim limits are fields in the output file, not promises in a contract.
Every artifact carries its schema version, instrument version and the exact analysis performed, so a result can be rebuilt years later.
Open formats, published schema, client-held files. If Surve disappeared tomorrow your evidence would still open and still parse.
Deliberately narrow.
The most useful thing a small tool can do is know exactly where it stops. Surve produces the instrument and the evidence. Everything to the right of that line is already solved by software your company owns.
| Surve does not replace | Because |
|---|---|
| ChatGPT, Claude, Copilot | They interpret evidence. Surve produces evidence they can read without a plugin. |
| Power BI, Fabric, warehouses | They hold the intelligence layer. Surve writes into it. |
| Qualtrics, SurveyMonkey | They are blank canvases. Surve ships the method already configured. |
| CRM and project tools | They track work. Surve produces one artifact per activity and stops. |
Five environments,
one evidence format.
The consoles are separate because the work is separate. What makes them one platform is the file that comes out the other end.
| Console | The question it answers | What it hands on |
|---|---|---|
| Engage | What do people say when we ask them directly? | Responses and an evidence file, ready for Activate to distribute |
| Quest | Is B actually different from A, and by how much? | A tested result with the claim boundary stated |
| Activate | How do we run this instrument in the real world? | Station-tagged responses back into the source console |
| Assure | Are we ready to submit, label or launch? | A dated readiness artifact with the gaps named |
| Signals | What changed in the category, and what rests on it? | A signal that becomes the next Quest or Engage run |
Every instrument here is meant to be run by the team that needs the answer, without a research vendor in the middle. That constraint is what keeps the instruments small, the wording fixed and the output structured.
The method is the product.
The software is just the part you can click.
Turn collected evidence and external signals into decision-ready intelligence.
Consoles are where work gets done. Dashboards are where it gets understood. Each one is its own environment, running on fictional demo data in your browser.
SurveSignals
What is moving in your categories.