Had a question around the WebView tracker and how to use it in certain scenarios.
First Scenario:
If we have a mobile app that is using screens from a website that already has the browser tracker installed on it, would it be possible to also run the WebView tracker in parallel? If we run it in parallel, will both trackers send events to the collector? If so, would we have to use some sort of logic to detect how the screen is being viewed to determine whether to use the web tracker or the browser tracker?
Second Scenario:
If we have a web SDK that is being used in a browser experience and a hybrid app experience, can the WebView tracker work on it’s own within a browser? All the documentation says that it needs to be subscribed to by the iOS or Android SDK, but if a user is viewing the web SDK in a desktop browser, how do the events get sent?
So in scenario 1 you can do this, you do ideally need to name the trackers differently so tracker_name would be the logic flag you can use to easily differentiate. This tracker name is part of the initialisation options, from memory I think it’s set to ‘co’ as an example meaning company.
The second scenario, in theory the inbuilt device browser will do the sending of events. I’m not 100% sure but someone will know better and reply. Best practice is likely the SP SDK which works very well.
Yes, they can be run in parallel, but because they’re different modules you essentially have to double-call all the trackSelfDescribingEvent etc methods, once for the actual Browser Tracker, and once for the WebView tracker. The normal “dispatch” logic (which gets all initialized trackers to send each event) won’t work as if you had just created multiple trackers, for instance; they’re totally oblivious to each other. If you want to not double track and just detect which one to use, you can check the same interfaces the WebView tracker does: const useWebView = !!(window.SnowplowWebInterface || (window.webkit && window.webkit.messageHandlers && window.webkit.messageHandlers.snowplow) || window.ReactNativeWebView); This value will be true if there’s a subscribed WebView hosting the page, and false otherwise.
Kind of, the WebView tracker calls will all check the above interfaces, and if not found, they will safely do nothing. So on a desktop you can have the same code calling the WebView tracker and it will just not track anything (so you need to implement the Browser Tracker too per above if you want that to be tracked normally) but on mobile when something is described it will use the mobile tracker.
Thanks for all the help so far. So the docs for the WebView tracker seem to be pretty straightforward. I see that trackSelfDescribingEvent and trackPageView can be imported from @snowplow/webview-tracker. The project I’m working on also leverages link tracking through the @snowplow/browser-plugin-link-click-tracking package.
Is there any way to also forward these events to an App through a WebView? Or would you instead need to replace that with a trackSelfDescribingEvent call?
Is there any way to also forward these events to an App through a WebView? Or would you instead need to replace that with a trackSelfDescribingEvent call?
Replacement with trackSelfDescribingEvent is your best bet for now unfortunately; I don’t think there’s many other good options in the v3 trackers.
v4 should have some better options but that may not be out in time for your project, unfortunately.
Yeah that seems to be the only option after some further digging. Appreciate the response! Might have to explore that as an avenue but I’m not sure what effects that might have as of yet.