-
Notifications
You must be signed in to change notification settings - Fork 106
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
Issue parsing Ahoy::Event properties hash attribute #93
Comments
This issue has been addressed in part by adding metadata to Ahoy Events, which partial solution has been added to the branch site_analytics which will need to be rebased off current master. That branch includes a first draft of an analytics page that graphs pageviews by day, visits by user location, etc. We do not track clicks, but at this point, I do not remember if we had trouble doing it, or if we just hadn't figured out what metrics we wanted to track. |
@campgurus Have you solved this? |
no sir. Just coming back to take a look again. It would be nice to have some analytics. |
finally got an answer on this. Based on the slowness of the query, we may need to figure out something asynchronous or not have real time data, but, it does return the desired results from the Events.properties hash. https://stackoverflow.com/questions/35753631/querying-ahoy-gem-events here is what the query looks like to find out how many times an article has been viewed:
|
relates/dupe to #145 |
Ok. Time to rethink this effort. The above query is so resource intensive as to not make sense for us. Right now, the Ahoy::Events table is taking up the majority of our db capacity but giving us little of the feedback we wanted. Instead of recording every view of every page and every click of every button int he generic way we are doing it now, I would suggest creating custom trackers within the controllers for the events we are interested in. Specifically, remove the code I believe it would be easy to track article views, follows, comments, which would give us enough to create a relatively robust "trending" list (for lack of a better term). Events would still belong to Visits, which attach to users and contain basic info we could use in parsing events by user, user location, device etc allowing us to build a decent analytics page that could include:
With additional work, I think we could record other information that will help shape the product like how many people click on the related case photos, or how many click to follow a case or comment, but don't complete the action. How many people click thru from the recent updates list, how many people search, etc. |
As pointed out by @trystant, as of March 24, 2016, the gem documentation outlines a method for querying Events based on elements of the properties hash: https://github.com/ankane/ahoy#querying-properties However, i am still unable to retrieve and records. I have tried both the jsonb approach (Throws error " "no implicit conversion of Hash to string") and the text datatype (no error but returns 0 results) |
Thinking of using json instead of jsonb to see if it works. Here is link to how to change the datatype: http://stackoverflow.com/questions/27343231/how-to-use-jsonb-in-rails Same error as jsonb - no implicit conversion. |
Can you provide example queries & the results? I think that would help with answers to those specific questions. |
here is one:
attempting to find this result: http://ebwiki.org/admin/ahoy~event/00fc3a49-7245-4a61-a50e-e22554915228 |
Doing the following provides an answer of sorts. The first line gets all the events where the page property isn't null. The second counts all the events that visit the page
The problem is, searching this way is slow, cumbersome and not too productive. A better solution would be to find a better data store for this Ahoy data. The current solution doesn't pass muster. |
BTW, I figured this out from the response to your stackoverflow answer. It might be worth checking with the Ahoy creator about best practices for storing & retrieving Ahoy data. |
One final thing; we installed Ahoy with the idea that it would be relatively simple to get that data and review it. If that's not going to be the case, that changes the whole value proposition of Ahoy. In the future, I really do think we need to take a closer look at a feature in advance so that we can accurately judge how much work it's going to be to implement it in a way that works well. |
Unless there's something else, I'm closing this thread. |
not sure why we closed this issue. In any case, I think the solution may be related to this SO thread: http://stackoverflow.com/questions/9814622/searching-serialized-data-using-active-record |
Just reviewing the README for the Ayo gem, and we may have a solution to querying the properties hash:
adding that line to the model allows us to use the where_properties method(i think this has been added since I last reviewed these docs over a year ago) to query the properties hash. this works on my local. I am making that change in a branch and pushing a PR. |
Adding `include Ahoy::Properties` to Ahoy::Event model. This allows a query such as `Ahoy::Event.where(name: "$click").where_properties(class: "info2".count` to find the number of clicks on links with class "info2" Clearly, using more descriptive class names will help us in presentng and analyzng this data.
Ahoy stores Events with 2 basic attributes:
name:
(e.g. click, view, etc) andproperties
.properties
is a hash which has varying keys depending on what type of event. For example, a click event may have keys like class, and page, while view has "url" and "page_title"For the purpose of creating some site analytics, we need to parse the ahoy events data, but in the default configuration, it is difficult to take the population of events and discern e.g. how many times a particular page was viewed.
So in the site_analytics branch, we have begun to record a custom "Viewed Article" event with custom attributes. Ahoy then stores an event with name: "Viewed Article" and a properties hash with our custom keys.
However, I have still had difficulty querying the data from properties hash. By default ahoy stores properties as a text data object. I reached out to @ankane who is the owner of the gem who is offering guidance in a thread that is still ongoing here: ankane/ahoy#120
The text was updated successfully, but these errors were encountered: