「机票理赔系统」的客户多维画像表（Customer 360）深度设计，目标是：可用于业务运营 + 风控反欺诈 + 增长营销 + 数据资产沉淀，并且能长期演进成公司的核心资产。

1）总体原则：画像不是一张表，是一套体系 #

画像体系 = 身份（Identity）+ 事实（Facts）+ 维度（Dimensions）+ 特征（Features）+ 评分（Scores）+ 合规（Consent）

你最终会落地成三层数据：

1. ODS 事件层：所有原始行为/业务事件（申请理赔、上传材料、登录、支付、客服沟通…）
2. DWD 明细层：结构化后的标准明细（订单、航班、理赔案件、证件、联系人…）
3. DWS/ADS 画像层：面向业务直接用的宽表、标签、评分、分群

2）核心主键设计：统一客户 ID（最关键） #

机票理赔一定会遇到：同一人多邮箱、多手机号、多平台登录、同护照不同拼写。

建议做 Identity Graph（身份图谱）：

2.1 客户主表（customer） #

• customer_id：内部唯一主键（雪花/UUID）
• status：active/frozen/blacklisted/closed
• created_at / updated_at

2.2 身份映射表（customer_identity） #

一人多身份，多身份归一到 customer_id：

• identity_id
• customer_id
• identity_type：email/phone/passport/national_id/apple/google/ota_uid/payment_fingerprint/device_fingerprint…
• identity_value_hash：强烈建议存 hash（原值放 PII 表或 KMS 加密字段）
• verified_level：0 未验证 / 1 邮箱验证 / 2 手机验证 / 3 证件验证 / 4 人脸/活体（如果你以后做）
• first_seen_at / last_seen_at
• 索引：(identity_type, identity_value_hash) 唯一 + (customer_id)

2.3 合并策略（merge） #

• 同一个护照（或证件）出现，且通过验证 => 高置信合并
• 同 email/phone 但未验证 => 低置信，不自动合并，只做候选链路
• 维护 identity_link_confidence（置信度）与 merge_reason

这一步做不好，你的画像资产会“碎裂”，后面所有标签与风控都会失效。

3）画像数据分区：PII 与非 PII 必须隔离 #

建议拆成两套库/表（至少逻辑隔离）：

• PII Vault（敏感库）：姓名、证件号、生日、地址、原始邮箱/手机号、护照扫描件路径…
• Profile Store（画像库）：标签、偏好、评分、统计指标、案件事实

PII 表字段必须：

• 加密（KMS 或字段级加密）
• 审计日志（谁在何时读取）
• 最小权限（客服/运营读脱敏；风控读更多；研发默认不可读）

4）画像域建模：你需要的“维度面”清单 #

下面是理赔业务最通用、也最值钱的画像域（建议按这个建表）：

A. 基础属性域（Demographic / Basic） #

表：customer_basic_dim（非敏感版）

• customer_id
• country_of_residence（常住国）
• preferred_language
• time_zone
• acquisition_channel（SEO/Referral/Agency/Ads…）
• first_touch_at / last_active_at
• lifecycle_stage（new/active/returning/vip/churn_risk）

**确保可运营：**这张表能让你做“生命周期运营”。

B. 出行与订单域（Travel / Booking） #

表：customer_travel_fact（按 customer 聚合的事实）

• customer_id
• trips_total
• trips_last_12m
• avg_ticket_price
• avg_lead_time_days（提前多少天订票）
• top_airlines（可存 json 或拆子表）
• top_routes
• top_departure_airports
• intl_ratio（国际航班占比）
• night_flight_ratio / connect_ratio（中转占比）

这张表决定你能不能做：高频人群、商务人群、航司偏好、路线偏好。

C. 理赔案件域（Claims / Case） #

表：customer_claim_fact

• customer_id
• claims_total
• claims_approved
• claims_rejected
• approval_rate
• avg_resolution_days
• compensation_total_amount
• compensation_avg_amount
• last_claim_at
• claim_type_dist（delay/cancel/denied_boarding/baggage…）
• airline_dispute_rate（航司争议占比）
• document_missing_rate（材料缺失率）

这张表是“业务价值资产核心”，也是风控核心输入。

D. 材料与可信度域（KYC / Document Quality） #

表：customer_kyc_dim

• customer_id
• kyc_level（0-3）
• passport_verified / id_verified
• name_match_score（订单名与证件名一致性）
• doc_upload_success_rate
• doc_forgery_risk_score（如果你后面接 OCR/风控模型）
• last_kyc_at

理赔业务极度依赖材料质量，这一域能显著提升通过率与处理效率。

E. 行为与产品使用域（Behavior / Engagement） #

表：customer_behavior_fact（事件聚合）

• customer_id
• sessions_last_7d / 30d
• apply_start_count
• apply_submit_count
• dropoff_stage（停在哪一步：航班信息/乘机人/材料/签字/收款…）
• avg_form_fill_time_sec
• customer_support_tickets
• csat_score（满意度）
• last_channel（web/h5/app）

