Entries with tag announcement .

As the beta phase of the new product search aproaches the end, we continue rolling out the features. Today, we are happy to present you two latest additions to the API interface - the EAN and the merchant category filters.

EAN filter

You can now search for products using the unique international article number - the EAN. It's a great filter for all those barcode scanner applications, which don't have any other keywords to use. EAN can be passed as a query parameter and will limit the results to matching products only. Even though EAN uniquely identifies a product, it is possible that you will get multiple results if several merchants have the same item for sale. Here's an example request to find the Galaxy Note 10.1 (ean 8806085308091):

Please note that not all merchants provide EANs for their product data feeds, therefore not all products in our database can be found using their article number.

Merchant category filter

Most shops use their own category tree to organize products. They are different from merchant to merchant, but make good and reliable search criteria if you want to get the best possible search result for a specific merchant. We are therefore adding the functionality to filter products by the merchant category or several categories. Like EAN, merchant category can be passed via REST URL query parameter. You can also pass multiple categories, from the same or different merchants by repeating the query parameter. For example, if you wanted to search for Samsung tablets and notebook PCs, you could formulate a query like this:

Currently we have identified a few programs that provide low quality category data or do not provide it at all. Therefore this resource will not return categories where it detects that data is not correct. We will be working with advertisers to improve EAN and category data quality over time.

Background

First, a bit of background on how current categorisation works. Products are assigned to a zanox category automatically, using a machine-learning algorithm, which makes this decision based on keywords in the product name, description and other fields. This approach allows us to categorise products independently of how much information is provided and does not force merchants to adopt (or map to) the zanox category tree. But as with all machine-learning algorithms - it is not perfect, especially when it comes to recognising same items in different languages or spotting a difference between a real item and its accessory (e.g. iPad and iPad case).

Changes and solutions

To address these shortcomings, we have already introduced result filtering by merchant categories and today we are announcing discontinuation of the current zanox product categorisation. Existing clients will continue working without changes until the 1st of January 2014. After that, queries using the old category IDs will return an empty resultset without errors.

We advise you to rely on search keywords and merchant categories if you need better filtering.

We are happy to present you the latest addition to our API resource family - the sale basket. As you might know a single sale can contain multiple products, which can belong to different categories and have different commissions. While the Publisher API has always had a resource to get sales or an individual sale, the response included an undefined commission and a "basket" as tracking category in case of multiple products in a single sale.

To cover this gap, we now introduce a new basket resource, which, among other properties, returns products in the sale basket, their respective tracking categories and commissions. A basket item looks like this:

To get the basket, you will have to provide the sale ID as a REST URL path parameter. Sale IDs are returned by the aforementioned sales resource. The basket resource is protected, so you will need to generate the zanox OAuth signature as described in the authentication documentation. This functionality is implemented in REST API only, with the usual XML or JSON response formats to choose from.

There is an announcement on the main zanox blog, about maintenance work that we will be carrying out over the last two weekends of October. I wanted to make it a bit more transparent on the developer blog about what effect this will have on our APIs.

Publisher and Connect APIs

Due to maintenance, we are going to set these APIs into read only mode for a couple of hours on the first weekend and if necessary, on the second weekend as well. For all you Publisher REST API users, this means that POST, PUT and DELETE requests will be returning HTTP 503 - Service unavailable. Publisher SOAP API will also deny all create, update and delete operations returning an HTTP 503 too. The Connect SOAP API will deny promoting and closing sessions, creating new connects and getting UI URL.

All Publisher REST API GET methods and SOAP API get* operations will continue to work as expected. The essential for apps "getSession" and "getOfflineSession" in the Connect SOAP API will not be affected either.

Data API

Data API is not affected.

ERP API

Unfortunately, access to the ERP API will have to be blocked during maintenance - you will not be able to log into the service.

Please note, that no data will be lost during the maintenance, and you will be able to catch up with your retrieve, update and create requests after the maintenance window.

The shut-off of the zanox Shop@ network in November of last year made searching products and AdMedia in the API much more complex. Without the pool of freely available ads and products, each search query now requires a list of program IDs where the publisher is confirmed. No results are returned if this list is not provided. This is often cumbersome, as getting your confirmed program IDs requires making another API call, or a number of them if you are accepted to more programs than the maximum result page size.

Based on this feedback we decided to improve a thing or two to make lives of our developers easier. As it happens, a small feature request evolved into a full-scale rebuild of zanox search infrastructure and today I am happy announce that we are nearly there!

Without going too much into detail, I can still provide some insight for the tech-savvy. Parallel to not-the-latest-version Lucene, which drives our current product search, we have built up a fully-automated Solr 4 environment.

So what can you expect? Well, several things, actually.

Near real-time product availability in search

The first thing we improved on is delay between importing products from the Advertiser to their availability in search results. While current system refreshes its index once a day - at midnight, the new search will continuously index new products as they come in. So the delay will be reduced from the maximum of 24h to around the maximum of 45m. That's how long it takes us to index our biggest product feed. Averages should be much lower though - 10-20m.

Search in all confirmed programs without providing program IDs

The default behaviour of search was changed to automatically search all confirmed programs if no program IDs are provided in the search query. This way, developers will save the before-mentioned API call(s) to retrieve all program IDs.

Search products of all zanox programs without applying

Have you ever wondered which programs have products relevant to you? Now you can search within all programs with the URL query parameter partnership=all. Note, that no tracking links will be returned for programs, that have not confirmed you.

Fixing known bugs

Many of you are familiar with API returning less than 50 items in one page, even though total results is much bigger than 50. This behaviour is also described in the known bugs section of the product search documentation.

<page>0</page>
<items>4</items>
<total>21528</total>

This issue has been addressed in the new search version.

One important feature that is NOT in the current Beta is product categories. We are still working on improved machine learning algorithms that categorize the products, and we will add it in the near future.

We see the above features as must-haves for the rollout. But the new technology will enable us to add more bells and whistles in the future development iterations. What we have in the "pipe" is improved product categorization, better performance and in the long-term - also moving admedia search and program search onto the new backend.

Looks good, so when is it going into production? Well, actually it is live already, first accessible via our REST API. The main stream of requests is still chanelled to the old search, but if you append the query parameter solr=true to the resource URL, your results will come from the Solr cluster. The developer team is still measuring and tuning the performance, writing automated tests and fixing any "teething issues", but it is there for everyone who wants to test it out.

When we are sure that the new search meets our quality expectation, we will start switching more and more requests to the new backend. The good news for you, the developers? You don't have to add a single line of code, the API interface remains the same. If you want to switch over to the new search before we do it for you - you can use the solr=true parameter. Additionally, you don't have to provide any program IDs, unless you want to limit results to those particular programs. Here's an example:

Having said that, we would be very happy to hear from the early adopters, trying out our search. What are your impressions? What works, what doesn't and what can we improve? Head to the documentation section to read about the new parameters and their usage.