Session Replay Events provide the page-by-page structure behind a visual Session Replay.
While Chapter 18 focused on watching the recording itself, Chapter 19 focuses on understanding the supporting event information that tells you:
AIUNIFY Analytics specifically defines its Replay Page Events view as:
Replay page events
and explains:
“Only pageviews type events show up in this modal.”
The fundamental structure is:
Replay Recording → Pageview Events → Page Journey Timeline → Jump to Page → Investigate Behavior
This distinction is important.
A Session Replay can contain many underlying recording events.
The Replay summary displays:
Tracked events
which represents the overall number of recording events associated with that Replay.
However, the Replay page-event layer intentionally extracts only the recording events representing page loads/Pageviews.
Therefore:
Tracked Events ≠ Number of Pageviews
Suppose a Replay contains:
Tracked events: 1,250
That does not mean the visitor viewed 1,250 pages.
The Replay may contain many recording events needed to reconstruct:
while the Page Journey might contain only:
5 Pageviews
The Replay timeline concentrates on those meaningful page transitions.
To review Replay Events:
The individual Replay belongs to a specific Website Session and Visitor.
Beneath the visual Replay player, AIUNIFY Analytics creates a chronological timeline of the Pageviews recorded during the Session.
Each timeline item contains:
This gives you a quick map of the Session without requiring you to watch the entire recording from beginning to end.
The Replay data contains multiple event types.
For the page timeline, AIUNIFY Analytics specifically extracts its page-load events and converts them into a separate list of Pageviews.
For each Pageview, Analytics derives:
This Pageview list is then used to build the visible Replay timeline.
Replay Pageviews are collected as the Replay recording is processed.
The resulting timeline therefore follows the visitor's recorded page journey.
Conceptually:
Page A
↓
Page B
↓
Page C
↓
Page D
This lets you reconstruct the sequence in which the visitor moved through the Website.
A Session might show:
/
9:15:04 AM
↓
/services
9:15:48 AM
↓
/pricing
9:17:06 AM
↓
/contact
9:18:42 AM
The timeline tells you the structural journey.
The Replay player shows what happened visually during that journey.
Each timeline entry prominently displays the recorded Website:
Path
For example:
/
/services
/pricing
/contact
/products/enterprise
The Replay processor extracts this Path from the recorded page URL.
Paths allow you to quickly understand the visitor's navigation pattern.
For example:
Home → Pricing → Contact
suggests a straightforward journey.
Whereas:
Pricing → Home → Pricing → FAQ → Pricing
may indicate repeated evaluation of the same information.
The path itself does not explain why the visitor behaved that way, but it tells you where to investigate.
Each Replay timeline item includes an external-link control that opens the actual recorded page URL in a new browser tab.
Use this when you want to compare:
What the visitor saw in the Replay
with:
What the Website currently looks like
A Replay represents the Website as it was recorded.
The live Website may have changed since then.
Possible changes include:
Therefore, if an old Replay looks different from the page opened through the current URL, that does not automatically indicate a Replay problem.
Each timeline item displays the recorded time of the Pageview.
This helps you understand the pace of the Session.
For example:
Home — 10:00:00
Services — 10:00:20
Pricing — 10:03:45
The visitor moved quickly from Home to Services, but spent several minutes before reaching Pricing.
Time differences can provide useful context.
For example:
Home → Pricing in 5 seconds
may suggest rapid navigation.
Pricing → Contact after 4 minutes
may suggest the visitor remained on Pricing for a longer period before continuing.
However, Pageview timing alone cannot prove exactly what the visitor was doing during the interval.
Use the visual Replay for that context.
Each Replay Pageview also displays the recorded browser viewport dimensions.
For example:
1920 × 1080
1366 × 768
390 × 844
This information helps you understand the layout visible to the visitor at that moment.
Responsive Websites can look significantly different depending on screen dimensions.
A navigation problem visible at:
390 × 844
may not exist at:
1920 × 1080
Viewport information can therefore be especially useful when investigating:
Each page timeline entry contains a Play button.
Selecting that control tells the Replay player to jump directly to the point corresponding to that Pageview.
This is one of the most useful Replay investigation tools.
Suppose a Replay lasts:
12 minutes
but you only care about what happened when the visitor reached:
/pricing
Instead of watching the first eight minutes:
/pricing in the timeline.AIUNIFY Analytics stores the timestamp for each Pageview in the timeline.
It calculates the Pageview's position relative to the beginning of the Replay timeline and instructs the player to move to that point.
This makes the timeline both:
Informational
and:
Interactive
As the Replay progresses, AIUNIFY Analytics compares the player's current recording timestamp with the Pageview timestamps in the timeline.
The corresponding timeline entry is highlighted as playback reaches that portion of the Session.
This helps you keep track of:
Which page am I currently watching?
When the currently active Pageview changes, AIUNIFY Analytics can automatically scroll the timeline toward the corresponding entry.
This is particularly useful for Sessions containing many page transitions.
You do not have to manually search the timeline every time the Replay moves to another page.
AIUNIFY Analytics also defines a dedicated:
Replay page events
view.
Its information message states:
Only pageviews type events show up in this modal.
The purpose is to provide a simplified page-load sequence rather than every underlying Replay event.
A Replay Page Event can display:
The entries are visually separated so the sequence can be followed from one Pageview to the next.
Replay Page Events are explicitly presented as:
Pageview
rather than Click, Scroll, or other Analytics event types.
This reinforces that Replay Page Events are intended to describe the page journey.
The detailed Replay Page Event representation displays the full recorded URL.
This can provide more information than the shortened Path displayed in the primary timeline.
For example:
Timeline:
/pricing
Page Event URL:
https://example.com/pricing
Both represent Pageviews, but they serve slightly different purposes.
Optimized for:
Optimized for:
The timeline is the primary playback-navigation tool.
This is the most important distinction in Chapter 19.
Contain only Replay:
Pageviews
The interface explicitly states this limitation.
Can contain broader Advanced Analytics activity such as:
Session Events were covered in Chapter 13.
Suppose a visitor:
May show:
Pricing
↓
Contact
May show:
Pageview — Pricing
↓
Scroll — 70%
↓
Click — Request Demo
↓
Resize
↓
Pageview — Contact
This is why the two views should not be treated as duplicates.
A visual Replay already contains a large amount of behavioral detail.
The page-event layer therefore provides a simplified navigation framework:
Where did the visitor go?
while the Replay itself answers:
What visually happened there?
and Session Events can answer:
What structured Analytics interactions were recorded?
A useful model is:
Where did the visitor go?
What did the visitor appear to do?
What structured interactions did Analytics record?
Using all three provides a more complete investigation.
Suppose the Visitor reaches:
/contact
but does not convert.
Shows:
/contact
at 3:42 PM.
Lets you observe the recorded interaction with the page.
May reveal:
Determines whether the defined Conversion occurred.
This separates navigation, behavior, and business outcome.
Suppose a Visitor visits Pricing three times.
Timeline:
/pricing
↓
/services
↓
/pricing
↓
/faq
↓
/pricing
This repeated Pageview pattern may be worth investigating.
Use the timeline Play controls to jump directly to each Pricing visit and compare the behavior.
A Replay might show:
Landing Page
↓
Services
↓
Case Studies
↓
Pricing
↓
Contact
This is a relatively linear sales journey.
You can then examine:
Another Replay might show:
Pricing
↓
FAQ
↓
Pricing
↓
FAQ
↓
Pricing
Repeated navigation can be a signal worth investigating.
Possible questions include:
The Replay shows behavior; it does not automatically determine the reason.
Timing between Pageviews can help identify moments worth reviewing.
For example:
Landing → Pricing: 15 seconds
Pricing → Application: 6 minutes
The longer period on Pricing may deserve closer Replay review.
Use the timeline Play button to jump directly to that point.
Rapid Pageview changes may indicate:
Use the visual Replay before interpreting fast transitions as a problem.
A longer period before the next Pageview may represent:
Again:
Time ≠ Attention
The Replay provides more context.
A particularly useful workflow is to compare Replay Page Events with a Goal Conversion.
Suppose a Goal occurred at the end of the Session.
Review:
Page 1
↓
Page 2
↓
Pricing
↓
Testimonials
↓
Conversion Page
Then watch the Replay around the final pages.
This can help identify patterns preceding successful conversions.
Heatmaps tell you how many visitors behave across a page.
Replay Events tell you how one visitor moved between pages.
Example:
Heatmap:
Pricing page has strong CTA activity.
Replay timeline:
Visitor reaches Pricing.
Replay:
Observe the individual interaction.
This creates:
Aggregate Pattern → Individual Example
If a visitor ultimately leaves the Website through an external destination:
This can be useful for journeys involving:
Remember that one Replay represents one Session.
The Visitor may have additional Sessions before or after it.
For broader analysis:
Replay → Visitor → Sessions
You may discover:
Session 1: Services
Session 2: Pricing
Session 3: Pricing → Contact → Conversion
The Replay timeline explains one Session, while the Visitor record explains the larger journey.
The Replay player loads the underlying recording events and builds the visual Session from them.
For performance, AIUNIFY Analytics initially loads part of the Replay and then adds remaining recording events progressively.
From a user's perspective, this means longer recordings may continue preparing after the initial player appears.
Although all Replay events are used for the visual recording, only the extracted Pageview events are sent to the page timeline.
This explains why:
Tracked Events
can be much larger than:
Timeline Pageviews
This is expected.
The Replay's:
Tracked events
metric represents the broader recording.
The timeline represents only the selected page-load events used to identify Pageviews.
Do not expect those numbers to match.
If the visitor only loaded one recorded page during the Session, the timeline may contain only one Pageview.
That does not mean the Replay contains only one recording event.
The visitor may still have:
without navigating to another page.
If you expected another page:
Replay Page Events represent recorded page-load events, not every interaction.
First confirm that you selected the correct Pageview in the timeline.
If the Replay itself fails to load or reconstruct correctly, AIUNIFY Analytics can report:
“Sorry, we have detected some issues with this replay session and we can not display it.”
Try another Replay to determine whether the problem affects only the individual recording.
The Replay represents the recorded Website state.
If the Website has since changed:
the live page opened from the external-link control may no longer match the recorded experience exactly.
Use the Replay itself as the historical behavioral reference.
For an individual recording:
For a converted Visitor:
Open Goal Conversion
↓
Identify Visitor
↓
Identify Session
↓
Open Replay
↓
Review Page Timeline
↓
Find Conversion-Related Page
↓
Jump to That Point
↓
Watch Preceding Behavior
↓
Review Session Events
↓
Compare with Other Converting Replays
This can help identify recurring behaviors associated with successful customer journeys.
For a suspected problem:
Identify problem page
↓
Find Replays containing that Path
↓
Jump directly to Pageview
↓
Watch visitor behavior
↓
Review Session Events
↓
Compare with Heatmap
↓
Look for recurring pattern across multiple Replays
↓
Form improvement hypothesis
Avoid redesigning a Website based on one unusual Session.
When reviewing Replay Events, confirm:
The Replay structure can be understood as:
Recorded Session
↓
Full Replay Event Stream
↓
Uses the broader recording data to reconstruct the Session.
↓
Extracts page-load events.
↓
Displays:
Path → Time → Viewport → Jump Control
↓
Provides additional structured Analytics behavior.
↓
Provides the business outcome.
This is the complete relationship between Replay navigation, behavioral events, and conversion analysis.
You should now understand that Replay Events serve two different purposes inside AIUNIFY Analytics.
The full recording contains the event data required to reconstruct the visual Replay, while the Replay Page Events layer intentionally extracts only Pageview/page-load events for the page journey.
The visible timeline uses those Pageviews to display:
Path → URL → Time → Viewport → Jump Control
and allows you to move directly to a specific page in the recording.
As playback progresses, AIUNIFY Analytics identifies and highlights the corresponding Pageview entry in the timeline, keeping the page journey synchronized with the Replay.
Most importantly:
Replay Page Events = Page Journey
Visual Replay = Recorded Experience
Session Events = Structured Behavior
Goals = Business Outcome