Page Components

Overview

A component is a new element added to a live page. There are four kinds, and they are the words used everywhere in the product, including on the dashboard and by the agent:

These combine. A quiz inside a popup is tracked as both, so it appears under popups and under quizzes rather than forcing you to pick one.

A component is a page change like any other. It is targeted the same way, it ships behind the same approval, it runs as part of a test, and it reverts the same way. See Targeting for who sees it and Experiments Workflow for how it is measured against the original page.

Adding A Component

There are two paths, and they do not cover the same ground.

Ask for what you want in plain language: a dismissible bar announcing free shipping over $50, an exit popup offering a demo, a three-question quiz that routes to the right plan. The agent writes it to match the page it is going on, rather than dropping in a themed template that looks borrowed.

Components are only ever added when you ask for one. Tailor will propose copy and layout changes on its own, but it does not decide on its own that a page needs a popup.

Where It Goes

A component that belongs in the page flow is anchored to an element you point at: under the hero, above the pricing table, after the third section.

Anything that floats above the page (a popup, a pinned bar, a floating widget) is anchored to the page body instead, not to an element. This is about durability rather than layout. An element anchor is a signature that can decay when your site is rebuilt and the markup around it changes; the page body cannot. An overlay pinned to the body keeps working through a redesign that would have orphaned it.

Previewing

To see a trigger-gated component without waiting for the trigger, add t_component_trigger=<component name> to the preview URL. That forces it open and skips any cooldown, so you are not clearing storage between refreshes to see it twice.

What Gets Measured

Every test that has components gets a Components tab on its dashboard, alongside the usual results. Before anything is added it reads “No Tailor components on this test yet”.

What it reports, per component:

• Used it — people who interacted with it at all.
• Opened it, CTA, Dismissed it, Answers — broken out by what they did.
• Started, Finished, and Finish rate — for quizzes.

To count a component interaction as a conversion, the component calls a goal you have already created of type callback. It has to exist first: an unknown key does not quietly create one. See Conversion Goals & Tracking.

Quizzes

A quiz reports starters, finishers, and a finish rate. The rule is exact: someone counts as finishing when they answered every question the quiz has.

That rule undercounts a branching quiz. If a path through the quiz skips questions by design, a visitor who completed their path has still not answered every question, so they will not be counted as finished. This is a known limit rather than a bug: read finish rate on a branching quiz as a floor.

Answers are counted, not stored. Tailor records that a question was answered, never the content of what somebody typed, and it cannot tell you which result a visitor landed on.

Storage And Consent

Components that need to remember something (a dismissal, a cooldown, an answer so far) use Tailor's own storage rather than touching the browser directly. Writing straight to localStorage, sessionStorage, cookies, or IndexedDB is refused before it can be saved.

That is not a style preference. On-device storage is gated by your visitors' cookie consent and by the data-processing terms on your account, so it has to run through a layer that can honour both.

Accessibility

Overlay components are held to a floor, because a popup is the easiest thing on a page to make unusable with a keyboard:

• A close control you can actually see.
• Escape closes it.
• Focus moves into it when it opens, and returns where it came from when it closes.
• Focus stays inside it while it is open.