数据质量项目计划制定

客户主数据数据质量改进项目计划

1. 项目目标与范围
- 目标
  - 建立统一的客户黄金记录，提升客户主数据的准确性、完整性、一致性与可用性。
  - 降低重复客体与无效联系方式比例，保障合规与隐私安全。
  - 构建可持续的数据质量治理、监控与持续改进机制。
- 范围
  - 数据域：个人客户、企业客户、联系人、地址、账号与关系、联系方式（电话、邮箱）、偏好与同意、KYC/税务标识、层级关系（法人/分支）。
  - 系统边界：CRM、ERP、营销自动化、电商、客服系统、KYC系统、数据仓库/湖、第三方参考数据服务。
  - 数据生命周期：采集、标准化、验证、匹配/去重、合并/黄金记录、发布与同步、监控与问题处置。

2. 组织与角色
- 治理结构
  - 数据治理委员会：批准标准、阈值与合并策略；决策重大变更。
  - 数据域所有人（业务）：定义业务规则与优先级；验收KPI。
  - 数据管理员/数据管家（Steward）：规则维护、问题分流、人工审核。
  - 数据质量分析师：剖析、规则设计、指标监控、根因分析。
  - MDM/数据平台负责人：平台架构、匹配引擎、工作流与接口。
  - 数据工程：数据管道、标准化与规则执行实现。
  - 安全与合规：隐私分级、访问与加密控制、合规审计。
  - 测试与发布：测试策略、回归套件、变更管理。
- 决策与RACI（摘要）
  - 规则与阈值：业务Owner负责，Steward与DQ分析师协作，治理委批准。
  - 合并/拆分：Steward执行与复核，治理委裁决疑难案例。
  - 上游变更：系统Owner负责，数据平台评审，DQ分析师验证影响。

3. 现状评估与基线建立
- 数据剖析内容
  - 唯一性：客户主键、证件/税号、邮箱+电话组合。
  - 完整性：核心字段非空率（姓名/公司名、国家、城市、主联系方式、同意状态）。
  - 合规性/格式：电话E.164、邮箱格式与域名MX、国家代码ISO 3166-1、邮编与城市匹配。
  - 一致性：国家与电话区号一致、邮编与城市一致、法人与分支关系一致。
  - 新鲜度/时效：最近更新时间分布、增量到达时延。
  - 重复度：Exact/标准化后/模糊层级重复率。
- 方法与输出
  - 全量剖析结合分层抽样；对高风险字段进行分桶与异常点检测。
  - 输出基线报告：指标定义、当前阈值、问题分布与优先级列表、样例记录。
  - 建立数据字典与业务术语表；标注PII与敏感度等级。

4. 指标体系与目标阈值（示例，最终以基线与业务风险评估为准）
- 完整性：核心字段非空率 ≥ 98%（姓名/公司名、国家、主联系方式）；地址要素 ≥ 95%。
- 有效性：邮箱格式与域检验通过率 ≥ 96%；电话格式合法率 ≥ 98%。
- 一致性：国家-区号、邮编-城市一致性 ≥ 97%。
- 唯一性：重复客体率 ≤ 1.5%（标准化后）；Exact重复 ≤ 0.2%。
- 准确性：与权威参考数据（地址、国家码、税号校验）一致性 ≥ 97%（抽检或对比）。
- 新鲜度：T+1日落地率 ≥ 99%；关键属性延迟中位数 ≤ 24小时。
- 数据质量事件SLA：P1 ≤ 4小时止血，24小时内根因判定。

5. 规则体系设计
- 标准化与格式化
  - 姓名/公司：去空白/多空格、统一大小写与常见缩写映射（例：Co., Ltd → LIMITED）；中文繁简体统一。
  - 地址：标准街道、门牌、城市、行政区、邮编分段；按国家模板规范化；地理编码可选。
  - 电话：解析并转换为E.164；校验国家-区号匹配；剔除非数字与伪号。
  - 邮箱：语法校验（RFC 5322子集）、域名有效与MX记录检查（不进行未经许可的SMTP探测）。
  - 国家/地区：ISO 3166-1 alpha-2；语言/货币码与国家一致。
- 业务校验
  - 年龄限制/KYC必填（适用于个人客户）；企业税号/注册号格式校验（按国家规则）。
  - 联系方式选择：至少一种可联络渠道有效（电话或邮箱）。
  - 同意状态：来源、时间戳、作用范围（渠道/目的）齐全。
- 跨字段一致性
  - 邮编—城市—州省三者一致；国家—电话区号一致；法人-分支归属一致。
