83 lines
3.6 KiB
Markdown
83 lines
3.6 KiB
Markdown
# 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%`，分母是有支付成功订单的非测试账号去重用户数，不是全量注册用户
|
||
|
||
后续算加微率时按这个分母来。
|