Skip to content

Compare assets

Compare assets (asset display logic) controls which prototype a participant sees on pages that already use a prototype. It does not decide which pages appear — that is Section randomisation or Display logic.

Use compare assets when the task is the same (or parallel) but the design or build differs — classic prototype A/B, age-segmented designs, or condition-based routing from a URL parameter.


QuestionAnswer
What changes per participant?The prototype (Figma, ProtoPie, Adobe XD, URL, upload)
What stays the same?Pages, tasks, and questions on those pages
Where do I set it up?Path Logic → Compare assets on a page or section
Who sees what?Driven by a randomisation group or condition variable
Do I map screens on variants?Yes — each variant needs start / end / success mapping where the source task requires it
Where do results come from?The prototype the participant actually saw, not the default on the page

Page-levelSection-level
ScopeOne page, one prototype assignmentAll pages in the section that share the same source asset
Best forSingle-screen A/B on one task pageMulti-page flows using the same baseline prototype
Task mapping policyAlways shared — one start/end/success mapping for the task on that pageConfigurable — shared or per page / per task (see below)
Override ruleSection compare overrides page-level compare for pages included in the section config

Section-level is the right choice when several pages (e.g. Page 4 and Page 5) use the same source prototype and you want one comparison block that covers all of them.

If a page is already part of a section comparison, the page’s Compare assets panel shows a locked notice — edit the comparison from the section instead.


The source asset is the prototype currently assigned on your pages in Build — the baseline participants would see without compare assets. In the wizard you pick which asset to compare; each source asset gets its own comparison configuration if multiple prototypes appear across the section.

Each group value (randomisation group or condition value) maps to a variant prototype. The first rule is usually the Original (same as the source). Other rules are variants — different files or URLs that need their own screen mapping.

DriverUse when
Randomisation variableBalanced random A/B/C assignment (same idea as Randomisation groups)
ConditionPrototype depends on URL params, sample, screener answers, or another variable (e.g. ageGroup = Youth vs Old)

You can create a randomisation variable inline in the compare wizard or reuse an existing one.

Interactive tasks (goal-based, first click, etc.) on Figma / ProtoPie / Adobe XD prototypes define start screens, and sometimes end screens or completion paths. URL prototypes with advanced tracking can define success URLs.

When a participant is assigned a variant, the test must know the equivalent screens on that variant’s file — otherwise tasks cannot start, complete, or be scored correctly.

FieldApplies toMeaning
Start screenPages with a task that has a defined startWhere the participant begins on the variant
End screen / pathsGoal-based tasks with an end screen or specific pathWhere success is measured on the variant
Success URLURL prototypes with advanced trackingThe URL that counts as task success on the variant

The Original rule uses the screens already configured on your pages. Variant rules need you to pick the matching screens on each variant file.


When comparing at section level across multiple pages or tasks, you can choose how granular variant mapping is:

SettingOptionsWhen to use
Start screenSame for all pages · Per pagePer page when each page starts on a different screen in the source (e.g. Page 4 vs Page 5)
End screen / pathsSame for all tasks · Per taskPer task when multiple goal-based tasks end on different screens
Success URLSame for all tasks · Per taskPer task when URL tasks use different success URLs

Toggles only appear when they are relevant — for example, the End screen toggle appears when you have more than one goal-based task that needs an end, not for first-click-only sections.

When you switch from shared to per page or per task, existing shared values are copied into the new slots so you can adjust them without starting from scratch.

While editing, amber warnings appear if source tasks differ but policy is still shared, for example:

  • Pages use different start screens → switch start to Per page
  • Goal-based tasks use different end screens → switch end to Per task

Follow these before saving if your variants need different mappings per page or task.


  1. Add prototypes in Assets & Media (Prototypes and assets)
  2. In Build, assign a prototype to each task page and configure interactive tasks (start, end, etc.)
  1. Open the section that contains your task pages → Path Logic → Compare assets
  2. Select source asset — the prototype used on those pages
  3. Choose driver — randomisation variable or condition
  4. Map groups to prototypes — Original + each variant
  5. Variant task mapping — set policy toggles if shown, then map start/end/success for each variant
  6. Fallback — what to show if no rule matches (nothing or a default prototype)
  7. Save
  1. Open the pagePath Logic → Compare assets
  2. Same wizard, but only that page’s task is in scope
  3. Mapping policy toggles are hidden — one shared mapping per variant is enough

After saving, the summary card shows:

  • Comparison title — e.g. “2 variants by ageGroup (randomisation)”
  • Pages affected in this section
  • One block per group (Youth, Old, …) with prototype name and Original / Variant badge
  • Per page · task type rows, for example:
Page 4 · Goal-based task
Start: …
End: …
Page 5 · First click
Start: …

The Original block reflects screens configured on your source pages. Variant blocks show the mapped screens on each variant file. Mapping: X/Y complete counts every required slot (e.g. two per-page starts plus one shared end = 3).

Use Edit to change groups, variants, or mapping. Source tasks on this asset (in the edit wizard only) lists what the source prototype expects before you map variants.


Goal: One task page; Group A sees Design A, Group B sees Design B.

