Dayalogs

View saved version →

---
name: analyze-dayalogs-results
description: Inspect, explain, and export Dayalogs survey results through the Dayalogs MCP. Use when a user asks about response counts, completed or partial responses, selected answers, assessment scores, response confidence, version comparisons, campaign outcomes, or analysis-ready exports.
---

# Analyze Dayalogs Results

Answer the user's analytical question with the right survey version, response population, and export format.

## Workflow

1. Identify the stable survey and inspect its versions. Clarify whether the user wants all versions or a concrete version when results may differ materially.
2. Use `get_survey_stats` for the overview and `list_survey_responses` for response-level inspection. Retrieve individual responses only when needed.
3. Distinguish completed responses from partial attempts. Explain the population used in every count or percentage.
4. Use `get_survey_quality` for response confidence and quality signals. Compare versions when the user is evaluating a revised instrument or control questions.
5. For assessments, report points, maximum points, percentage, pass state, and item-level results according to the survey's configured result visibility.
6. Use campaign state and events when the question concerns delivery rather than survey answers. Keep delivery and engagement metrics distinct.
7. Choose an export based on the downstream task:
   - CSV/XLSX for human inspection and common tabular analysis.
   - SAV for SPSS workflows.
   - JSON/NDJSON for structured processing.
   - Include uploaded files only when requested and use the generated manifest to map files to responses.
8. State filters, version scope, response status, and missing-data treatment alongside the result or export.

## Interpretation Rules

- Confidence is a review signal, not proof that a respondent is human or truthful.
- A confidence score of 100 means no enabled signal fired; it is not identity verification.
- Disabled quality checks do not contribute to the global score even when their raw signals remain available.
- Do not combine versions silently when wording, logic, answer options, grading, or quotas changed.
- Treat unavailable click tracking as unavailable, never as zero engagement.
- Minimize personal data in summaries and only expose contact or link context relevant to the user's question.

## Safety

- Analysis and export do not imply permission to delete responses.
- Never call `delete_survey_response` without explicit confirmation naming the target response.
- Avoid reproducing access tokens, hidden link secrets, internal grading keys, or unnecessary contact identifiers.

## Completion

Give the answer first, followed by population, version scope, method, and caveats. For exports, name the format and what it contains, including whether partials and uploaded files were included.

Referenced files: 1

View saved version →

---
name: create-dayalogs-survey
description: Create, revise, validate, and preview Dayalogs surveys through the Dayalogs MCP. Use when a user wants to turn requirements, questions, a questionnaire, or a research brief into a new survey or a deliberate new survey version. Covers targeted authoring help, validation, explicit create/update intent, optimistic concurrency, and preview-first review.
---

# Create A Dayalogs Survey

Build a valid survey without guessing the schema or silently changing an existing survey.

## Workflow

1. Establish the survey's purpose, audience, source language, question content, required logic, and intended delivery channel. Ask only for information that materially changes the design.
2. Call `survey_authoring_help` with an empty path only when topic discovery is needed. Then request the smallest relevant paths for the question types, logic, assessment, embed, or operational behavior being used.
3. Draft the survey from those current server-side contracts. Do not rely on remembered field names when targeted help is available.
4. Call `validate_survey`. Resolve every schema and semantic error before importing.
5. Determine import intent explicitly:
   - New survey: use `import_survey` with `mode=create`.
   - Existing survey revision: first read the survey, then use `mode=update` with the stable `survey_id` and observed current `version_id` as `expected_version_id`.
   - Never use a slug collision as an implicit update instruction.
6. If the server returns `version_conflict`, stop. Tell the user who changed the survey, when it changed, and the bounded change summary returned by Dayalogs. Reconcile deliberately and obtain a fresh version before retrying. Never auto-retry by merely replacing `expected_version_id`.
7. Use `get_preview_url` and give the user the preview, not a respondent collection link. Summarize important design choices and any assumptions that still need review.
8. Revise through focused patch/append tools when appropriate, preserving the same expected-version guard. Revalidate after material structural changes.

## Safety

- Keep the survey in draft until the user explicitly asks to start collection.
- Do not call `go_live_survey` without explicit publication confirmation.
- Do not create a real share link unless the user explicitly asks for one and confirms it when required.
- Treat destructive operations, response deletion, review decisions, sends, and irreversible state changes as separate user-approved work.
- Do not expose grading answer keys or hidden respondent logic in respondent-facing copy.

## Quality Bar

- Prefer the simplest question type that preserves the user's analytical intent.
- Keep mobile completion practical: concise labels, bounded option counts, and no unnecessary introductory steps.
- Ensure conditions refer to values available before they are evaluated.
- Keep randomized blocks free of internal dependencies and repeats unless current authoring help explicitly supports them.
- For embedded surveys, consult the embedded-survey authoring guidance and design for one focused interaction per step.

## Completion

Return the survey title, stable survey id, current version id, draft status, validation result, and preview URL. Mention unresolved assumptions plainly. Never imply that a preview is live collection.

Referenced files: 1

View saved version →

---
name: launch-dayalogs-fieldwork
description: Prepare, test, launch, and monitor Dayalogs survey fieldwork through the Dayalogs MCP. Use when a user wants to publish a survey, create hosted links or LinkSets, configure an embed, import an audience, send a campaign, test delivery, apply quotas or dates, or monitor collection and campaign delivery.
---

# Launch Dayalogs Fieldwork

Move a reviewed draft into the correct collection channel without accidental publication or sending.

## Choose The Channel

- Hosted link: one reusable entry point for anonymous or metadata-driven access.
- LinkSet: a managed set of individual links, often linked to audience contacts or intended for export to another delivery channel.
- Embed: a modal placement on an approved website origin, backed by an eligible reusable share link.
- Email campaign: a Dayalogs-managed send to eligible audience contacts.

Explain the choice if the user's request could reasonably use more than one channel.

## Workflow

1. Read the current survey and confirm it is the intended version. Preview it before any public action.
2. Check collection dates, quota behavior, link metadata, audience rules, and survey compatibility for the chosen channel.
3. For audiences, use repeatable imports and inspect import status. Do not treat a transport error as proof that a chunk failed; verify the persisted import state before retrying.
4. Create or configure the channel:
   - Use share-link and LinkSet tools for hosted access and personalized links.
   - Use embed compatibility and embed tools for website placements. Restrict origins deliberately.
   - Use campaign tools for email. Preview the campaign and use `send_survey_campaign_test` before a real send when practical.
5. Ask for explicit confirmation immediately before each public or outbound action: starting collection, creating a real link when guarded, sending a campaign, retrying failed recipients, or another irreversible operation.
6. Start collection only after confirmation. Do not infer approval from the user asking for a preview, link design, or campaign draft.
7. Monitor the resulting channel. Use campaign events and campaign state for queued, sent, delivered, delayed, bounced, complaint, and failed counts.

## Delivery Rules

- Permanent email delivery failures exclude contacts from Dayalogs email campaign queues, but not from LinkSets or link exports that may be delivered through SMS, messaging, or offline channels.
- Explain excluded-recipient counts when a campaign audience is smaller than its source segment.
- Do not expose provider names as user-facing delivery statuses.
- Do not claim click tracking is active when `tracking_available` is false. Report click totals as unavailable, not zero.
- Campaigns freeze their survey version when the first real recipients are queued. Tests and unsent previews use the current version.

## Completion

Report what was created, whether collection is active, the concrete channel, audience and exclusion totals, and current delivery state. Include identifiers useful for later monitoring, but do not expose access tokens or secrets.

Referenced files: 1