Session Abandonment Analysis Prompt Template

This prompt is designed for product managers and AI program managers who need to analyze user drop-off patterns from conversation trace data. It takes structured session traces as input and produces an abandonment trend report with root-cause hypotheses, affected user segments, and retention impact estimates. Use this prompt when you have production trace data that captures turn-by-turn user interactions and you need to identify where and why users are abandoning sessions.

The prompt assumes you have already extracted and structured the relevant trace fields before calling the model. Required inputs include session IDs, turn sequences, user actions, assistant responses, tool-call outcomes, and abandonment flags per session. The output is a stakeholder-ready report, not a raw data dump. The model is instructed to segment abandonment patterns, hypothesize root causes grounded in trace evidence, and estimate retention impact with explicit confidence levels. Do not use this prompt for real-time abandonment prediction or for analyzing non-conversational product funnels. This is a post-hoc analysis tool for stakeholder reporting, not an operational detection system.

Before running this prompt, validate that your trace data includes clear abandonment signals—such as explicit session termination, prolonged inactivity thresholds, or user-reported dissatisfaction events. If your traces lack these signals, the model will produce speculative results that undermine stakeholder trust. Always pair the output with a human review step when the report will inform roadmap decisions or retention investments. For continuous monitoring, pair this prompt with a scheduled pipeline that aggregates traces weekly or monthly, and compare trend reports over time to distinguish transient issues from systemic product gaps.

This prompt template is designed to be copied directly into your AI harness or observability platform. It accepts structured trace data representing user sessions that ended before a defined conversion or completion event. The prompt instructs the model to produce a structured abandonment trend report with root-cause hypotheses, affected user segments, and retention impact estimates. All placeholders are enclosed in square brackets and must be replaced with your actual production trace data, schema definitions, and operational constraints before execution.

textCopy
You are an AI session analyst reviewing production conversation traces for abandonment signals.

Your task is to analyze the provided session trace data and produce a structured abandonment trend report.

## INPUT DATA
[TRACE_DATA]

## OUTPUT SCHEMA
You must return a valid JSON object conforming to this schema:
[OUTPUT_SCHEMA]

## ANALYSIS CONSTRAINTS
- Only classify a session as abandoned if the user did not return within [ABANDONMENT_WINDOW_HOURS] hours and no completion event was recorded.
- For each root-cause hypothesis, cite at least one specific trace event (by trace_id and turn number) as supporting evidence.
- If a hypothesis cannot be supported by the trace data, mark it as speculative and assign a lower confidence score.
- Do not invent user demographics or intent beyond what is explicitly present in the trace data.
- Segment users only by the dimensions provided in [SEGMENT_DIMENSIONS].
- Retention impact estimates must be expressed as directional trends (increased/decreased/unchanged) with a confidence level, not as precise percentages unless directly calculable from the data.

## EXAMPLES
[EXAMPLES]

## TOOLS AVAILABLE
[TOOLS]

## RISK LEVEL
[RISK_LEVEL]

## OUTPUT
Generate the abandonment trend report as a single JSON object with no additional commentary.

To adapt this template, replace each placeholder with your production context. [TRACE_DATA] should contain the raw or preprocessed session traces, typically as a JSON array of session objects with fields like trace_id, turns, events, user_id, and session_end_reason. [OUTPUT_SCHEMA] must define the exact JSON structure you expect, including fields for abandonment_rate, top_hypotheses, affected_segments, and retention_impact. [ABANDONMENT_WINDOW_HOURS] is a critical business parameter—set it based on your product's expected return cycle. [SEGMENT_DIMENSIONS] should list the allowed grouping keys such as ["user_tier", "entry_channel", "device_type"]. If your harness supports tool calls, populate [TOOLS] with available functions like query_session_db or calculate_confidence_interval. Set [RISK_LEVEL] to high if the output will inform budget or staffing decisions, which triggers additional validation and human review requirements. Always validate the model's output against your schema before surfacing it to stakeholders, and log any schema violations for prompt refinement.

This prompt is designed to be called as part of a scheduled reporting pipeline, not a real-time user-facing endpoint. The typical harness runs weekly or daily, pulling session trace data from your observability store (e.g., a vector database of conversation traces, a data warehouse, or a logging platform). The prompt expects pre-aggregated session data—individual turn logs are too verbose. You must pre-process raw traces into session-level summaries containing: session ID, user segment label, entry point, exit point, turn count, tool calls attempted, and any explicit user feedback signals before passing them to the model.

The implementation should wrap the LLM call in a validation layer that checks the output against the expected schema before the report reaches a stakeholder. At minimum, validate that: (1) the JSON parses without error, (2) the abandonment_rate field is a float between 0.0 and 1.0, (3) each root_cause_hypothesis contains a non-empty description, affected_segments array, and confidence score, and (4) the retention_impact_estimate includes both a numeric value and a unit. If validation fails, retry once with the validation error message appended to the prompt as a correction hint. If the second attempt also fails, log the failure, flag the report for human review, and send a partial summary with a validation_status: failed marker rather than silently dropping the data.

For model selection, use a model with strong structured output capabilities and a context window large enough to hold your session summary batch. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Avoid small or quantized models for this task—the root-cause reasoning requires nuanced pattern recognition across multiple sessions. Set temperature to 0.1 or lower to maximize consistency across report runs. If your session data exceeds ~80% of the model's context window, split the batch by user segment or time slice and run the prompt in parallel, then merge the results in application code. Do not truncate sessions silently—missing data produces false abandonment signals.

Logging and audit trail: Store every prompt invocation with its input hash, output, validation result, and timestamp. This is critical for two reasons. First, product managers will question abandonment trend shifts, and you need to distinguish between real user behavior changes and prompt or data pipeline regressions. Second, if a root-cause hypothesis leads to a product change that harms retention, the audit trail lets you trace the decision back to the evidence. Log the raw model response before validation so you can debug schema drift even when validation catches the error.

Human review gate: This prompt produces decision-support output, not automated actions. The report should always route to a human reviewer—typically a product manager or data analyst—before any product change is made. The harness should attach a review_status: pending flag to the output and require explicit acknowledgment. If the prompt's confidence scores for root-cause hypotheses fall below a configurable threshold (we recommend 0.6), escalate the entire report for deeper investigation rather than presenting low-confidence hypotheses as actionable findings. The prompt is an analysis accelerator, not a replacement for product judgment.