# Compare User Journeys > > - **Type:** Skill - **Install:** `agentstack add skill-amplitude-mcp-marketplace-compare-user-journeys` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [amplitude](https://agentstack.voostack.com/s/amplitude) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [amplitude](https://github.com/amplitude) - **Source:** https://github.com/amplitude/mcp-marketplace/tree/main/plugins/amplitude/skills/compare-user-journeys ## Install ```sh agentstack add skill-amplitude-mcp-marketplace-compare-user-journeys ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Compare User Journeys Investigate what distinguishes two user groups by pulling session replays and metrics for each, then producing a behavioral diff. This skill answers "what do winners do differently?" with concrete evidence from real sessions. --- ## CRITICAL: Tool Reference **Primary tools:** - **`Amplitude:get_session_replays`** — Find sessions for each user group using event count filters and user property filters. Run this twice — once per group. - **`Amplitude:get_session_replay_events`** — Decode replays into interaction timelines. Run this for sessions from both groups. **Supporting tools:** - **`Amplitude:search`** — Search for existing charts, funnels, dashboards, events, and cohorts relevant to the comparison. Always check for existing analysis before building from scratch. - **`Amplitude:get_cohorts`** — Discover existing cohorts that define the groups (e.g., "power users", "churned", "converted"). - **`Amplitude:get_events`** — Discover valid event names. Never guess event names. - **`Amplitude:get_event_properties`** — Discover properties available for segmentation. - **`Amplitude:query_chart`** / **`Amplitude:query_charts`** — Pull quantitative metrics segmented by the two groups for statistical grounding. - **`Amplitude:get_feedback_insights`** / **`Amplitude:get_feedback_mentions`** — Check if feedback themes differ between groups. --- ## Instructions ### Step 1: Define the Two Groups Parse the user's request to identify Group A and Group B. Common comparison patterns: | Comparison | Group A | Group B | |---|---|---| | Conversion | Users who completed the goal | Users who didn't | | Engagement | Power users / high-frequency | Casual / low-frequency | | Retention | Retained users | Churned users | | Plan tier | Enterprise / paid | Free / trial | | Outcome | Successful (e.g., activated) | Failed (e.g., dropped off) | | A/B test | Variant A | Variant B | For each group, determine: - **Defining criteria**: What makes a user belong to this group? (cohort, event, property) - **Labels**: Clear names for the report (e.g., "Converters" vs. "Drop-offs", not "Group A" vs "Group B") If the user's request is ambiguous (e.g., "compare power users"), ask: "What defines a power user for your product — is there an existing cohort, or should I use a frequency/engagement threshold?" ### Step 2: Get Context and Discover Segments 1. Call `Amplitude:get_context`. If multiple projects, ask which to compare within. 2. Call `Amplitude:get_cohorts` to check if existing cohorts match the requested groups. Existing cohorts encode institutional knowledge — prefer them over ad-hoc definitions. 3. Call `Amplitude:get_events` to discover events relevant to the comparison (the goal event for conversion comparisons, engagement events for activity comparisons, etc.). 4. Call `Amplitude:get_event_properties` for the key events to discover available segmentation properties. ### Step 3: Quantitative Comparison (Metrics) Before watching replays, establish the statistical picture. Budget: 3-4 chart queries. **First, search for existing analysis.** Call `Amplitude:search` with keywords related to the comparison (e.g., "onboarding funnel", "agent creation", "checkout conversion"). Existing charts and funnels encode institutional knowledge and save query budget. If you find a relevant funnel or segmented chart, use `Amplitude:query_chart` on it instead of building from scratch. Use `Amplitude:query_chart` or `Amplitude:query_charts` to compare the two groups on: 1. **Volume & composition**: How many users are in each group? What's the ratio? 2. **Key metrics segmented by group**: Conversion rates, session frequency, feature adoption, retention — whatever metrics are most relevant to the comparison. 3. **Feature usage differences**: Which events does Group A fire significantly more than Group B? Use event totals or unique user counts segmented by group. **What to look for:** - Large percentage differences in specific event frequencies - Features used exclusively or predominantly by one group - Timing differences (Group A does X on day 1, Group B waits until day 7) - Volume differences (Group A does X 5 times per session, Group B does it once) Record the top 3-5 quantitative differences — these become hypotheses to validate or enrich with replays. ### Step 4: Find Sessions for Both Groups Run `Amplitude:get_session_replays` **twice** — once for each group. Request `limit: 8` for each. **Exclude internal users by default.** Unless you're specifically studying internal behavior, add a user property filter to exclude your company's email domain (e.g., `gp:email does not contain "amplitude.com"`). This prevents internal test sessions from polluting the comparison. **Building group filters:** If groups are defined by a **cohort**, filter on the cohort's defining user property or event. If groups are defined by an **event outcome** (e.g., completed checkout vs. didn't): - **Group A (converters)**: Filter for sessions containing the conversion event (use `eventCountFilters` with `operator: "greater or equal"`, `count: "1"`). - **Group B (drop-offs)**: Filter for sessions containing the entry event but NOT the conversion event. Since `get_session_replays` doesn't support "did not do" filters directly, filter for the entry event only, then when watching replays in Step 5, check the interaction timeline for absence of the conversion event. Discard sessions where the user actually converted and replace with additional sessions until you have 4-6 confirmed drop-offs. If groups are defined by a **user property** (plan, segment): - Use user property filters with `event_type: "_all"`. ### Step 5: Watch Sessions — Extract Interaction Timelines For each group, call `Amplitude:get_session_replay_events` for 4-6 sessions. Use `event_limit: 300`. **Budget: 8-12 total sessions (4-6 per group).** **Rate limiting and large responses:** - Call `get_session_replay_events` in batches of 3-4 at a time, not all at once. The Session Replay API enforces concurrency limits and will return 429 errors if overwhelmed. If you hit a 429, wait briefly and retry. - Some sessions have extremely high interaction counts (100K+ raw events). If a response is too large and gets saved to a file, read the key portions from the saved file path. For sessions with very high `total_raw_events`, consider using a lower `event_limit` (e.g., 150) to stay within response size limits. **While analyzing, track these behavioral dimensions for each session:** | Dimension | What to capture | |---|---| | **Navigation path** | Sequence of pages visited. Note the order and any pages unique to this session. | | **Feature engagement** | Which features/areas the user interacted with. Note depth (quick glance vs. extended use). | | **Pace & hesitation** | Fast and confident vs. slow with pauses. Note long gaps between actions. | | **Exploration vs. focus** | Did the user go straight to their goal or browse around? | | **Friction encountered** | Errors, rage clicks, back-navigation, abandoned inputs. | | **Session outcome** | Did they accomplish something? What was the last action before leaving? | For each session, write a 2-3 sentence behavioral summary capturing the overall pattern. ### Step 6: Synthesize the Behavioral Diff This is the core analytical step. Compare the two groups across the dimensions above. 1. **Tabulate patterns.** For each behavioral dimension, summarize what Group A typically does vs. Group B. 2. **Identify differentiating actions.** Find behaviors that are: - **Present in Group A, absent in Group B** — These are the strongest signals. "Converters explore the template gallery before creating their first project. Drop-offs skip it entirely." - **Present in both but with different frequency or depth** — "Both groups use search, but power users average 4 searches per session vs. 1 for casual users." - **Present in Group B, absent in Group A** — Negative signals. "Churned users spend time on the pricing page comparing plans. Retained users don't." 3. **Rank by explanatory power.** Which differences most plausibly explain the outcome gap? Lead with the most compelling. 4. **Generate hypotheses.** For each major difference, propose a causal hypothesis: - "Converters use templates because templates reduce time-to-value. If we surfaced templates more prominently, more users might convert." - "Churned users hit errors on the integration page. Fixing these errors could reduce churn." 5. **Cross-reference with feedback** (optional but valuable). Call `Amplitude:get_feedback_insights` with terms related to the differentiating actions. If Group B complains about something Group A doesn't, that strengthens the signal. ### Step 7: Present the Behavioral Comparison Structure the output as a comparative report a PM or growth lead can act on. **Required sections:** 1. **Comparison Summary** (3-4 sentences): Who was compared, the sample size, the single most striking behavioral difference, and the top hypothesis. Written as a narrative you could paste into a strategy doc. 2. **Groups Defined**: - Group A: [Label] — definition, N sessions watched, N users in population - Group B: [Label] — definition, N sessions watched, N users in population - Time window analyzed 3. **Quantitative Context** — Key metric differences between groups (from Step 3). Present as a concise table: ``` | Metric | [Group A Label] | [Group B Label] | Delta | |--------|-----------------|-----------------|-------| | [Metric 1] | [value] | [value] | [diff] | | [Metric 2] | [value] | [value] | [diff] | ``` 4. **Behavioral Diff** — The core findings, ranked by explanatory power: For each differentiating behavior: ``` ### [Behavior Title — ≤10 words] **Signal strength:** [Strong/Moderate/Emerging] | **Seen in:** X of Y [Group A] sessions vs. X of Y [Group B] sessions **[Group A Label]:** What this group does — specific actions, pages, patterns observed. **[Group B Label]:** What this group does instead — or doesn't do. **Hypothesis:** Why this difference matters and what it suggests about the outcome gap. **Evidence:** Replay links from both groups showing this contrast. ``` 5. **Journey Maps** (optional, for flow comparisons): A simplified side-by-side view of the typical path each group takes: ``` [Group A]: Landing → Templates → Create Project → Invite Team → Active Use [Group B]: Landing → Create Project → Settings → ... → Churn ``` 6. **Actionable Hypotheses** (3-5 items): Concrete experiments or changes suggested by the behavioral differences. Each should follow the format: "If we [change], then [Group B behavior] should shift toward [Group A behavior], because [evidence]." 7. **Confidence & Caveats**: Note sample size limitations, whether patterns were consistent across sessions, and what additional data would increase confidence. 8. **Follow-on prompt**: Suggest next steps — "Want me to audit the [specific flow] where the groups diverge most, build a chart tracking [differentiating action], or investigate a specific user from either group?" --- ## Edge Cases - **Groups are hard to distinguish.** If the two groups behave very similarly in replays, report that finding. It's valuable — it means the behavioral difference may be upstream (acquisition source, timing) rather than in-product. Suggest investigating pre-signup or external factors. - **One group has few sessions.** If one group has <3 watchable sessions, note the limited sample and reduce confidence. Present findings as "preliminary" and suggest waiting for more data or broadening the time window. - **User asks to compare 3+ groups.** Decline and suggest pairwise comparison: "Comparing more than 2 groups at once dilutes the analysis. Which two would you like me to start with?" Offer to run a second comparison after. - **Cohort doesn't exist.** If the user references a segment that doesn't have a cohort, build the group filter from events and user properties. Suggest creating a cohort for reuse: "There's no 'power users' cohort defined. I'll filter by [criteria]. Want me to suggest a cohort definition to save?" - **Conversion event isn't clear.** If comparing converters vs. non-converters but the conversion event isn't obvious, call `get_events` and propose 2-3 candidate events. Let the user confirm. - **nodeId limitations.** Interaction timelines show coordinates and node IDs, not element names. When comparing actions between groups, describe by page context and interaction sequence rather than specific UI elements. Focus on which pages and flows users engage with, not which buttons they click. ## Examples ### Example 1: Converter vs. Non-Converter User says: "What do users who complete onboarding do differently from those who drop off?" Actions: 1. Get context, discover onboarding events (signup, each onboarding step, activation event) 2. Query onboarding funnel conversion rate and identify the biggest drop-off step 3. Find sessions: Group A = completed activation event; Group B = started onboarding but didn't activate 4. Watch 4-5 sessions per group, track navigation paths and feature interactions 5. Synthesize: "Activators spend time on the template picker (avg 3 templates previewed). Drop-offs skip templates and go straight to blank project — then stall." 6. Present behavioral diff with hypothesis: "Templates reduce blank-page paralysis. Surfacing them earlier could lift activation." ### Example 2: Power Users vs. Casual Users User says: "How do our most active users use the product differently?" Actions: 1. Get context, check for existing "power user" cohort 2. Define groups: top 10% by session frequency vs. bottom 50% 3. Query feature usage segmented by group — which features show the biggest usage gap 4. Find sessions for both groups, extract timelines 5. Synthesize: "Power users use keyboard shortcuts and saved views. Casual users navigate through menus and re-do searches." 6. Present diff with hypothesis: "Discoverability of shortcuts and saved views is low. Adding onboarding tooltips could shift casual users toward power user patterns." ### Example 3: Retained vs. Churned User says: "Why are some users churning after the first week?" Actions: 1. Get context, define groups: users active in week 2+ vs. users who never returned after week 1 2. Query retention curve and week-1 engagement metrics by group 3. Find sessions from each group's first week 4. Compare: what did retained users do in week 1 that churned users didn't? 5. Cross-reference with feedback from churned users (if available) 6. Present: "Retained users connected an integration in their first session. Churned users didn't — and 3 of 5 churned users visited the integrations page but left without completing setup." ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [amplitude](https://github.com/amplitude) - **Source:** [amplitude/mcp-marketplace](https://github.com/amplitude/mcp-marketplace) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-amplitude-mcp-marketplace-compare-user-journeys - Seller: https://agentstack.voostack.com/s/amplitude - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.