Configure top and bottom of page events in Web SDK
When delivering personalized experiences, a web page’s loading time is essential. To minimize the time a user waits for personalized content, Web SDK supports the configuration of top and bottom of page events.
Top and bottom of page events describe a method of asynchronously loading various elements in the page while keeping the page load time at a minimum:
- The top of page event requests personalization as soon as the page begins to load.
- The bottom of page event records a page view when the page finishes loading.
Adobe Analytics ignores top of page events, which leads to more accurate metrics recording since only one page hit is recorded (the bottom of page event).
You can configure top and bottom of page events in two ways: by calling the Web SDK JavaScript library (alloy()) directly, or by using the Web SDK tag extension in the Adobe Experience Platform Tags UI. The tag extension’s Send event action includes a ‘Use guided events’ option that pre-configures field values for the ‘Request personalization’ (top of page) and ‘Collect analytics’ (bottom of page) scenarios. Each example below shows both implementations.
Top of page event top-of-page
The example below configures a top of page event that requests personalization but suppresses display events for automatically rendered propositions. Those display events are sent with the bottom of page event instead.
| code language-js |
|---|
|
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Parameter | Required/Optional | Description |
type |
Required | Set this parameter to decisioning.propositionFetch. This special event type tells Adobe Analytics to drop this event. When using Customer Journey Analytics, you can also set up a filter to drop these events. See Edge Network event types in Adobe Analytics for more information. |
renderDecisions |
Required | Set this parameter to true. This parameter tells Web SDK to render decisions returned by the Edge Network. |
personalization.sendDisplayEvent |
Required | Set this parameter to false. This parameter stops display events from being sent. |
Configure a Send event action in the rule that fires at the top of the page. Enable Use guided events, then select Request personalization. This option locks ‘Type’ to ‘Decisioning Proposition Fetch’, ‘Render visual personalization decisions’ to enabled, and ‘Automatically send a display event’ to disabled.
To set these fields manually instead, leave Use guided events disabled and configure each field yourself.
Bottom of page event examples bottom-of-page
Auto-rendered propositions bottom-auto-rendered
The example below configures a bottom of page event that sends display events for propositions that were automatically rendered on the page but suppressed in the top of page event.
| code language-js |
|---|
|
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Parameter | Required/Optional | Description |
personalization.includeRenderedPropositions |
Required | Set this parameter to true. This parameter enables the sending of display events that were suppressed in the top of page event. |
xdm |
Optional | Use this object to include all the data that you want for the bottom of page event. |
Configure a Send event action in the rule that fires at the bottom of the page. Enable Use guided events, then select Collect analytics. This option locks ‘Include rendered propositions’ to enabled.
To set this field manually instead, leave Use guided events disabled and enable Include rendered propositions directly. Optionally, populate the XDM field with an XDM object data element that carries your page data.
Manually rendered propositions bottom-manually-rendered
The example below configures a bottom of page event that sends display events for propositions that were manually rendered on the page (that is, for custom decision scopes or surfaces).
| code language-js |
|---|
|
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| Parameter | Required/Optional | Description |
xdm._experience.decisioning.propositions |
Required | This section defines the manually rendered propositions. You must include the proposition id, scope, and scopeDetails. See Manage display events for more information. Manually rendered personalization content must be included in the bottom of page event. |
xdm._experience.decisioning.propositionEventType |
Required | Set this parameter to display: 1. |
xdm |
Optional | Use this object to include all the data that you want for the bottom of page event. |
The ‘Use guided events’ option does not cover this scenario, so configure the action manually:
-
Create an XDM object (or Variable) data element that populates
_experience.decisioning.propositionswith each rendered proposition’sid,scope, andscopeDetails, and sets_experience.decisioning.propositionEventType.displayto1. See Manage display events for more information. -
In the Send event action for the bottom of page rule, leave Use guided events disabled and reference the data element from the XDM field.
Single-page application with top and bottom of page events spa-example
In a single-page application, you must specify the view name on each view change so that Web SDK renders the correct personalization at the top of the page and records the correct view at the bottom of the page.
First page view spa-first-view
In this example, home is the view loaded on the initial page load.
The top call requests personalization for the home view without recording an Analytics hit or firing display events. The bottom call records the page view and fires the suppressed display events. Include the same viewName in both calls so that the view is recorded consistently.
| code language-js |
|---|
|
-
Create an XDM object data element that sets
web.webPageDetails.viewNameto the view’s name (for example,home). -
Configure a top of page Send event action: enable Use guided events, select Request personalization, and reference the data element in the XDM field.
-
Configure a bottom of page Send event action: enable Use guided events, select Collect analytics, and reference the same data element in the XDM field so that the
viewNamematches in both events.
Second page view — option 1 spa-second-view-option-1
In this example, a single event is sufficient because the personalization for the page has already been fetched.
| code language-js |
|---|
|
-
Create an XDM object data element that sets
web.webPageDetails.viewNameto the new view’s name (for example,cart). -
On the view change, configure a single Send event action: leave Use guided events disabled, enable Render visual personalization decisions, and reference the data element in the XDM field.
Second page view — option 2 spa-second-view-option-2
Use this approach when you need to delay the bottom of page event (for example, when the page’s analytics data is not ready at the time of the view change). Handle the view change in two steps:
- At the top of the page, render the already-fetched propositions without making an Edge Network call.
- Once the analytics data is ready, send the bottom of page event.
Include the same viewName in both calls so that the view is recorded consistently.
Call applyPropositions at the top of the page to render the cached propositions for the new view. Then call sendEvent at the bottom of the page with includeRenderedPropositions: true so that the suppressed display events fire.
| code language-js |
|---|
|
-
Create an XDM object data element that sets
web.webPageDetails.viewNameto the new view’s name (for example,cart). -
For the top of page event, configure an Apply propositions action and set the View name field to the view’s name (for example,
cart). This action renders the already-fetched propositions without contacting the Edge Network. -
For the bottom of page event, configure a Send event action: enable Use guided events, select Collect analytics, and reference the data element in the XDM field.
GitHub sample github-sample
The top-and-bottom sample in the alloy-samples repository demonstrates how to request personalization at the top of the page and send analytics metrics at the bottom. Download the sample and run it locally to see how top and bottom of page events work. The sample uses the JavaScript library directly; the same patterns apply when you configure equivalent rules in the Web SDK tag extension.