In part one of this series, we broke down how a completely fictional smartphone manufacturer named Orange might organize their jPhones into a cohesive search index. Let’s see how we might apply that same logic to a different industry — here we’re writing about a fictional automotive tools reseller we’ll call Clip-On. You’ll see how this methodology takes into account business requirements and creates the optimal search experience in the process.

To recap, what’s a product? Last time we spent quite a bit of time on this question. It’s a bit tough to answer precisely, but what we came up with is that a product is an item, service, or category of items or services, as distinguished from other products (other items, services, or categories of…). Remember this image from part one?

We drew the borders where they are because it feels like thats where they should naturally separate. The items that this company sells (in this case, different types of boots) naturally align into certain definable categories.

Those definitions are not universal, though! We tested this on smartphones, and as it turns out, the color of the phone has the same effect on the eventual search index as does which year’s edition it is. That might feel a little counterintuitive, so definitely check that article out for the full reasoning. In short though, each product, in the context of a search index, is going to be searchable. That should be somewhat self-explanatory, but it has the strange side effect that if some customers might search for blue jPhones specifically, the blue jPhone needs to be its own searchable product so that those customers find exactly what they’re looking for. In other words, the color difference splits jPhones into separate products just like how the jPhone 11 and jPhone 13 Pro are different products. Meanwhile, arguably more consequential differences like phone size or storage space are just left as options in the checkout flow instead of having their own searchable products — after all, it’s unlikely that anybody will search specifically for a 256GB jPhone.

How would this look for our new case study participant, Clip-On? Right away, I can see two main new factors:

1. When searching for tools, queries end up being much more specific. Users don’t just search wrench. They search for 1/4in 12 point steel usa wrench. Suddenly, a lot more things have to be included in our search index so that potential customers will find exactly what they want.
2. As well, the product catalog is a lot more diverse. We’re not just selling a bunch of smartphones which can all be described in roughly the same way. Now we’re selling wrenches and hammers, drills and screwdrivers, chisels and pliers, wire cutters and grinders, ratchets and polishers, and on. We have to put a lot more thought into what can actually fit in the search index, since the whole “indexing” part (where Algolia caches your product database for near-instant, realtime lookup) requires consistent attributes on each product.

So, let’s pick two products — let’s say a wrench and a pair of wire strippers — and think through the search index creation process with these new factors in mind.

Designing for tools — wrenches and wire strippers

How might we model a wrench like this one?

The first and probably most valuable measurement is the head size (that determines what size nut the wrench can turn). We should also store the length of the handle, or of the whole wrench perhaps. The material that the wrench is made out of is fairly important too since sometimes they’re made out of plain steel, and other times they’re made out of a stronger alloy. The customer will likely also want to know which company made the tool (since we’re just reselling it) and the country that it was manufactured in. Because of the specificity of the search queries we’ll be getting, we can assume that all of these attributes are searchable.

Next, how might we model these wire strippers?

This tool does a lot more than just stripping wires, but we’re just going to keep the model simple for demonstration’s sake. We can store the physical dimensions of the tool, but the utility of those numbers are rather limited, especially in the context of search. Who’s going to search specifically for wire strippers that are exactly 9.72 inches long? Instead, like we did with the wrench, let’s analyze which measurements are actually useful. In this case, the size of those first few circular holes down the center of the tool which determine the range of wire diameters that the tool can strip effectively. From the developer’s point of view, this might seem like a strange thing to be important, but this is why we don’t work on search in isolation.

But as for the other attributes — aren’t they the same as on the wrench? Really, every tool is going to share some properties like material, manufacturer, and countryOfOrigin. These properties can appear on every product in the search index. So we already know how to handle these: just place them in the product JSON like we did for things like color on the jPhones.

But how will we handle the attributes that change from product to product? This part is rather tricky, but it’s important to keep in mind our rather narrow scope here. We’re assuming that you have a product database that actually hydrates your product pages with data, and so when we take something out of our search index, we’re not actually throwing that data away — it can always be queried from the database. Our scope here is limited just to search, so we can make some decisions that would probably be bad practice if we were talking about long-term data storage. With that said, let’s talk about serialization.

What if we made a single, searchable string that contains our product-specific attributes, but in a human-readable way that matches what our users might reasonably search for? For example, take this JSON version of our wrench and wire stripper models from above:

[
	{
		"name": "10 mm 12-Point Metric Combo Wrench",
		"manufacturer": "PeopleWhoMakeWrenches, Inc.",
		"countryOfOrigin": "USA",
		"material": "chrome"
	},
	{
		"name": "Wire Stripper and Cutter",
		"manufacturer": "BPlusTools Corp.",
		"countryOfOrigin": "USA",
		"material": "steel"
	}
]

Obviously some of the information, especially on the wrench, is baked into the name or title, but what do we do with the rest of the product-specific data?

Again, this is bad practice if you’re storing these products in your database, but we’re just making a search index, so the rules change a bit. Let’s create a new attribute called specs and give it a serialized version of the product’s custom specs.

[
	{
		"name": "10 mm 12-Point Metric Combo Wrench",
		"manufacturer": "PeopleWhoMakeWrenches, Inc.",
		"countryOfOrigin": "USA",
		"material": "chrome",
		"specs": "10mm head size, 9in handle length"
	},
	{
		"name": "Wire Stripper and Cutter",
		"manufacturer": "BPlusTools Corp.",
		"countryOfOrigin": "USA",
		"material": "steel",
		"specs": "Can cut 10 gauge, 12 gauge, 14 gauge, 16 gauge, 18 gauge, 20 gauge, and 22 gauge wire"
	}
]

It’s worth being rather specific in a way that emphasizes possible search keywords and the way that they’ll likely, naturally be combined together. For example, many people will search 10mm without a space, while others may search 10 mm with the space. Having it in the name of the wrench one way and another in the specs attribute will make sure that we match both cases, though Algolia is smart enough to get us close to expected behavior even if we don’t take this step. The same goes for the gauge repeated multiple times for the wire strippers. If someone searches for a specific gauge or gauge range for the tool, we have the best chance of matching their search this way.

Note: this may look odd, yet we never have to show this string to the user! Sometimes we have the preconception that everything that we search by is displayable information, but that doesn’t have to be true! Our search index can be (and should be) largely tailored to the AI that is going to rank our search results. We’re going for functionality here — what we actually show to the user can be pulled from our product database, if necessary.

Conclusion

So what have we learned in this series (be sure to check out part one if you haven’t already)? Most importantly, it’s that your search index and the products that it contains shouldn’t be treated just like the products in your database. The methodology that we laid out here of analyzing the possible search queries and factoring that knowledge into how you divide searchable products from one another, creates the smoothest possible search experience for your users and makes the developers’ lives far easier. I’m sure that you can see how and why this is applicable to you, even if you don’t work at Orange or Clip-On: the less friction between the desire to buy something from your company and the checkout completion button, the more money that your company makes. Sounds like now is the time to get started with Algolia, right?

And hey, since carefully considering the construction of your search index means increased revenue, perhaps you’d be justified in asking your higher-ups to reward you with a little piece of it come payday…and if not, maybe you’d consider joining me here at Algolia? Take care and thanks for reading!