- 主键与业务键
  - 内部不可变主键（GUID/雪花ID）；业务键（证件号/税号）映射与版本管理；外部源系统键留存。

6. 去重与实体解析（个人/企业分治）
- 匹配策略
  - 分层阻塞：国家+标准化姓/公司首字母+邮编前缀+电话后四位等组合，降低全局比对复杂度。
  - 精确匹配：业务键、邮箱（规范化后）、电话（E.164）。
  - 近似匹配：姓名/公司（Jaro–Winkler/Levenshtein）、地址（token-based相似度）、邮箱本地段相似、语音编码（Double Metaphone）。
  - 阈值与权重：按属性置信度设置加权分；> 高阈值自动合并；介于高低阈值进入人工审核；< 低阈值不合。
- 合并与生存者规则
  - 来源信任等级排序（KYC/核心系统 > 自填表单 > 第三方 enrichment）。
  - 字段级策略：最新时间优先、非空优先、来源优先；保留多值（多电话/邮件）与标注首选。
  - 可回滚合并与审计：记录匹配证据、规则版本、操作者与时间。
  - 误合并防护：黑名单对、关系约束（不同国家+不同税号且无强证据不合并）。
- 人工审核工作流
  - 分配队列、SLA与抽样复核；高风险字段双人复核；决策模板与证据留存。

7. 数据修复与丰富
- 上游防错
  - 表单级校验（同步）：必填、格式、选项受控词表；实时地址/电话校验API可选；重复预检提示。
  - 数据契约：字段类型、取值域、唯一性、变更通知规范。
- 批量清洗
  - 历史数据分批（按风险与价值优先级）：标准化→规则校验→匹配→合并→回写/发布。
  - 自动修复策略：规范化、参考数据替换、可推断值填补（仅在规则允许范围内，保留来源标记）。
- 丰富与验证
  - 地址权威库校验与地理编码；电话运营商/类型校验（在合法前提下）；邮箱域名信誉库。
  - 行业分类、公司编码（如LEI/本地统一社会信用代码）使用合规来源；记录许可证与使用范围。

8. 技术架构与实现
- 数据流
  - 源系统 → 着陆层（原样保留） → 标准化与校验层 → 匹配与实体解析层 → 黄金记录/发布层（Hub） → 消费端（CRM/营销/分析）。
- 组件
  - 数据质量规则引擎（批/流）、匹配引擎（可扩展阻塞+相似度计算）、MDM存储与服务接口（读写API）、人审工作流与队列、元数据与血缘、质量指标仓与可视化、告警与工单集成。
- 工程实践
  - 环境隔离（Dev/Test/Pre/Prod）；规则与模型版本化；CI/CD集成数据与规则测试；基础设施即代码；回滚策略。
  - 性能：分布式计算（如Spark）支撑批量匹配；在线防重采用缓存与近实时索引；分区与并行优化。

9. 隐私与合规
- PII分级与标注；最小化与目的限制；合法合规处理（如GDPR/CCPA/本地数据安全要求）。
- 同意与偏好管理：记录来源、时间、渠道与用途；下游传播与执行。
- 访问控制：基于角色的最小权限；字段级脱敏；传输与静态加密；审计日志。
- 数据主体权利：查询/更正/删除流程与SLA；去标识化与保留期限策略；测试环境使用脱敏数据。

10. 实施阶段与里程碑（参考工期，依据数据量与系统复杂度调整）
- 阶段1 启动与治理设立（2周）
  - 建立治理委员会与角色；确认范围、风险与成功标准；完成术语表初版。
- 阶段2 现状评估与基线（4周）
  - 全量/抽样剖析、基线报告、问题清单与优先级、数据字典与PII标注。
- 阶段3 规则与模型设计（4周）
  - 标准化/校验规则库、匹配策略与阈值、合并与生存者规则、数据契约草案。
- 阶段4 平台与管道实现（6周）
  - 规则引擎与匹配引擎、数据管道、元数据与质量指标仓、可视化与告警、工单集成。
- 阶段5 批量清洗与去重（4周）
  - 历史数据清洗与合并、人工审核回路、回写/发布、性能与稳定性优化。
- 阶段6 UAT与推广（2周）
  - 业务验收、指标复核、用户培训、上线准备与变更评审。
- 阶段7 上线与稳态监控（2周）
  - 生产切换、稳定运行观察、阈值微调、运维交接。
- 关键输出物
  - 基线报告、规则库与数据契约、匹配与合并设计文档、流程与操作手册、仪表板与告警、培训材料。

11. 质量监控与问题管理
- 指标采集与展示
  - 每日/每批次产出维度指标与规则过检率；按源系统/地区/渠道分解；趋势与异常检测。
