Akke / 专题 · 识别有效用户

识别有效用户 — 触达候选主页画像过滤

需求方案 · 提交人 饭粒 · 2026-06-05 · ✅ 已部署生产(PR #132 merged · 2026-06-06 · worker v241)· 回测 3/3
① 口径② 现状诊断③ 已实现的 5 道检查④ 回测⑤ 验收时间表⑥ 边界与风险⑦ Out of Scope
01做什么 · 口径

号源筛出来的触达候选要更精准——尽可能排除同行(全屋定制 / 装修 / 装饰),以及卖设计、卖灯具、卖瓷砖的商家号,不把 DM 配额浪费在无效用户上。

为什么现在拦不住?实战案例:B嗯嗯(广东)
评论「我需要装修,怎么联系你?」→ 意向 85 分 + 标「强买家信号·联系方式」→ 做成案例页准备交销售加微 → 后发现她做灯具。昵称干净 + 满分买家话术,两道文本过滤全漏;身份只暴露在主页里。

引流号(主动塞微信)、跨行业 B2B 不在本期口径内(PM 已拍板收窄)。

02现状诊断 · 过滤链路 3 层,洞在「主页画像」
现状能不能拦「卖灯具的」
1. 文本 gate
peer-filter.ts
昵称(已含「灯具店」「建材」等 ~60 词)+ 评论内容套话,analyze 投 LLM 前生效部分 只拦昵称暴露身份的
2. LLM 意向分打的是评论文本拦不住 同行会写满分买家话术
3. 发送前人工看主页写在拉单流程 step 2,纯靠人自觉最可靠但不自动 无沉淀、会漏
核心洞:身份藏在「主页简介(signature)/ 主页视频」里,而现有文本 gate 只扫昵称+评论,不扫 signature。评论入库时也没存 signature——「免费扫」不存在,必须补拉主页,区别只在拉多少。
03已上线的 5 道检查(PR #132 已 merge · src/lib/lead-validity.ts 两个拉单入口共用)
检查怎么判成本强度
1. 主页画像signature / 认证主体 / 昵称重扫同行词(室内装修/灯饰/照明/瓷砖…)export 入口复用本来就拉的 profile 请求零新增;claim-leads 补拉 ~30-60 次/天
2. 签名挂微信签名里挂自己微信 = 引流/卖家(归一化破「我的_微__信__是_xxx」打散伎俩)。真买家是问微信,不会把自己微信挂签名零(同一次请求)
3. 主页视频墙主页视频标题 ≥2 条命中同行词且占比 ≥40%(满屏「全屋定制案例」);业主记录自家装修只发 1-2 条,单条不定性零(lead_profiles 已存主页视频标题,纯 DB)中强
4. 跨视频同文同一用户把一模一样的评论刷到 ≥3 个视频下 = 收割/引流;2 个视频或短文案("多少钱一平"类)只告警不杀——真买家比价场景零(库里本来就存全量评论,纯 DB)
5. 认证主体透出worker 新增返回企业认证("XX灯饰有限公司")/自定义认证("优质房产领域创作者"),并入检查 1零(同一次请求 +2 字段)

拉单流程(判无效 → 沉淀「无关」+ 释放 claim,全员永久出池,防同事重复拉到同一卖家):

RPC 拉候选
5 道有效性检查
主页画像/挂微信/视频墙/同文/认证
命中 → 沉淀「无关」+ 释放 claim
报告逐条列原因
干净名单交给运营
不够提示再跑一次补拉
设计变化 vs 06-05 方案:① 视频标题画像原计划留 V2——实现时发现 lead_profiles.raw_videos 基建已存在,零成本提前落地;② 不做 1.5× 超额拉取——gate 剔除后实拿不足时「再跑一次」更简单;③ analyze 全量的问题天然消失(6/4 起 analyze 只打分,主页拉取本来就在 claim 时)。
04回测 · 3 个已知漏网案例全拦住(真实 DB + 真实接口,2026-06-06)
案例当时怎么漏的现在哪道拦住
B嗯嗯(卖灯具)昵称干净 + 满分买家话术,两道文本过滤全漏双杀 跨视频同文(同句刷 3 个视频)+ 签名挂微信(签名=「我的_微__信__是_chengxinjiuwu」,下划线打散「微信」躲关键词,归一化后命中)
谢大叔→聊房(房产创作者)旧词表无「聊房」拦截 昵称:聊房(文本层 + 画像层都拦)
太湖美景昵称无信号,身份在简介拦截 签名:室内装修
「跨视频同文」这条检查直接命中实战:B嗯嗯那句「我需要装修,怎么联系你?」在库里刷了 3 个不同视频——这道检查是全部信号里最便宜的(零抖音请求,纯数据库查询),却独立拦住了最难的案例。
05验收时间表 · 基线 → 回测 ✅ → 复测
✅ 2026-06-06
代码 + 回测 3/3 + 已 merge 部署生产(D0 = 2026-06-06)
CI 全绿 → squash merge → worker v241 部署 → /api/status 与 /health 均跑在 c247aee,新认证字段运行时验证返回正常。gate 已对所有新拉单生效
🟡 D0 机器普查完成 · 待人工确认
基线:全历史已触达 845 人机器普查(原计划抽 100 → 应 PM 要求两次扩样 → 全历史普查,无抽样误差)+ 人工确认 = 改造前无效率 X%
6/6 完成:有史以来真发出过私信的 845 人(= 806 条评论标过 contacted 去重 + 39 个只在 lead_claims 盖章 consumed 的;后者顺带暴露 mark 链路小缺口——claim 已消耗但评论没标 contacted),全部现场拉主页跑改造后 gate 画像层(只统计、不回写历史)。结果:机器标红 23 人(2.7%)——16 签名露馅(工厂/五金/家具/建材/软装/设计师/定制…)+ 4 签名挂微信 + 3 昵称露馅,AI 当时全给 78-100 高分;回测样本「B嗯嗯」「谢大叔→聊房」也被全量扫描原地抓出(gate 自洽 ✅)。拉取失败 0(中途 18% 失败系连发节流,降 1 并发重试全恢复——实战包络:30-60 次/天没事,连发数百次要降速)。待人工:① 逐条确认 23 条标红真假(「加加💋」类签名:公司可能误伤)② 从 822 条干净堆随机抽 30-50 条量机器漏检率,两数合出 X%。复核页 data/baseline/d0-annotation-20260606.html
2026-06-13
复测:抽 100 条新流程已触达 leads 人工复核,同行/卖货占比 ≤5% → 验收
与基线对比,给领导的就是「X% → ≤5%」这组数字
06边界 case 与风险(已按此实现)
情况处理
signature 为空(大量用户不写简介)放行,不误伤;空字段只跳过该项检查
主页接口失败 / 超时放行 + 拉单报告显式列出「N 条主页拉取失败」,不静默跳过也不断拉单
signature 含「装修」但属业主语境("正在装修中")不收单字「装修」,只收「室内装修 / 全案设计」等完整形态
同文刷 2 个视频 / 文案 <6 字("多少钱一平"类)只告警不硬杀——真买家比价可能在 2-3 条视频下问同样的话
主页视频单条命中同行词不定性(业主记录自家装修);要 ≥2 条且占比 ≥40% 才判
被 discard 的候选 claim 锁主动释放(status='expired');释放失败也无碍,4h 自然过期
gate 剔除后实拿 < 请求数脚本如实报「实拿 M/N,再跑一次补拉」,不做超额拉取

风险:worker 主页接口走 sec_user_id 路径,回测 3 个真实 sec_uid 全部拉回成功;但未大批量验证海外出口反爬表现——上线后观察拉取失败率(报告里有显式计数),失败率高退回本机拉取兜底。

历史数据:不回填、不清理已触达历史(低影响又烧钱);只对 merge 后新拉单生效,基线抽样仅作统计。

07Out of Scope(本期不做)
✅ 已提前落地 · 6/6 补修供给
主页视频标题画像
代码并入本期(检查 3)。6/6 实测发现 lead_profiles 全表 0 行空转:唯一 enqueue 点 analyze-once 无 cron 调度从未运行,且 scrape_jobs 的 job_type 白名单根本不认 scrape_lead_profile(5/06 migration 漏改,插入必报 23514)。已修:migration 扩白名单(已 apply prod)+ claim 时补 enqueue(PR #136,已 merge 部署);端到端验证 worker 抓回 video_count=5
💬 大白话:「看他主页发过什么视频来判断是不是同行」原计划下期做,结果发现存主页数据的基建早就有,就提前并进本期。但 6/6 一查,这张存画像的表从建好到现在一直是空的——给它喂数据的流水线有两个故障:① 定时任务压根没排上日程,从来没跑过;② 数据库门卫的「工单类型白名单」不认这种工单,一提交就被拒。两处都已修好,现在改成「每次拉单时顺手下工单去抓对方主页」,并实际验证抓回了数据。
天然消失 · 有副作用
analyze 全量拉主页
6/4 起 analyze 只打分——但 analyze-once 退役也带走了 lead_profiles 的唯一供给源(当时没发现,因为白名单 bug 让它本来也没跑通过)。6/6 起供给改挂在 claim 时(PR #136,已 merge 部署)
💬 大白话:判断评论的人是不是同行/卖货商家,最准的办法 = 点开他的抖音主页看(签名/认证/发过的视频),即「查户口」。问题是放在哪一步查:

做法 A · 来一条评论查一次(全量):每天 ~5,400 次主页请求(日均打分评论量,6/7 实测)→ 抖音判定爬虫、封号封 IP;且查的人里 95%+ 根本不会被发私信(每天真发 DM 仅 20-30 条),白查。
做法 B · 发私信前才查(✅ 现行,PR #136 起):运营拉单选出今天要发的 30-60 人时才查这几十人 → 量缩 ~100 倍抖音无感,且查谁都是马上要花 DM 配额的,一次不浪费。像机场安检放在登机口查真要上飞机的,而不是全城每个路口查所有人。

历史背景翻译:「6/4 起 analyze 只打分」= 以前打分机器人还兼职查户口,6/4 起兼职取消,做法 A 自动不存在;副作用是取消兼职时没人发现「存户口档案的柜子」唯一进货渠道也被一起砍了(柜子一直是空的没人察觉),6/6 发现后修好,改成做法 B 顺路进货。
✅ 已提前落地 · 6/7 已部署生产
反评(RC)通道 profile gate
RC 候选已用新词表(文本层自动生效);主页画像层 6/7 已接并上线(PR #145 merged,production=d29e835,/api/status 确认):pickCandidates 文本过滤幸存者拉主页过 isPeerProfile + isPeerVideoWall,命中沉淀「无关」,fail-open。RC pick 每天 09:00 一跑、拉取量在反爬包络内。6/8 首跑验证 ✅:picked 47 → kept 47(剔 0),队列写入比 cron 启动晚 64s = 47 次主页拉取的真实耗时(纯 DB 路径只要 2-5s),证明 gate 在拉;本机用同一套函数独立复核当天 47 人——0 同行、0 拉取失败,剔 0 是「候选真干净」不是 gate 空转
💬 大白话:我们触达用户有两条路:发私信(DM)和去他评论下面回一条(反评/RC)。「查户口」防同行这套关卡,私信这条路已经装齐了两道门(① 看昵称/评论文字 ② 点开主页看签名认证),反评这条路原来只装了第一道门。6/7 把第二道门也装上并发布上线了——反评每天只挑一二十个人,挨个点开主页看一眼完全花得起。两条路现在同一套门、同一份黑名单:任何一条路认出的卖家,另一条路也不会再碰。解决的问题:昵称干净、评论装得像真客户的卖家(基线普查实测占已触达的 2.7%),文字上看不出来,过去会害我们跑到同行视频底下公开搭话——白费配额还被同行看光。效果:杜绝这种翻车,约每 2-3 天拦下一个漏网卖家,黑名单两条路共享。
V2 看数据 · 6/6 已测
无画像用户实时拉主页视频
6/6 实测:近 14d 高/中意向 5536 个用户覆盖率 0%(供给管线从未运行)。PR #136(已 merge)接通后画像随拉单逐日积累(~30-60 工单/天),是否还需实时补拉等积累 1-2 周再看
💬 大白话:五道检查里有一道是「看他主页都发过什么视频」——满屏全是定制柜安装/灯具出货的,八成是卖家。这道检查不当场去翻他主页,而是翻我们自己的档案柜(之前存好的记录)。6/6 发现档案柜是空的(进货渠道坏了,当天已修好),所以这道检查暂时形同虚设,但另外四道(签名/认证/挂微信/刷屏)不受影响、照常拦人。档案现在每天随拉单自动攒 30-60 份,越攒越全。剩下一个小决策:碰到没档案的人,要不要当场去翻一次他主页?——先攒 1-2 周,看看有档案的人占比多少再定,不急。