You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The docs say track() accepts two arguments, with the second argument being the view type. However, 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
Add 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.
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” )
The text was updated successfully, but these errors were encountered:
The pull request was merged but our Codeship was not deploying anymore. We have now moved to Travis and this is deploying properly with the PR merged. Please also note we added in some support for a flow we used to have which is based on a command queue instead of calling the Tracker functions directly (this is still possible for backwards compatibility). The command queue approach works more like Google Analytics.
Problem
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.The docs say
track()
accepts two arguments, with the second argument being the view type. However, 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
Add 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:
https://github.com/EmpyrNetwork/empyr_web#tracking
The text was updated successfully, but these errors were encountered: