买家真实性验证 · 短链方案

591 在屋主委托链路上做媒合：屋主提交委托 → 平台分发给中介 → 中介带看、回报。买家只出现在中介的回报里，平台手上没有任何独立信息可以核对。中介回报「本周带看 5 组」，这个 5 目前是纯声明。

中介不会把买家电话交给平台 —— 那是他的客户资源，也涉及个资。所以方案的输入只有：中介提交的买家条目（自填标识）+ 一条平台生成的短链。

产出的核心指标

条形为示意比例，实际分布待灰度数据。中介评级、线索分发若要用带看量，应该用 effective_count 而不是 claimed_count。

买家为什么会点

中介转发的东西，买家点开率取决于对买家有没有用。落地页应该是一个买家本来就想看的页面，采集是副产品：

• 房源完整资料页：带看后中介本来就要发资料给买家 —— 把这个动作变成发短链，中介有动机用
• 实价登录 + 周边行情：591 的强项，买家真的会看
• 看屋纪录卡：这次看的是哪间、几坪、开价多少，方便买家比较多间

关键 让中介有动机转发，比让买家有动机点击更重要 —— 中介不转发，这条链路根本不启动。所以短链必须做成「中介本来就要做的事」的更好版本，不能是额外负担。

3.1 URL 形态

https://591.tw/v/{token}          # 验证短链
https://591.tw/v/aK9x2Qm4f7Bd     # 示例，12 字符

3.2 token 构造：随机 + HMAC 校验位，不自解释

token = base62(random_48bit)  ||  base62(HMAC-SHA256(secret, random)[0:3])
         └── 8 字符，2.8e14 空间 ──┘     └──── 4 字符校验位 ────┘

长度 12。服务端先本地验校验位，不通过直接 404，不查库。

3.3 映射表

短链不携带任何语义，映射全放服务端，可随时撤销、改绑、加限制。

-- 短链主表：token → (中介, 买家条目, 房源, 委托)
CREATE TABLE verify_link (
  token         CHAR(12)     PRIMARY KEY,   -- 随机 + HMAC，不可枚举
  entrust_id    BIGINT       NOT NULL,      -- 委托单
  property_id   BIGINT       NOT NULL,      -- 房源
  agent_id      BIGINT       NOT NULL,      -- 中介：结果归因到他
  buyer_ref_id  BIGINT       NOT NULL,      -- 中介提交的买家条目
  purpose       ENUM('viewing','offer','lead') NOT NULL,
  status        ENUM('created','sent','clicked','judged','expired','revoked'),
  max_clicks    SMALLINT     DEFAULT 10,    -- 允许重复点；超额是风险信号，不阻断
  created_at    DATETIME     NOT NULL,
  expires_at    DATETIME     NOT NULL,      -- 建议 14 天，给中介转发留余裕
  KEY idx_agent (agent_id, created_at),
  KEY idx_entrust (entrust_id)
);

-- 中介提交的买家条目：不含电话，中介不给我们也不要
CREATE TABLE buyer_ref (
  buyer_ref_id  BIGINT PRIMARY KEY,
  agent_id      BIGINT NOT NULL,
  label         VARCHAR(64),                -- 中介自填：代号 / 姓氏 / "王先生"
  claimed_at    DATETIME,                   -- 中介声称的带看时间
  claimed_type  VARCHAR(20),
  created_at    DATETIME
);

-- 点击事件：一次点击一行，不覆盖，全部留痕
CREATE TABLE verify_click (
  click_id      BIGINT PRIMARY KEY,
  token         CHAR(12) NOT NULL,
  ts            DATETIME(3) NOT NULL,
  -- 网络层（302 阶段即可得，无需 JS）
  ip            VARBINARY(16),
  ip_asn        INT,
  ip_geo        VARCHAR(32),
  ua_raw        VARCHAR(512),
  ja4           CHAR(36),                   -- TLS 指纹，抗 UA 伪造
  referer       VARCHAR(255),
  -- 指纹层（落地页 JS 回传，加载即采集，无需用户动作）
  fp_hash       CHAR(64),                   -- Canvas+WebGL+Audio+字体+屏幕 综合
  cookie_id     CHAR(32),                   -- first-party，1 年
  ls_id         CHAR(32),                   -- localStorage 备份，抗 cookie 清除
  screen        VARCHAR(24),
  tz            VARCHAR(40),
  ua_ch         JSON,                       -- User-Agent Client Hints
  channel       ENUM('pc','touch','ios','android','line'),
  -- 身份层（有就记，不主动索取、不弹窗）
  x591_user_id  BIGINT,                     -- 恰好登录着就能拿到
  line_user_id  VARCHAR(48),                -- 仅 LIFF 形态，本方案不强求
  app_device_id VARCHAR(64),                -- 恰好装了 App 且被唤起
  -- 行为
  dwell_ms      INT,
  interacted    TINYINT,
  KEY idx_token (token, ts),
  KEY idx_fp (fp_hash),
  KEY idx_cookie (cookie_id)
);

