持续用户研究

Automatically run a lightweight diary study and turn it into weekly product signals and experiment-ready recommendations.

When to use

• - The team must decide what to build, fix, or prioritize and needs behavior evidence over time, not one-off opinions.
• A founder or PM asks for scoped weekly learning (for example, onboarding drop-off causes this week).
• You need to compare what people report with what they actually do across days or touchpoints.
• You need low-overhead, repeatable diary loops tied to one explicit research goal.
• You need actionable weekly outputs with direct experiment plans.

When not to use

• - The request is only broad brand sentiment with no product decision attached.
• The team needs statistically representative market sizing instead of qualitative behavior understanding.
• The study context is high-risk regulated or sensitive (medical, legal, minors, government) without dedicated compliance design.
• The required data can be answered with existing telemetry alone and no user context is needed.
• You cannot secure participant consent, secure storage, and redaction safeguards.

Security & Permissions

• - Minimize access: only access participant contact data, diary entries, and tool scopes required for this study.
• Redact by default: remove names, emails, phone numbers, handles, account IDs, exact addresses, and direct identifiers from all synthesized outputs.
• Keep raw and reports separate: store raw unredacted entries in a restricted location; publish only redacted report artifacts.
• No secret exfiltration: never copy API keys, tokens, credentials, or hidden configs into prompts, reports, or tickets.
• No unnecessary filesystem/shell actions: prefer explicit API-based tool calls (Slack/Email/Notion/Linear/GitHub APIs) and avoid opaque shell operations.
• Multimedia controls: store attachments in restricted buckets/folders, enforce signed URL expiry, and reference attachment IDs in reports instead of raw files.
• Retention discipline: define and enforce retention windows per study; delete or anonymize raw data after the retention window.
• Auditability: log consent status, prompt schedule events, reminder events, and report generation events.

Credential contract:

• - Always required (all deployments):
• INLINECODE0: runtime profile selector used to choose enabled integrations and routing mode.
• INLINECODE1: restricted location for raw entries.
• INLINECODE2: redacted report output location.
• INLINECODE3: deterministic redaction tokenization salt.
• Conditional (only when integration enabled):
• Notion: RESEARCH_NOTION_TOKEN, RESEARCH_NOTION_DATABASE_ID.
• Slack: RESEARCH_SLACK_BOT_TOKEN, RESEARCH_SLACK_SIGNING_SECRET.
• Email: RESEARCH_EMAIL_PROVIDER, RESEARCH_EMAIL_API_KEY, RESEARCH_EMAIL_FROM.
• Optional ticket sync: RESEARCH_LINEAR_TOKEN, RESEARCH_LINEAR_TEAM_ID, RESEARCH_GITHUB_TOKEN, RESEARCH_GITHUB_REPO.

Profile selector note:

• - Example values: core, slack, email, notion, mixed.
• INLINECODE20 is a non-secret selector and does not grant external API access.

Strict rule:

• - Unset tokens for disabled integrations; do not preload unused credentials.

Scope anchor + supported study types

Primary scope anchor:

• - Founder/PM request: "Track onboarding drop-offs this week and tell me what to fix."

Support these study types in the same workflow:

• - Habits/frequency: understand repeated usage cadence for feature X.
• Motivations/emotions: understand why users choose or avoid task Y and how that changes over time.
• Journey progression: map research -> decision -> purchase touchpoints and friction points.
• Channel/device comparisons: compare behavior by channel, device, or context across a week.
• General behavior tracking: broad behavior shifts inside a defined product scope.

Rule:

• - Use the primary user story as a scope anchor only.
• Keep method flexible so one skill run can execute any supported study type above.

Diary study timeline

A) Plan

1. 1. Define the decision to inform and one clear study goal.
2. Write 3-7 research questions tied to that decision.
3. Choose focus type:

• - broad_behavior: wide behavior context.
• INLINECODE22: product feature/flow usage.
• INLINECODE23: one behavior or task.
• INLINECODE24: multi-stage touchpoint progression.

1. 4. Choose timing mode:

• - signal default for lightweight studies.
• INLINECODE26 for rare/high-value moments.
• INLINECODE27 for high-frequency habits.
• INLINECODE28 when one mode is insufficient.

1. 5. Set duration using expected event frequency:

• - Daily/high frequency: 5-10 days.
• Medium frequency: 10-14 days.
• Rare events: 14-28 days.

1. 6. Select tools (Notion/Airtable/Google Sheets optional) and storage boundaries.
2. Define participant profile and segmentation tags.
3. Set sample target, overrecruit factor, incentives, min entries, and max entry caps.
4. Finalize templates and follow-up rules.
5. Prepare pilot mode (24h internal test).

B) Recruit + consent

1. 1. Import participant candidates from CSV or JSON export.
2. Screen and segment against the participant profile.
3. Overrecruit to protect against drop-off.
4. Send consent template with plain-language participation rules.
5. Activate participants only after explicit consent confirmation.

C) Pre-study brief

