上周，一家在线汽车配件商店的老板写信给我。他在 WooCommerce 目录中拥有 14000 个职位，每月托管费用为 3000 卢布，还有一个非常具体的痛点——搜索。该人士表示：“客户输入零件号，按 Enter 键，等待六秒钟，得到空结果，然后去找竞争对手。我每天都在赔钱，但我不知道该怎么办。”我问他已经尝试过什么。结果我安装了三个不同的搜索插件，其中一个每年支付 79 美元，但没有一个真正解决了问题。搜索仍然很慢，它不原谅打字错误，而且我根本不懂俄语的形态。找到了“轴承”一词，但不再找到“轴承”。
这个故事也不例外。我几乎每周都会从不同的人、不同的商店听到这样的说法，但都遇到同样的问题。你知道最让我惊讶的是什么吗？这并不是说 WordPress 的内置搜索不好——这一点早已众所周知。事实上，大量的店主甚至没有意识到情况有多糟糕，以及他们每个月因此损失了多少钱。他们将低转化率归因于竞争、季节性、广告——除了网站标题中的小搜索框之外的任何因素，所有买家中有 30% 到 60% 会通过该搜索框。
让我们看看为什么会发生这种情况，您可以采取什么措施，以及为什么我们最终在 COS WP Woo 插件中构建了自己的 Typesense 搜索模块。我会毫不修饰地告诉你——用真实的数字，用我们踩过的耙子，用我们在一家拥有近一万七千种产品的战斗商店中得到的结果。
为什么内置 WordPress 搜索对在线商店来说是死刑
要了解问题的严重性，我们需要花点时间深入了解一下。当客户在标准 WordPress 搜索栏中输入查询并按 Enter 键时，会发生以下情况：WordPress 接受该查询并针对 MySQL 数据库生成 SQL 查询。此外，它以最原始的方式实现这一点 - 通过两边都有百分比的 LIKE 运算符。翻译成人类语言，听起来是这样的：“亲爱的数据库，请检查 wp_posts 表的每一行，并检查 post_title 或 post_content 字段在其内部的某个位置是否包含该字符序列。”没有索引，没有优化，什么都没有——只是逐行的完整搜索。
在包含 50 篇文章的博客上，这效果很好。在一个有上千种产品的商店里，这是可以忍受的。但是，当你有十个、十五个、两万个职位，并且每个产品都有元字段、属性、描述、变体时，这就会变成一场灾难。 MySQL 开始窒息了。该请求应立即执行，需要一秒半到三秒的时间。如果服务器当时正在加载其他任务，那么五到六秒内就很容易了。
但慢度也不是那么糟糕。真正的问题是这种搜索是愚蠢的。他不懂形态学 - 如果一种产品被称为“合成机油”，而买家正在寻找“机油”，则标准搜索将找不到它。因为“motor”和“motor”对于 LIKE 运算符来说是不同的字符串。它不会原谅拼写错误 - 您输入“壳牌石油”而不是“壳牌石油”，就是这样，零结果。他不知道如何保持相关性 - 如果有 300 个产品与查询匹配，它们不是按重要性排名，而是按发布日期排名。一条 200 卢布的工业电缆将比 100 万卢布的发电机贵，仅仅是因为它是后来添加到目录中的。
我思考了很长一段时间，为什么WordPress在存在了二十年之后，还没有获得正常的搜索。我得出的结论是，问题不在于开发人员的懒惰，而在于架构。 WordPress 被设计为博客引擎，搜索博客与搜索产品目录是完全不同的任务。对于博客，只需使用关键字搜索文章即可。对于商店，您需要按文章、按品牌、按特征、按同义词、按名称的一部分查找产品，同时考虑到拼写错误 - 并在瞬间完成此操作，并具有即时预览和过滤功能。 WordPress 根本就不是为此而创建的，并且任何试图“完成”标准 WP_Query 的插件都无法从根本上解决这个问题。你无法修复设计造成的损坏。
事情是这样的：大多数 WooCommerce“搜索插件”就是这样做的 - 尝试改进标准查询。他们添加了按元字段、SKU 的搜索，并通过额外的表连接来提高相关性。它产生了效果——百分之二十，也许百分之三十。但根本问题仍然存在：搜索仍然通过 MySQL，仍然通过穷举搜索，仍然没有词法，也没有对拼写错误进行正常处理。这就像试图驾驶Zhiguli赢得一级方程式比赛一样，只需将其漆成红色并在其上贴上扰流板。
Typesense - 当我第一次看到差异时
我们没有立即使用 Typesense。首先，我们研究了 Elasticsearch，这是 Amazon、eBay 和全球一半主要电子商务网站使用的公认的全文搜索标准。从技术上讲，Elasticsearch 非常棒。但对于中小型网店来说，这就像购买矿用自卸车来从Pyaterochka运输产品一样。 Elasticsearch 至少需要 2 GB 的 RAM 才能运行。实际上，为了舒适地工作，您需要 4 到 8 GB。这是一个单独的服务器或功能强大的 VPS。加上Java栈，加上复杂的配置，加上需要监控和维护。对于一个拥有一万到一万五千种产品的商店来说，这就像用大炮射麻雀一样，而且大炮的维护成本也很高。
然后一位同事推荐了Typesense。老实说，我对此表示怀疑——这个开源项目并不像 Elasticsearch 或 Algolia 那样广为人知。但我决定尝试一下，第一次测试确实让我感到惊讶。我们将包含一万五千个产品的索引加载到 Typesense 中，搜索查询在五到十二毫秒内开始执行。不是秒——毫秒。相比之下，通过对同一目录进行标准 WooCommerce 搜索的同一请求需要 800 到 1500 毫秒。差别不是几倍，而是几十倍。
但速度只是硬币的一方面。开箱即用的 Typesense 可以做一些 MySQL 永远无法做到的事情：考虑拼写错误的搜索，即所谓的拼写错误容忍度。买家输入“Castrol”而不是“Castrol” - 仍然可以找到所需的油。写了“液压油”——Typesense 知道这是一个拼写错误，并给出了正确的结果。对于俄语商店来说，这一点至关重要，因为俄语键盘布局和拉丁品牌名称是无穷无尽的拼写错误来源。人们在错误的时刻切换布局、用音译书写、混淆“i”和“th”、“e”和“e”——而 Typesense 可以正确处理所有这些。
另外，值得一提的是形态。对于英语来说，这并不是那么重要——那里的词法相对简单。但俄语则是另一回事。在我国，一个名词可以有十二种形式，一个动词可以有更多形式。 “Oil”、“oils”、“oil”、“oil”、“oil”、“oils”——所有这些都是相同的产品，搜索引擎必须理解这一点。 Typesense 支持俄语词法，并且它不能完美地工作 - 存在边缘情况 - 但它比 MySQL 中愚蠢的字符串比较要好一个数量级。
与 Elasticsearch 相比，Typesense 消耗的资源也少得离谱。对于两万个产品的索引，一到两百兆的 RAM 就足够了。它是用 C++ 编写的，作为单个二进制文件运行，不需要 Java，也不需要复杂的基础设施。你可以直接将它安装在运行WordPress的同一台服务器上，它将和平共处，消耗最少的资源。或者使用基于云的 Typesense Cloud - 有针对小型项目的免费计划和相当实惠的付费计划。
当我看到这一切的实际效果时，我发现很明显：WordPress 的内置搜索需要完全替换，而不是“改进”。我们开始在插件内部构建 Typesense 集成，以便商店所有者可以获得 Algolia 级别的搜索，但无需支付数百美元的月费，也无需弄清楚如何设置搜索引擎。
我们是如何构建它的 - 以及我们犯了什么样的错误
这个想法听起来很简单：我们从 WooCommerce 获取数据，将其加载到 Typesense 中，通过 AJAX 小部件显示结果。当然，在实践中，一切都变得更加复杂。出现的第一个问题是到底要索引什么。产品名称一目了然。说明也。然后细微差别就开始了。 SKU（商品编号）是必须的，因为许多 B2B 买家专门通过商品编号进行搜索。产品属性 - 是的，因为人们可能会搜索“5W-30 油”并期望搜索到具有 5W-30 粘度属性的产品。价格 - 分面过滤所需，以便您可以按价格范围过滤结果。类别适用于相同的方面。品牌——一样。有库存 - 因为没有什么比找到完美的产品却发现缺货更糟糕的了。
我们更进一步，为产品附加的 PDF 文件添加了基于内容的索引。这听起来很奇怪，但对于工业商店来说，每件产品都附有技术文档、安全数据表和证书，这改变了游戏规则。采购经理可以输入 GOST 编号或特定批准的名称，搜索将找到文档中提到该 GOST 的产品。以前，这需要手动打开每个 PDF。
下一个任务是同步。 Typesense 索引必须是最新的。当经理添加新产品、更改价格、更新描述时，这些更改应反映在搜索中。我们通过 Action Scheduler（内置的 WooCommerce 任务计划程序）实现了这一点。每次保存产品时，都会触发一个挂钩，将更新索引的任务排队。 SearchIndexerJob 接手此任务并更新 Typesense 中的相应文档。这是在后台异步发生的 - 经理不会等待索引更新，他只是保存产品并继续。
老实说，我们在同步方面遭受的损失最大。第一个版本同步更新索引，就在 save_post 挂钩中 - 当从 1C 大量导入商品时，这会导致服务器崩溃。想象一下：一包 300 个产品到达，每个产品都有一个对 Typesense 的 HTTP 请求。每分钟 300 个请求仍然可以忍受，但如果导入是分块的并且有 15000 个产品，服务器就会开始阻塞。我们通过 Action Scheduler 切换到队列 - 然后问题就消失了。现在，在批量导入期间，更新索引的任务会排队并批量处理，而无需加载 WordPress 或 Typesense。
另一个不明显的问题是初始索引。当商店刚刚连接搜索模块时，需要对整个目录进行索引。对于拥有一千种产品的商店来说，这需要一两分钟。对于我们拥有 16,844 种产品的战斗商店，初始索引大约需要二十分钟。我们通过将其分成 250 个产品的批次来优化流程，并在批次之间暂停，以免服务器过载。管理面板中显示进度条 - 所有者可以看到有多少百分比已被索引，并且可以轻松执行其他操作。
还有一个关于编码的故事。 Typesense 与 UTF-8 配合得很好，但一些 WordPress 商店的产品带有棘手的字符 - 不间断空格、特殊破折号、品牌符号。一家石油商店在其产品名称中保留了“™”，并且在发送到 Typesense 时破坏了 JSON 序列化。我必须在索引之前添加文本规范化 - 清除不可见的控制字符，用常规引号替换“智能”引号，以及处理真实数据的其他乐趣。
单独的章节 - 分面过滤。当客户搜索“机油”时，他会得到四百个结果。如果没有过滤，这是没有用的——没有人会翻阅四百张卡片。您需要方面：按品牌（壳牌、嘉实多、卢克石油）、粘度（5W-30、10W-40）、类型（合成、半合成）、价格（500 至 2000 卢布）过滤。 Typesense 原生支持分面过滤 - 我们只需指定哪些字段是分面的，引擎就会自动计算每个类别中的产品数量。用户不仅看到过滤器列表，还看到带有数量的过滤器 - “壳牌 (47)”、“嘉实多 (32)” - 并且可以快速将结果范围缩小到所需的产品。
同义词、管理和分析 - 智能搜索的三大支柱
真正的智能搜索与简单的快速搜索之间存在着三个区别。第一个是同义词。每个利基市场都有自己的行话、缩写和替代名称。在油店里，“变速箱”=“齿轮油”=“齿轮油”=“齿轮油”。在电子产品商店中，“移动”=“智能手机”=“电话”=“手机”。在建材商店中，“石膏板”=“石膏板”=“干石膏”。如果搜索引擎不知道这些同义词，就会失去客户。
我们已使管理同义词变得尽可能简单。在 WordPress 管理面板的搜索部分，有一个“同义词”选项卡。您添加一组同义词 - 例如，“齿轮油”、“传动装置”、“齿轮油” - Typesense 开始将所有这些术语视为等效术语。买方输入任何选项并收到相同的结果集。设置需要五分钟，效果是每天保存数十个搜索会话。
还有另一种类型的同义词 - 单向。此时，美孚必须找到美孚品牌产品，但反之则不然。或者，当“动力转向液”应该找到“动力转向油”时，但搜索“动力转向油”不必包括标记为“动力转向液”的所有内容。这种微妙之处在术语可能含糊不清的技术领域尤其重要。
第二件重要的事情是结果的管理。有些请求对企业具有战略意义。例如，您知道查询“机油 5W-30”为您带来最多的搜索买家。您希望搜索结果中的第一个项目不仅仅是任何随机的 5W-30 油，而是特定的项目 - 也许具有最高的利润，也许来自合作伙伴品牌，也许是那些当前正在销售的产品。策展允许您根据特定请求记录特定产品在搜索结果中的位置。您说：“搜索“5W-30 油”时，始终首先显示 Shell Helix Ultra，其次显示 Castrol Edge，并从搜索结果中完全隐藏产品 X。”它有效。
我知道有些人对手动调整搜索结果的想法感到冒犯。他们说搜索必须客观，算法必须决定。从理论上讲这是真的。但实际上，商业并不是一项学术活动。您有需要推广的产品。有货物需要出售。有合伙义务。搜索中的智能推销与实体店中的推销一样合法，糖果总是在收银台，牛奶总是在最远的角落。
第三个也许是最被低估的功能是搜索分析。我们记录每个搜索查询：他们在寻找什么，他们是否找到了什么，他们是否点击了结果。从这些数据中，我们可以得到一幅无法通过任何其他方式获得的图片。你看上个月有两百人搜索“防冻液红G12”，没有人找到任何结果——因为在你的目录中这个产品被称为“冷却液G12+红”。添加同义词 - 每月 200 个丢失的搜索会话将变成 200 个找到的产品和潜在销售。
或者另一个例子。您会看到每个月有一百人正在寻找特定的文章 - 比方说，“550046983”。这是目录中没有的壳牌机油零件号。但你有另一家制造商的类似产品。如果没有搜索分析，您永远不会知道这数百人来了，没有找到产品就离开了。现在，您在顶部的“搜索无结果”中看到此请求，您可以做出决定：要么将此产品添加到目录中，要么设置一个同义词，将该请求重定向到类似物，或者至少显示横幅“没有找到此商品？尝试我们的类似物...”
搜索分析本质上是满足买家需求的直接沟通渠道。他们自己通过搜索栏告诉你他们想要什么。剩下的就是倾听。
我们以方便的形式显示分析：热门查询、没有结果的查询、点击率低的查询（当人们找到结果但不点击时，这意味着结果不相关）、按天和按周的趋势。商店经理可以每周访问一次分析部分，花费十五分钟，并获得比任何市场研究更有用的需求信息。
搜索小部件 - 对于买家来说它是什么样的
我之前讲的都是后端。索引、同义词、分析——买家看不到这些。他看到一个搜索栏，他的使用经验决定了他是买东西还是离开。因此，我们对搜索前端进行了特别谨慎的处理。
搜索小部件的工作原理如下。买家开始输入文本 - 在第二个或第三个字符之后，搜索栏下方会出现一个包含结果的下拉窗口。不仅仅是文本链接，还有完整的产品卡：缩略图、名称、价格、库存情况。买家甚至在完成请求并按 Enter 之前就可以看到结果。这就是所谓的“键入即搜索”，由于谷歌、亚马逊等大型平台的帮助，人们已经习惯了这种标准。当您的商店也能做到这一点时，这不仅仅是方便，更是一个信号：“我们是一家认真的商店，这里的一切都按其应有的方式运作。”
每次击键都会发出对 Typesense 的请求，但会有 200 毫秒的反跳 - 以免买家快速打字时用请求轰炸服务器。响应时间为 5-50 毫秒，结果立即更新。感觉就好像结果已经准备好，等待展示。
该小部件可以通过短代码插入到任何页面。您可以将其放在网站标题中，而不是标准的 WordPress 搜索中 - 为此，在大多数主题中，您只需将短代码添加到所需的小部件块中。可以放置在单独的搜索结果页面上。可以用作登陆页面元素：“在 3 秒内找到您需要的油” - 并且有一个搜索行可以立即显示结果。这是一个强大的信任元素，因为它向买家表明目录确实很大并且易于浏览。
当客户按 Enter 或单击“显示所有结果”时，他们将进入搜索结果页面。这就是我之前谈到的分面过滤发挥作用的地方。左侧是一个过滤面板，其中包含类别、品牌、价格范围和属性。右侧是带分页的产品卡。过滤器可立即生效 - 无需通过 AJAX 重新加载页面。单击“壳牌” - 列表瞬间更新，仅显示壳牌产品。我删除了过滤器，整个列表又回来了。这是客户在市场上习惯的用户体验级别，它将您的商店与竞争对手区分开来，搜索会在一张无限的表格中返回所有结果，而无法进行过滤。
我将单独告诉您有关突出显示匹配的信息。当客户搜索“HLP 46 液压油”时，搜索结果会以粗体或彩色突出显示找到的单词。买家立即了解为什么该特定产品出现在搜索结果中，并可以快速评估其相关性。这是一件小事，但它显着改善了体验并减少了从请求到点击的时间。
还有一件事经常被忽视，那就是适应性。搜索小部件在移动设备上可以正常工作。目前，大多数在线商店的移动流量占 60-70%。在手机上，带有结果的下拉窗口占据了屏幕的整个宽度，产品卡适应狭窄的屏幕，结果页面上的过滤器折叠到滑动面板中。没有任何东西会破裂，没有任何东西可以相互叠加。这似乎是一个显而易见的要求，但你会惊讶地发现有多少搜索插件仍然在手机上无法正常工作。
16,844 种产品 - 在战斗中如何发挥作用
理论很好，但我们来谈谈真实的体验。我们有一个润滑油商店 - 16,844 种产品、WooCommerce、基于 Porto 的自定义主题，以及带有 Typesense 搜索模块的 COS WP Woo 插件。这家商店是我们的实战训练场，我们在这里用真实的数据和真实的客户来测试所有功能。
在引入 Typesense 之前，该商店的搜索通过标准 WooCommerce 进行，并进行了多项改进 - 通过附加插件按 SKU 和属性进行搜索。搜索查询的平均响应时间范围为 800 到 2000 毫秒，具体取决于服务器负载。在分秒必争的移动设备上，速度慢得惊人。我们根本没有收集搜索查询分析——没有工具。
在 Typesense 上启动搜索模块后，我们对目录进行了完整索引。超过一万六千个产品 - 通过 Action Scheduler 在后台建立索引大约需要二十分钟。 Typesense 中的索引大小约为一百五十兆字节。 Typesense 本身的 RAM 消耗约为 200 MB。对于具有 8 GB RAM 的服务器来说，这是难以察觉的。
切换到 Typesense 后的平均搜索查询响应时间为 8-15 毫秒。这考虑了位于同一服务器上的 WordPress 和 Typesense 之间的网络延迟。对于消费者来说，这看起来像是即时响应——他开始打字，甚至在他手指离开按键之前结果就出现了。
我们从第一天开始收集搜索分析，它很快就显示出有趣的事情。事实证明，很大一部分买家是按商品编号搜索产品，而不是按名称，而是按字母数字代码。这是 B2B 领域的典型情况：采购经理有一份包含文章的规格，然后只需将它们一一打入即可。对于这种情况，具有自动完成功能的即时搜索可以节省大量时间。经理无需每次等待三到五秒才能加载结果页面，而是立即收到答复，并且处理订单的速度可以快很多倍。
分析的另一个发现是结果为零的查询数量。第一周大约占总数的 15%。也就是说，每六个或第七个买家中就有一个没有找到他想要的东西。我们分析了这些查询并发现了几种模式。有些请求存在拼写错误和替代拼写，这些问题通过设置同义词得到了解决。其中一些请求确实不在目录中，但添加是有意义的。有些是对目录中的产品的请求，但名称不同。经过一个月的分析和同义词处理后，我们将零结果的请求比例减少到 4-5%。这意味着大约 10% 之前空手而归的买家现在找到了他们想要的东西。
这是一个具体示例。买家经常搜索“VMGZ”——这是业内知名的液压油品牌。但在目录中，该产品被称为“液压油 VMGZ-45”，标准搜索仅通过完整出现找到它。如果买家只是输入“VMGZ”而不输入“-45”，就会有结果，但如果他输入“VMGZ oil”，则搜索已经丢失，因为单词的顺序不同。切换到 Typesense 后，这个问题消失了 - Typesense 在所有字段中搜索，考虑词序，并找到部分匹配。另外，我们添加了同义词：“VMGZ”=“VMGZ 液压油”=“VMGZ-45 油” - 现在任何这些查询都会生成正确的产品。
如果我们谈论对业务指标的影响 - 在这里我们需要说实话，我们没有进行纯粹的 A/B 测试，所以我不能以科学的准确性说转化率因搜索而增加了 X%。但我们看到了一种相关性：引入新搜索后，以将商品添加到购物车结束的搜索会话的百分比有所增加。买家开始更频繁地使用搜索，而不是浏览目录 - 这是合乎逻辑的，因为搜索现在比搜索类别更快、更可靠。带有“我找不到产品”字样的支持请求数量实际上已经消失了。
我不会给出转化增长的具体数字，因为我认为这是不诚实的——影响转化的因素太多，如果没有受控实验，不可能孤立其中一个因素的贡献。但我可以自信地说：快速智能搜索消除了买家和购买之间最烦人的障碍之一。而排除障碍就是转化优化的本质。
还有一个很少讨论的方面——服务器负载。标准 WooCommerce 搜索是加载 MySQL 数据库的繁重 SQL 查询。每个搜索查询都是多个表的 JOIN、全表扫描、CPU 和磁盘 I/O 消耗。当十个人同时在网站上搜索时，同时有十个重查询。在资源有限的主机上，这不仅会减慢搜索速度，还会减慢整个网站（目录页面、购物车、结账）的速度。借助 Typesense，MySQL 的搜索负载被完全消除。数据库执行其应该执行的操作 - 处理订单、更新余额、使用购物车。搜索由为此优化的单独引擎处理。这在高峰负载期间（销售、促销、流量显着增加）尤其重要。
我们在商店注意到，将搜索转移到 Typesense 后，平均 MySQL 负载下降了 15% 到 20%。这听起来不是很多，但实际上这是“网站稳定”和“网站在高峰时段定期变慢”之间的区别。对于一家收到价值数万、数十万卢布订单的商店来说，结账时每一秒的延迟都可能导致订单丢失。
我们不能不提到文档搜索。这是一个很少有人实现的功能，但对于工业和 B2B 商店来说却非常宝贵。我们的模块可以索引产品附带的 PDF 文件的内容。技术数据表、合格证书、安全数据表、使用说明 - 所有这些都是文本，并且所有这些都可以通过搜索获得。工程师输入 TU 或 GOST 编号，然后搜索查找其技术文档中提到该标准的产品。对于购买工业润滑油的公司来说，油品的选择不是由价格决定，而是由是否符合特定标准决定，这从根本上改变了使用目录的体验。他们不再打电话给经理并要求“找到一种符合 GOST 17479.4-87 的油” - 他们自己在三秒钟内通过搜索找到它。
特别令人自豪的是重新索引的速度。当我们通过自己的集成模块与 1C 连接同步时，每天晚上商店都会收到所有 16,000 个产品的价格和余额更新，对我们来说，搜索索引更新得同样快非常重要。 Typesense 可在 1-2 毫秒内处理单个文档的更新。一万六千次更新总共大约三十秒。相比之下，为此卷重新建立 Elasticsearch 索引需要几分钟甚至几十分钟的时间，具体取决于配置。
我将告诉您另一种情况，它很好地说明了“搜索有效”和“搜索正常工作”之间的区别。在我们的目录中，我们有不同包装的油 - 同样的油可以在 1 升、4 升、20 升罐和 208 升桶中出售。这是四种不同的产品，价格不同，物品不同，但本质上是相同的产品。当买家搜索“Shell Helix HX8 5W-30”时，他希望看到并排的所有包装，以便选择他需要的包装。标准的 WordPress 搜索返回的结果是它们与其他壳牌油混合在一起，因为相关性是由标题中的词序和发布日期决定的。 Typesense 按匹配程度排名 - 精确的名称匹配始终高于部分匹配，并且所有四个包都位于第一个位置，以自然的方式分组。买家立即看到所有选项，无需滚动三页结果即可进行选择。
我认为极其重要的另一点是数据安全性和隔离性。 Typesense 仅对您明确选择索引的数据进行索引。它无法访问 WordPress 数据库，不知道用户密码，看不到订单，也不存储客户的个人数据。该索引仅包含产品信息：名称、描述、价格、属性、图像。对于与企业客户合作且必须遵守个人数据处理要求的商店来说，这是一个重要的优势。搜索引擎实际上无法“泄漏”公共目录信息之外的任何内容，因为其中没有其他内容。
我还想谈谈拥有成本，因为这是最常被问到的问题。 Algolia 是 Typesense 在云搜索领域最著名的竞争对手，起价为每千次搜索 1 美元。听起来很便宜，直到你算一下。如果您每天有 1000 名访问者，每个访问者平均进行 3 个搜索查询（一个基本查询和两个自动完成的合格查询），那么每月就有 9 万笔交易。加上索引 - 每个产品更新也被视为一次操作。对于一家拥有一万六千种产品且交易活跃的商店来说，Algolia 的账单每月很容易达到 50-100 美元。尽管 Algolia 是一项出色的服务，但我不会说它有什么不好的。
Typesense Cloud 的价格要便宜得多，处理无限数量请求的专用实例的起价为每月 29.99 美元。没有交易费用，没有账单，月底也没有惊喜。如果您准备在服务器上安装 Typesense，它是完全免费的，因为 Typesense 是完全开源的。对于我们的战斗商店，我们选择了自托管选项 - Typesense 与 WordPress 在同一服务器上运行，消耗 200 MB 内存，并且不花费一分钱。唯一的“成本”是初始安装时间，对于熟悉 Linux 的人来说大约需要三十到四十分钟，如果使用 Docker，则只需点击几下。
当我将 Typesense 的成本与商店因搜索不佳而损失的金额进行比较时，差异是如此明显，以至于问题本身似乎是反问的。每天丢失一个订单——假设平均账单是三千卢布——那就是每月九万卢布。一。当 15% 的搜索查询以零结果结束时，有多少订单会丢失？搜索什么时候无法识别拼写错误？当客户等待三秒钟然后去找能够立即得到结果的竞争对手时？我不想猜测具体数字，但损失的规模显然超过了解决方案的成本——几个数量级。
这是我在使用搜索时意识到的：正确的搜索不是一项功能，而是基础设施。这是在线商店中与购物车或结账相同的关键部分。您可以拥有完美的目录、精美的设计、快速的交货 - 但如果买家找不到他需要的产品，其他一切都不重要。然而，搜索是大多数 WooCommerce 商店中投资最不足的部分之一。人们花费数千美元做广告，吸引流量，然后因为最简单的事情而失去客户——“我没有找到我要找的东西。”
如果我们从另一面来看呢？投资于改善搜索的每一卢布都不是为了吸引新流量，而是为了转化现有流量。您无需按点击付费，无需按展示付费 - 您只需停止失去已经到达的用户即可。从这个意义上说，良好搜索的投资回报率可能明显高于其他广告活动的投资回报率。
我一直在思考为什么 WordPress 社区长期以来一直容忍糟糕的搜索。我认为事实是大多数店主根本不知道它有何不同。他们已经习惯了这样一个事实：搜索是一件缓慢的事情，并不总能找到他们需要的东西。他们没有了解搜索在 Amazon 或 Ozon 上的工作原理，也不认为 WooCommerce 商店可以使用相同的技术。当你向他们展示差异时 - 你实际上打开两个浏览器窗口，一个使用标准搜索，另一个使用 Typesense，然后输入相同的查询 - 人们的下巴简直要掉下来了。 “可以吗？” - 最常见的反应。
是的，这是可能的。这是必要的。我们使其尽可能易于访问 - 我们将其直接内置到插件中，并提供分步设置、易于理解的管理面板和自动同步。无需手鼓跳舞，无需编程，无需单独的服务器 - 尽管此选项也适用于需要可扩展性的人。连接 Typesense Cloud 或将其安装在您的服务器上，在设置中指定 API 密钥，单击“索引” - 二十分钟内您的搜索速度提高了五十倍，并且可以理解拼写错误、俄语形态和文章。这并非营销夸大其词，这就是实际发生的情况。
我想说的最后一件事。我们并没有止步于现在所拥有的。搜索是一个生命系统，必须随着商店和客户的期望而发展。我们的近期计划包括根据购买和浏览历史记录个性化搜索结果、与推荐引擎集成以及移动设备的语音搜索。电子商务世界正在走向日益智能的客户体验，而搜索处于这一趋势的最前沿。
同时，如果您的 WooCommerce 商店包含 1000 多种产品和标准 WordPress 搜索，请尝试输入一些拼写错误的查询并查看结果。如果结果让你感到不安，那么是时候做出改变了。我知道从哪里开始。
试用 COS WP Woo - 免费 14 天。安装插件，将智能搜索模块连接到 Typesense，看看您的客户体验将如何改变。无功能限制，无卡绑定。只需快速、智能的搜索，即可在几毫秒（而不是几秒）内找到客户所需的内容。