Adobe DMP的一些设计

一直挺喜欢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)

Estimated Total Population (Potential)

Real-Time Population (Existing)

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的核心模块研发。