Reliable Triggering of Web SDK sendEvent on Hash-Based SPA Filter Changes (Adobe Launch + Target)
Hi, I need some help regarding an issue with our Adobe Experience Platform Web SDK and Adobe Target implementation.
We are working on an integration using Adobe Launch, Web SDK (sendEvent) and Adobe Target, where everything works correctly on the initial page load. We already have a working setup where the Web SDK sends a request using correct decisionScopes, and a separate applyPropositions rule is used to render the experiences.
However, we are facing an issue in a SPA environment where the page does not fully reload. Instead, filter changes update the URL using hash changes (window.location.hash).
The problem is that when the user changes filters:
- the URL hash updates correctly
- but we cannot reliably trigger a new
sendEvent - the Launch History Change event is inconsistent
- sometimes it fires multiple times for the same filter change
- sometimes it does not fire at all depending on navigation flow
As a result, the Web SDK request is not consistently sent, and in some cases we do not receive any Target response (no activities / propositions returned).
Constraints:
- We cannot modify the site code (Launch-only solution required)
- We cannot use
_satellite.track - The application is hash-based routing (not History API based)
- We must keep the current architecture unchanged:
sendEventfor fetching decisionsapplyPropositionsfor rendering Target experiences
Goal:
We need a stable and reliable approach to:
- detect real filter changes in a hash-based SPA
- ensure
sendEventis triggered exactly once per real filter change - avoid duplicate or missed executions caused by History Change inconsistencies
- keep the existing Target + Web SDK architecture unchanged
Any guidance on how to properly handle this scenario in Launch would be greatly appreciated.