<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>用户分层 on PlumePHP</title><link>https://plumephp.com/tags/%E7%94%A8%E6%88%B7%E5%88%86%E5%B1%82/</link><description>Recent content in 用户分层 on PlumePHP</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Wed, 24 Jan 2024 09:42:00 +0800</lastBuildDate><atom:link href="https://plumephp.com/tags/%E7%94%A8%E6%88%B7%E5%88%86%E5%B1%82/index.xml" rel="self" type="application/rss+xml"/><item><title>游戏服务器玩家画像分层架构设计</title><link>https://plumephp.com/game-server-player-segmentation-architecture-design/</link><pubDate>Wed, 24 Jan 2024 09:42:00 +0800</pubDate><guid>https://plumephp.com/game-server-player-segmentation-architecture-design/</guid><description>&lt;h2 id="背景与问题"&gt;背景与问题&lt;/h2&gt;
&lt;p&gt;玩家画像系统一开始通常只是运营后台里的几个筛选条件：等级大于 20、七天未登录、充值金额超过 100。到了中后期，它会变成活动投放、礼包推荐、流失召回、风险隔离、A/B 实验、新手保护和客服优先级的共同底座。最容易出问题的地方不是标签算错一次，而是每个业务都自己算一份“玩家类型”，同一个玩家在活动服里是回流用户，在商城里是高价值用户，在风控里又被当成异常用户。玩家分层架构要解决的是：标签从哪里来，什么时候刷新，哪些业务可以用，出问题时如何解释。&lt;/p&gt;</description></item></channel></rss>