- 告警与SLA
  - 阈值越界、异常波动、到达延迟、重复率激增；P1/P2分级；自动创建工单并路由至Steward。
- 问题单生命周期
  - 发现→分流→止血→根因分析（上游/规则/平台）→修复与验证→预防复发（流程/契约/代码变更）。
- 回归与变更
  - 规则变更触发回归测试；关键数据集设立金标样本集；每月评审阈值与漂移。

12. 测试与验收
- 测试类型
  - 单元测试（规则与标准化函数）、集成测试（端到端管道）、性能测试（匹配规模与延迟）、UAT（业务场景）、回滚演练。
- 金标与抽检
  - 建立标注样本（重复/非重复、地址/电话边界样例）；定期人工抽检准确率。
- 验收标准（示例）
  - 达到第4节目标阈值；无P1未关闭问题；审计与安全测试通过；文档与培训完成。

13. 风险与缓解
- 误合并/漏合并
  - 缓解：多层阻塞与证据加权；人工审核队列；可回滚与黑名单对。
- 规则漂移与过拟合
  - 缓解：定期校准与AB对照、漂移监控、版本管理与回归。
- 性能瓶颈
  - 缓解：阻塞键优化、并行与分片、近实时索引；离线批与在线防重分离。
- 合规与隐私风险
  - 缓解：合法合规评估、最小化、访问与加密控制、供应商合规审查。
- 业务中断与回写冲突
  - 缓解：灰度发布、幂等与去重写入、事务与幂等键、冲突检测。
- 上游配合不足
  - 缓解：数据契约与变更窗、接口版本化、例外处理与质量罚则。

14. 资源与预算（估算框架）
- 人力
  - DQ分析师 1–2人，数据工程 2–3人，MDM/平台 1–2人，Steward 1–2人，测试1人，安全/合规0.5人。
- 基础设施
  - 计算与存储（批处理与索引/缓存）、监控与日志、工单与可视化。
- 第三方
  - 参考数据/验证服务（地址/电话/邮箱），MDM/DQ工具许可（如采用）。
- 注：实际投入依据数据量、系统数量、合并复杂度与合规要求调整。

15. 变更管理与培训
- 变更流程
  - 规则/阈值变更申请→影响评估→治理委员会批准→测试→灰度→发布；变更记录与公告。
- 培训
  - 面向Steward与客服：去重审查、合并/拆分操作、问题单处理。
  - 面向数据工程与分析：规则实现、监控与告警处理。
  - 面向业务：黄金记录使用、数据契约与表单规范。

16. 关键实践与注意事项
- 先立标再提质：以基线与风险驱动优先级，避免大而全一次性清洗。
- 上游+中台双向治理：源头校验与中台纠错并行，优先消除系统性根因。
- 全链路可追溯：保留原始值、标准化值、规则与证据，以支撑审计与纠错。
- 审慎丰富：仅接入必要参考数据，记录来源与许可证，避免未经同意的推断性数据。
- 安全默认开启：字段级脱敏与最小权限；测试环境只用脱敏或合成数据。

附：示例指标计算定义
- 完整性（字段F）：非空记录数(F)/总记录数。
- 有效性（规则R）：通过R的记录数/参与校验的记录数。
- 唯一性（键K）：1 − 重复记录数(K)/总记录数。
- 新鲜度（属性A）：在SLA时间窗内更新的记录数/总记录数。
- 去重精确率/召回率：基于金标样本，TP/(TP+FP) 与 TP/(TP+FN)。

本计划为标准化技术方案模板，具体指标阈值、工期与资源需在完成基线评估与业务风险评估后确定并落地为可执行排期与SLA。

Event Logs Data Quality Improvement Project Plan

1. Purpose
- Establish a disciplined, repeatable program to improve the accuracy, completeness, consistency, timeliness, and reliability of event logs across applications and infrastructure.
- Implement standards, controls, and monitoring to prevent, detect, and remediate data quality issues at source and throughout the pipeline.

2. Scope
- In-scope sources: application logs (frontend, backend services), infrastructure/platform logs (containers, hosts, gateways), security events, and clickstream telemetry.
- Environments: development, staging, production.
- Systems: log producers, ingestion pipelines (streaming and batch), storage layers (data lake, warehouse, observability store), downstream analytics (BI, ML features, alerting).
- Out-of-scope: non-event datasets (e.g., transactional tables) unless directly derived from logs.

