We charge based on a combination of feature usage and search volume. All our plans include the first 20,000 searches per month. We only charge for completed searches and apply discounts as your search volume grows. We do not charge for bots, software updates or standard tech support.

Note: When your dev engine goes up, we begin charging 50% of your subscription fee. Once you are live in production, we will charge the full amount (100%). You do not pay for searches (i.e. those above 20,000/mo) until you are live in production. 

Yes. All features in our product spec sheet that are not listed in any of the plans above are included. You will not pay extra for anything else. Note: we offer a premium SLA that can be purchased seperately.

No. Loop54 is SaaS (software-as-a-service), this means our engines our hosted in the cloud and new versions can be rolled out without any extra work or cost to our clients. To access some new features, some clients may need to implement new APIs.

No. You will not pay for those pesky bots. At the end of every month we go through your searches and filter out all known bots and spiders. We then adjust your price accordingly. Please note: we make our best attempt to catch all the bots (i.e. we update our list of know bot IPs regularly), but it is nearly impossible to spot them all. 

Yes, you can stop your monthly subscription any time you want. We simply request that you give us three months advanced notice. 

It's quite simple. We charge per search POST request made to our API. A search is only considered as such when the visitor has completely typed out their query and clicked "search" (i.e. unique searches per user session)

Yes. Our algorithm builds relevance by analyzing the product catalogue and finding patterns in the metadata. Therefore, a minimum of around 500 products is required for our algorithm to work well and deliver the value we believe it should.

You will always have a direct line to tech support. At implementation, we introduce you to a member of our tech operations team. They will work closely with you to ensure the setup goes smoothly and give you advice on UI/UX design. After launch, they will regularly monitor your engine for issues and be available over chat or phone should you have any questions. 

Yes. Our standard SLA includes a Monthly Uptime Percentage (MUP) of 99.8%. All critical issues are addressed by the next work day. Non-critical issues are addressed within two work days (work day: Monday-Friday, 9-18).

A premium SLA is available should you require faster response times and/or percentage discounts if MUP goes below 99.8%.

Loop54 has an average query speed of 55 Querys /s and an average response time of ~100ms - usually less. 

Yes. Our insights dashboard will provide a complete overview of your usage in terms of the total number of searches executed per month.

We've broken our implementation process into six steps. We've had customers go live in as little as five days, but on average it takes about 3 weeks. You can review the detailed onboarding timetable here.

Yes. we've created libraries (with code examples) for the most common software platforms - Javascript, PHP, Java and .Net. The libraries are open source and available on our Github page.

Yes. Google analytics tracks the URL when a search occurs (e.g. www.yoursite/search?text=query) and this will not change when using Loop54. We do not alter your sitemap or frontend in any way. 

No. We are just an API. We do not have any impact on your frontend. You control how search results are layed out and what information is displayed along with each result (i.e. picture, copy, etc.). We have put together a UX Design Guide to help you.

Once we receive your product feed we build a model of your catalogue - identifying and mapping the complex relationships between products. Because of this mapping, we're able to generate a list of related results.

These related products are similar to the 'direct results' but they do not contain the actual search term in their metadata (i.e. they would have never been found through simple text-matching search). Basically, they have nothing to do with the actual search query, but everything to do with the what products are listed as 'direct results'. Learn more.

Response times will be much faster than to filter on your end once the products are returned by the engine.

If you choose to filter on your end instead, then we would first have to return all the products in the search results and as a second step you would have to apply filters to that list of products prior to showing any results to the user. Doing this will add unnecessary latency.

Boost or bury search results or category listings based on any product attribute. For example, promotional campaign, new products, high-margin products, etc. Boost and bury rules are applied to an established list of relevant results/products - this ensures that what is boosted still matches the user's intent.

For example: <OnSale>true</OnSale> would get 25% higher value so it has a higher possibility to appear at the top of the results/listings. The opposite goes for products that you want to “bury”, which is typically used for products that are out-of-stock.

It's like a software-to-software interface. Its how the code on your end communicates with the code in our search engine. An API is imply the rules regarding how that communication should work.