What’s the most robust and effective way to implement Adobe Target on a Single Page Application (SPA)

[Stella-Tsn]

Hello,

I’d like to request your input on the most robust and future-proof way to implement Adobe Target on a Single Page Application (SPA) — particularly for a complex hotel booking system.

Currently, the implementation is client-side via Adobe Tag Manager, which has led to flickering, broken tests due to re-rendering, extended QA cycles, many workarounds which lead to slower experimentation velocity — all of which impact sprint delivery and overall efficiency.

While the agency (Adobe Licensed Architects) positioned this setup as industry best practice, Adobe’s own documentation recommends a hybrid implementation for SPAs. This approach combines client-side flexibility (at.js) with server-side or Edge Delivery stability, ensuring faster performance, more reliable experiment delivery, and reduced flicker — especially critical in dynamic, transaction-heavy environments like hotel booking systems.

Furthermore, I would like to understand how Target calls are triggered across different implementation types (client-side via Tag Manager, hybrid, and server-side) and how these variations impact Adobe Target call volumes and associated licensing costs.

Given these considerations, I’d appreciate your perspective on how we can align our setup more closely with Adobe’s recommended hybrid model to support both scalability and experimentation velocity moving forward.

Thank you for your insights.

Best regards,

/Stella

[AinoVi]

Hi @Stella-Tsn 

When it comes to SPA sites, there are some Adobe best practices, but in the end it really comes down to what your testing roadmap look like, the type of tests you plan, your specific site/setup in your spa e.g. when and how is content fetched from the server, so i would consider the best practices more of a guiding and not the final truth, as it really depends on your setup.

WebSDK and Target is a solid setup - even on SPA, so I wouldn't question that setup. It has a few drawbacks when it comes to goal tracking, but nothing that cannot be worked around.

The server-side and hybrid approach could be a solution, but also comes with some drawbacks. Server-side would fix flicker, but would remove some of the freedom you have by using the VEC, as all test would have to be created using the form-based composer as server-side doesn't support the VEC. You would also be limited to only test certain elements defined up front and would be heavily be depending on IT.
When it comes to hybrid, then Adobe supports this with the WebSDK as well and is documented here. Again, all depending on your need, your backend and the hybrid approach may not be the right solution for you.

As mentioned, some of the things to take into consideration when deciding on the implementation method are: how does your testing roadmap look like, what types of tests/personalization are you planning on (simple/advanced), do you plan on support from developer for setting up the tests or can you do it in the VEC and what are some of the specific challenges in your SPA website e.g. when is content fetched (this will most likely require input from one of your developers). I would recommend you bring these input to your agency and have them outline the pros and cons for each of the implementation methods, so you can make an informed decision on the best way forward for the implementation.

Lastly, Adobe is releasing an update to handling flicker, but last i heard is that it won't be released until next year.

Hope this helps. Without knowing your specific setup it is difficult to provide a concrete answer to your questions, but it doesn't necessarily sound like you're in a wrong setup.

Kind Regards,
Aino Virtanen