这张表让你做到：漏斗优化、转化率提升、自动化运营（召回、提醒补材料）。

F. 支付与结算域（Payment / Payout） #

表：customer_payment_dim

• customer_id
• payout_method（bank_transfer/paypal/wise/…）
• payout_success_rate
• chargeback_rate（如果你收服务费）
• avg_service_fee_paid
• payment_risk_flags

特别注意：很多欺诈与纠纷都藏在“收款路径”里。

G. 风控反欺诈域（Risk / Fraud） #

表：customer_risk_score

• customer_id
• risk_level（low/med/high）
• fraud_score（0-100）
• suspicious_identity_links（同设备多账号、同银行卡多护照等）
• blacklist_hit（命中黑名单）
• manual_review_required（是否需要人工复核）
• reasons（json：命中的规则/模型解释）

配套：risk_event_log 记录每次评分、命中的规则，保证可追溯。

H. 偏好与营销域（Preference / Marketing） #

表：customer_preference_dim

• customer_id
• contact_preference（email/whatsapp/wechat）
• language_preference
• marketing_opt_in
• preferred_claim_assistance（全托管/自助/律师介入）
• agency_affinity（来自旅行社/渠道标识）

I. 合规授权域（Consent / GDPR） #

表：customer_consent

• customer_id
• consent_type：terms/privacy/marketing/data_share/biometric…
• version
• granted_at / revoked_at
• source（web/app/agency）
• proof（签署记录 hash / pdf 存证路径）

未来你做欧洲业务，这张表会救命：授权可证明、撤回可执行、数据可删除。

5）画像“宽表”设计：给业务一个一张表就能用的出口 #

在画像层建议做一张主宽表（便于运营、风控、CRM、BI）：

表：customer_profile_wide（DWS） #

字段分块：

• 识别：customer_id, lifecycle_stage, acquisition_channel, preferred_language
• 活跃：last_active_at, sessions_30d, dropoff_stage
• 出行：trips_12m, top_airline_1, top_route_1, connect_ratio
• 理赔：claims_total, approval_rate, compensation_total_amount, avg_resolution_days
• KYC：kyc_level, name_match_score, doc_missing_rate
• 支付：payout_success_rate, chargeback_rate
• 风控：fraud_score, risk_level, manual_review_required
• 合规：marketing_opt_in, consent_version

更新策略：

• 行为/漏斗：近实时（分钟级/小时级）
• 案件/支付：准实时（事件触发）
• 统计指标：日更（T+1）即可
• 评分：事件触发 + 每日重算兜底

6）标签体系：可解释、可运营、可版本化 #

标签不要随意堆字段，建议做统一标签中心：

表：tag_definition（标签定义） #

• tag_code（如 VIP_TRAVELER, HIGH_FRAUD_RISK）
• name
• type：enum / number / boolean
• calculation_logic（sql/规则描述/模型版本）
• owner（运营/风控/产品）
• version
• enabled

表：customer_tag（标签值） #

• customer_id
• tag_code
• tag_value（string）
• score（可选）
• computed_at
• expires_at（强烈建议：很多标签要过期）
• source（rule/model/manual）

标签要“可版本化”，否则你改一次规则，历史对不上。

7）事件体系：画像资产的“源头活水” #

强烈建议从第一天就把事件打好（否则后期补不上）。

统一事件表：event_log

• event_id
• customer_id（若当时未知可为空，后续回填）
• anonymous_id（cookie/device）
• event_type：apply_started/apply_submitted/doc_uploaded/claim_approved/payout_sent/support_ticket_created…
• event_time
• properties（json）
• source（web/app/agency/cs）
• ip/country/device_fingerprint（风控要用）

8）风控规则与评分：从规则开始，逐步模型化 #

你可以分三层：

1. 硬规则（Blocking）：证件冲突、黑名单命中、同银行卡关联多人且高频理赔…
2. 软规则（Scoring）：多账号同设备、材料缺失率高、申请时间异常集中…
3. 模型（Later）：当你积累到几千/几万案件才值得上 ML

配套必须有：

• risk_decision_log（每次判定的输入、输出、理由）
• manual_review_queue（人工复核工作台）

9）技术落地建议（不依赖大厂也能做） #

如果你想“最小可行 + 可演进”，推荐：

• OLTP：MySQL / PostgreSQL
• 缓存 & 画像服务：Redis（热字段）
• 事件采集：直接写 DB（MVP），后面换 Kafka/Redpanda
• 画像计算：定时任务 + 增量更新（先别上重型数仓）
• 画像对外：一个 Profile Service 提供统一接口（给运营后台、风控、客服、营销）

10）最小 MVP 版本：先做哪些表最值钱 #

如果你想最快把“画像资产”跑起来，先做 8 张：

1. customer
2. customer_identity
3. customer_consent
4. claim_case（案件明细）
5. flight_segment（航段明细）
6. event_log
7. customer_profile_wide（每日重算）
8. customer_risk_score（规则评分）

这样你就能做到：

• 客户归一
• 漏斗可追踪
• 案件效率提升
• 反欺诈起步
• 运营可分群