哈Ha！
我将分享我们如何基于对潜在买家的“知识”来构建自己的个性化系统的经验。
我们的解决方案与经典解决方案之间的唯一区别是，将多种解决方案结合使用，可以满足一系列要求：
- 该服务应该可以在N个站点上立即使用
- 动态受众细分
- 在不同细分受众群条件下进行预测的协作过滤
- 以点击内容分析为基础，以推荐内容+商品动态组合的形式预先生成的静态
- 考虑到动态系数，几乎实时地从RAM更改内容
这是更详细的:)关于帮助我们更好地改变堆栈的耙子。
背景知识
有一组具有相同主题的站点，其受众是相似的-拥有一个站点。 内容是不同的，通常，每个站点都会发布有关控股公司生产的商品的信息。 除了这些“内容”网站之外，还有自己的在线商店，这些产品在其中出售。
每个站点都有自己的营销团队，自己的GA和Ya Metrics柜台。 市场营销人员通过分析自己的受众，根据访问者的需求自定义网站内容。 这些站点的受众自然会相交，但是由于当时没有单个计数器，因此分析结果是本地的。
任何分析师都会做出正确的决定，并掌握更多数据。 为了达到这个良好目的，他开发了自己的计数器版本。
为什么不使用Google Analytics（分析）？抽样，缺乏从外部站点，通过我们的大量站点，通过用户观看的详细信息等一系列操作来吸引用户的所有信息的能力。 是的，就Google Analytics（分析）任务而言，它是一个很好的工具，但是当您想实时获取数据并立即决定向访问者展示什么内容时，那么……分析巨头就没有这种解决方案。 我们不建议使用带有客户ID的铃鼓跳舞，以在网站之间转移。
为所有站点设置一个计数器并不是一个完全正确的“政治”决定，它们将立即陷入免费版本的限制。
我必须马上说，我并没有开始重新发明轮子，而是将自己限制在一个适度的职能上，其职责是：
- 修复每个唯一用户，无论该组位于哪个站点。 这对于创建单个客户端配置文件是必要的，在该配置文件中，他的所有数据都将参考每个站点写入。
- 跟踪会话中组中所有站点之间的一长串过渡。 这对于确定：用户的利益； 他们看了什么； 他们买了什么； 放在篮子里但没有买的东西； 在购买过程中，不同站点的哪些产品可能是“替代产品”等。
- 跟踪所有营销人员（在站点的每个团队中）的广告活动以进行后续分析。 这对于以下目的是必要的：丰富每个访客的形象； 确定与产品相关的最佳广告活动； 参照产品或广告系列等确定有效的广告渠道 清单很长。
所有数据都实时注入本地集合。 事实证明还不错。 将来，可以按产品和按受众，受众，广告活动，点击量来源以及所有想到的内容进行汇总报告。 对于每单位商品，都有关于价格，库存数量，折扣，促销甚至海量数据的数据。
称赞这种情况，我是分析师+开发人员+市场营销人员+经理+我可以访问该馆藏中数字化的所有内容。 一开始我没有技术任务，我自己解决了普通的数据分析任务。
技术时刻：
- MongoDB被用作统一存储系统
- 基于javascript的实时数据收集
- 基于rabbitmq的站点之间的本地数据交换
虽然一切都像其他人一样...但是后来开始了
鉴于已经积累了足够的关于购买者和产品的知识，我们决定为在线商店创建自己的推荐系统。
一切都很好。 我们分析了一切，但没有狂热。 该模型的大小增加了，而通常情况下，我需要更多的时间到了。
技术时刻2：
- MongoDB复制可以继续存在，但分片立即被放弃了。 此刻还没有涉及许多内部方面。 如果clickstream集合可以分散在分片周围，则用户配置文件的集合不再存在。 可以从部分报告中收集来自不同分片的聚合查询结果，但是执行速度仍有很多不足之处。 没有分片，它会更好，更稳定地工作
- 基于javascript的实时数据收集-这里的CORS + HTTPS捆绑是独裁者。 举例来说，当一个用户来到该小组的一个站点，而我们的服务立即在多域区域中“授权”了他（我记得当时有5个独立的站点），这对于同行商人来说在技术上是美丽而神秘的，他们现在可以看到所有立刻为所有网站建立连锁。
- 推荐服务的模型是用Python编写的。 但是培训花了很长时间。 模型文件为几十GB。
- 推荐器服务在其自己的API上可以正常工作，但是服务器的响应成为瓶颈，或者说是获取结果所花费的时间。 数据越多，模型越大，模型越大，则产生结果的速度就越慢。 作为回应，有必要考虑许多每小时变化的因素（库存商品库存，用户特征和时尚，各种折扣等）。
几个月后，API的质量跨越了所有“质量”理智的界限。 对于用户而言，响应速度超过了400ms。 内容块缓慢收集，该站点开始明显呆板。 MongoDB集合总计有数千万条记录...
是时候改变一些东西了
几乎所有仪器都在操作级别记录下来，每次打喷嚏都被测量。
什么改变了什么：
- MongoDB上的Clickhouse
- 进一步的MongoDB到MongoDB + Tarantool
- 烧瓶前夕
- 猎鹰的进一步烧瓶
- 一个单独的文件在js中带有promises，并且在所有域上都具有用户授权。 他们没有改变逻辑，赢得了重构
为什么不使用公制API？起初，我只是在寻找Yandex提供的现成解决方案的方向，但时间并不长。 当一个站点正在运行时，这很好。 当有n，并且您想立即处理数据时，就没有时间与手鼓跳舞了。
为什么选择MongoDB？不断增加产品规格，但是，其中的一些规格并不能始终显示。
使用汇总查询-非常适合团队当地技术风格的格式。 古典SQL不想产生表。
通常，对存储和处理的数据的类型和变体进行了修改。
起初，我以为我会使用Yandex clickhouse作为服务的基础，但是后来我放弃了这个想法，但是clickhouse也位于我们的堆栈支架中。
一个新的时代已经来临，每秒2000个请求……只要在一周内推出新功能，负载就会增加更多。
在机器学习期间，我第一次在htop中看到100％的12个内核负载，并在生产服务器上进行了完全交换。 Zabbix主动告知MongoDB已经在10分钟内两次更改了副本中的主数据库。 每个人都想要稳定和可预测的状态。
现在该改变2.0了
用户数量增加了。 客户数量是相似的。 对于曾经去过任何网站的每个人，我们都积累了个人资料。 定期访客的观众形成了一部分。
你知道怎么办？ 是的，任何有关分析和内容多样性的非标准报告：
- 选择所有来自上一季度广告系列A的用户，从中找到对规则N的商品感兴趣的用户，然后排除仅购买股票的用户，将所有产品放入购物篮然后离开的用户网站。 根据他们的说法，如果这些用户现在进入商店的网站并购买了Z商品，则按照商店收入的降序进行排序。 诸如此类，以及其他珍珠母按钮...
- 为了分析传入流量，对于具有utm标签Y的用户形成内容报价，但在构建之前，请识别用户，排除上周但在站点S（持有站点中的一个）中并对产品Q感兴趣的用户-生成按x，y，z标准排序的内容
- 找出那些经常访问站点A，有时发生在站点B（他们访问特定区域），并且在线商店中平均支票超过N卢布的用户是很不习惯的
实际上，这不是“异常编程”的格式，我想要其他东西。 另一个来找我们。 在做广告活动的时候，在线商店不堪重负，我们可以说一下我们的API-shki，它“紧随其后”抓住了这一负载。
准时做出决定
我们对受众进行了分析，决定收集的内容不是针对所有人，而是针对一组访客。 整个人群聚集在一起。 每个集群都有自己的特点和购物的“品味”。 群集每天完成。 这是必要的，以便在下一次访问时，用户将准确显示与他最对应的内容。
从会话到会话，客户的兴趣和需求发生变化，并且如果上次自动将他分配到编号788897的集群，则根据他当前的兴趣，系统可以将其转移到编号9464的集群，这将更有效地影响后续转换。
在每日聚类过程之后，启动了下一个阶段-训练模型，考虑新的数据和有关客户的知识，并考虑出现在货架上或永久保存的商品。
对于每个群集，我们预先形成了内容块并将其记录在内存中。 然后，Tarantool充满了荣耀。 以前，我们使用它来存储快速数据，然后将其用于机器学习。 这是最好的解决方案，以免困扰已经忙于其他任务的MongoDB。 Tarantool在太空中存储的商品数据，用户数据（有关买方的必要知识）。
粗略地说，今晚我们为明天可能访问该站点的每个受众“准备”了内容。 用户进来后，我们迅速确定我们是否对他有所了解，如果答案是肯定的，则所需的内容包将发送给Nginx。 另外，对于NoName用户，默认群集已与其内容组合在一起。
后处理以进行个性化
我们知道有简单的用户，而有些用户我们拥有完整的知识。 所有这些东西都在Tarantool中并实时更新。
在页面组装时，我们了解了每个访客的购买和废弃购物篮的整个历史（如果他以前是我们的客户），确定了他的集群从属关系，点击流模块提供了有关流量来源的知识，我们了解了他的过去和眼前的兴趣。 我们从之前查看过的产品中（在该组织的任何网站上）快速构建了一系列TOP50，我们“确定了时尚”并混入了这些产品的“口味”内容，其中的主题通常是TOP50中的门类。 对最后查看的产品进行的简单分析带来了实实在在的收益。 集群内容，我们丰富了个性化。
我们经验的结果
- N次创建个人内容的过程得到了加速
- 服务器负载减少15倍
- 考虑到用户资料和网站上当前正在发生的事件，我们可以考虑到许多心愿单营销商，产品演示的功能以及许多例外情况，亲自创建几乎任何内容，所有这些操作约25ms
- 此类区块的转化率不会低于5.6％-用户愿意立即购买更接近其需求的产品
- 页面加载速度非常理想-他们将“过去”集群的内容删除了> 67％，这是正确的
- 我们提供了一种工具，可以根据营销人员的任务，给出“较早发生的事情”的答案，还可以在考虑到潜在买家的兴趣和需求的情况下，帮助在不久的将来将内容分散化
- DMP的信息已添加到每个买家的个人资料中，现在我们可以进行聚类，包括按社交网络，兴趣，收入水平和其他甜食
- 我们的推荐服务变得更好，商店中的订单更多
这有什么好处？
我们获得了新的经验，测试了一些以前不知道如何处理的假设，我们没有将第三方付费解决方案用于没有考虑我们所有功能并在同一个领域中工作的推荐服务。 团队收到了一个很好且有趣的案例，他们成功地进行了处理。
胃口越来越大……现在我们正在测试内容组装的新逻辑。 我们希望收集广告活动，新闻通讯和其他外部活动的页面。 该计划包括将配置逻辑从手动模式转移到机器学习方向。 网站将过自己的生活，除“爆米花”外，我们还将根据AI的观点观察网站内容呈现方式的演变。