You can now tweet “@DropinIn I am bored” and get an event recommendation nearby
It only took us less than a month of part-time work. Clearly shows how damn efficient our Innovation Lab at Tenqyu works (really needed to boast this!).
But now it’s official! It’s done, live, out there, ready for action. Time to shine!
The reason for creating it was that although we already have a quite successful app in the event discovery space (500K+ events listed in 2016–25% of market share) we felt that the age of apps is over and thus platform integration is the next big thing. Go where your customers are.
No tweet left behind
We have launched with drop!in a Twitter social listening app that provides event recommendations based only on a tweet. And that is actually massively cool. Why is it cool? Because communication is the new platform! We expect that going forward with the advent of artificial intelligence for voice generation/recognition, dynamic content generation, and instant categorisation visual user interfaces and will gradually reduce. Of course what could be easier than sending a tweet compared to finding an app, downloading it, loading it, and learning how to use it, given Twitter is already open.
In the new world, aTwitter platform user tweets a pre-defined string to Drop!in like this :
@DropinIn event recommendations in New York
And it will return an event near you starting soon. It’s like magic.
How does this magic work?
The implementation was swift. For those of you who are hackers or technically inclined, our stack is setup like this:
1. Python StreamListener using Tweepy
2. Redis Queue
3. RQ worker to handle the incoming requests.
4. Geospatial recognition of the location
5. API call to our API clearinghouse
6. ML based recommendation of event
7. Automated content generation
8. Reply tweet to original Tweet author.
The Redis Queue was necessary to ensure that the stream-listener listening to the firehose from Twitter does not lose sync. In some cases we had seen several tweets per second coming in which then had to wait until our internal operations (writing to db, looking up web services, running the AI components) were completed causing the system flow to crash as the firehose listener lost state.
Other takeaways
Leverage pre-existing python libraries. This makes rolling-out services like this a breeze. Tweepy, geopy, sci-kit, nltk, and tensorflow are among the components used and can be highly recommended. If we experience large and unexpected growth we need to check if some components can or need to be replicated internally but at this stage I am not expecting it.
Follow the Twitter Automation rules. You should only send automated Tweets if they are unique replies to a specific request (push vs pull). We had the drop!in Twitter account banned for the week because we send a default reply if the customer had no location named. Now the system dies silently if we are not 100% sure where you want to have events for.
This Twitterbot, it is a showcase for us internally how we can create cutting edge applications without living in the Apple or Android ecosystem but rather the Twitter one. It is our first endeavour towards the world of communication . Since now most of the components are modules, we could consider plugging them into Alexa, Facebook, Line, weChat, or Snapchat going forward. Overall the implementation was swift and surely beats app roll-out issues (UI asset generation, app store approval, layout issues, form-factor support, etc)
What started as an experiment now needs users so we can see how users will react to it. But overall it is already a welcome addition to the product family and since we can control each segment of the process we hope it will provide a great way to gaining exposure for our work on event discovery.
Thank you for coming this far! I hope you liked this post.
