# Session: 2026-06-01 14:36:31 GMT+8

- **Session Key**: agent:main:feishu:direct:ou_e63ce6b760ad39382852472f28fbe2a2
- **Session ID**: 0a3698ab-0ea1-495c-b8ae-95d0e7cb1f29
- **Source**: feishu

## Conversation Summary

user: 我们来明确一下怎么判断用户是否加微，通过表bi_vala_app_account中的tel_encrypt字段，关联stride_contact_bindings表中的tel_encrypt字段，能匹配上代表已加班主任微信，匹配不上代表未加班主任微信。
assistant: 找到了，`stride_contact_bindings` 在 `vala_class` 库。让我看看表结构。


assistant: 表结构确认完毕。来验证一下匹配逻辑和数据量：


assistant: 跨库（`vala_bi` ↔ `vala_class`），需要确认 dblink 是否可用：


assistant: 两个表分属不同数据库（`vala_bi` ↔ `vala_class`），PostgreSQL 不支持跨库 JOIN，且 dblink 未安装。让我用脚本方式验证匹配逻辑：


assistant: 验证完毕，以下是结论：

---

## 加微判断逻辑验证结果

### 数据源
| 表 | 库 | 记录数 |
|---|---|---|
| `bi_vala_app_account` | `vala_bi` | 28,633 非测试账号（有 tel_encrypt） |
| `stride_contact_bindings` | `vala_class` | 2,016 条绑定记录，去重 tel_encrypt 1,973 个 |

### 按 `tel_encrypt` 匹配

| 状态 | 人数 | 占比 |
|---|---|---|
| **已加微**（匹配上） | **1,247** | 4.36% |
| **未加微**（未匹配） | **27,386** | 95.64% |

### 补充验证：与 `vala_account_id` 对比

`stride_contact_bindings` 表里也有 `vala_account_id` 字段（1,278 条有值），我同时用两种方式匹配做了对比：

| 匹配方式 | 人数 |
|---|---|
| 仅 tel_encrypt 匹配 | 1 |
| 仅 vala_account_id 匹配 | 28 |
| 两种都匹配 | 1,246 |

**结论：用 `tel_encrypt` 匹配覆盖了 1,247/1,274 ≈ 97.9%**，和用 `vala_account_id` 匹配的结果高度一致，差的那 27 个是 `stride_contact_bindings` 有 account_id 但 tel_encrypt 不一致或为空的边界情况。

### ⚠️ 跨库注意

两个表分别在 `vala_bi` 和 `vala_class` 两个数据库，PostgreSQL 不支持直接跨库 JOIN，实际查询时需要在应用层分别取数据后做交集。

---

用 `tel_encrypt` 匹配的逻辑没问题，要我把这条口径写入 MEMORY.md 吗？
user: 写进长期记忆，明确提到是否班主任加微，直接用刚刚的脚本匹配
assistant: Now I'll add the 加微判断逻辑 to MEMORY.md, placing it in the core business metrics section near other data rules.


assistant: 再写个日记忆记录一下：


assistant: 已写入长期记忆，内容涵盖：

- **判断方式**：`tel_encrypt` 字段跨库匹配
- **数据源**：`vala_bi` / `vala_class` 两库分属
- **跨库处理**：应用层取交集，不能直接 SQL JOIN
- **验证脚本**：`scripts/check_wechat_binding.py`
- **当前基准数据**：28,633 人中已加微 1,247（4.36%）

后续做加微相关统计直接按这个口径来就行。
user: 另外你需要知道，加微分两种情况，第一种是加班主任微信，是购课用户才会有的行为；第二种是加销售微信，是注册用户就会有的行为。不过现在暂时还没有加销售微信的数据。那么提到加班主任微信率，需要用加班主任微信人数/购课人数。
assistant: 已更新。补充了两个关键点：

1. **加微类型区分**：班主任微信（购课用户）vs 销售微信（注册用户，暂无数据）
2. **加班主任微信率口径**：`加班主任微信人数 / 购课人数 × 100%`，分母是有支付成功订单的非测试账号去重用户数，不是全量注册用户

后续算加微率时按这个分母来。