1. 1. Run a short onboarding call or send equivalent written onboarding.
2. Explain what to report, how often, and expected entry duration.
3. Explain incentive and payout requirements (minimums and caps).
4. Share good entry examples and poor entry examples.
5. Confirm participant timezone and preferred prompt window.

D) Run & monitor

1. 1. Send prompts on schedule by selected timing mode.
2. Track compliance daily (sent, completed, missed, late, fallback-used).
3. Send reminders for missed entries.
4. If missed, send reduced-effort fallback prompt before marking non-compliant.
5. Handle drop-off with rescue messaging and simplified restart instructions.
6. Allow mid-study adjustments only when they reduce confusion without steering outcomes.

Mid-study adjustment rules (bias-safe):

• - Allowed: clarify wording, shorten entry length, shift send window, simplify format.
• Not allowed: inject hypotheses, add leading examples, redefine success criteria midstream.
• Always log change timestamp, rationale, and affected participants.

E) Optional post-study interview

1. 1. Schedule 20-30 minute debrief with a subset of participants.
2. Validate strongest themes and probe contradictions.
3. Investigate surprising behaviors and unresolved gaps.
4. Keep interview prompts neutral and evidence-grounded.

F) Analysis

1. 1. Revisit original research questions and decision context.
2. Code/tag entries by theme, stage, trigger, blocker, and sentiment.
3. Analyze behavior shifts over time and key influencing factors.
4. For journey studies, map touchpoints, transitions, delays, and abandonment points.
5. Apply saturation logic before finalizing claims.
6. Produce only evidence-linked recommendations with testable experiments.

Timing mode selection guide

Use this decision sequence:

1. 1. Is the behavior rare but high-value (for example, activation failure, checkout abandonment)?

• - Choose event.

1. 2. Is the behavior frequent and routine (for example, daily usage habit)?

• - Choose interval.

1. 3. Is this a lightweight weekly pulse where events may not self-trigger reliably?

• - Choose signal.

1. 4. Do you need baseline routine + specific event captures?

• - Choose mixed.

Mode guidance:

• - event mode:
• Prompt immediately after target event; require short contextual details.
• Best for low-frequency, high-insight moments.
• INLINECODE34 mode:
• Prompt on fixed cadence (daily or every X days).
• Best for repeated routines and trend tracking.
• INLINECODE35 mode (default):
• Prompt at planned check-in windows with contextual cueing.
• Best for low-friction weekly decision loops.
• INLINECODE36 mode:
• Combine interval baseline + event trigger + signal rescue prompts.
• Best for onboarding flows and journeys with uneven activity.

Mixed-mode patterns:

• - Onboarding diagnostics:
• INLINECODE37 once daily + event when user exits onboarding unfinished.
• Habit studies:
• INLINECODE39 daily + signal at end-of-week reflection.
• Journey mapping:
• INLINECODE41 per stage transition + signal every 2-3 days for missing stages.

Sample size and overrecruit

Qualitative target ranges (completed participants):

• - Focused product question: 8-12 completes.
• Segment comparison (2 segments): 12-20 completes total.
• Journey mapping across multiple stages: 15-24 completes.
• High variability context: 20-30 completes.

Overrecruit rule:

• - Formula: recruit_n = ceil(sample_size_target * overrecruit_factor).
• Default overrecruit_factor: 1.4.
• Typical range: 1.3 to 1.8 depending on expected attrition.

Attrition planning:

• - Anticipated drop-off <20%: factor 1.3-1.4.
• Anticipated drop-off 20-35%: factor 1.4-1.6.
• Anticipated drop-off >35%: factor 1.6-1.8.

Saturation reminder:

• - Increase sample only when new entries still introduce decision-relevant themes.
• Stop expansion when additional participants mostly confirm existing patterns.

Incentive and response requirement model

Core rules:

• - Pay for consistent participation quality, not raw message volume.
• Set clear minimum entry threshold for completion payout.
• Set max counted entries to prevent incentive gaming.

Recommended structure:

1. 1. Completion base payout:

• - Paid if participant meets min_entries_required and consent/compliance rules.

1. 2. Optional per-entry bonus:

• - Small amount per valid entry, counted only up to max_entries_allowed.

1. 3. Quality gate:

• - Entry must include required closed + open components; low-information spam is non-qualifying.

Default calculation model:

• - min_entries_required = ceil(planned_prompt_count * 0.7).
• INLINECODE51.
• INLINECODE52.

Anti-gaming controls:

• - Ignore duplicate entries submitted within a short lockout window unless marked correction.
• Cap bonus at max_entries_allowed.
• Reject entries with copied repetitive text across multiple days unless justified.

Pilot mode

Run pilot before live recruitment:

• - Duration: 24 hours.
• Participants: 1-2 internal testers.
• Mode: use intended production timing mode (or mixed if planned).

Pilot checks:

