The Buzz Count Algorithm & Popularity Metric

Algorithms and metrics are becoming an increasingly important way in which Web content is mediated to us. The development of algorithms is a lucrative endeavour and is also generating debating amongst the academic community[1]. Many well known Web applications, such as Google, Flickr, Facebook, Netflix and Amazon, use algorithms to identify relevant content. Flickr, for instance, has an “interestingness algorithm,” which assesses the level of interaction a photograph receives[2], and iTunes have a “Genius” song recommender service[2].

One of the most important metrics and algorithms on the Web is Google’s “PageRank.” In order to assess the significance of a page, Google assigns a webpage with a PageRank. Put simply, PageRank is based on the number and quality of incoming and outgoing links, which are recorded when its Web crawlers crawl the Web. As well as counting the number of links, Google takes into consideration the PageRank of incoming links. In other words, if a page X is linked to by a “popular page” Y, then page X will receive a higher PageRank[3].

On the EventHive platform, an event popularity metric and  recommender system, known as the “buzz count,” will be incorporated to improve the users’ experience. When a user hover overs an event on the dashboard, or taps on a touchscreen, a popularity metric, the “buzz count,” will be presented to them. At the same time, an event recommender system will operate on the service that recommends events on a personalised basis.

This blog post will explore the “buzz count” in further detail and Jack will explain what factors this algorithm will take into consideration and compare it to Flickr’s interestingness algorithm where appropriate. Insights into the interestingness algorithm have been extracted from Flickr’s patent application (link).

The Concept and Motivation

EventHive’s “buzz count” is a popularity metric that helps people assess the liveliness of nearby events. By “popularity,” EventHive are referring to how many people are at an event and how widely it is discussed online. The “buzz count” assigns a popularity metric between 1 and 10, with 10 being high popularity. The metric is calculated relative to the specified event size. For example, Glastonbury music festival is a larger event than a local nightclub event, and Glastonbury would expect more attendance and discussion. The event organiser specifies the size of the event based on a predefined scale when registering. The “buzz count” allows people to quickly assess the popularity of events, allowing potential attendees to make more impulsive decisions about the events they attend.

Secondly in parallel, EventHive’s recommender system  recommends events to users based on the factors such as location, event type, and friend activity. These systems allow EventHive to personalise their service and encourage more people to attend events.

As Amy Shuen points out with regards to Flickr’s interestingness algorithm, the “buzz count” will help generate collective user value (for more information on “collective user value,” see Jack’s post). In Flickr’s case, the algorithm helps the platform capitalise upon trendsetters and community catalysts, driving interaction amongst users[3]. Equally on the EventHive platform, the “buzz count” will identify popular and lively events and notify users of this, aiming to drive more interaction and attendance. The “buzz count” also drives competition amongst event organisers; event organisers will benefit if they have a higher “buzz count” because it reflects better upon their events.

Buzz Count’s Factors

There are several important elements that will be factored into the “buzz count” metric and popularity algorithm. In Flickr’s interestingness algorithm, it takes into consideration factors including the amount of user-entered metadata (tags, categories etc.), access patterns (e.g. click rates and views) related to the media object, and frequency of activity[4].

Below is a list of some of the “buzz count”’s key factors. The underlying assumption of each factor and some of its implications are highlighted.

Attendance

As well as users directly “registering” attendance, one distinctive feature of EventHive is its ability to verify attendance by GPS. This allows potential attendees to see how many registered EventHive users are at an event at any given time. For example. one will be able to see how many people are at a nightclub event nearby and see how “lively” it is. The “buzz count” will factor how many people are in attendance and will compare this against the venue size.

  • Assumption: If there are more people – relative to the venue’s capacity – at an event it is more “popular.”
  • Implication: there will be some ethical and consent issues around the disclosure of and use of GPS-location that EventHive will have to address. EventHive will have to ask permission for GPS location usage and explain how it will be used. In addition, EventHive will only be able to take into consideration the GPS location of registered EventHive users, not the whole mass of people at an event.
Social-Networking Site Activity

