Short version — Dayalogs separates survey design, audience preparation, LinkSet creation, campaign sending, and response collection. That gives teams more control and lets each project use the workflow that fits best.
Survey design
Questions, blocks, presentation rules, conditions, variables, languages, and quotas define what the survey is.
Fieldwork setup
Audiences, contacts, LinkSets, and campaigns define who gets the survey and how they receive it.
Collected data
Responses are what comes back once the survey is live and respondents start using real links.
How the model fits together
At a high level, Dayalogs works like this: you prepare a survey, decide who should receive it, generate the right links, optionally send invitations, and then collect and export responses.
A quick mental model is: surveys define the questionnaire, audiences define the people, LinkSets define the links, campaigns define the send, and responses define the collected data.
Understanding a few technical terms
You do not need to be technical to use Dayalogs. Still, a few terms appear often in the help center because they make the product easier to explain. Your AI assistant and the Dayalogs MCP handle most of this for you.
MCP
MCP is the connection layer that lets AI tools like Claude, ChatGPT, Codex, Grok or Manus work directly with Dayalogs.
Structured data
Structured data means information stored in a predictable shape, such as contacts, CRM records, product lists, household members, or any other organized dataset.
Schema-first
Internally, Dayalogs describes surveys with a clear structured format before anything is rendered or published.
JSON schema
JSON schema is the formal contract behind that internal survey structure.
Core concepts
Survey
The questionnaire itself: wording, questions, logic, endings, languages, and collection settings.
Audience
The pool of people you may want to contact for one or more surveys.
Contact
An individual person record with fields like name, email, phone, and extra structured data.
LinkSet
A managed set of links for one survey.
Campaign
The email send layer that sits on top of a LinkSet.
Response
A stored survey submission, complete or partial depending on the survey rules.
Variables
Named values that the survey can use while it runs.
Hidden fields
Values that should travel with the response without being shown as a normal visible question.
Quotas
Collection limits that stop responses once a target is full.
Blocks
Logical units in the survey flow.
Pages
The respondent-facing screens that group questions into steps.
Conditions
The rules that decide whether a block, question, or path should appear.
Survey lifecycle
Most projects move through the same stages, even when the exact workflow differs by team. Dayalogs keeps those stages visible so people know whether they are still preparing, reviewing, collecting, or closing down a survey.
Draft
The survey exists, but it is still being built, checked, or adjusted.
Review
The survey is stable enough to collect internal feedback before fieldwork starts.
Publish
The survey is ready to collect real responses through live links.
Pause
Collection is temporarily stopped without deleting the survey or its history.
Archive
The survey is no longer part of active fieldwork, but its structure and results remain available for reference and export.
Relationship map
The chart above is the shortest useful way to read the Dayalogs model: a survey moves from draft to published fieldwork, contacts flow in through audiences and LinkSets, campaigns sit on top when you want Dayalogs to send the invitations, and everything ends in responses and exports.