Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for WEB_DETAILS_VIEW to track() #4

Closed
samblyon opened this issue Aug 1, 2018 · 2 comments
Closed

Add support for WEB_DETAILS_VIEW to track() #4

samblyon opened this issue Aug 1, 2018 · 2 comments

Comments

@samblyon
Copy link
Contributor

samblyon commented Aug 1, 2018

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 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.

From current readme:

https://github.com/EmpyrNetwork/empyr_web#tracking

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” )

@ChrisSargent
Copy link

Also seeing this behaviour.

@jcuzens
Copy link
Contributor

jcuzens commented May 13, 2019

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.

@jcuzens jcuzens closed this as completed May 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants