面对复杂多变的业务，我们应该如何设计产品架构，才能不会重构再重构呢？我们不需要想答案，看下这个行业被奉为圭臬的理论是什么，我们遵守、学习、应用就是了。因为这个理论已经被验证，随着市场的变化仍然对业务具备指导意义，这足够说明问题了。

2017年阿里巴巴提出的“人货场”模型就是零售、营销、电子商务等行业经久不衰的理论。本期先分享下客户体系的搭建，后续文章会逐步更新。

前段时间被问了一个问题，“你觉得产品经理如何保证产品的健硕性？”

我回答：“产品设计要符合市场定律。”

一、“人货场”为什么适合私域

私域的运营，本质上也是对“人货场”三者关系的运营。

传统的营销，比如商超，在固定的地点集中陈列货物，供人选购。商超就是“场”，是商品信息，物流信息，交易信息的载体。现在做私域，“微信”是场，“短信”是场，“WhatsApp”是场，“Line”是场，通过各种消息体把“货”带到客户面前。

我们现在回过头来看那些私域的定义，比如“企业拥有独立三方平台、可重复、低成本甚至免费触达用户的用户池”，“独立”“重复”“低成本”等特性其实都是“场”赋予的。所以私域是十分契合“人货场”理论的。

二、用户信息和账户信息的设计

与现实的商超，公域的购物平台不同，私域的“场”一般不负责物流、库存等的管理，更多是连接“人”和“货”，即把特定的商品或服务带给特定的人群。

上文提到，微信、WhatsApp等都是“场”，任何一个“人”在“场”中都是一个独立的个体，带有“场”所赋予的特性（如昵称、头像等）及唯一标识（如微信生态的Unionid、WhatsApp的手机号等）。而在“场”的作用下，人有了分身—“账户”。一个实实在在的人可以在同一个“场”中有多个账户（比如，一个人有多个微信），也可以在不同的“场”中有不同的账户（比如，一个人可以有微信，也可以有WhatsApp）。

根据“人”与“场”的相互作用关系，我们抽取出了两个私域产品的底层实体——“用户信息”“账户信息”，两者之间是1：N的关系。在这澄清一个大多数人犯的错误，很多产品同学一开始做私域，只做企微一个“场”，直接把微信昵称、头像、Unionid等属性归到了用户信息上，这是错误的，直接限制了产品的扩展性。

在这层结构中，“人”等同于“用户信息”，是一个实实在在的人，“场”赋予“人”的特征具化为了“账户信息”。userid与“场”中的唯一标识（Unionid、手机号、邮箱等）之间的关联关系组成了One ID的基本雏形（注意，不要误以为这就是One ID，远非这样）。

整个客户体系，在这两个实体上开枝散叶（本文只拆结构，不做扩展，用户行为属性、心理属性、标签等信息不在此赘述）。

这两个实体也是实现精细化营销、多矩阵产品营销的基石。

我们举例两个场景：

引流

1. 打电话确认客户意向；
2. 客户意向明确，挂电后短信发送加微短链；
3. 客户点击链接，按引导添加工作人员企微；

在这个场景中，涉及到了三个“场”，电话，短信，企微。要想衡量引流的效果，客户最终是否加微成功，就要知道手机号与Unionid（或external_userid）之间的关联关系——即One ID。

营销

1、客户主动打电话咨询课程情况——了解客户意图；

2、发表一条课程优惠名额仅剩2个的朋友圈——委婉逼单（一般不直接发消息，营销目的太强，客户反感）；

在这个场景中，涉及到了两个“场”，电话，企微。利用合适的时机，在不同“场”中自由切换进行营销，就要知道手机号与Unionid（或external_userid）之间的关联关系——即One ID。

“场”具有地域性，一般一个国家或地区用来做私域的“场”基本是固定的，比如我们中国主要是手机号、邮箱、微信、QQ等，美国主要是WhatsApp、Instagram，日本、中国台湾主要是Line，韩国是Kakao。如果要做国际业务，当然就会接入更多的“场”，但一个用户所在的“场”依然是有限的。

我们也有可能会自己造“场”，比如一家游戏公司会发售多款游戏，每个游戏就是一个“场”，在微信私域中做用户运营，尤其是大R玩家，一定要知道这个微信用户对应游戏中的哪个ID，才能点对点的提供服务，进行营销。

总之，在这套客户体系中，每个“场”中的用户都会成具化一个或多个“账户”，业务从单“场”运营扩展为多“场”运营，也只是在这个架构中插入一条账户数据而已，就向积木拼插一样简单易用。