Integration with other social networking sites is an important part of the EventHive platform. By connecting to the API, keyword searches on Twitter and Instagram hashtags, as well as tweets themselves, will be performed. To avoid skewed results, keyword searches will be restricted to references to the event organiser and event name.

  • Assumption: The more social media activity (i.e. more keyword occurrences) the more “popular” the event.
  • Implication #1: Not all social networking site content will be positive. A scenario could occur where tweets about an event are negative and criticise the quality of an event. In this case our underlying assumption is contradicted; greater SNS activity does not necessarily equate to greater popularity. To avoid this, sentiment analysis could be introduced to filter out SNS content that is negative and this could be used to influence the popularity metric accordingly.
  • Implication #2: If event organisers are aware that social-networking site activity is a factor that influences their “buzz count,” this insight could be abused. Event organisers could skew results by actively increasing keyword and user mentions using dummy accounts. Some regulation or policing will be required to ensure that our analysis of social-networking site activity is representative.
Page Views, Registrations and Ratings

Flickr’s interestingness algorithm takes into consideration the amount of views and click throughs a photograph receives, as well as user-generated metadata assigned to a photograph. In a similar way, EventHive will take into consideration the amount of views an event hive (event page) receives. The “buzz count” will also take into consideration how many users have registered to attend this event on the event page (“registration” is a superficial means of expressing your intention to attend an event). Thirdly, the “buzz count” will factor in the rating a user gives an event organiser.

  • Assumption: The more page views, registrations, and higher ratings the more “popular” the event.
  • Implication: Similar to the previous implication, page click and views can be fabrication in the favour of an event organiser. Similar regulation or policing will be required to ensure that our analysis of social-networking site activity is representative. Secondly, registration does not guarantee attendance.

Personalisation

The ability to personalise algorithm results and metrics is an important part of different Web application’s recommender services. According to their patent application, Flickr makes attempts to personalise the interestingness algorithm in several ways, often relying upon location and user behaviour. It takes into account the geographical location associated with the media object and the user, matching it to predefined relationships between their two locations. Flickr observe behaviour history, looking for whether or not a user has favourited more than one photo associated with the same location.[5]

Running alongside the popularity metric, EventHive will incorporate an event recommendation system. With the buzz count, this system contributes to EventHive’s distinctiveness and value as a platform. The recommendation service allows EventHive to personalise the user experience. Events will be recommended based on nearness of location, type of event (e.g. rock concert), event history (if a user has attended rock concerts in the past, this could influence results), and friend activity. The inclusion of friend activity works on the assumption that people would prefer to go to events that their friends are going to. The recommendation system also adds value to event organisers. The recommendation system allows event organisers to reach targeted audiences; their events will be noticed by people who are more likely to attend them.

Summary

The “buzz count” is a complex algorithm and metric that helps EventHive personalise its user experience and contribute to the platform’s collective value. At its heart, the “buzz count” allows potential attendees to effortlessly and impulsively observe the popularity of events. There are several key factors that underlie the “buzz count” which have been discussed here. As Jack has identified, the implementation of the “buzz count” could be problematic and careful consideration will be needed to overcome some of the issues raised in this page.

Alongside this, Jack briefly explained the concept behind EventHive’s event recommendation system. In particular, the way in which this recommender service will personalise the EventHive experience, as well as generate value for both potential attendees and event organisers, has been explained. The combination of these two intelligent systems helps set EventHive apart from its competition, making it an effective and desirable event-based social networking service.

References

[1] Solon Barocas, Sophie Hood, and Malte Ziewitz, “Governing Algorithms: A Provocation Piece” (March 29, 2013). Available at SSRN: http://ssrn.com/abstract=2245322 or http://dx.doi.org/10.2139/ssrn.2245322

[2] https://www.flickr.com/explore/interesting/

[3] Sergey Brin, and Lawrence Page, “The Anatomy of a Large-Scale Hypertextual Web Search Engine,” In Proceedings of the seventh international conference on World Wide Web 7, 107-17 (Brisbane, Australia: Elsevier Science Publishers B. V., 1998).

[4] Amy Shuen, “Users Create Value,” in Web 2.0: A Strategy Guide (Sebastopol, CA: O’Reilly Media, Inc, 2008), 12-13.

[4] https://www.flickr.com/explore/interesting/

[5] http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220060242139%22.PGNR.&OS=DN/20060242139&RS=DN/20060242139

, , , , ,

No comments yet.

Leave a Reply

Powered by WordPress. Designed by Woo Themes