3. Objectives and Success Criteria
- Define and enforce a canonical structured logging standard with schema validation at ingestion.
- Reduce invalid or unparseable events by ≥80% from baseline.
- Reduce duplicate event rate to <1 per million events.
- Ensure ≥99.5% completeness for mandatory fields.
- Reduce schema drift incidents to ≤2 per quarter with controlled evolution.
- Achieve ≤5 minutes median end-to-end timeliness (event_time to availability for analytics) for streaming logs.
- Implement continuous monitoring with automated alerts and runbook-based remediation.

4. Stakeholders and Roles
- Data Quality Lead (project owner): orchestrates plan, defines standards, sets thresholds, leads triage.
- Logging/Producer Engineers: implement structured logging and identifiers, ensure compliance with schema.
- Data Platform Engineers: build ingestion validation, quarantine flows, deduplication, and monitoring.
- Observability/Monitoring Team: dashboards, alert routing, SLOs.
- Security and Privacy: PII classification, masking, retention controls.
- Product Analytics/BI: downstream acceptance tests, feedback loops.
- Incident Response: handles quality incidents and root cause analysis.

5. Data Quality Dimensions and Metrics (Event Log Specific)
- Accuracy: field-level domain validity (e.g., status_code ∈ [100–599], log_level ∈ {DEBUG, INFO, WARN, ERROR}).
- Completeness: mandatory fields non-null (% missing per field).
- Consistency: uniform types, formats, and enumerations across services; schema compatibility rate.
- Timeliness: event_time to ingestion_time; distribution and SLAs; late arrival rate (% arriving > watermark).
- Uniqueness: duplicate rate per million; collision rate of event_id or hash.
- Integrity: referential/correlation integrity (presence rates of trace_id, request_id, session_id); cross-field logical rules (e.g., error_code present iff log_level=ERROR).
- Conformity: adherence to schema versions; schema drift count.
- Lineage/Traceability: coverage of service_name, environment, region; ability to trace event through pipeline.
- Observability metrics: parsing error rate, validation failure rate, quarantine volume, dead-letter queue backlog.

6. Standards and Canonical Model
- Structured logging required; prefer JSON or Protobuf for machine readability.
- Timestamp: event_time in UTC using ISO 8601 with timezone offset or epoch milliseconds; include ingestion_time assigned at pipeline.
- Identifiers: correlation_id or request_id, trace_id/span_id (compatible with OpenTelemetry), service_name, environment, host_id, region, deployment_version, event_name, event_version.
- Enumerations: define controlled vocabularies (log_level, event_category, environment).
- Field dictionary and schema registry: define types, required/optional, constraints, description, owner.
- Schema evolution policy: backward-compatible changes allowed; breaking changes require deprecation window, dual writes, and migration plan.

7. Architecture for Data Quality Controls
- Source-side validation: producer libraries enforce schema and enumerations; drop or warn before emit.
- Ingestion validation: streaming gate (e.g., Kafka/Kinesis consumer with validator) applies schema checks; invalid events routed to quarantine/dead-letter with structured error context.
- Parsing/Normalization: unstructured logs parsed with deterministic patterns; normalized to canonical schema; track parse success rate.
- Deduplication: compute event_hash from stable fields (producer_id, event_name, event_version, event_time, correlation_id) and apply sliding-window dedupe with watermark.
- Ordering and lateness handling: use event_time with watermarks; define lateness threshold per stream; late events handled via correction paths.
- Storage: curated, validated layer separated from raw; partition by event_date and service_name; maintain versioned schema.
- Monitoring: data quality checks executed continuously (streaming and batch) with metrics to monitoring system; alerting integrated with incident management.
- Lineage: capture and store run metadata (job_id, code_version, schema_version) for each hop.

8. Data Cleaning Rules
- Timestamp normalization: convert to UTC; reject or quarantine timestamps outside logical ranges; correct known format deviations.
- Canonicalization: trim strings, normalize casing where defined, standardize user agents and IP formats; decode/normalize encodings.
- Deduplication: drop events with identical event_hash within configurable window; log dedupe decisions with reason.
- Null handling: impute only for non-identifying derived fields where business-approved; never impute identifiers or timestamps.
- Free-text messages: extract structured fields where feasible; preserve original message for traceability.
- Out-of-order events: maintain separate handling pipeline; annotate events with lateness metadata.

9. Validation Rules (Examples; finalize per field dictionary)
- Required fields: event_time, event_name, event_version, service_name, environment, correlation_id/trace_id, log_level.
- Format checks: ISO 8601 timestamp, UUID format for identifiers, regex patterns for request_id.
- Domain rules: status_code in HTTP range; environment ∈ {dev, staging, prod}; log_level enumerations enforced.
- Cross-field rules: error_code required iff log_level=ERROR; session_id required for user events; region required for infrastructure events.
- Uniqueness: event_id unique within producer; event_hash duplicate rate threshold.
- Size/shape constraints: payload size limits; nested object depth limits.
- Schema compliance: reject events violating declared types or unexpected fields unless flagged as experimental with versioned schema.

