The readme states that it is possible to track merchant detail views separately from overall results views. However, the current track function does not support this.
While the docs say track() accepts two arguments, with the second argument being the view type, the function actually only accepts a single argument and the view is always set to _e.view, with the result that the view type is always WEB_SEARCH_VIEW.
Proposal
This PR adds support for a custom view string. It is the simplest approach, allowing an override view string and defaulting to _e.view. It is not necessarily the best approach.
From current readme:
WEB_SEARCH_VIEW indicates that the offers were viewed as search results and WEB_DETAIL_VIEW indicates an offer being viewed in detail.
...
Calling the “track” method If you don’t wish to use the attribute approach outlined earlier then it is always possible to call the tracking methods directly as in the examples below:
// Explicitly call the track function with the id of the offer, and the view context the offer appears in
Tracker.track(“5554”, “WEB_DETAIL_VIEW” )
Tracker.track([“5554”,“5556”,”5558”], “WEB_SEARCH_VIEW” )
samblyon
commented
5 years ago
Problem
The readme states that it is possible to track merchant detail views separately from overall results views. However, the current
trackfunction does not support this.While the docs say
track()accepts two arguments, with the second argument being the view type, the function actually only accepts a single argument and the view is always set to_e.view, with the result that the view type is alwaysWEB_SEARCH_VIEW.Proposal
This PR adds support for a custom view string. It is the simplest approach, allowing an override view string and defaulting to
_e.view. It is not necessarily the best approach.From current readme: