CatalogId and ProductId

[prosperent brian]

CatalogId is a unique identifier for a single product within our catalog. It will always return a single product, and it will be the same product every time (unless of course it no longer exists). It used to be the productId (more on that below).

The productId on the other hand is a hash based on just the product name. A query for a productId will return all identically named products. This is used for price comparisons. We made this change after experimenting on theNetPool. Sending a query for the product keyword doesn't work well because a search engine isn't actually capable of only returning exact matches. It ignores spaces caused by removed stop words and tokenized words, so two similar but not identical products will be returned with a product search.

To get around this, we now take the product name and create an md5 hash of it. Since there are no spaces and no tokenization ever takes place, we can compare two hashes and know that they are exactly the same. It's a cleaver way of performing exact matches in the search engine.

Now we can use the productId to return products for true price comparisons.

[AcidRaZor]

Ah sweet, so when we do a lookup on a productID and it returns more than 1 product, comparison time :p

I feel retarded when I read what you guys are up to :D

[prosperent brian]

You got it, multiple results = comparison. :)

[nite]

Has the API been updated to handle requests to CatalogId?

[AcidRaZor]

Has the API been updated to handle requests to CatalogId?

There's nothing in the current API that prevents you from using it, no. However, it does appear that there exist no "filterCategoryId" if you call it via the query string.

You should be able to do something like:


$prosperentApi->set_filterCategoryId('xyz');


Though I'm not 100% sure if there is something on the end of Prosperent that needs to happen yet and I haven't tested it now. So can't say if it'll work or not. Maybe you could test? :p

[prosperent brian]

CatealogId is basically just used for clicks, and that part is already in place on our end. You don't need to do anything to take advantage of that. We updated our click routing to handle everything with that.

[AcidRaZor]

I have a details page that use to rely on the hash from ProductId to generate the page content. Now that ProductId is used for product comparisons (in lieu of keywords), and now that CatalogId has taken the place of what ProductId was doing, I was wondering if I could use CatalogId in the same manner as I used ProductId.

hxxp://www.domain.com/shop/details.php?filterCatalogId=1cc7626037d31abaf7ebed 07892f1cb7

In essence, I'm using $_GET['filterCatalogId'] to grab the CatalogId and firing off an API request with just the CatalogId information in order to grab just the one unique product to be rendered on the details.php page.



$prosperentApi_Catalog_Query = new Prosperent_Api( array
(
'api_key' => $PROSPERENT_API_CQUERY,
'cacheBackend' => 'File',
'cacheOptions' => array( 'cache_dir' => $_SERVER['DOCUMENT_ROOT'] . '/shop/_includes/cache/' ),
'channel_id' => $PROSPERENT_CHANNEL_ID_CQUERY,
'debugMode' => $PROSPERENT_DEBUG_MODE_CQUERY,
'enableCoupons' => $PROSPERENT_ENABLE_COUPONS_CQUERY,
'enableFacets' => $PROSPERENT_ENABLE_FACETS_CQUERY,
'enableJsonCompression' => false,
'enableQuerySuggestion' => $PROSPERENT_ENABLE_QUERY_SUGGESTION_CQUERY,
'filterBrand' => $PROSPERENT_FILTER_BRAND_CQUERY,
'filterCatalogId' => $PROSPERENT_FILTER_CATALOGID_CQUERY,
'filterProductId' => $PROSPERENT_FILTER_PRODUCTID_CQUERY,
'filterKeyword' => $PROSPERENT_FILTER_KEYWORD_CQUERY,
'filterMerchant' => $PROSPERENT_FILTER_MERCHANT_CQUERY,
'limit' => $PROSPERENT_LIMIT_CQUERY,
'location' => $PROSPERENT_LOCATION_CQUERY,
'minPrice' => $PROSPERENT_MIN_PRICE_CQUERY,
'maxPrice' => $PROSPERENT_MAX_PRICE_CQUERY,
'minPriceSale' => $PROSPERENT_MIN_PRICE_SALE_CQUERY,
'maxPriceSale' => $PROSPERENT_MAX_PRICE_SALE_CQUERY,
'page' => $PROSPERENT_PAGE_CQUERY,
'query' => $PROSPERENT_QUERY_CQUERY,
'sid' => $PROSPERENT_SID_CQUERY,
'userAgent' => $PROSPERENT_USER_AGENT_CQUERY,
'visitor_ip' => $PROSPERENT_VISITOR_IP_CQUERY
) ) ;


Nothing has changed for you. The first product returned should be enough for your "match", and you could (if there are more than 1 product returned) add them as "Related Products" on your page if you do not have the capability of doing comparison (or have the layout for it)

[nite]

Thanks, Acid.

I've learned that the way they're doing the ['productId'] now saves me a query. I use to fire off a query based on Product ID to get the initial product, then fire off a second query using $result['data'][0]['keywords'] from the first API request to the keyword filter of the second API request. Now, they're doing that for me.

[prosperent brian]

We're trying to simplify things anywhere we can, and also make options to use standard queries through filters and such so people don't have to mess with extended queries.

[nite]

Yeah, it's real awesome!

I really liked using extended queries to search categories, once upon a time. The traditional issue with categories is that each merchant uses their own delimiters. But I've been using a little PHP to clean it up, and I've had pretty good success with it.



preg_split ('/\s?(\>|\[#\]|\/|\,|\;|\:|\::|\&|\-)\s?/',$Product_Result['cloud_categories']);

[AcidRaZor]

Would you guys ever depreciate extended queries?

[prosperent brian]

No

but we are trying to make the standard api do as much as possible, because the results will always be better.

[garydubbs]

Would you guys ever depreciate extended queries?

i hope not, about 20% of my traffic relies on extended queries.

[312k1t]

Now I'm making some requests (against products search endpoint) with parameter filterCatalogId, but no products there.

[prosperent brian]

There is no filter for that yet. You still use the productId filter for now. We use the cacalogId on clicks on our end :)

[700]

I need to return 1 single product to grab product infos (price,title,description,merchant ...etc)
Am I able to use this function => $prosperentApi->set_filterCategoryId('xyz'); ??

[prosperent brian]

You mean catalogId? If so, yes, a catalogId will always return one specific product.