微拍堂：推广 / ROI / 增长平台

一、项目定性

这条线最容易被讲浅。你不要讲成：

我做过广告平台对接。

更好的定性是：

我做过广告增长和 ROI 数据链路系统，覆盖原始曝光点击事件、激活归因、行为回传、LTV 回传、广告管理后台、报表分析、优化助手、动态落地页和部分 DMP / 推荐能力。

这条线是你打 Go、分层架构、高并发、数据链路、微服务和解决方案能力的关键项目。

二、对应项目与代码线索

这条线对应的内部项目主要包括：

lizard：广告系统 PHP 项目
lizard-go：广告系统 Go 项目
collect：ROI PHP 项目
go-roi：ROI Go 项目
qingzhu-ad：青竹广告推荐 / 扣费 / 业务剥离
wpt-marketing-api-sdk：第三方广告平台接口 SDK

这些仓库名不适合直接放简历里，但适合你自己做项目备忘和面试准备。

三、你可以如实表述的角色

可以如实表述为：

参与广告增长和 ROI 相关系统后端研发
既做过 PHP 侧后台和规则配置，也做过 Go 侧实时链路和消费者
参与高并发数据链路、报表分析和业务后台的设计与治理
参与现网服务、资源和存储方案梳理

如果被问得更细，可以说：

我在这条线里更偏后端解决方案和数据链路落地，重点做过实时回传、事件采集、广告管理后台、优化助手、报表分析和 Go 消费者相关能力。

四、详细功能点清单

1. 广告数据接入与事件链路

收集广告商下发的点击数据
收集前端上报的动态落地页数据
曝光、点击、激活、注册、登录、支付等事件处理
用户设备、UA、Cookie、广告参数清洗
行为数据与用户标签使用

你可以讲的场景

广告平台点击到达监测地址
原始数据清洗
后续激活归因和行为回传
数据流向 BI / 报表 / 回传系统

2. ROI / 归因 / 回传

激活归因
设备匹配
IP + OS 兜底匹配
注册 / 登录 / 支付行为回传
高价值用户回传
LTV 回传
虚拟回传
回传失败重试
配置化回传规则

你可以讲的重点

不是只接一个平台，而是把点击、激活、行为、回传整条链路打通
高价值和虚拟回传说明你们做过真实投放优化支撑

3. 广告管理后台

广告账户层级
广告计划层级
广告组层级
广告创意层级
账户详情看板
广告操作记录
广告管理后台业务梳理
废弃功能梳理与治理

你可以讲的重点

这不是“只做回传接口”，还有完整后台系统
业务规则、层级、配置和数据回流都要打通

4. 优化助手 / 报表分析

优化助手
广告数据列表
报表聚合分析
多维筛选、聚合、排序
大数据量统计查询
广告操作记录查询

你可以讲的重点

这是 ClickHouse 的核心落地场景
不只是查询快，更是把分析压力从业务主库剥离出去

5. 动态落地页 / 埋点链路

动态落地页埋点数据
前端上报进入 Kafka
后续消费与统计
相关数据写入 ES

你可以讲的重点

这条链路最适合解释为什么需要 Kafka
也很适合讲 ES 不是主库，而是承接查询和埋点分析

6. DMP / 标签 / 推荐 / 扣费

DMP-go
人群标签
推荐 / 扣费逻辑剥离
实时标签与投放支撑
青竹广告相关业务

你可以讲的重点

这条线说明你不是只做广告后台，也接过推荐和数据层能力

7. 自动管理 / 广告管家 / 自动化创建

广告管家
自动管理
自动化投放能力
执行型异步流程

你可以讲的重点

这类功能更像执行引擎，不适合全放在同步 PHP 流程里

五、技术架构分层与为什么这么选

这条线非常适合你回答“为什么用这些技术，而不是别的”。

1. MySQL

承接：

账户
计划
规则
配置
后台业务主数据

为什么：

强关系
强事务
业务状态清晰

2. MongoDB

承接：

ROI 业务原始数据
点击、激活、用户行为、回传记录
三方原始曝光 / 点击事件

为什么：

写入频率高
数据量大
字段结构相对灵活
更适合作为原始事件承接层

你可以直接讲：

MongoDB 在这里不是业务主库，而是原始事件层。

3. Kafka

承接：

点击数据流转
落地页埋点数据
行为事件异步消费
高峰期解耦和削峰

为什么：

主流程不能被长链路拖死
需要重试、积压处理、消费扩展
适合解耦生产与消费

4. ClickHouse

承接：

