Given a symbol, return its popularity ranking among all other symbols. If all symbols are ordered by their popularity from least popular to most popular, this is the index in that list.

If two symbols have the same popularity, sort secondarily alphabetically by symbol.

When trying to view individual stock activity or popularity changes on the weekend, the robintrack service doesn’t work. It should be changed to let you be able to view the last available saved data(from Friday) rather than not work at all. Maybe it could also put up a alert/notification that “this data is not reflective of any activity today” or something. Because sometimes it’s useful to be able to use robintrack over the weekend

When min_popularity is 0, a divide by zero error occurs on the backend. This is happening inside MongoDB in the aggregation pipeline.

Rails doesn't seem to be accepting queries with symbols that have a period in their name like BRK.A or HVT.A.

Params:

• Duration
  • Largest popularity increase in this period of time
• Limit
• Relative
  • If true, the change is calculated as a percentage of total popularity. If false, the absolute change amount is used instead.
• Min Time Amount
  • Only used if relative is true. Only assets that have a popularity of this amount will be considered in relative popularity calculations. (If you have a stock with 5 popularity and it goes down to 4, that looks like a 20% popularity change. This filters those out.)

Maybe an endpoint like /popularity_changes/increase/[symbol]/[duration]/[limit], or duration and limit could be optional query params with defaults.

A parameter should be added to the popularity history and quote history endpoints that, when provided, only sends one data point per day for data from over one year ago. The parameter can be called partialOldData or something like that.

Assuming the current date is June 12 2020 and the flag parameter is set, then the returned timeseries should be filtered to remove all but one update from each day before June 12 2019. The first data point from each day can be picked, discarding the rest.

The keys used in caching should be updated to reflect this new parameter.

Everything should be infinite scroll, lazy-loaded, smooth.

It would be nice if the popularity_history (and I suppose popularity_history_csv) API endpoint(s) supported the ability to return only data points in a given time frame (ex., "get me popularity data for TSLA between 2020-03-01 and 2020-03-06"). Currently, as far as I can tell from the source code, this endpoint only supports fetching the entire popularity history for a ticker (which for many tickers is years worth of several-times-a-day data). That makes it impossible to politely use your API to, say, keep daily tabs on a few tickers: if you want data for today (every day), you have to also fetch a couple of years worth of data (every day). Ouch.

The way I'd envision this is to add optional start_time and end_time query parameters to the endpoint(s), which (logically, at least) default to, say, the UNIX epoch (or first time when data was available for the ticker) and now, respectively, to maintain backwards compatibility with the current implementation (i.e., fetch all history). These parameters would both take some sort of encoding of a timestamp, say ISO-8601 or whatever is easy enough to get a parser for in Ruby. It should be easy enough (I think?) to plumb these further down into the get_history_for_symbol method and the MongoDB query that actually gets the data to service the endpoint call. This query gets modified to select based on the timestamp field being between start_time and end_time (inclusive).

