plugins/adobe-cja/skills/cja-segment-performance-comparator/SKILL.md
Compares the performance of two or more audience segments across key metrics side by side. Use this skill when someone wants to compare audiences, cohorts, or groups — for example, "how do mobile users compare to desktop users on conversion," "compare new vs. returning visitors," "show me the difference between these two segments," "compare these audiences on our KPIs," or "which segment performs better." Also trigger for "segment comparison," "audience comparison," or "cohort comparison."
npx skillsauth add adobe/skills cja-segment-performance-comparatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Compare 2–5 audience segments across a set of key metrics in a side-by-side matrix. The output tells the user not just what each segment looks like in isolation, but which segment wins or loses on each metric — and which differences are large enough to act on.
This skill answers the question "which audience should we focus on?" with data. Segment comparisons drive product decisions, personalization strategy, and budget allocation — so clarity and actionability matter more than exhaustive data.
findSegments — search for segments by name or keyworddescribeSegment — understand the logic of candidate segments before using themfindMetrics — resolve base metric IDsfindCalculatedMetrics — include custom KPIs in the comparisonlistComponentUsage — identify the most-used metrics as default comparison setrunReport (with segmentIds or adhocSegments) — pull metric values per segmentfindDataViews to list available data views.setDefaultSessionDataViewId with the chosen ID.If the user named specific segments, resolve them:
findSegments(search: "<segment name>")
For each match, call describeSegment to verify it is the correct one:
describeSegment(segmentId: "<id>")
Show the segment definition summary to the user if there is ambiguity:
"I found two segments matching 'mobile users': Mobile Visitors (All Devices) and Mobile App Users. Which do you want to compare?"
If the user says "compare mobile vs desktop users" but there are no matching segments, offer to create ad hoc segments inline for the comparison:
"I don't see pre-built segments for mobile and desktop. I can create temporary ad hoc segments for this comparison using device type. Should I proceed with ad hoc segments, or would you like to create permanent segments first?"
Ad hoc segments are constructed using adhocSegments in runReport — no
save required for the comparison itself.
Maximum 5 segments for a single comparison. More than 5 creates a matrix that is too wide to read meaningfully. If the user requests more, say:
"I'll limit to the 5 most relevant segments for readability. Would you like me to prioritize by usage count or stick with your list order?"
Resolve named metrics via findMetrics and findCalculatedMetrics.
If the user did not specify metrics, pull the top metrics by usage. The
listComponentUsage tool does not support a limit parameter — it returns all
components ranked by usage count; take the top 6–8 from the result:
listComponentUsage(componentType: "metric")
listComponentUsage(componentType: "calculatedMetric")
Prefer calculated metrics over raw base metrics when they measure the same thing — calculated metrics reflect intentional KPI definitions.
Good comparison metrics should be meaningful across all segments. For example, "Revenue" is meaningful for both mobile and desktop users; "App Installs" is only meaningful for mobile. Remove metrics that would be trivially zero for one segment.
If unsure, ask: "Should I use your standard KPI set, or focus on specific metrics like conversion rate, revenue, and engagement?"
For each segment, run a runReport with that segment applied and all
comparison metrics included. Note that runReport takes metricIds as a
comma-separated string, startDate/endDate (not dateRange), and a
dimensionIds (required even for summary-only reports — use a low-cardinality
dimension like variables/daterangeday or variables/web.webPageDetails.name).
The summary totals for all metrics are in summaryData.filteredTotals:
runReport(
dimensionIds: "variables/web.webPageDetails.name",
metricIds: "metrics/visits,metrics/revenue_1,metrics/orders_1_1",
startDate: "<period start>T00:00:00",
endDate: "<period end>T23:59:59",
page: 0,
limit: 1,
segmentIds: "<segment id>"
)
For ad hoc segments, use the full CJA segment definition object:
runReport(
dimensionIds: "variables/web.webPageDetails.name",
metricIds: "metrics/visits,metrics/orders_1_1",
startDate: "<period start>T00:00:00",
endDate: "<period end>T23:59:59",
page: 0,
limit: 1,
adhocSegments: [{
"func": "segment",
"version": [1, 0, 0],
"container": {
"func": "container",
"context": "visitors",
"pred": {
"func": "streq",
"val": { "func": "attr", "name": "variables/device_type" },
"str": "Mobile Phone"
}
}
}]
)
Read metric totals from summaryData.filteredTotals[i] where i is the
0-based index of the metric in the metricIds string.
Run one report per segment. Collect all results into a matrix:
For each cell (metric × segment):
value[metric][segment] = raw metric value from runReportFor each metric row:
winner = segment with the highest value (or lowest, for "lower is better" metrics)loser = segment with the lowest value (or highest, for inverse metrics)range = (max − min) / max × 100 — the spread across segments as a percentagesignificant = true if range > 10% (a meaningful difference worth acting on)Generate the report inline and write to
/tmp/cja_segment_performance_comparator_report_<YYYY-MM-DD_HHMMSS>.html.
Read template.html and use it verbatim. Do not improvise the
HTML structure or CSS — only fill in the {PLACEHOLDER} tokens ({ORG_NAME},
{DATE_RANGE}, {DATA_VIEW}, {GENERATED_DATE}, {SEGMENT_NAMES_SUMMARY},
{SEGMENT_NAME}, {COLOR}, {VISITOR_COUNT}, {NUM_SEGMENTS}, {NUM_METRICS},
{NUM_SIGNIFICANT}, {OVERALL_WINNER}, {METRIC_NAME}, {VALUE},
{WINNER_SEGMENT}, {SPREAD}, {INSIGHT_TEXT}) and repeat segment chips,
matrix rows, and insight boxes once per data item. Use the cell-winner /
cell-loser classes per Phase 4 winner/loser rules.
After building the matrix, generate 3–5 insight bullets for the Insights section:
Insights should be plain English, not metric IDs. Name the specific segments and metric values.
runReport per segment with all metrics; collect results./tmp/cja_segment_performance_comparator_report_<YYYY-MM-DD_HHMMSS>.html.open /tmp/cja_segment_performance_comparator_report_<YYYY-MM-DD_HHMMSS>.html."Compare our mobile vs. desktop segment performance for last quarter."
findDataViews, user selects. Call setDefaultSessionDataViewId.findSegments to locate the "Mobile Users" and "Desktop Users" segments. Show matched names and IDs to confirm. User approves.runReport for Q1 2026 with both segments applied. Tabulate results side-by-side.tools
Use the run-workflow MCP to discover, compose, execute, publish, and save Adobe Firefly workflows. TRIGGER when: user asks what actions are available, what the MCP can do, how to process images/video/3D via workflow, wants to build/run/save/publish a workflow, OR pastes any workflow/batch/execution ID. BARE ID (UUID/workflowId/batchId) = INSPECT ONLY — call inspect_run, NEVER run_workflow_submit. ALWAYS call list_actions first for capability/discovery questions. DO NOT TRIGGER for direct Firefly API calls without MCP (use firefly-api-specs).
tools
Run predefined featured workflows via run-workflow MCP. TRIGGER when user names a featured workflow (retargeting, banners at scale, localization, packaging, banner advertising, etc.) or asks to run a known marketing/production workflow. Requires run-workflow MCP. ALWAYS call get_featured_workflow before compose_workflow. DO NOT TRIGGER for custom one-off workflows with no named template — use run-workflow skill.
tools
Migrate an Adobe Commerce App Builder project from the Integration Starter Kit or Checkout Starter Kit to the new App Management approach. Run from the root of the App Builder project to be migrated. Pass --auto to skip confirmation prompts (suitable for CI or batch use) — auto mode prints a summary of all Q&A questions answered with their defaults. Pass --doc-scan-only to scan README.md and env.dist for outdated content without modifying any files. Use when the user wants to migrate an App Builder project from the Integration Starter Kit or Checkout Starter Kit to the App Management approach, or mentions upgrading their Adobe Commerce extension architecture.
development
Add or modify webhook interceptors in an Adobe Commerce app. Use when the user wants to intercept Commerce operations to validate input, append data, or modify behavior — before or after execution. Requires a base app initialized with commerce-app-init.