A session replay is a recording of a visit you can watch after it happens. Not a summary someone wrote from memory. The clicks, the page changes, and the place they stopped. Screenshots are the stills. The replay is the motion.
Before you launch an app you built with Claude Code, Lovable, Base44, or Cursor, that recording is the fastest way to see your product as a stranger. You will not sit perfectly still and "be a new user." You know too much. A replay lets you be late to the visit. You watch someone else, who was given a goal and no hints, and you see the moment the app failed them.
This guide explains what you are watching, how to watch without drowning, and how to turn one ugly minute of replay into a fix prompt. The visitors in these replays are practice visitors. They are real browser sessions. They are not your future customers' private lives. That distinction matters, and it is spelled out below.
What you are actually looking at
There are two ways a Persqo run keeps the visit, and both are replays of the same idea.
One is video, built from frames of the browser while the visitor worked. You press play. You see the page move.
The other is a structured replay of the page: you move through the visit and see the clicks and the screens in order. It is the same session, stored so you can inspect it, not only watch it as a movie.
Some runs have the structured replay. Some fall back to video. Some keep a simple step list when a richer recording is not there. The report still has screenshots of the steps either way. You do not need to know which format you got before you can learn something. Open the run, watch what is there, and read the steps beside it.
The visitor in the recording is one of the three drafted personas. They had a name, a role, a goal, a device, and a comfort level. They used a real browser at that device's size. If the goal was to sign up, they could fill the form and submit it like a new customer, with a test email. They will not pay, send a text, message a real person, delete an account, or change a password that is already in use. If they reach a payment page, they stop, and the note says they stopped before paying. You will see that stop in the replay. It is expected. It is not a broken card form until you test payment yourself.
The replay is tied to findings. A console error, a dead link, a missing label, an overflow, a slow open, a missing title or heading: those are listed with severity and a screenshot. The replay answers the question the list cannot: what did the visitor do just before that? A finding that says "stuck on /signup" becomes obvious when you watch the click that returned them to the home page.
Treat the replay as evidence. It is not a mood board. It is what the browser did.
Practice visitors, not a hidden camera on customers
Watch practice sessions before you ever think about recording real people. The practice visitor was created for the test. You accepted the goal. The point of the replay is to debug your app.
That is different from dropping a recorder on every future customer. Real people deserve to know when a product records their screen, and a pre-launch guide is the wrong place to invent a policy for that. Get the practice replays working first. Your signup, your empty state, and your phone width should be clean before a stranger's time is what you are studying.
Also be clear about what the practice signup does to your data. Because the session can submit your real form, your database may gain a test account at visitor@example.com. The replay will show the form being filled and sent. That account is a tool. Remove it if you do not want it in the list. Do not point this flow at a page where a submit would email your entire customer list or charge a card. The session refuses payment and refuses to message a real person, and you should still avoid aiming it at dangerous buttons. Give it the public signup and the first job.
If a page is private, the public session will not log in as your customers. Later, if you want pages behind login tested, you can provide a test account. The password is locked and only used on that site. The replay of that visit is still a practice account, not a customer. Do that only after the public door works.
What to watch for
Play the stuck visitor first. Watch once without pausing, so you feel the path. Watch a second time and stop at the moments below. You are not grading the visitor. The visitor did what the screen suggested. You are grading the screen.
The first wrong tap. They wanted signup and they opened the blog, or a footer link, or a button that says "Learn." That means the primary action does not look primary. Note the words they tapped and the words you wish they had tapped.
The scroll past the goal. The button exists and they never reach it because a tall hero or a row of quotes ate the first screen. On a phone-width replay this is common. The mobile guide tells you how to fix the width. The replay tells you they never saw the control.
The repeated tap. They tap the same control again because nothing changed. The page ignored them, or the change was too subtle to count. Pair this with console findings. A throw on click often looks, in the replay, like a tap that did nothing.
The form that returns to the start. They fill email, they submit, a toast flashes, the marketing page is back, and they are signed out. This is the signup bug the signup guide is about. The replay is the proof. Your user list either has the test email or it does not. Watch, then check the list.
The stop. They sit on a page and the session ends there, goal not reached. Read the heading on that page. If you cannot say what they should tap next, they could not either. That is an unclear next step, and it is a fix even when no error was thrown.
The overflow wiggle. The window moves sideways, or the button is cut. You will see them miss the edge. The finding will say the content overflows. The replay makes it obvious enough to write a fence: stack this row, do not redesign the site.
The payment stop. They reach a checkout and the visit ends before any card. Good. Do not "fix" the replay by asking the editor to skip payment. Finish the path up to that door, and test the card with the payment tool's own test mode, outside this visitor.
Write timestamps in your own words, even roughly. "After the second tap on Join, the home page returned." That sentence belongs in the prompt. The replay is the source. The sentence is what the editor reads.
Ignore music-video instincts. You do not need to comment on every hover. Three moments, the worst one first, are a fix. A twenty-point critique of a two-minute visit becomes a prompt that rewrites the product. Pick the moment that blocked the goal.
Screenshots, replay, and the finding list
Use all three. They answer different questions.
The finding list is the index. It is sorted with serious problems first. It tells you where to look. A missing image alt on a footer logo is not the first thing to watch if signup is stuck. Click the stuck finding.
The screenshot is the still you can paste into your own notes and glance at while you edit the prompt. It is the screen at that step, not the whole story. If the screenshot shows "You're in" and the header shows "Log in," you already have the bug in one frame.
The replay is how the still happened. It stops you from inventing a cause. Builders invent causes constantly: "they must have skipped the modal." The replay shows there was no modal. Believe the replay over the story you like.
A practical order:
- Read the verdict. Reached, stuck, or unclear.
- If stuck, open the top finding and its screenshot.
- Watch the replay from the start of that visit once.
- Write three moments.
- Read the fix prompt the report already drafted. Correct any step the replay contradicts.
- Paste into Claude Code or Cursor, or into Lovable or Base44.
- After the patch, run the same visitor and watch the new replay far enough to see the new moment. The goal line is the summary. The new replay is how you know the path is actually calmer.
The prompt guide, how to turn bug reports into Claude Code fix prompts, is the paste step. Replay is the input. The prompt is the output. Do not paste a prompt you have not watched, unless the finding is a plain broken link you already understand. For signup and for "they got stuck," watch first.
How to watch one visit without getting lost
Replays tempt you to rewatch forever. Set a small routine.
Watch the signup visitor end to end, even if you think signup works. It is the door.
Watch any visitor marked stuck, end to end, once.
Skim a visitor who reached the goal. Pause only if you see a wrong tap they recovered from. If the recovery was ugly, it is still a usability fix. If it was a single mis-tap and they immediately found the button, you can leave it.
Keep notes in the five-part shape the editor needs: who, steps, what happened, what should happen, fence. You are not writing a documentary. You are writing a prompt. If your note gets longer than the sample in the fix-prompt guide, you are describing two bugs. Split them.
Compare two replays when you regress. The old one reached the goal. The new one, after a prompt that "only changed copy," gets stuck. Watch the old click, then the new click. The difference is the bug. Say it in one sentence. "The Join button used to open /signup. It now opens /about." That sentence plus the fence "change only the Join target" is a complete prompt.
If the replay and the finding disagree, trust what you can see, and mention both in the prompt so the editor is not confused. "The finding says unlabeled field. The replay also shows the submit returning to the home page. Please fix both." Deleting the finding because you are focused on the redirect will bring the unlabeled field back next week.
Phone replays deserve a full watch, not a skim. A wide-window habit makes you assume the button was visible. The phone replay is where you see it was not. If you only watch one replay tonight, watch the phone visitor who tried to sign up.
A scene you can practice seeing
Made-up habit app, so the watching is concrete. The visitor is a first-time user on a phone. The goal is to sign up and add one habit.
You press play. The home page loads. A large illustration fills the screen. They scroll, pass a row of quotes, and only then find Start. They tap Start. The form has two boxes. The placeholders vanish as they type. They pause, clear both fields, and type again. They tap Create. A toast says the account is ready. The next frame is the home page, illustration first, and the header still offers Start. They scroll, looking for the habit list. The session ends. Verdict: stuck.
You check findings. Unlabeled fields on the form. No console error. No overflow on the form, but the home page was taller than the phone. The user list has no test email, which you confirm outside the replay. So the toast lied, and the path was also too long.
You do not write a novel. You write two prompts, because there are two bugs.
First, QA: create does not create, the toast claims success, the replay returns to the signed-out home. Show errors on the form. On success, open an empty habit list. Keep the layout.
Second, usability, after the first is fixed: move Start above the illustration on a phone width so a new visitor sees it without a long scroll. Do not delete the illustration. Stack it lower.
You could have merged them. You would have gotten a redesigned home page and a still-broken create. The replay made the order obvious: they did find Start, eventually, and the create was the hard stop. Fix the hard stop, rerun, watch the new replay, then decide if the scroll still hurts. Often the second watch shows a calm path and you skip the visual prompt. That is the replay earning its keep. It talks you out of extra changes.
The screenshot of the toast plus the signed-out header is the still you keep in the prompt. The replay is how you know the toast and the header were the same visit, seconds apart.
After you have watched
A replay you do not act on is a movie. Close the loop.
- Paste the corrected prompt.
- Rerun the same persona.
- Watch the new visit until the goal or the new stuck moment.
- Save the passing replay in your mind as the baseline, or keep the run, so the next regression has something to compare.
- Only then invite a real person to try that same goal.
When they try it, you are not "collecting replays of customers" yet. You are asking one human to do one job and tell you where they paused. If you later add a recorder for real traffic, that is a product decision with consent, retention, and a reason. It is not required to launch, and it is not what this pre-launch watch is. The pre-launch watch is the practice browser, the screenshots, and the prompt.
If a run is unclear, the replay is how you decide whether to edit the goal or edit the app. An unclear verdict with a calm path and no finish line means the goal was fuzzy. Tighten the goal. An unclear verdict with wandering taps means the next step is invisible. Change the screen. The replay is the tie-breaker. Do not flip a coin and restyle.
You can launch without a lab. You should not launch without having watched one stranger's session, even a drafted one, try to get in. Press play before you send the link.
Questions people ask
Is this a recording of my real customers?
Before launch, no. The replay is the practice visitor's browser session: a drafted persona who tried a goal on your public site. It is not your customer's private browsing, and it is not a surprise recording of a person you invited. When real people arrive later, that is a different decision, with a different duty to tell them. This guide is about watching the practice sessions first.
Is the replay a video file?
Sometimes. When the run records video, you watch a video. Other runs store a replay of the page you can move through click by click. Either one is the session. Screenshots are the stills from the same visit. You do not need a video file for the replay to be useful.
What should I watch for?
The first wrong tap, the scroll that passes the button, the form that submits and returns to the start, and any moment the visitor stops. Pair that with the findings list so a console error or a dead link is not something you have to notice by eye.
Can I skip the replay if the goal was reached?
You can, and you will miss the confused path that happened to arrive. Watch a reached goal once, at least the signup one. If the path is calm, later reached goals can be a quicker look. Always watch a stuck goal before you write a fix.
Does the replay type real passwords into my app?
The signup session can fill a test email and a test password on your form and submit like a new customer. The replay is there so you can see that the form was used. Do not reuse that pattern with a real customer's password. The practice visitor will not pay, send a text, or change a password that already belongs to someone.