Fusepump problems

[Steerpike]

Tweet

Has anyone noticed the glaring problem with Fusepump feeds ? - If you are using XML, the feeds do not have a consistent structure.

For example, one merchant is providing

<imageURL>XXX</imageURL>

Another provides

<images>
<image>
<thumbnail>XXX</thumbnail>
<large_image>YYY</large_image>
</image>
</images>

This means that, whilst it's easy to rename a tag, the fact that one is nested and the other not is going to require custom configuration for every feed.

This is based on only 2 examples, there are probably going to be many more.

Should there not be top level tags for all important data and a consistent base format - after all, presumably this is meant to make our lives easier.

[durkster]

Hi Steerpike,

Thanks for the feedback. This is a very valid point - unfortunately, FusePump feeds aren't always designed with aggregation in mind. We work with the merchant and tend to take guidance from them over how we present the data. We tackle feeds on a merchant by merchant basis and try to distribute as many attributes as we possibly can for each, which doesn't mean our feeds are always easy to combine. It does, however, mean they're as comprehensive as possible.

In the example you've outlined below, the first merchant only has single images per product so we're only able to supply an <imageURL> field. The second merchant has multiple images per product and supplies thumbnails as well as full size images. We opt to include both in this case so that we're not excluding data which might be useful. There's clearly a trade off here between completeness of feed and ease of aggregation.

We'd definitely like to produce aggregated versions of feeds in the near future though (and aggregated versions of the feed tools for particular verticals) and thats where we'll consolidate the feed structure to provide top level tags for all important data and a consistent base format. Overall, there'll be less data in an aggregated feed than you might be able to access if you downloaded several merchant specific feeds, but it'll be easier to use for certain applications.

I think you're right that a good intermediate solution would be if it were possible to restructure fields in the feed (as well as simply rename them) and that's in development too

Robert Durkin
Co-founder
FusePump Ltd

[Steerpike]

Hi Durkster,

I appreciate what you're saying here, but I would think, primarily that it's going to be comparison sites that are using the feeds, which typically involves downloading a large quantity of separate feeds and parsing them.

With no set format, this is going to make it very time consuming to manage feeds if not impossible for some people. With all of the networks using a set structure, I need only write around 10 parser applications. Without this, with 250 merchants (assuming they were to use FusePump), I'm going to be writing 250 parsers :scared - this would have a major impact not only on writing the code, but the time taken to parse the feeds overnight - as it stands, my feeds finish parsing just in time, taking from 1.00am - approx 5.30am

How about having a set of mandatory top level fields which duplicate others if necessary - eg sku, name, description, price, link, image, model, brand, full category heirarchy
These are the essentials, and in most cases all that is needed. Then, there is always the option of using the other fields if required.

Also, whilst I'm here, I tried to use the Argos feed via FusePump, but there is not a field for just a plain description of the product - hence I'm back to the vanilla CJ feed.