SA技术架构串讲思路

“客户需求决定产品设计，产品设计决定技术选型”

私有化部署:数据安全、数据资产、数据二次开发

用户行为分析：活跃情况、频次分布、核心流程转化等

全端数据采集：iOS、安卓、Web、H5、微信、业务数据等

灵活多维分析：地域、品类、年龄、渠道等

秒级导入和查询：每天十亿级别数据量的数据实效性

why

全埋点：浏览、点击、启动、退出等，范围广、颗粒粗

可视化埋点：基于全埋点，使用成本低，管理成本高

代码埋点：开发成本高，依赖应用发版，灵活颗粒细

客户端埋点

DebugConsumer：校验导入数据，方便开发调试

ConcurrentLoggingConsumer：输出指定路径，按天切割，结合logagent

BatchConsumer:批量发送，不抛异常，丢失风险

服务端埋点

SDK

优劣势、最佳实践、上报机制、采集方案

优劣势、使用场景

LogAgent ：读取日志，校验数据，数据不丢不漏

FormatImporter：常见格式数据的导入

BatchImport：符合神策格式，写入kafka

HDFSImporter：符合神策格式，写入HDFS

Logstash+Filebeat

导入工具

数据接入

使用场景、格式要求、接收组件、部署位置

Nginx：高并发下状态下的连接及数据上传 ➡️ access.log

edge：处理（数据解密）并分发实时数据，给下游组件使用

SDG：数据校验、预处理、IP解析

数据接收

Kafka：接收并持久化数据，允许订阅Topic

数据中转

数据传输

对外接口、保存时间、安全性

保存时间、功能原理、开放性

Extractor：渠道追踪、用户关联、首日首次

DataLoader：Stream模式、Batch模式

数据导入

kudu：低延迟写入高性能分析的存储系统

HDFS：分布式文件存储系统

数据存储

数据建模/存储

组件演进、性能、可用性

存储格式、存储内容、转换方式、性能、可用性、安全性、开放性

QueryEngine：将数据查询请求，翻译成优化后的 SQL 交付执⾏

查询引擎

数据查询

缓存策略、灵活性、及时性、实效性

WebSever：用来承载供用户使用的可视化分析页面

数据可视化

数据架构

why：采集用户行为，数据来自设备，如何通过设备采集的数据来定位后面真实主题的行为，是用户关联的意义

场景：小明下载APP ➡️ 浏览课程介绍➡️注册和登录➡️购买课程

浏览课程：用来标识用户的是设备ID（未登录）

购买课程：用户完成注册登录后发生的业务行为，标识用户的是用户ID，即登录ID

事件拆解：

问题：如果设备ID没有和用户ID打通，就无法关联分析，ID- Mapping解决了这一问题

举例

Android：默认使用AndroidID > UUID

IOS：默认使用IDFA > IDFV > UUID 

Web：Cookie_ID(清理缓存或切换浏览器会变化)

小程序：默认使用UUID，删除会变，建议使用open ID

设备ID

业务数据库里的主键或其他唯一标识

登录ID

1.只使用设备ID

2.设备ID关联登录ID（1对1）

3.设备ID关联登录ID（1对多）

方案

用户关联(ID Mapping)

what：网站或者APP在平台上投放了广告，想知道每天访问的用户情况，对新增用户的指标进行更加深入的分析

What：在某个渠道投放的是H5/Web的落地页，想知道该渠道带来的落地页的流量数据，就可以使用神策的Web渠道追踪

原理：拿到原本的落地页URL链接，神策进行二次加工，加上utm参数，提供给渠道方，当用户通过渠道方进入到落地页当中，由于事前已经在落地页中加载了SDK，会自动将utm相关属性加到pageview事件的属性当中

1.神策平台生成 web 推广链接，分别是 web 长链、web 短链、二维码

2.在第三方渠道投放神策生成的推广链接

3.用户在第三方平台点击推广链接，触发渠道链接触达事件 （$ChannelLinkReaching）

4.推广链接跳转至推广页面，触发 web 浏览事件，且挂上广告系列参数 utm_XXX 并且同时写入用户属性 首次系列广告参数（ utm_XXX )

web 通用渠道推广

Web渠道追踪

App模糊渠道追踪（App外推广）

App精准渠道追踪（App内推广）

App渠道包渠道追踪（应用市场推广）

APP渠道追踪

渠道追踪

SA技术串讲思路

为什么要做这款产品，技术选型的思路

关联逻辑、涉及哪些埋点接口、数据存储、技术组件

归因逻辑、使用场景、优缺点