I don't know what your bandwidth for working on Robintrack is these days, but if you think you wouldn't be able to get this feature out any time soon yourself, I'd be willing to (try to) cook up a pull request if you'd be willing to review it. (Assuming you want this feature yourself, that is, though I suspect it might help in your eventual implementation for #43.)

/instruments/price_distribution/[instrument_id]

Should be plotted on the charts; maybe only for the one that is displayed on the details page. Will be good to have.

Should simply return the number of unique symbols in the database. It should take an optional param that provides a number of hours ago in which there must have been a popularity update for it to be included in the count.

So, if the param is 5 and the symbol hasn't had a popularity update in the past 5 hours, it won't be included in the total.

Should probably rename to _PRN.csv or something and put info about that on the download page to help people out who use the data on Windows

Would it be at all possible to make the scraped price data downloadable? Despite my best efforts, I can't find free price data to join with the popularities - every API I tried so far only has some variant of daily historical data, or realtime quotes. It would be a great help to have hourly data going back a year or more (the best RH API can do is interval=hour&span=month)

Params:

• Duration
  • Largest popularity change (either up or down) in this period of time
• Limit
• Relative
  • If true, the change is calculated as a percentage of total popularity. If false, the absolute change amount is used instead.
• Min Time Amount
  • Only used if relative is true. Only assets that have a popularity of this amount will be considered in relative popularity calculations. (If you have a stock with 5 popularity and it goes down to 4, that looks like a 20% popularity change. This filters those out.)

Maybe an endpoint like /popularity_changes/change/[symbol]/[duration]/[limit], or duration and limit could be optional query params with defaults.

Probably due to the large number of holders and some interaction with Python for that

When events like splits happen, the internal Robinhood ID for assets changes while the ticker and underlying asset stays the same. In order to provide continuity in charts on the site, some kind of script or similar solution should be implemented to merge the data from the old and new ID into one.

Params:

• Duration
  • Largest popularity decrease in this period of time
• Limit
• Relative
  • If true, the change is calculated as a percentage of total popularity. If false, the absolute change amount is used instead.
• Min Time Amount
  • Only used if relative is true. Only assets that have a popularity of this amount will be considered in relative popularity calculations. (If you have a stock with 5 popularity and it goes down to 4, that looks like a 20% popularity change. This filters those out.)

Maybe an endpoint like /popularity_changes/decrease/[symbol]/[duration]/[limit], or duration and limit could be optional query params with defaults.

This endpoint should return an array of bins indicating how many symbols have popularities within a given range. It should include one parameter, which is bin count. This should be a positive integer greater than 1.

You'll want to select the most recent popularity measures for all symbols in the index and figure out the range (it's going to be 0 to the popularity of the most popular symbol). You'll then want to divide that range into bin_count bins and for each bin sum up how many symbols have a popularity within its range.

In order to make it easier to render on the frontend, please include a min_popularity and max_popularity field along with the bin array itself.

Need to prevent overzealous bots from overloading things

To make it easier to see the magnitude of changes. Should there also be an option for zeroing the axes?

Hey! So my friend is into stocks and wanted a way to pull some of this data into his spreadsheets so I wrote a small script that pulled data from y'alls site and outputed a nice csv:

https://github.com/robertDurst/popularityFromRobinTracker

Just wanted to say thanks for doing this and this is a nice feature to have if y'all have time.

Rock on ✊

Rather than routing users to a different page to view graphs, the graph should be displayed inline on the leaderboard page. We can maintain a details page to view more advanced stats or more detailed info, and just have the chart display on the leaderboard page.

I want to implement a way to page through symbols in order of their popularity, so the page will have a "next most popular" and "next last popular" arrow that take you to the next symbols. So, I need a way to get that data from the API.

Technically, an endpoint that takes a symbol and returns the next and last most popular would be fine, but I figure that adding a more generic one that just returns the next and least most popular from an index would be more useful for other things.

I'd like to see filters introduced because a large change in popularity of a large cap isn't necessarily sending the same signal as a change in a small cap.

Link to Finbox, Unhedged and/or Yahoo Finance.

Example:

Rather than make a new API request every time the user enters a new value or clicks one of the buttons, let's wait 0.75 seconds or something to see if they change it again first.

This will work with Quantopian live feed as well as give people with more limited data analysis tools a better option than the huge full DB export.

Simple comparison chart that plots many different stocks side-by-side to show how their popularities have changed over time. Will probably require customized axes for the chart; we still want them to be displayed relative (maybe give users a chance to toggle them to absolute? Yeah, that would be good.)

Sorry for creating issue instead of using the feedback link. Feedback link did not work.

Seems that API is down and returning 503, hope this gets resolved soon.

The histogram should support going back in time and viewing the popularities at some point in the past, and the bars should be animated when they change because that would be cool.

I want to allow users to page through the popularity table for most and least popular symbols. So, I need an optional startIndex param that can be used to offset the search for either most or least popular.

In addition, I'd like the symbols to be secondarily sorted alphabetically by their symbols in the case that two or more symbols have the same popularity.

That way, that chart will stay open when the user switches between different screens.

I need to know what my users are doing. As a longer-term goal, I want to integrate the API clickstream into my fireworks visualizer or something similar so I can see EVERYTHING the users are doing.

When markets close, spreads become massive and the actual bid/ask price become more than useless, making the charts cluttered and unreadable. We should use the last traded price instead. It may be necessary to use the last traded after hours price, if that's available.