Multiple SiteCatalyst Calls on one page

[martin_saoud]

We have the following requirement: On a Single Page Application, there is one page that can contain several widgets. The setup of these widgets is user-specific (every user has a different setup). The requirement is now to make a SiteCatalyst-Request on the display of the main page and one SiteCatalyst-Request for every widget. The question is now of how to implement these requirements. I thought of queueing the requests somehow like this: - Main page and every widget make a call to page_queue(data), where data contains the specific UDO parameters. - within page_queue, there are subsequent calls to utag.view(data, queue_callback), but the next call to utag.view() is only done in the callback function queue_callback What makes me unsure is that I once read in an article that you should avoid multiple calls to utag.view(). Are multiple calls to utag.link() better? Thanks in advance

[james_hartley]

Hi Martin, For the SiteCatalyst request on the main page - this should trigger by default if our tag is loading on the page. There is a default utag.view call. Sounds like you've got that down :). For the subsequent calls that occur post page load you can call a utag.view or utag.link. Within utag.view or utag.link you can then pass the relavant data as you mentioned. It completely depends on how you want to report on the widgets in your report suite. The utag.view is representative of an s.t call and utag.link is representative of an s.tl call. So a utag.view would report as a page view for each interaction of the widget and the utag.link would be considered a custom link/event. There is a risk that you could inflate your pageview count using utag.view on the subsequent calls depending on your reporting goals. Does this help?

[samrat_dsouza]

Hi Martin I'd start with basics, every call made to SiteCatalyst costs money. Tracking widgets as pageViews can be very expensive. Instead, look at at widgets as content displayed and interacted with. It make sense track only interactions as pageViews and keep views collated in one single call. Imagine, one page having 5 widgets loads, 6 (5+1) unique pages in pages report doesn't give any insights. Though any interaction with any widget on the page, would be interesting to see as pages - depending on the website. To keep it short, track widgets loaded with the main pageLoad call in a list prop or listVar(hit expiry) with a view event. Now, any interaction there on should be tracked as pageView with pageName including the widget info and listVar(expiry as HIT). Hope this helps. If making multiple calls is the only solution, then use an extension and write a script to loop through an array and fire utag.view for specific UID. Cheers Samrat D'souza

[martin_saoud]

Thanks for your answer, I'll check with our SiteCatalyst specialist then.

[martin_saoud]

Thanks for your answer. My question was mainly if I run into problems when I call utag.view() or utag.link() more than once - for example in a loop. I once read in a post that this could mess up things because utag.view() does not finish all the actions, but triggers asynchronously other subsequent actions. My question is, if for example utag.data could be messed up doing actions like this. Thanks in advance for any comments!

[james_hartley]

Hi Martin, I think that reaching out to your account manager would be best at this point as you have a specific use case that needs resolution. They can get a technical resource assigned and develop the best course of action :). Thanks!

[martin_saoud]

Hi James, I will do that - to avoid that he gets bored without having to solve technical issues. :-)