10. Monitoring and Alerting
- Dashboards:
  - Validation failure rate by stream and service.
  - Missing mandatory field rates.
  - Schema drift occurrences and versions.
  - Duplicate rate and dedupe actions.
  - Parsing error rate for unstructured logs.
  - Timeliness lag (p50/p95) and late arrival rate.
  - Identifier coverage (trace_id, correlation_id).
  - Quarantine and DLQ volumes and age.
- Alerts:
  - Threshold-based (e.g., mandatory field completeness <99.5%).
  - Change-point detection for sudden spikes in error rates.
  - Schema change detected without approved request.
  - NTP/time sync issues detected via drift checks across hosts.
- Tools:
  - Data validation frameworks (e.g., Great Expectations, Deequ) for batch checks.
  - Streaming validations in consumer services (e.g., Flink/Spark Streaming custom operators).
  - Metrics emitted to monitoring stack (e.g., Prometheus/Grafana) with service labels.
  - Data catalog for schema and ownership; schema registry for versioning.

11. Issue Management and Remediation Workflow
- Detection: automated alert or analyst observation triggers incident.
- Triage: classify severity and impact; identify affected services and time ranges.
- Root cause analysis: review producer changes, deployment logs, pipeline code, schema registry diffs.
- Remediation:
  - Hotfix producer or validate library; roll back or patch.
  - Adjust parsing rules; reprocess quarantined events if recoverable.
  - Backfill corrected events where safe and traceable.
- Documentation: incident record with timeline, metrics, fix, and prevention actions.
- Prevention: update standards, tests, and monitoring; add guardrails in CI/CD for producers.

12. Privacy, Security, and Compliance
- PII classification: identify fields containing personal data; enforce masking or tokenization before storage in shared layers.
- Access controls: role-based access to raw versus curated logs.
- Retention: define retention policies per log category; implement deletion workflows.
- Encryption: in-transit and at-rest encryption required.
- Auditability: maintain change logs for schema and validation rule updates.

13. Change Management and Governance
- Data Quality Council: cross-functional group approves standards and schema changes.
- Producer certification: services must pass pre-deployment data quality tests (schema validation, identifier coverage, timestamp correctness).
- Schema evolution request process: propose, review, approve, implement with versioning and backward compatibility tests.
- SLAs: document DQ SLAs per stream; publish on internal portal; review quarterly.
- Training: provide structured logging libraries, templates, and developer guidance.

14. Implementation Plan and Timeline (12 weeks)
- Week 1–2: Discovery and Baseline
  - Inventory log sources, pipelines, and downstream consumers.
  - Profile current quality metrics (completeness, duplicates, parsing errors, timeliness).
  - Identify high-impact streams and top issues.
  - Deliverables: source inventory, baseline DQ report, prioritized backlog.
- Week 3–4: Standards and Design
  - Define canonical schema, field dictionary, enumerations, and identifiers.
  - Select and design validation architecture (source-side and ingestion-side).
  - Define dedupe strategy, lateness handling, and quarantine flows.
  - Deliverables: logging standard document, schema registry setup, validation and dedupe design.
- Week 5–7: Build Controls and Tooling
  - Implement producer libraries for structured logging and schema compliance.
  - Build ingestion validators, quarantine/DLQ, and normalization parsers.
  - Implement streaming/batch DQ checks and metrics emission.
  - Deliverables: producer SDKs, validator services, parsing modules, initial dashboards.
- Week 8: Pilot and Hardening
  - Onboard 2–3 high-volume services; run in shadow mode if needed.
  - Validate thresholds, tune alerts, measure performance impacts.
  - Deliverables: pilot results, tuning changes, go/no-go criteria.
- Week 9–10: Rollout
  - Phased rollout to remaining services; enforce pre-deployment DQ gates.
  - Migrate unstructured logs to structured format where feasible.
  - Deliverables: rollout plan execution, service compliance reports.
- Week 11: Backfill and Remediation
  - Reprocess quarantined events when recoverable; perform targeted backfills.
  - Close known quality gaps; document exceptions.
  - Deliverables: backfill logs, remediation notes, updated DQ metrics.
- Week 12: Operate and Govern
  - Formalize SLAs and runbooks; establish ongoing reviews.
  - Handover to operations; schedule quarterly audits.
  - Deliverables: runbooks, governance schedule, final DQ improvement report.