1. 1. Entry completion time median is 5-10 minutes.
2. No entry exceeds 15 minutes unless intentionally long-form.
3. Questions are clear without facilitator intervention.
4. Closed + open responses together produce usable evidence.
5. Reminder + fallback sequence works as expected.

Pilot pass criteria:

• - At least 80% of pilot entries meet quality requirements.
• No major ambiguity in prompt wording.
• Report synthesis can produce at least one evidence-backed signal.

If pilot fails:

• - Simplify prompts.
• Remove ambiguous wording.
• Reduce entry burden before launching live study.

Compliance monitoring

Track per participant daily:

• - promptssent
• entriescompleted
• entriesmissed
• reminderssent
• fallbackentriescompleted
• consecutivemisseddays

Reminder policy:

• - First miss: gentle reminder.
• Second miss in a row: fallback prompt (reduced effort).
• Third miss in a row: dropout rescue message and optional pause.

Fallback prompt requirements:

• - 1 closed question + 1 short open response.
• Estimated effort: <=3 minutes.
• No penalty for using fallback when participant discloses constraints.

Dropout rescue flow:

1. 1. Acknowledge friction without blame.
2. Offer simplified participation option.
3. Confirm whether participant wants to continue or exit.
4. Preserve data rights and payout rules clearly.

Optional post-study interview

Use only when:

• - Weekly signals contain unresolved contradictions.
• Behavior shifts need causal explanation.
• Journey transitions are unclear from diary logs.

Interview constraints:

• - Duration 20-30 minutes.
• Use neutral prompts that reference participant's own prior entries.
• Do not force confirmation of existing hypotheses.

Outputs:

• - Add debrief notes as supplemental evidence.
• Mark evidence provenance as debrief vs diary.

Analysis and saturation logic

Analysis sequence:

1. 1. Re-state study goal and research questions.
2. Normalize entries and redact identifiers.
3. Tag entries with codebook fields (behavior, trigger, barrier, outcome, stage, emotion).
4. Create participant-by-day timeline to inspect change over time.
5. Identify influencing factors (context, device/channel, constraints, external events).
6. For journey studies, map touchpoints and failure handoffs.
7. Calculate theme emergence trend by period.
8. Apply saturation test before final recommendations.

Saturation logic:

• - Compute percentage of new decision-relevant themes in the latest window.
• Default window: last 20% of entries.
• If new decision-relevant themes <10% and no high-risk unknowns, treat as approaching saturation.
• If >=10% or contradictions remain unresolved, extend study or run targeted debrief.

Recommendation requirements:

• - Every recommendation maps to a specific signal.
• Every signal maps to at least two evidence points when possible.
• When confidence is low, recommend risk-reduction experiments, not major irreversible changes.

Weekly User Signals + Recommendations quality bar

Report constraints:

• - Max length: 1 page.
• Include exactly top 3 signals.
• Each signal must include:
• Evidence snippets (redacted).
• Confidence (Low/Med/High) and explicit reason.
• One testable recommendation as an experiment plan.

Experiment plan minimum:

• - Hypothesis.
• Experiment method.
• Primary metric.
• Decision rule.
• Owner and timebox.

Writing rules:

• - No generic advice.
• Tie every claim to observed pattern + evidence.
• Distinguish observed behavior from participant interpretation.
• Explicitly note change-over-time where relevant.

Communication templates index

Use templates in /prompts:

• - Consent: INLINECODE60
• Onboarding brief: INLINECODE61
• Diary entry template bank: INLINECODE62
• Adaptive follow-up rules: INLINECODE63
• Optional debrief guide: INLINECODE64

Standard operational snippets:

• - Invite:

"We are running a short diary study to understand how this product decision should be improved. You will share brief, in-context entries over [X days]. Typical entry time is 5-10 minutes."

• - Reminder:

"Quick reminder for today's diary check-in. A short entry is enough; if time is tight, use the short-form option."

• - Thank-you:

"Thanks for today's entry. Your details on what happened and why are directly helping this week's product decisions."

• - Dropout rescue:

"No pressure. If the current format is heavy, we can switch to a lighter 2-minute check-in so your perspective is still represented."

Examples

Example Study Brief 1: Onboarding drop-off

CODEBLOCK0

Example Study Brief 2: Habit/frequency for feature X

CODEBLOCK1

Example Study Brief 3: Multi-touchpoint journey

CODEBLOCK2

Example Weekly Report 1: Onboarding drop-off (1 page format)

Period: 2026-03-02 to 2026-03-08 Decision focus: Reduce onboarding abandonment in first session Top 3 User Signals + Recommendations

CODEBLOCK3

Example Weekly Report 2: Habit/frequency for feature X (1 page format)

Period: 2026-03-02 to 2026-03-08 Decision focus: Increase weekly repeat use of Feature X Top 3 User Signals + Recommendations

CODEBLOCK4

Example Weekly Report 3: Journey mapping (1 page format)

Period: 2026-03-02 to 2026-03-08 Decision focus: Reduce stalls from research to purchase decision Top 3 User Signals + Recommendations

CODEBLOCK5