Timeout Errors in Action Blocks Causing Missing Web SDK Beacons

[mavenido95]

Hi everyone,

We recently migrated to Adobe Analytics Web SDK implementation and have been encountering timeout errors in Action Blocks, especially under slow network conditions (3G). This results in missing interact calls, meaning both page load and link click beacons fail to fire.

To mitigate the issue temporarily, we have shifted some Action Blocks to Condition Blocks to ensure earlier execution. However, we know this is not a standard approach, and we want to address the root cause properly.

A few key details about our setup:

• Launch script is self-hosted and loaded asynchronously.
• Timeout issues seem to impact specific Action Blocks, leading to beacon failures.
• Adjusting setTimeout values helped slightly but did not fully resolve the issue.

Questions:

1. Why is this occurring specifically in Web SDK? Are there known timing dependencies?
2. Are there any best practices or configurations we should check to prevent timeouts in Action Blocks?
3. Could self-hosting the Launch script asynchronously contribute to this behavior? If so, how can we optimize it?
4. Any suggestions for debugging or resolving this issue without relying on non-standard workarounds?

Would appreciate any insights or recommendations. Thanks in advance!

[Jennifer_Dungan · Accepted solution]

Timing issues are always tricky...

I haven't switched to WebSDK, but I have had my fair share of trying to align timing between site code, third party integrations, and Adobe...

In Launch, I believe the standard timeout in most code blocks is 2 seconds (or 2000 milliseconds). In each Action, there should be Advanced settings that you can expand and change the timeout:

Most of my rules, I increased to 5000 (I have a lot of custom JS, and I also had to build in "setTimeout" and loops to allow for all our third party code to properly load to include all the data I need when the page is fully ready). This is both a standard and non-standard work-around... The timeout being the standard, but to compensate for what I know is going to be slower code.

Not saying you will need all that, but increasing the timeout settings should just allow the action to run longer before "failing".. this might be all you need to make your tracking work.

As for self-hosting your files, that shouldn't have an impact... it might impact how long it takes the file to load (not saying it is, but if the file wasn't loading from a CDN it might not load as quickly as it could)... but that wouldn't affect the actual rules.... The JS files load, then the triggers and actions are all run on the client side from those files (the JS has already been downloaded to the local machine).

I would try adjusting the timeout, and see if that fixes it.

Good Luck

[mavenido95]

Hi Jennifer,

I appreciate your prompt response to this concern. I also checked with Adobe Support, and they confirmed that this is the recommended approach.

My additional concern was whether adjusting the timeout would impact page performance. However, since we are using an asynchronous implementation and the site executes separately from the Launch script, it should not have any direct performance impact. That said, the execution of subsequent rules could be affected. To prevent this, we can simply ensure that the "Wait for next action" option is unticked, allowing other rules to proceed without delay.

Thanks again for your insights and support!