15. Deliverables Summary
- Logging standard and canonical schema with field dictionary.
- Schema registry and evolution policy.
- Producer libraries and CI/CD data quality tests.
- Ingestion validation, quarantine/DLQ services, dedupe module.
- Parsing and normalization pipeline for unstructured logs.
- Data quality dashboards and alerting rules.
- Runbooks for triage and remediation.
- Final baseline and improvement reports with metrics.

16. Risks and Mitigations
- Producer resistance to changes: provide libraries, templates, and phased adoption; enforce CI gates after grace period.
- Performance overhead: benchmark validators; optimize hot paths; allow sampling where appropriate for non-critical streams.
- Schema fragmentation: enforce registry and review process; restrict ad hoc fields without approval.
- Time synchronization drift: implement NTP monitoring; flag suspicious timestamps; correct in pipeline if safe.
- Privacy exposure during normalization: apply masking/tokenization at source; review fields with Security.

17. Ongoing Operating Model
- Continuous monitoring of DQ metrics with weekly reviews.
- Quarterly schema and standards audits.
- Incident postmortems with action items tracked to completion.
- Regular training for new services and teams.
- Feedback loop with downstream consumers for fit-for-purpose validation.

This plan provides a structured approach to establishing robust data quality for event logs, integrating standards at the source, validation at ingestion, systematic cleaning and normalization, and continuous monitoring and governance to sustain improvements.

转化数据的数据质量改进项目计划

1. 项目目标
- 建立可持续的数据质量框架，提升转化数据的准确性、完整性、一致性、唯一性和及时性，支持稳定的归因分析与业务决策。
- 构建从采集到消费端的端到端质量控制与可观测性，实现可追溯、可验证、可告警的管道。
- 将关键质量指标纳入SLA/SLO进行持续监控，形成闭环改进机制。

2. 适用范围与数据边界
- 数据域：转化事件（下单、支付成功、注册完成、关键转化步骤）、相关会话/点击事件、订单/支付明细、广告投放与渠道元数据。
- 数据来源：
  - 应用/网站SDK埋点（Web/App）
  - 第三方广告平台回传（如：通过API或离线批量文件）
  - 自有CRM/订单/支付系统
  - 离线转化回传（呼叫中心、门店POS等）
- 覆盖链路：采集 → 传输 → 落地（原始层） → 标准化/清洗（明细层） → 归因与汇总（事实层/指标层） → 应用（BI、归因报表、投放回传）。

3. 数据质量维度与量化指标
- 完整性（Completeness）
  - 必填字段非空率：event_time、event_name、order_id、user_id/匿名ID、currency、value、source、channel ≥ 99.5%
  - 关键关联字段存在率：order_id↔支付明细/ERP对账关联 ≥ 99.0%
- 准确性（Accuracy）
  - 金额对账误差：订单金额聚合与财务系统差异绝对值/财务值 ≤ 0.5%
  - 货币与汇率应用准确率 ≥ 99.9%
- 一致性（Consistency）
  - 枚举值有效率（渠道、媒介、活动、国家码、币种等） ≥ 99.5%
  - 时区统一：UTC存储率 100%，本地化仅在展示层完成
- 唯一性（Uniqueness）
  - 重复事件率（按幂等键聚合） ≤ 0.1%
  - order_id 在事实层唯一（每个订单仅一次有效转化记录）
- 及时性（Timeliness）
  - T+0/P95延迟 ≤ 30分钟（流式）或 T+1 09:00（批处理）
  - 迟到事件率（超归因窗口到达） ≤ 1%
- 可追溯性（Traceability）
  - 事件血缘可用率 100%，可定位源系统、代码版本、采集SDK版本

4. 基线评估与现状剖析（2-3周）
- 数据剖析
  - 字段分布、缺失、异常值、时间戳偏移、跨源差异、枚举值漂移
  - 近90天数据采样与全量分层扫描结合，识别高风险字段与高缺陷来源
- 对账与一致性检查
  - 转化金额/订单数与财务系统/ERP/支付网关对账
  - 广告平台回传与自有数据对账（按订单数、金额、点击关联比例）
- 管道健康
  - 数据延迟、丢包率、重试率、死信队列量、分区倾斜与热点
- 输出基线报告与优先级清单（问题按影响度和可修复性分级）

