Thought Flow

Tag: Antecons

  • Creating a Shopify plugin

    This post is about Antecons, a product recommendation engine, now part of Conversio. Antecons is no longer commercially available, but I have kept my developer diary on my website with permission.


    In the last post about Antecons, I wrote about frequent patterns and MapReduce. Since then, this base functionality has been tweaked to work a little better but the main focus has been on creating the first plugin for Antecons: A Shopify app.

    I have previously mentioned that it is important to me that Antecons can be easy to set up. Although focusing on the API initially was a great way to get started, it has become clear after some thought that the reach is limited if the entire product is just an API from the beginning. So I have begun implementing a plugin (or an app as they call it) for Shopify. There are two reasons for choosing Shopify as the first integrated platform for Antecons:

    1. It is easy to get started with app development on Shopify and their API is quite extensive.
    2. Shopify was simply something I knew before-hand so I did not need to research other options too much.

    So far, it has been a good experience working with the Shopify API. Integrating with Python/Google App Engine was very easy thanks to their open source API bindings for python.

    The Shopify app for Antecons is not finished yet or at least, I do not consider it in a state where I can release it. However, it is in state where it installs correctly and delivers recommendations to the webshop it is installed on. Instead of writing a lot about that, below are some screenshots that show the functionality. The suggestions by Antecons are the little “You might also like” products.

    Antecons installation start
    Antecons installation start
    Antecons app authentication
    Antecons app authentication
    Antecons installed
    Antecons installed
    Product page suggestion
    Product page suggestion
    Cart page suggestion
    Cart page suggestion
  • Antecons developer diary part 3

    This post is about Antecons, a product recommendation engine, now part of Conversio. Antecons is no longer commercially available, but I have kept my developer diary on my website with permission.


    On Friday, October 5, 2012, Antecons was started over from scratch and another journey begun. How long this journey will be and what will happen is uncertain. But here are some initial notes on the progress.

    Where to begin

    Starting out is often a bit slow, mostly because lots of questions pile up. Like what programming language to use and what platform to deploy on. What about project management, bug tracking and early documentation? It is easy to get caught up in those things and it happened to me as well on the first day. I was inspired when I read that Jeff Atwood does not make TODO lists. However, writing down a few ideas and making some mental notes works well for me to get a feel for what I want to do with Antecons. But TODO lists might not be useful and micromanaging a project for a one-person team in the exploratory/early phase is definitely not worth it.

    So I ditched the project management for now, I have no bug tracker and the documentation I wrote initially is already outdated. When will I ever learn. Instead of wasting more time, I made decisions. Use Python, deploy on Google App Engine and start making a simple web-based API using JSON for data representations and then take it from there.

    To REST or not to REST

    REST (Representational State Transfer) is an interesting choice of architecture for web-based APIs. REST is kind of a buzzword and most REST APIs are not actually RESTful according to Roy Fielding who coined the term. So of course, I decided that my API would be truly RESTful. Alas, the choice of JSON for data representation makes it difficult to make a hypertext-driven API since there are no widespread standards for how links should be represented in JSON, unlike e.g. the very precise definitions in the Atom Syndication Format (an example is this blog’s Atom feed ).

    There is a specification draft called JSON schema that is very promising so I decided to try and use it for the API. A very crude first alpha version of the API was actually fully hypertext-driven based on the principles outlined in JSON schema and all data representations were described by a JSON schema. Using JSON schema has two advantages:

    1. It provides a way to validate data both on the client and server side.
    2. It is cool to be RESTful.

    Ok, so while number one is useful, number two is kind of silly. And actually I think it is ok to not be truly RESTful but still use some of the REST principles to build an API. My favorite example right now is the Google Calendar API which uses resources for data representation and HTTP verbs to interact with these resources but is not hypertext-driven. According to the Richardson Maturity model, it is probably level 2 REST — if there is such a thing. With Antecons, this is the level of REST I am aiming for.

    So what about JSON schema? Well currently, I am making a JSON schema for all data representations in Antecons but I have not decided whether or not I should continue this trend. If using JSON schema means that some code can be autogenerated by the client then that is fantastic. But I do not know of any ready-made tools to do that, such as is the case for e.g. WSDL in Visual Studio.

    Progress

    After this Friday, I should have another crude alpha version ready for publishing. After it is out there, I will write about it here. The API cannot do much right now. You can just upload some simple data and view it. Basic basic stuff. But I also hope to have the first data analysis algorithms ready within the near future. Then it starts getting exciting.

  • Antecons developer diary part 2

    This post is about Antecons, a product recommendation engine, now part of Conversio. Antecons is no longer commercially available, but I have kept my developer diary on my website with permission.


    In part 1 of the Antecons developer diary, I wrote about what stalled the development of Antecons a year ago. It was a combination of a lack of time and a lack of vision. In this post, I will elaborate on the problems I ran into and how I intend to tackle them (or not) this time.

    The ideal scenario

    To reiterate from my last post, the ideal scenario for getting Antecons to work with a webshop looks like this:

    1. User registers for Antecons and receives a unique User ID.
    2. User inserts 10 lines of Javascript code in the header of each webshop page where Antecons should show recommendations.
    3. Antecons takes care of the rest and starts showing recommendations on the user’s webhsop.

    There are two major problems with this approach: How do we get the data foundation and how do we automatically show the recommendations.

    The data foundation

    The recommendations of Antecons are supposed to be based partly on previous purchases in a webshop. But how can Antecons gather sales data for the data foundation. I can think of a few solutions:

    • Send sales data to Antecons in batches.
    • Send sales data to Antecons the moment a purchase is made.
    • Have Antecons fetch sales data from a tracker that is already set up, such as Google Analytics.

    All of the above require some action from the user and thus deviate from the ideal scenario. The first two require implementation on the webshop before using Antecons. The third also requires implementation on the webshop but in an earlier step, i.e. when setting up Google Analytics.

    Besides sales data, the data foundation would probably also consist of data about each product, such as product name, description, image and product page url in order for Antecons to automatically show recommendations. Some of the options from above also apply here. We could:

    • Send product data to Antecons in batches.
    • Send product data to Antecons the moment a product is created/changed.
    • Create a web crawler that extracts product data from the webshop.

    The first two options are basically the same as listed earlier. The third option, however, has some potential, especially if the product pages are nicely marked up with appropriate tags, classes or similar that could tell a crawler something about the data. For example, a crawler could be set up to look for the following elements:

    <img class="product-image" src="images/a-fine-image.jpg" />
    <span class="product-name">Nice product</span>
    <div class="product-description">It has good features.</div>
    <span class="product-price-single">42</span>
    

    If the crawler regularly searched through the webshop, the user would not have to update their product catalogue themselves.

    The presentation

    Let us assume that we have the data foundation. Now, we need to show recommendations on the user’s webshop. But how can Antecons know where to show recommendations on e.g. a product page if the recommendations are shown completely automatic from a piece of Javascript code. It seems it would require at least some user action. To make it simple for the user, maybe the user can just create sections of a page where Antecons is allowed to show recommendations. These sections could be marked like this:

    <div class="antecons-recommendations"></div>
    

    Antecons could then insert recommendations in these sections. There is a problem though. What about products that change pictures, prices, urls and so on? How can these changes be reflected automatically by Antecons with immediate effect: Well, they cannot, unless the Antecons data is updated at the same time as the user data is updated. Perhaps a web crawler could help in this regard, as mentioned in the previous section but it might not be the best way to do it.

    The “solution”

    In software development, there is rarely a perfect solution to a problem. So I have decided to step back and say: The user probably has to do some initial work to get Antecons up and running and that is ok. Instead of focusing so much on the initial setup, I will try to make an API that is easy to use, fast and provides good data analysis possibilities. First, it makes sense to construct a minimal viable API for Antecons. This API would provide the following:

    • A way to send transactional data to Antecons (e.g. sales data).
    • A way to fetch recommendations for a single item.

    And that is basically it and what I am currently working on. After that, we can iterate. I have not shelved the idea of having a crawler and I have not shelved the idea of having some simple Javascript code to do a lot of the work for the user. But it might be that a better option is to write some plugins for popular e-commerce systems such as Magento, Shopify and others. As I just said: We can iterate. This is just the beginning.

  • Antecons developer diary part 1

    This post is about Antecons, a product recommendation engine, now part of Conversio. Antecons is no longer commercially available, but I have kept my developer diary on my website with permission.


    It has been a year since the first announcement of Antecons. What has happened since then? Absolutely nothing. The reason for this seems to be pretty straightforward: I have been occupied with full-time consulting and I have made a deliberate choice of working a five-day 40-hour work week. That leaves no room for extra work. However, this has changed slightly. Since October 1, I have had a four-day work week. This leaves one day to do other stuff and I have decided to continue my work on Antecons and I intend to blog about the (slow) progress.

    Consider this part 1 in a series of posts about my experiences, design decisions and the current state of Antecons. First, I would like to fill in the gap in the history of Antecons from last year until now. There is more to the story than just a lack of time.

    Where we left off

    One year ago, I made a promise, a prototype and a teaser. The prototype is a recommendation engine that is still running on one webshop (as far as I know). It is written in C# for .NET, uses Microsoft SQL server as database and is deployed directly on the end-user’s server using a pre-compiled DLL that can be referenced from any .NET application. As I was developing the prototype, I already had a couple of basic objections to my own design:

    1. It required the user to use .NET and SQL Server.
    2. It required me to use Visual Studio, IIS and Windows as a development environment.
    3. It required the user to integrate the component into their webshop. This included:
      1. Setting up an SQL database and tables conforming with the Antecons data format.
      2. Synchronizing webshop purchases with the Antecons database and keeping it updated.
      3. Manually running the recommendation algorithm to pre-create recommendations.
      4. Integrating Antecons into the webshop design in the appropriate places to show the pre-created recommendations for the current product being shown.

    The first two points were easily fixed by deciding to replace the pre-compiled DLL component with a webservice. Using an API for Antecons, there would be no constraints on the user regarding their server software or webshop programming environment.

    And thus was born the teaser, a web application written in Python and running on Google App Engine. It never turned into a webservice with an API. Instead it was a website that showed what the essence of Antecons was: A recommendation engine based on association rule mining (or market basket analysis). As it turned out, this was the easy part and implementing a simple API would have been too. But the third point I outlined above, that was the real killer.

    The promise

    A quote from my company website:

    Metacircle has been developing a data analysis tool for some time. It is called Antecons.

    And from the Antecons teaser website:

    The API is currently under development…

    These quotes sum up the promise I made myself (and the world): To work on Antecons. Did I succeed? No. Do I feel bad about that? Yes. What killed the project? Time and wishful thinking.

    Time grew short when I started working full-time but this is only part of the explanation. As hinted above, I was also held back by the third design objection. Setting up Antecons for actual usage was, in my opinion, too difficult and too much an obstacle for widespread usage. How could Antecons be made so it would be super easy to setup, super easy to deploy and super easy to run. The ideal scenario looked like this:

    1. User registers for Antecons and receives a unique User ID.
    2. User inserts 10 lines of Javascript code in the header of each webshop page where Antecons should show recommendations.
    3. Antecons takes care of the rest.

    This is how e.g. Google Analytics works and it is quite amazing how much information it gathers and how useful this information is, based on such a simple installation. If Antecons could be as easy to install as Google Analytics, which is installed on millions of websites, there would be a huge potential and many users could benefit from it.

    But the difficult questions piled up fast. For example, how would Antecons gather information on user’s sales data and how would it know where to show recommendations on a user’s webshop. The answers I came up with all lead to the same conclusion: The user would have to do some work and Antecons could not be fully automated, not even partially. This shattered my overall vision for Antecons and my head has been throwing around ideas ever since. Maybe the ideal scenario was wishful thinking but in any case, this was the end of the line. Until now.

    Where we are

    It has been two weeks since I started over with the Antecons project. In the next blog post, I will elaborate on what specific design obstacles that put the project on ice. This is an important pretext for what I have started working on right now. Later, I will write more about specific design decisions and actual implementation. The API should even have some partial functionality coming up very soon. Stay tuned.

  • Antecons

    Release fast and iterate“. In some parts of the computing world this is the mantra and I think it’s time for an early announcement: Metacircle has now released an actual product (kind of). It is called Antecons, short for antecedent – consequent. Antecons is a small and simple component that suggests items based on previous usage data (such as purchases) and it is currently being tested on vildmedvin.dk.

    Why did I create Antecons? Well, there are several reasons, actually.

    • I love data mining and business intelligence
    • Good recommendation engines improve conversion rates and thus profit for e-businesses.
    • Recommendation engines are not available to everyone at a low price. Most current solutions like avail.net target big companies and corporations. Antecons targets everyone.
    • People have already shown interest in Antecons. This includes my faithful partners at MCB as well as the founder of Remove The Background

    Let’s keep it real. The business intelligence market is very competitive and many companies are years of research ahead of me. I do not plan to steal their customers. I plan on making advanced technology available to the masses.

    In its current form, Antecons is simply a .NET DLL component with a public API for interacting with Antecons. It needs access to an SQL server and will thus only work with ASP.NET applications. I am currently exploring the possibilities of making Antecons a software-as-a-service (SaaS) product and a proof-of-concept prototype is being built for the Google App Engine, although it has not been finally decided where to host the first SaaS version. You can check it out here.

    If Antecons gains traction, I will give up consulting and work solely on making it an excellent and easy-to-use product. For now, it has been a major personal success to see something get out there. I hope the interest continues.