Wize Commerce regularly hosts expert talks on topics of interest to our internal global staff, and external partners.
The edited notes and video for this talk are below.
How we’ve built our Services Platform
Wize Commerce is a platform for acquisition and revenue optimization of e-commerce traffic. We have been profitable for the past 10 years and Nextag is now the #2 paid comparison-shopping site on the Internet.
We’re evolving from a shopping-comparison engine, to offering our Wize Commerce platform to businesses outside of our company. To accomplish this, we have to make it easy for customers to leverage our platform. We think the best way to do this is to make this platform a set of services.
The work at Wize Commerce is progressing along two tracks. First, we are building a framework to support services with features like request prioritization, controlled rate of service requests, and automated generation of documentation to make it easier for people to consume these services. The second track requires developing and deploying the actual services themselves.
Having an SOA (Service Oriented Architecture) helps our partners achieve their goals by having all the heavyweight business logic, such as billing calculation, user personalization, search results customization , etc., go to the back-end of the website. So the front end of the website just has to worry about presentation.
Some of the services we’ve developed for our shopping comparison sites:
- Product search service, which allows us to access our vast catalog of millions of products.
- Our visit and click service, which allows us to track users across our site and allows us to bill merchants based on what features the user is seeing.
- Our Buzz Score service (a Buzz Score is basically a measure of the social buzz around a product), which will help a site create much more compelling social features.
Next on our roadmap is A/B testing services. Over the years, we’ve developed a very robust and highly optimized A/B testing framework in Java. We’re exposing this experimental framework as a service and creating a Ruby client for it.
When a client wants to sign up for services provided by Wize Commerce, the first thing they do is set up and provision their account. Secondly, they provide their catalog. We support several different formats for the catalog to make it easier for our customers. We call this our import service, which ingests a customer’s catalog and makes it available for search. Then, we agree on the specific products and categories we want to bid on.
When a user comes to one of our client sites, the first thing that will happen is our visit service will be called. This will create a visit, which will begin the process of tracking the user throughout the site. Next, the client site will call our experimentation service, which will determine which side of the A/B tests the user will be on – for the hundreds of tests we have going on at any given time. The user will then browse around the site for a bit, and when the user makes a significant click, they’ll call out to our click service which will record the click information into our data store.
In front of these three services, we have a shared externalization layer, which handles authentication, throttling, and json translation. What this allows us to do is control access to our services, as well as translate our thrift responses (Apache Thrift is the language in which our services speak) into whatever format the client wants.
In its end state, the Wize Commerce platform exposes millions of events that occur inside the platform in near real time to our clients, calling our traffic acquisition and revenue optimization services.
Subscribe to the Wize Commerce blog to get news on Wize Commerce expert talks and other events, as we launch them.