5. 数据标准与数据模型（3-4周并行推进）
- 事件与字段标准
  - 统一事件命名：purchase、subscribe、complete_registration 等
  - 主键与幂等键：event_id（例如哈希 source + order_id + event_time_ms + source_event_id），订单层主键 order_id
  - 时间字段：event_time（UTC，毫秒精度）、ingest_time、processing_time
  - 标准化字段：currency（ISO 4217）、country（ISO 3166-1 alpha-2）、device_type、os_version、utm_*、click_id、gclid、fbclid
- 口径与业务定义
  - 转化定义：以支付成功（已扣款且未退款）为最终转化口径；如需行为转化，单列事实表并明确标识
  - 归因窗口与规则：默认最后非直接点击，点击7天/曝光1天（可按渠道差异化配置），跨设备优先用户ID，其次设备ID
  - 去重规则：同一 order_id + user_id + 归因窗口内，多源到达仅计一次有效转化
- 模型分层
  - 原始层（stg_raw_*）：按来源原样落地+最小必要元数据
  - 明细层（dwd_event_*）：标准化字段、单位、时区、枚举、合规脱敏
  - 事实层（fact_conversions、fact_orders）：一单一行，含归因结果、价值、币种标准化金额
  - 维度层（dim_user、dim_device、dim_campaign、dim_channel、dim_geo、dim_product）

6. 质量规则与验证策略
- 模式与契约（Schema/Contract）
  - 针对每个源定义数据契约：字段、类型、是否必填、取值范围、唯一性约束、版本策略；破坏性变更需提前公告与灰度
- 字段级校验
  - 非空与值域：currency ∈ ISO列表；value ≥ 0；country ∈ ISO列表；event_time 在合理时间窗口
  - 格式：ID类字段正则校验；UTM参数规范；URL/域名合规
- 业务规则
  - order_id 在事实层唯一；退款/取消生成冲正记录且净值一致
  - 金额和税费关系：总金额=商品金额+税费+运费-折扣（容差阈值）
  - 迟到事件处理：在可配置回溯窗口内补写与重算归因
- 关联与完整性
  - 事件→订单→支付明细全链路可关联率
  - 跨源合并：click_id/gclid/fbclid 优先匹配；无点击则采用会话与UTM归因
- 去重与幂等
  - 幂等键落地去重（Merge/Upsert）；同源重复丢弃，不同源重复合并

7. 采集与传输质量控制
- 埋点规范
  - 文档化事件字典、字段、触发时机、依赖上下文；SDK版本管理与强制升级策略
  - 客户端校验：本地缓存+重试+队列上限；批量发送阈值；网络失败重试与退避
- 传输可靠性
  - 流式通道开启幂等、重试、死信队列监控；批处理校验文件完整性（大小、记录数、哈希）
- 丢包与采样
  - 禁止非必要采样；若需采样，声明采样率与还原逻辑；丢包监控与阈值告警

8. 数据清洗与修复策略
- 标准化
  - 时区统一为UTC；金额与币种标准化（保留原币与折算币）；语言/编码统一UTF-8
  - 枚举映射：渠道与媒介字典化管理，未知值归类为 other 并记录来源
- 异常与缺失修复
  - 规则修复：尾随空格清理、大小写统一、无效字符剔除
  - 合理插补：当业务可推断（如缺失 currency 且订单有币种）再插补；否则标记并上报
- 反作弊与异常检测
  - 可疑模式识别：极高频同设备/同IP、极短会话停留、UA异常组合、时区与IP地理不一致
  - 为可疑事件打分并降权或隔离审计，不直接删除
- 历史回补
  - 对历史缺陷数据逐批回补与重算归因，分阶段回填（近7天→近30天→近180天），设置检查点与对账

9. 身份解析与去重
- 标识优先级
  - user_id（登录态）> crm_id/email_hash/phone_hash > device_id（IDFA/GAID/AndroidID）> anon_id（cookie/自生成）
- 解析策略
  - 构建稳定用户键 user_key（图谱式合并：Heuristic + 可配置规则）
  - 冲突策略：合并前审计记录；避免跨人群错误合并
- 评估
  - 使用标注样本评估精确率、召回率；设定最低阈值并监控波动

10. 归因与口径统一
- 归因引擎
  - 规则引擎可配置：窗口、优先级、跨设备、跨渠道、触点去重
  - 多口径输出：业务默认口径（最后非直接点击）、广告平台对齐口径（各平台要求）
- UTM与渠道治理
  - 统一映射表：source/medium/campaign 内容规范与清洗逻辑
  - 非法UTM自动降级为 direct/other 并记录
- 多源去重
  - 基于 order_id 与 event_id 的跨平台去重；点击ID优先去重，缺失时按会话去重