-- 去重与过滤结果：一条 buyer_ref 一行
CREATE TABLE verify_result (
  buyer_ref_id  BIGINT PRIMARY KEY,
  device_key    CHAR(64),                   -- 归一化后的装置标识，去重就靠它
  clicked       TINYINT,
  is_duplicate  TINYINT,                    -- 与同委托其他条目撞装置
  dup_of        BIGINT,                     -- 合并到哪条
  is_filtered   TINYINT,                    -- 命中过滤规则
  filter_reason JSON,                       -- 命中了哪些规则，供中介申诉时解释
  judged_at     DATETIME
);

3.4 device_key：去重的基准

去重的准确度全看 device_key 取得稳不稳。按可靠性降序取第一个非空值：

3.5 两段式采集，全程无感

没有第三段。不做 LIFF 授权弹窗、不做登录引导、不做 App 强制唤起 —— 那些属于身份认证方案，不在本次目标内，且会显著压低点击转化。

3.6 状态机

created ──(中介转发)──> sent ──(首次点击)──> clicked ──┐
   │                                                      │
   │                                    (T+14d 或批量任务) ↓
   │                                                    judged ──> 回写 effective_count
   └──(中介撤回/争议/风控)──> revoked      expired ──> clicked = 0

4.1 全端共通（无前置条件，302 阶段即可得）

IP + ASN + 粗地理、User-Agent、Accept-Language、JA4 TLS 指纹、Referer、点击时间戳。任何端都拿得到，也任何端都能伪造（改 UA、挂 VPN），只当辅助信号。

4.2 分端明细

4.3 测试链接与覆盖率指标

测试域名   https://591.xx/v/{token}
测试 token 每端预生成 20 条，token → (中介ID, 买家ID) 映射预置在 verify_link
落地页     /v/landing?t={token}，加载后 POST /v/collect
回收       按 channel 分组，导出 verify_click 全字段做覆盖率统计

覆盖率指标（每端分别统计）：
  click_rate      = 点击数 / 转发数
  fp_rate         = 拿到 fp_hash / 点击数
  cookie_rate     = 拿到 cookie_id / 点击数
  device_key_rate = 拿到任一级 device_key / 点击数        ← 决定去重覆盖面
  fp_collision    = 不同真人撞同一 fp_hash 的比例          ← 决定兜底层能不能用
  cookie_ttl      = cookie 实际存活天数（分端）            ← 决定跨周去重

5.1 去重

5.2 过滤

5.3 中介设备库：这套方案里最硬的一条信号

「点击装置 = 中介自己的装置」是唯一一条几乎没有假阳性的规则，也是这套方案能真正挤掉水分的地方。而它的数据来源是现成的 —— 中介登录 591 中介后台和中介 App 的设备记录本来就有。

• 建 agent_device 表：agent_id × device_key × 最近登录时间，滚动 90 天窗口
• device_key 归一化口径必须与 verify_click 完全一致，否则对不上（cookie 不同域会失效，需以 App device_id 与指纹为主）
• 跨域限制是这条规则的主要落地难点：中介后台的 cookie 和 591.tw/v/ 的 cookie 若不同域就关联不上 —— 建议短链域与主站同域，走同一个 first-party cookie 空间

建议 这一条优先于五端实测做技术验证。如果 agent_device 关联不上，方案的过滤能力就只剩模拟器和脚本检测，价值会打对折。

5.4 呈现

• 给屋主：「中介回报 5 组带看，其中 3 组已由不同装置开启」。只给正向计数，不做「疑似造假」这类指控 —— 假阴性太高，没点开的绝大多数是真买家懒得点
• 给中介：看得到自己的 effective_count 与未点击条目，有申诉入口。不展示过滤规则细节，避免被针对性规避
• 给平台：中介评级、线索分发权重若要用带看量，改用 effective_count

• 告知：落地页须有采集告知与隐私政策连结。虽然全程无感，但无感不等于不用告知
• 目的限定：写明「确认带看纪录、防止重复计数」，不得挪作广告定向或线索转卖 —— 一旦挪用，正当性基础就没了
• 最小化：本方案不采集买家姓名、电话，buyer_ref.label 是中介自填代号；不要因为「顺手」去要电话，那会把一个轻量方案变成个资项目
• 留存期：verify_click 原始字段建议 180 天后降级为聚合特征，只保留去重结果与 filter_reason
• 不做跨站追踪：全部 first-party cookie，不接第三方追踪 SDK。既是合规要求，也是让 cookie 活得久的技术前提 —— 被浏览器判定为追踪器，cookie 会被更快清掉，直接损害去重能力