优化助手
广告报表
大数据量聚合查询

为什么：

这是分析型查询，不是事务型查询
多维聚合、排序、报表不适合长期压在 MySQL 上

5. Elasticsearch

承接：

动态落地页埋点数据查询
定向数据
检索类场景

为什么：

检索和部分分析适合 ES
不作为业务主库

6. Go

承接：

实时链路
消费者
批量同步
高并发处理
部分执行型服务

为什么：

更适合常驻服务
并发模型自然
更适合消费者和高吞吐处理

7. PHP

承接：

广告后台
规则配置
计划管理
业务逻辑

为什么：

业务规则复杂
变化快
协作密集

最适合你的一句话

这条线不是 PHP 不够才上 Go，而是业务层和数据链路层天然就适合分层，PHP 做后台和规则，Go 做实时链路和高并发处理。

六、现网规模与高并发证据

你这里有一组很适合面试里讲的现网资源信息：

lizard-php：2 台 8 核 16G
lizard-go：HTTP 服务 2 个 pod，ctl 服务 1 个 pod
roi-php：4 台 4 核 16G
roi-go：
点击数据 ctl 服务 3 个 pod
行为数据 ctl 服务 2 个 pod
HTTP 服务 2 个 pod
ckafka：
峰值带宽 300MB/s
磁盘容量 6000GB
MongoDB：
3 节点
24 核 64G
1.5T
ClickHouse：20.3
ES：3 台 8 核 16G

这些数据面试怎么用

你不需要背全部配置，但可以讲：

这是有明确现网规模和分服务部署的系统
不是单机玩具项目
Go 服务已经按消费者和 HTTP 服务拆过 pod

七、最值得讲的难点与解决方式

1. 原始事件链路长，问题定位不能只看单点

常见问题

点击数据丢失
曝光 / 点击进来了但后面没有激活
回传失败
报表对不上

你可以讲的解决方式

按链路分层排查
原始事件层
Kafka
消费者
回传规则
报表分析层
关键节点补日志、告警、重试
做幂等与唯一键设计
让数据链路可追踪、可重放、可修正

面试能展示什么

你不是只修单个接口
你能治理整条数据链路

2. 为什么要把部分能力从 PHP 迁到 Go

难点

并发高
脚本耗时长
批量处理重
长链路服务不适合继续堆在 PHP 里

可讲方案

将实时消费、批量同步、回传、行为链路拆到 Go
PHP 保持后台和规则逻辑
Go 承接高并发和长生命周期服务

面试能展示什么

你不是为用 Go 而用 Go
你会按场景拆服务边界

3. 为什么报表从 MySQL 拆到 ClickHouse

难点

数据量大
多维聚合多
排序筛选复杂
长期压主库成本高

可讲方案

MySQL 保留业务主数据和状态
ClickHouse 承接优化助手和报表分析
分析压力与事务压力分离

面试能展示什么

你懂 OLTP 和 OLAP 的边界
你会做存储分层

4. 为什么原始事件放 MongoDB

难点

写入量大
字段变化快
主要用途是留存和后续加工，不是强事务

可讲方案

原始点击 / 曝光 / 行为记录先落 MongoDB
后续清洗、归因、回传、报表再分层处理

面试能展示什么

你懂不同数据类型适合什么存储

八、这条线最能展示你的标签

Go 高并发和消费者实践
数据链路设计能力
Kafka / MongoDB / ClickHouse / MySQL 分层
广告增长和 ROI 业务理解
后台 + 实时链路双栈能力
高并发场景的治理与排障

九、这条线怎么讲最稳

一句话版

我做过的不是单一广告接口，而是一套广告增长和 ROI 数据链路系统，从原始点击曝光事件、激活归因、行为回传，到后台管理、报表分析和高并发消费者都有参与。

两分钟版提纲

这是完整增长系统，不是平台对接
你负责后台、实时链路和部分 Go 消费者能力
技术上做了明显分层

MySQL：业务主数据
MongoDB：原始事件
Kafka：解耦
ClickHouse：分析
Go：消费者和实时链路
PHP：后台和规则

重点问题是数据丢失、回传异常、报表一致性、高峰期吞吐
你通过分层、幂等、重试、告警和可观测性把系统做稳

十、如实表达时的边界

这条线你可以讲深，但不要夸成：

我一个人搭了整个广告平台
我是公司广告架构负责人

更稳的表达是：

我在这条线里负责核心后端能力和数据链路相关模块
我对这套系统的核心业务和技术分层理解比较深
我强项是把高并发链路、后台业务和报表分析真正落到线上