StepAction
1One page with one goal-based task and prototype A assigned
2Page → Compare assets → randomisation driver, 2 groups
3Group A → prototype A (original); Group B → prototype B
4Map start and end on prototype B to match the task

Policy: Shared for everything (default on page-level).


2. Same task, two designs (section, one page)

Section titled “2. Same task, two designs (section, one page)”

Same as above but configured on the section if you prefer all Path Logic in one place. Behaviour matches page-level when only one page uses the source asset.


3. Multi-page flow — one source asset, two variants

Section titled “3. Multi-page flow — one source asset, two variants”

Goal: Page 4 (goal-based: start + end) and Page 5 (first click: start only). Youth see mobile app A; Old see mobile app B.

StepAction
1Both pages use the same source prototype in Build
2Section → Compare assets → condition or randomisation on ageGroup
3Map Youth → original prototype, Old → variant prototype
4Set Start screen → Per page (Page 4 and Page 5 start on different screens)
5Keep End → Same for all tasks if only Page 4 has a goal end
6On the Old variant, map Page 4 start + end and Page 5 start on the variant file

Summary should show: Original and Old each with two rows — Page 4 (Start + End) and Page 5 (Start only).


4. Different starts per page, same end (common pattern)

Section titled “4. Different starts per page, same end (common pattern)”

Goal: Several pages share one goal end screen on the source, but each page starts elsewhere.

  • Start: Per page
  • End: Same for all tasks
  • Map each page’s start on each variant; map the goal end once (applies to the goal-based task)

5. Multiple goal-based tasks with different ends

Section titled “5. Multiple goal-based tasks with different ends”

Goal: Page 4 ends on Screen X; Page 6 ends on Screen Y.

  • End: Per task
  • Map end (or paths) separately for each goal task on each variant

Goal: Live site A/B; success = different thank-you URLs.

  • Use Success URL policy (per task if URLs differ)
  • Map success URL on each variant for advanced URL tracking tasks

7. Condition from URL or screener (not random)

Section titled “7. Condition from URL or screener (not random)”

Goal: ?cohort=old sees the old design; everyone else sees the default.

  1. Create a condition variable (URL param or answer-based)
  2. Compare assets → Condition driver
  3. Rules: cohort=old → old prototype; optional fallback → default

Do not rely on section subset randomisation for assignment — the link or screener drives the condition. See Display logic and routing for related patterns.


Goal: Group A does task set on pages 1–3; Group B does a different set on pages 4–6 and different prototypes.

  1. Section randomisation or Randomisation groups for which pages appear
  2. Compare assets on the relevant section for which prototype on those pages

See Experiment recipes — Prototype comparison.


Compare assets vs study groups vs randomisation

Section titled “Compare assets vs study groups vs randomisation”
FeatureChangesTypical use
Section/page randomiserWhich pages, subsections, or blocks appearDifferent modules or task flows
Randomisation groupsNamed groups in results for subset assignmentA/B/C with group labels in exports
Compare assetsWhich prototype on pages that already showSame tasks, different designs

You can combine them: randomisation picks the path; compare assets picks the prototype on that path.


Each response stores metadata.compareExposure: assigned compare group, per-section arms, and per-page prototype shown (including pages with no asset on that arm).

SurfaceBehaviour
Overview dashboardQuestions on compare pages get a group dropdown. Interactive tasks require one group; other questions also offer Global (all groups). A badge shows the prototype name (green) or No asset (red) for the selected group on that page.
Custom dashboardsQuestion chart widgets use the same group filter.
Responses panelCompare exposure lists section/page arms and whether a prototype was shown.
ExportsCompare group and Compare variable columns come from persisted exposure.
SegmentationCompare group is available as a segment field when exposure is stored.
Task paths / thumbnailsAnalytics uses the prototype each participant actually saw, not the default on the page in Build.
Study-wide filterCompare group dropdown above the results tabs filters participants, metrics, dashboards, and responses for one arm.
Synthetic previewSynthetic responses assign compare groups with balanced randomization and persist compareExposure like live data.
Smart AI dashboardRegenerate while a compare filter is active to scope AI insights to that group only.

Filter or segment by randomisation group or condition variable to compare variants. Preview with Follow logic and switch preview group/condition values to verify each variant before launch.


If you add a new page with the same source prototype after compare is configured:

  • The summary may show New or incomplete mapping until you edit and map the new page’s start (and end if applicable) on each variant
  • Switching policy to Per page after adding pages may require mapping the new page on variants

Re-open Edit comparison after structural changes to the section.


SymptomLikely causeFix
Variant task does not startStart not mapped on variantEdit comparison → map start for that page on the variant
Goal never completesEnd or paths wrong on variantMap end screen or paths on the variant file
Summary shows “Start, Start” with no page labelsOlder UI — refresh; summary should show Page · task type per rowUpdate builder / re-save comparison
Warning about different startsPolicy still “Same for all pages”Switch start to Per page
Page compare lockedSection compare already covers this assetEdit from section Path Logic
Mapping 3/3 but only two lines visibleShared end counted but not shown on first-click rowsEnd appears on the goal-based task row (Page 4), not on first-click pages