This is a guest post by Ryan Szrama, a Drupal eCommerce developer for Commerce Guys and user of the Relify API. Below, he shares his thoughts on using Relify for eCommerce, and how he built an integration in just one hackathon weekend.
I’m a long-time eCommerce software developer building solutions on Drupal, a leading open source CMS. Drupal has significant representation in government, publishing, and media / entertainment websites, and my company Commerce Guys is currently focused on turning it into a go-to solution for businesses looking to open new online stores or upgrade their existing sites.
It was easy enough for us to build out the core eCommerce framework using a module package we call Drupal Commerce. However, merchants need much more than a shopping cart and checkout form to be successful online. They need to integrate with numerous third party services providing essential payment, marketing / analytics, and conversion optimization solutions.
Relify is one such service that immediately captured my imagination. There are modules and integrations in the Drupal ecosystem for making recommendations, but none are as focused on delivering personalized recommendations at a large scale as Relify. Additionally, native recommendation solutions may require the use of database systems that the average Drupal developer does not have experience managing, making creating a personalized shopping experience out of reach for most of our users.
For these reasons, I was excited to attend this year’s Recs Hack Day to attempt an integration with the Relify API to bring simple product recommendations to Drupal Commerce. By the end of the day, I had released a full beta version of the Relify module to the Drupal community with a working demo site using our eCommerce specific distribution of Drupal, Commerce Kickstart, to embed product upset recommendations in our Add to Cart modal dialog. The work was solid enough to take home the “Best Use of the Relify API” prize, allowing me in turn to take home a shiny new Sparkfun Inventors Kit!
For the Drupal integration, I decided the best user experience would be for the developers to be able to create and manage their Relify data sets and recommenders from within Drupal itself. This gave me the greatest amount of information about the schema and purpose of data sets client side, allowing me to build additional validation into my forms and create an easy way to feed data into Relify by mapping Drupal entity properties to valid columns in a data set’s schema via the Rules module.
The configuration interface in the back-end of Drupal thus allows you to configure your API credentials, define data sets and recommenders, and define the business logic via Rules that determines when new records are added to your data sets.
The only use of recommendations right now is in what’s called an “area handler”, a plugin of sorts that can be added to pages and widgets created by Drupal’s Views module. It’s currently specifically geared toward product recommendations, but module can easily be used to add any type of data to your Relify data sets. The roadmap is wide open for working in new ways to use recommendations, with a natural next step being the usage of recommendations to filter lists of content or users on a site.
I had a great time participating in the sprint. Thankfully I’m pretty experienced with Drupal’s APIs, so I could pack a lot into my 24 hours. Ultimately, I’d love for Drupal Commerce users to see increased sales through the use of personalized product recommendations and will continue to develop the module in pursuit of that goal.
Grocery list and coupon apps are a popular way for busy consumers to have lists at their fingertips, on the go. With more and more people using their phones as a touch point in-store, why aren’t we taking advantage of helping them discover and save when they need it most?
This use case outlines how personalized recommendations can help increase order size by enticing your customers to “buy one more thing.”
We all get recommendations frequently from our friends with questions like ‘what’s good on the menu?’ or ‘what movie should I see’? But Relify recommendations aren’t based on what your users’ friends like, they’re based on what your users like. And what they do, and what they buy. We use existing data to create personalized recommendations that pertain to their lifestyle, in any category or industry.
Because of that, we’re starting a new blog series for #usecases to show you the power of recommendations and how they can be used in your app. We also just added use cases to our website and launched Pinterest boards to show visual examples. And if you have your own use case, we’d love to include it (just email firstname.lastname@example.org).
I’ll start with a subject that all of us can relate to: shopping in retail apps. *Use cases are explained from the most important viewpoint: the user.
Relify had the pleasure of hosting the first hackathon in our area this past weekend, and we were excited with the results. The day was a huge success and we had a great time. Thanks to everyone who came out.
Here’s the lowdown recapping the weekend:
Check out all 8 projects, winners and pics: goo.gl/xucDm
Host a hack: How to plan your own hackathon
Hacks are awesome ways to see how people interact with your technology, and can highlight bugs, opportunities and inconsistencies that you’re too close to see. Here are a few tips we learned for how to plan a hackathon:
Questions or thoughts? I’d love to help you plan your hack. Contact me.
What good is a recommendation that’s based on data if your algorithms don’t have access to ALL of the data that’s needed to generate the most relevant recommendations? More importantly, as a startup with limited time and resources, how can you open your platform to a potentially limitless firehose of inbound data and survive long enough to make a dime?
These are two serious questions we struggled to answer while scaling our recommendations as a service API. It’s easier and more cost efficient than ever to build a big data startup thanks to services like AWS, Heroku and Google’s Cloud Platform. That simplicity, however, still comes at a price. It only takes a day or two for us to burn through our allocated AWS free tier credits before our bank account starts shrinking.
It would be easy for us to charge for inbound API requests/data storage to solve our problem but doing so wouldn’t be fair to our customers because our value is in the recommendations we serve, not the resources required to generate them.
If you had been eavesdropping on our conversations while we worked to answer these questions you would have heard that:
We were so close! If it wasn’t for the damn workers we’d be set!
I had been tinkering with IronWorker and a few other Heroku worker add-ons for a week or two but wasn’t really feeling any of the offerings. The fundamentals of what we were looking for were there but all still seemed wildly inefficient. Tasks that should have taken less than twenty seconds to execute were taking minutes. Each add-on had its quirks and some of them were deal breakers. We’d come so far and had realized that there was a distinct possibility that we’d have to implement our own worker service.
Then fortune smiled. The folks at Iron.io sent me a “Tips & Tricks” email on the same day I was getting ready to start coding our worker service (no joke). In that email was a link to a blog post by one of Iron.io’s Co-Founders, Travis Reeder, entitled How to Reduce a 9 Hour Job to a 9 Minute Job. Were they reading my mind?
It turns out that we weren’t the only ones with such struggles as the first line of the post so poignantly states: “A common problem developers have is how to run through a large number of tasks in a short amount of time.” PREACH ON! I kept reading.
I immediately felt better (and a little silly) after reading the post. Why hadn’t I attempted to dig deeper into Iron.io’s blog before I threw in the towel? Or hit them up on HipChat (which I subsequently did, and they were awesome). The answer was there the whole time!
The post got me thinking about breaking work into smaller pieces to take advantage of concurrent task execution. I imagined that we could spawn additional tasks based on the total number of items in a queue and let recursion take its course until the workers burned through all of the records in each queue. The end result was a collection of workers that run on a schedule and are entirely self-contained within IronWorker. Their workflow goes a little something like:
This took us from having the ability to process 1,000-2,000 records/minute to 120,000/minute (2,000/second) based on our current pricing plan. Bumping ourselves up to the next plan would put us somewhere around 300,000/minute which clocks in at 5,000/second. And we didn’t bump write throughput up a single tick. Increase the write throughput and things get crazy fast!
And the best part? Everything I’ve mentioned above took less than a day to implement and costs less than $500/month (AWS costs included). FO REALZ.
Limitless scalability is real and the team at Iron.io is making it happen. IronWorker is rock solid and our stack wouldn’t be the same without it.