…ally mandatory created a new column content_name for now (instead of existing idaction_name, will maybe remove it again). Otherwise it is hard to know whether it was a content action or not and the actual problem was that maybe other actions already define an idaction_name which might be different to content_name. We need the content_name along other actions to match an interaction with an impression. Next: The client side and the redirect...
… or not. This is quite a complex task and I do not think it can always work 100%. There are too many factors and ways to hide an element. For instance using a zIndex, zoom level, when a div is scrollable, CSS might not be applied yet at the time we scan etc. So far this should cover most cases but it must be clear it cannot work in all and there still needs to be a lot of testing. Also need to detect whether CSS was applied or not
…iting this I noticed a few things that need to be changed and that do not work, also many possible new features for V2. Already updated a few things but will need to adjust more things before writing tests
…piece in case we detect the URL of an image, video or audio, pdf, ... automatically. Otherwise we cannot display a preview in the UI and one would not know which URL was actually meant. Thinking about using //domain/path instead of http://domain/path as it would track different content pieces for http and https otherwise
…stalled. When replacing the initial link urls link tracking might not be installed yet but enabled (will be installed on load event). When a click is happening on a content block we still need to use linkTrackingInstalled since then the credirect/tracking request is actually happening and we need to know whether outlink/download will track it or whether we have to do it separately. Make sure to call enableLinkTracking before trackContentImpressions although there should be no huge difference as both will be delayed until ready/load event anyway
Delay first content tracking request a bit to make kinda sure a possible
previous pageview request is already executed. If there is a new visitor
and there are 2 tracking requests at nearly same time (eg trackPageView
and trackContentImpression) 2 visits will be created as both visitors
are basically at the same time. This is only a workaround and it this
problem might still occur. Also delay a link earlier in case an
interaction is happening to make sure the browser waits for the
interaction to be tracked.