在海王出海平台，查看每个工单的粉丝重复率通常在工单的“受众/受众分析”或“数据统计”模块；如果平台未直接提供该指标，可以导出工单对应的粉丝名单（user_id、手机号、邮箱或第三方ID），用去重与交集计算重复粉丝数，再用“重复粉丝数 ÷ 工单粉丝总数 × 100%”得到重复率。下面我会用通俗的语言与实操步骤（含SQL与Python示例）、去重规则与可视化建议，帮你在不同场景下快速落地并验证数据。
先讲清楚概念：什么是“粉丝重复率”
粉丝重复率通常指某个工单中，已经在其他工单中出现过的粉丝所占比例。简单来说，就是“这次分配/投放的人里，有多少是老面孔”。不同团队可能会有细微差别：有的把“重复”限定在同一活动周期内（如30天），有的统计历史所有工单。
常见的定义变体
- 跨工单历史重复率：粉丝在任意历史工单出现过，即视为重复。
- 时间窗口重复率：只统计过去N天内是否出现（常见N=7/30/90）。
- 同类活动重复率：只在同一campaign或同一产品线内判断重复。
在哪儿看：平台原生与自建两种路径
如果海王出海平台本身有完善的数据中心，通常你可以在以下位置直接查看或导出指标：
- 工单详情 → 受众/受众分析 → 粉丝重合/重复率
- 数据统计/数据大盘 → 工单分析 → 受众重合报表（支持按时间窗口筛选）
- 导出功能：工单详情页导出粉丝名单，再在本地/BI中计算重复率
但很多时候平台并没有直接暴露“重复率”这个指标，这时就需要按数据源自算，下面我把可落地的步骤讲清楚。
数据源与准备：你需要的几张表
要做精确计算，至少需要这些字段：
- 工单表（orders）：order_id、order_time、campaign_id（或工单类型）
- 粉丝/受众表（fans）：user_id、外部ID（open_id/unionid）、手机号/邮箱（或hash）、follow_time
- 工单-粉丝关联表（order_fans）：order_id、user_id、assign_time（或被触达时间）
如果没有order_fans表，要能把触达记录或投放日志与user_id关联起来才行。
标准计算逻辑（一步步解释）
- 明确“重复”的定义与时间窗口（历史全部/30天/同类活动）。
- 为每个工单列出其粉丝集合 S_order（基于user_id或最可靠的唯一标识）。
- 为目标时间窗口内的其他工单合并粉丝集合 S_others。
- 计算交集：重复粉丝数 = |S_order ∩ S_others|。
- 计算重复率 = 重复粉丝数 ÷ |S_order| × 100%。
示例：用SQL实现（假设存在order_fans表及orders表）
下面给出一个通用的SQL思路，适配大多数关系型数据库：
思路：先把每个工单对应的粉丝列出来，再判断该粉丝是否在指定时间窗口内出现在其他工单里。
示例SQL（Postgres/兼容SQL）：
WITH order_fans AS (
SELECT of.order_id, of.user_id, o.order_time
FROM order_fans of
JOIN orders o ON o.order_id = of.order_id
),
prior_occurrence AS (
SELECT of1.order_id, of1.user_id,
CASE WHEN EXISTS (
SELECT 1 FROM order_fans of2
JOIN orders o2 ON o2.order_id = of2.order_id
WHERE of2.user_id = of1.user_id
AND o2.order_time < of1.order_time
/* 如果需要时间窗口，把条件改成 o2.order_time >= of1.order_time – interval ’30 day’ */
) THEN 1 ELSE 0 END AS is_repeat
FROM order_fans of1
)
SELECT order_id,
COUNT(*) AS total_fans,
SUM(is_repeat) AS repeat_fans,
ROUND(SUM(is_repeat)::numeric / COUNT(*) * 100, 2) AS repeat_rate_percent
FROM prior_occurrence
GROUP BY order_id
ORDER BY order_id;
说明：上面用历史任意时间做判断；若想限定30天窗口，把注释里的条件打开并调整。
示例：用Python（pandas）处理小规模数据
若你从平台导出了CSV，可以用pandas快速算出每个工单的重复率：
主要步骤：
- 读入order_fans表（order_id、user_id、order_time）
- 按order_id分组，生成每个order的粉丝集合
- 对每个order，筛选出之前的记录（或窗口内的），计算交集大小
伪代码思路（不逐行列出所有代码，但给出关键点）：
- df = pd.read_csv(‘order_fans.csv’)
- df[‘order_time’] = pd.to_datetime(df[‘order_time’])
- for each order in df[‘order_id’].unique():
- cur_set = set(df[df.order_id==order].user_id)
- prior = df[df.order_time < cur_order_time] (或限定窗口)
- prior_set = set(prior.user_id)
- repeat = len(cur_set & prior_set)
- rate = repeat / len(cur_set)
去重规则与匹配策略（核心且容易出错的地方）
“重复”看似简单，实际有很多陷阱：
- 唯一标识优先：如果可以用user_id或unionid，那就是最可靠的去重依据。
- 手机号/邮箱/第三方ID：若用手机号或邮箱，先统一格式并Hash隐私后匹配。
- 跨设备或跨平台：同人不同id需要做设备指纹或ID映射，通常用概率匹配，但要谨慎，把误判率考虑进来。
- 匿名或未登录用户：无法唯一识别的记录应单独统计为“未知重复”，并在分母或分析中注明。
- 时间窗口选择：短窗口会把长期粉丝当做新粉，长期窗口会把近期新的用户视为重复。选择应与业务目标一致。
实际案例演示（文字版小例子）
想象有3个工单：
| order_id | fans(user_id) |
| A | 1,2,3,4 |
| B | 3,4,5 |
| C | 2,6 |
如果按历史全部计算：
- 工单A：无先前工单，重复率=0/4=0%
- 工单B：与A重合的粉丝有3、4，重复率=2/3≈66.67%
- 工单C：与A重合粉丝有2，重复率=1/2=50%
如何在BI或看板中展示（可视化建议）
常见的展示维度：
- 按工单列表显示：order_id、total_fans、repeat_fans、repeat_rate（%）
- 时间序列：展示重复率随时间变化（折线图）
- 分层分析：按渠道/国家/活动类型切分重复率
- 热力图或矩阵：展示工单间的粉丝重合度（pairwise overlap）
一个典型的数据表结构如下：
| order_id | total_fans | repeat_fans | repeat_rate(%) |
| A | 4000 | 1200 | 30.00 |
| B | 3200 | 800 | 25.00 |
常见问题与排查思路（实践中会遇到）
- 出现异常高的重复率：先检查去重字段是否被正确使用（比如意外用到了session_id），再看是否窗口设定不当或数据被重复写入。
- 重复率忽高忽低：可能是不同工单使用了不同的受众库（例如A工单用的是“全量粉丝”，B工单只用“活跃粉丝”），核对受众筛选条件。
- 数据缺失或匿名多：把“未知”类别单独呈现，不要把不确定数据随意计入分母或分子。
- 跨系统ID不同步：需要做ID映射或引入统一用户ID体系（UID），否则重复率会被低估。
落地建议与优先级（怎么样快捷实现并可复用）
- 优先级1——确定唯一标识：确认order_fans使用的是统一的user_id或hash后的手机号/邮箱。
- 优先级2——建立基础报表：用一条SQL或脚本每天计算每个工单的total/重复/重复率并写入报表表。
- 优先级3——设置时间窗口参数化：把30/90天等窗口做成可选参数，方便不同分析需求。
- 优先级4——上BI看板：把列表、趋势与工单间重合矩阵放在数据看板，供运营直观判断受众污染程度。
合规与隐私要点
处理手机号、邮箱等敏感信息时，务必遵守当地法律与平台政策：对敏感字段做Hash、脱敏存储，日志访问加权限控制，导出时警惕泄露风险。
如果你现在想立刻查看某个工单的重复率：先去工单详情找“受众/数据分析”模块；找不到的话，导出工单粉丝表并按上面SQL或Python步骤计算。过程中遇到的具体字段名或接口路径会因为不同系统而异，但思路是一致的。接下来你可以按需把这个脚本定时化，或把结果推到BI看板，实现自动化监控。