11. 合规与隐私
- PII处理
  - 原始PII最小化采集，敏感字段入湖前脱敏/哈希（盐管理）；权限分级与列级加密
- 合规要求
  - 用户同意状态携带并在下游尊重；数据保留策略与删除请求（RTBF）可执行
- 审计与访问
  - 数据访问审计日志、变更审计与版本化

12. 监控、告警与可观测性
- 指标监控
  - 体量：事件计数同比/环比、季节性基线偏差
  - 质量：非空率、有效率、重复率、迟到率、对账差异、延迟P95
  - 漂移：字段分布漂移（PSI/KL），枚举新值检测，SDK版本占比
- 告警策略
  - 多级阈值（警告/严重）、静默窗口与抖动抑制；自动工单与值班流程
- 数据血缘与元数据
  - 端到端血缘图、数据契约验证结果、任务运行状态面板

13. 测试与发布治理
- 开发流程
  - 基础测试：单元测试（UDF/规则）、集成测试（管道）、契约测试（Schema变更）
  - 数据测试：样本对账、回归测试（新旧口径对比）、A/B并跑与影子发布
- 发布策略
  - 分阶段灰度、回滚预案、版本冻结窗口（大促/重要活动期间）

14. 治理与角色分工（RACI）
- 责任主体
  - DQ团队：质量指标与规则体系、监控与审计、缺陷管理（R）
  - 数据工程：采集/传输/存储与性能优化、幂等与容错（A）
  - 分析工程/数仓：模型与口径落地、测试、文档（R）
  - 业务与投放：UTM治理、渠道字典、归因口径确认（C）
  - 安全与法务：合规与访问控制（C/A）
  - 产品与研发：埋点规范与SDK版本治理（R）
- 变更管理
  - 变更评审、影响评估、回滚策略与通知机制（含外部数据提供方）

15. 实施路线图与里程碑（示例12周）
- 第1-2周：基线评估完成；发布问题清单与优先级；冻结破坏性变更
- 第3-5周：数据契约与标准模型落地；关键质量规则上线（非空/值域/去重/迟到）
- 第6-8周：归因引擎上线并双跑对比；对账自动化与监控面板上线；初次历史回补（近30天）
- 第9-10周：身份解析1.0上线；多源去重与渠道映射强化；异常与反作弊规则上线
- 第11-12周：SLA/SLO定稿；告警门限优化；文档与培训；项目验收与运营移交

16. 风险与缓解
- 来源方不稳定或无契约：签订数据契约与退化策略；离线备选路径
- 历史数据缺陷规模大：分批回补，优先近因数据；对账后再扩展时间窗
- 归因口径争议：多口径并存输出并标识用途；设立变更审批
- 身份解析误合并：严格规则与人工审计样本；保守合并策略
- 高峰期性能压力：弹性扩容、索引与分区优化、批次合理切分

17. 交付物
- 数据契约与事件字典、渠道与枚举映射表
- 数据模型与口径说明书（事实表/维表/指标定义）
- 质量规则库与测试用例、监控与告警面板
- 对账流程与报表、异常与修复操作手册
- 身份解析与归因引擎配置与评估报告
- 合规与访问控制策略、数据血缘与元数据目录

18. 资源与工具建议（可替换为等效方案）
- 质量校验与测试：Great Expectations/dbt tests/自研规则引擎
- 调度与编排：Airflow/Dagster
- 实时与批处理：Kafka/Kinesis + Spark/Flink/SQL引擎
- 元数据与血缘：OpenMetadata/Amundsen/Data Catalog
- 监控与告警：Prometheus/Grafana/ELK/云监控
- 对账与审计：SQL作业与校验框架、审计表

19. 持续改进机制（PDCA）
- Plan：按季度复盘质量指标与痛点，更新规则与SLO
- Do：灰度上线、数据回补、SDK升级
- Check：对账与监控评估、用户反馈与事故复盘
- Act：固化经验为契约/规则/自动化，淘汰低质量来源或改造上游

20. 验收标准（示例）
- 指标达成：核心必填字段非空率≥99.5%，重复率≤0.1%，对账误差≤0.5%，P95延迟达标
- 监控覆盖：≥95%关键表与字段纳入规则和仪表盘；告警漏报率≤1%
- 文档齐备：契约、模型、口径、运行手册、回滚预案完整
- 稳定运行：连续30天无P1质量事故，且告警闭环平均处理时长≤4小时

说明
- 本计划提供方法论与可实施模板。具体阈值和时间表需结合现有系统性能、数据规模与业务要求调整。
- 所有规则上线前需在影子环境或双写场景进行回归对比，确保口径一致与性能可控。