一直挺喜欢Adobe的产品，因为Adobe的产品敢于面对复杂，勇于解决一些极致的问题：例如PhotoShop解决极致的画笔问题，Premier解决复杂无比的视频编辑问题。
Adobe Audience Manager(AAM)是Adobe的DMP产品，解决Audience管理的问题。东野圭吾曾说过”比侦探小说情节更加复杂的就是人心”，看看Adobe的AAM如何管理复杂的人。
AAM相比其它公司产品DMP，功能更加强大和复杂。本文介绍其产品设计的一些概念和逻辑，看看AAM如何抽象和分解问题，并且将这些解决方案设计成产品，规模化解决客户的受众管理核心问题。问题如下：
1. 标签和人群概念
2.设备打通的设计
3.人群的算法模型
4.产品的架构设计
5 产品的发展阶段
第一部分， 人：信号(Signal) ，特征(Trait)，人群（Segment)
AAM就是管理一些五花八门，林林总总的各种标识（设备号，Cookie号，会员号等等）的各种属性，这些数据的来源也是各式各样的。如何统一这些管理呢？ AAM引入了三个概念信号（Signal),特征(Trait),和人群(Segment)。
a) Signal: 信息的最小单位，事件或数据中某个字段，例如流量参数中带有 "Product=camera"
b）Trait :Signal的表达式组合，Trait支持层级管理，还支持由算法自动生成的特征，支持有效时间(TTL)
c) Segment:Trait的表达式组合
Segment与Trait :
Segment和Trait是最容易造成混淆的，AAM提供了一个Trait和Segment进行比较的工具，支持查看相互的覆盖率。
Segment大小的实时预估：
其中包括非常多的细节设计，详见下面表格。
类型 解释Estimated Real-Time Population (Potential)
(预估) 曾经满足过Segment中Trait条件(不限时间），最近30天出现过的人Estimated Total Population (Potential)
预估总人数（只是预估值，并非实际发生值）Real-Time Population (Existing)
(实际值）曾经满足过Segment中Trait条件(不限时间），最近30天出现过的人Total Population (Existing)
(实际值）昨天满足Segment的人数
第二部分 Profile Merge /Device Graph
画像合并/设备打通是很多业务场景需要的，技术上的复杂度也比较高，隐私管理也很复杂。例如，以下问题都是设计难点。
设备打通/关联包括确定性关联和概论性关联，如何协调二者。
设备打通/关联后可能是一个人，也可能是一个家庭
设备打通的数据隐私也存在诸多考虑，如何处理用户信息和匿名信息的关联
总之，打通很美好，技术很复杂，应用在摸索。
对于这么复杂的问题，AAM如何支持这个问题呢？
答案就是是一切从简：事不过三！
支持最多3个自定义的打通规则
每个标识后面最多打通3个额外的标识
AAM的Profile Merge/Device Graph主要解决的是登陆用户的信息（例如会员信息），如何与匿名登陆的ID进行有效关联的问题。为了规避隐私问题，AAM不允许用户上载PII信息作为用户ID，如果需要上载，必须使用单向加密后方能上载。
以下就是设备打通规则的创建界面，有些复杂，我先解释解释：
认证选项(Authendicated Options)
选择是否需要关联登陆用户信息与设备信息
不收集
对于登陆用户，可以读写画像
匿名用户，可读最后一次；登陆用户，可写画像
选择最多三个数据源，关联登陆用户画像的数据源
设备选项（Device Options)
AAM不使用匿名画像的任何Traits (No Device Profile)
AAM可以使用匿名画像，以匹配Segement (Current Device Profile)
AAM可以读取最后三个登陆设备画像（Profile Link Device Graph)
Co-Op Device Graph: Co-op是Adobe的产品，参与客户可以上传设备关联图，合作形成更大更可靠的设备关联图，参与客户也可以集体获益。
支持第三方供应商：Third-Party Device Graph Options
AAM的设计有点绕口，我简化一下它的设计逻辑如下：
最后结果就是，一个设备ID/会员ID，它的后面可能带有最多3个其他标识（如设备）。这种能力会影响很多其他功能，例如人群大小预估，实际人群推送，关联的解开等等复杂操作。
第三部分.人群的算法模型
AAM的核心能力是创建人群，算法模型(Algorithm Models)也是创建人群的一种技术。相比手动指定各种规则，算法模型是通过数据源自动学习相关的特征，建立相关的人群模型。
一些好处如下：
支持规模化：手动制定比较麻烦，规则一旦多了，不容易维护；算法模型可以简化整个过程，自动化。
发现隐形特征：有些特征是关联特征，不容易区分，有些隐形特征，人比较难看出来，而算法比较容易处理。
离线评估：AAM支持离线的一些评估方式，可以离线评估模型的覆盖率和精准性。
创建算法模型的流程也非常直接：
对所有用户的历史特征(Trait)建立索引，包括30天，60天和90天。
对选中数据源的用户进行特征筛选，找出一些显著的特征，这些特征将区别于大盘的特征，而又能代表这些人群特征。
计算每一个显著特征的权重
对选中数据源的用户进行打分，并且将分数规则化
在Trait Builder中展现结果，通过阈值的设定，平衡准确性和覆盖率。
定期的数据处理和模型优化
第四部分 AAM产品设计发展的路
2015：
完善 Audience Marketplace
完善数据收集DCS的API和工具
完善各种报表
2016
完善各种API，包括权限等
推出Audience Lab，进行人群实验
支持公有云的数据传输
支持算法模型（Algorithm Model)
2017
增强Signal , Trail ,Segment的工具，性能
支持创意的测试
Audience Lab支持更多场景，包括模型生成和比较
2018
支持Data Explorer，集中式数据管理
Audience Lab增强测试能力
GDPR相关的支持
增强数据集成API ( Data Integration Library, DIL)
从以上的产品特征发布历史，我们可以看出AAM不断完善数据收集，处理和分析的各个细节，让工具更加实用和好用；另外，算法模型和实验能力也在不断加强，更加面向数据分析师和数据科学家。AAM定位还是在解决平台型的工具问题。
第五部分 AAM的系统架构
Adobe的帮助文档中有专门介绍系统架构的，架构很简洁，技术选型很务实。
系统组件包括数据收集，Tag管理，数据处理，数据推送(Action)。
数据收集：数据收集服务器(DCS)，全球服务器负载均衡器(GSLB), 画像缓存服务器(Profile Cache Servers），主要是人和Trait的关系。
数据处理：Hadoop系统：主要包括Hive支持数据仓库， HBase支持导入/导出元数据，trait规则，算法模型信息，管理功能等。Snowflake ，基于云的数据仓库，支持丰富的仪表盘等。SOLR：用于Segment大小的预估计算，主要利用SOLR的倒排表，快速获得预估人群大小。Tableau:用于交互报表和自定义报表的构建。
Tag管理：此处的Tag指的是各种客户端代码的生成，用于管理各种事件的上报等。数据集成库(DIL)：用于客户端的SDK库。 Akamai：发布和部署tag管理代码，类似于CDN功能。
数据推送: 用于客户数据的收集和推送，包括各种不同类型的数据交换，例如SFTP/S3/HTTP等。IRIS支持流式事件的数据传输。
AAM的系统架构图：
（点击可放大）
1.从系统架构图看出来，AAM利用了很多Amazon AWS的很多PaaS服务
S3: 用于广泛的云存储
Aurora：分布式的关系型数据库，支持OLTP用于事务性数据库操作
Redshift : 高效的数据仓库，数据源来自于Hadoop的很多运算结果
2.AAM积极利用各种开源/商业化工具解决各个核心模块的扩展性问题。
SOLR: 解决Segment预估的问题
Tableau: 解决自定义报表和交互问题
Snowflake: 高效的云端数据仓库，用于定时的报表报告。
小结
我们在设计产品和技术架构时，也会面临很多复杂性，参考AAM的一些设计，我有几点收获，与大家一起分享：
聚焦在核心问题的持续优化上
核心模型应该大道至简，例如 Signal, Trait ,Segment的设计
开放而简单的架构，如无必要，勿造轮子，拥抱云技术。
主要参考资料：https://marketing.adobe.com/reso ... aam/c_aam_home.html
作者介绍：
欧阳辰，品友互动，CTO，《Druid实时大数据分析》书作者，《构建高质量的软件》译者，超过17年的互联网老兵。曾任小米商业产品部 研发总监，实现从0到1的广告和大数据平台建设；曾任微软研发经理，负责微软移动Contexual Ads广告平台，参与Bing搜索引擎IndexServe的核心模块研发。
| 欢迎光临 168大数据 (http://bi168.cn/) | Powered by Discuz! X3.2 |