Tag or extension: how to prepare a test on a real website

Testing a real website requires deciding how the activity will be recorded. In UXTap, the in-site test block offers tag and extension. The choice depends on where the study takes place, the participant's device, and the type of evidence you need to consult later.

When the tag might make sense

The tag is installed on the pages of the website you control. During a task-based test, it records navigation, clicks, and scrolling, and presents the activity controls.

This modality also allows working on mobile, provided that the website, installation, and journey function in the participant's environment. The tag needs to be present on the relevant pages; checking only the first screen is not enough.

An important distinction: the tag does not capture the background image of the page. Therefore, do not promise that your analysis will have the same visual representation as a capture made by the extension.

When to evaluate the extension

The extension accompanies the activity in a compatible desktop environment and offers visual recording of pages, in addition to interaction events. It is an alternative when the study requires testing a website without installing the tag on it.

In UXTap, website comparisons use the extension modality. Even so, check the access, authentication, and navigation conditions of each target before data collection.

Do not plan a mobile study assuming the extension will work on mobile. Also, verify access to the installation on the research date; distribution availability should not be presumed from the existence of the feature.

Example: reviewing an appointment

Imagine a company that wants to observe customers booking an appointment on their own website. The audience typically uses mobile, and the team can install the tag. In this scenario, it's worth starting with a pilot of this modality.

Now imagine a navigation investigation on two websites, using desktop participants and demo environments. The extension can be evaluated for this design.

In both cases, the task needs to be equivalent to the real objective. Use fictitious data and avoid the activity depending on an unnecessary irreversible action, such as confirming a real purchase.

Check the entire task

Follow the journey from the study link to the return after the attempt. Include the paths the participant might take, not just the ideal route.

Use this checklist:

• Are the necessary pages within the recorded scope?
• Do domain changes or new tabs affect continuity?
• Does the success criterion match the objective?
• Can the person end an unsuccessful attempt?
• Do the records allow understanding what happened?

In UXTap, success can be defined by destination URL or manual confirmation, according to the configuration. Manual confirmation is a participant's declaration and should be interpreted with that context.

Tag or extension: choose the necessary evidence

If you need to analyze the exact position of an element on a page image, consider the availability of capture. If the goal is to track paths and responses on mobile, the tag may be more compatible with the audience.

No choice eliminates the pilot. Dynamic content, authentication, and browser restrictions can change the experience.

Document which modality was used and what limitations were observed. This helps the team understand what the replay or map represents.

Create a feasibility matrix before setting up the task

List the audience's device, the domains involved, who can install code, and what evidence will be needed. For the fictitious appointment on their own website, the team might have access to tag installation and need to include mobile participants. For comparing sites they don't control, the same installation is not available.

Also consider authentication pages, redirects, and external services. A task might start on the main domain and end on a third-party calendar. The fact that the first page records events does not demonstrate that the entire journey will be tracked. Mark each transition that needs to be verified in the pilot.

Define the necessary starting state in advance. Use demo accounts and data when the activity requires pre-filled information. Avoid turning the test into an attempt to execute purchases or irreversible changes. The goal is to observe the experience within a prepared scenario, not to produce unnecessary real effects.

An end-to-end pilot for the appointment

Open the study using the same path intended for the participant. Check the instructions, the start of the task on the website, navigation, selecting a time, and completion. Also test an attempt where the person fails to reach the objective. They need to have an understandable exit, according to the chosen configuration.

Verify the completion criterion. A confirmation URL might represent the expected outcome, but an intermediate page accessible before saving should not be used as success. In manual confirmation, the button indicates that the person declared they succeeded; complement the reading with evidence and a question about the outcome.

After the pilot, open the produced records. It's not enough to see the task control working on the screen. Check if navigation, clicks, and the expected visual evidence are available. Note where data collection was interrupted or lacked context and revise the installation or activity design before recruiting.

Plan the analysis according to the existing material

In the tag modality, do not promise a visual page background that it did not capture. It is possible to investigate sequences and responses with the available context, but a map over an image requires that image to correspond to the state and instrumentation used. The absence of this material should appear in the interpretation.

With the extension, verify the installation in the foreseen environment and the captures effectively recorded. Dynamic content, state changes, and opening other tabs may require attention in the pilot. The availability of a capture feature does not, by itself, guarantee that every scenario will be reconstructed without gaps.

For presenting the findings, state which modality was used and which parts of the task were observable. Relate a problem to a verifiable moment and consult the heatmaps guide before interpreting click positions and intensity. The instrumentation decision should remain visible until the delivery of results.

Prepare data collection with a real rehearsal

To start, configure a short task in UXTap and execute it on the intended device. Check the available events and visual evidence, then adjust the study.

Only then send the invitations. The decision between tag and extension should be resolved by the feasibility of the journey and the information needed to analyze the task.

Define the evidence with the session replays guide and consult the real website testing resource before preparing the instrumentation pilot.

Frequently asked questions about tag and extension

Can the tag track any website without installation?

No. It depends on being installed on the relevant pages of the website you control. If the journey passes through another environment, verify possible continuity before planning the analysis. For scenarios without installation access, evaluate the extension modality and its requirements.

Can I treat the extension as a mobile solution?

Do not plan this by assumption. The extension modality is intended for a compatible desktop environment. For mobile audiences, evaluate the tag on the website itself or other material suitable for the question. The chosen device needs to correspond to the experience the research intends to observe.

Do I need to use the same modality in all research?

No. The choice depends on website access, device, and necessary evidence. When comparing rounds with different instrumentations, record what changed in the recording and participation. Differences in capture and context can limit a direct comparison, even when the task has the same name.

Create your UXTap account to prepare your first study.