第四阶段 · 市场与数据
Customer privacy 与 Events：Consent、Cookie Banner 和 Pixel 去重
配置隐私政策、cookie banner、数据共享 opt-out 和客户请求，审查 Customer events 中的 App pixels 与 custom pixels，并验证同意前后事件和重复追踪。
本课怎么做才算完成
沿着 Settings > Customer privacy and Settings > Customer events 找到正确页面，再完成设置、保存、验证和记录。完成不是看过页面，而是能指出保存状态、验证结果和继续条件。
- 后台路径
- Settings > Customer privacy and Settings > Customer events
- 本课产出
- 一份隐私和事件清单，包含适用市场、banner、opt-out、政策链接、客户请求负责人、每个 pixel 的所有者、事件列表、consent 行为和去重证据。
- 可以继续
- 隐私入口按市场适用，三种 consent 状态可复核，事件来源和去重责任清楚，完整购买没有无法解释的重复事件。
- 必须暂停
- 如果拒绝后仍发送非必要事件、Purchase 重复或客户请求没有责任人，先暂停上线。
证据边界：隐私页面、banner 或 Customer events 列表不证明法律合规，也不证明浏览器、App 与所有事件状态没有重复或绕过 consent。
这一课为什么要先做
隐私不是发布一页 policy 就结束。要确认 banner 在哪些地区显示、拒绝后哪些 pixel 还能运行、opt-out 是否可访问、客户请求谁处理。主题代码、App pixel 和 custom pixel 同时发同一个 Purchase，会让广告平台看起来数据变多。
开始前准备
- 政策页写清实际数据收集、用途和分享。
- 列出分析、广告、聊天、评论和营销 App。
- 准备无痕浏览器和事件调试工具，不使用真实客户数据。
跟着英文后台一步一步做
每做完一步就刷新页面或从前台验证一次。后台显示已保存，不代表客户看到的结果一定正确。
配置 Customer privacy 区域
进入 Settings > Customer privacy，查看 Privacy policy、Cookie banner、data-sharing opt-out 和 customer data requests。按首发市场启用需要的体验，不要为了少一个弹窗就关闭必要的隐私入口。
做完后应该看到或拿到：得到按市场适用的隐私入口、banner、opt-out 和客户请求处理方式。
怎样算完成：每项都有市场范围、负责人、保存状态和可从前台找到的路径。
如果结果不对或入口没出现：如果入口没有出现，先确认当前店铺、市场、页面标题和保存反馈，不要在同名政策页面反复编辑。
留下证据：记录适用市场、隐私政策链接、banner 状态、opt-out 入口和客户请求负责人。页面列表不证明法律合规。
检查 Cookie banner 展示和文案
用无痕浏览器和目标国家视角打开店铺，分别测试 Accept、Decline 和 preferences。检查 banner 不遮挡关键按钮，语言与政策一致，拒绝后页面仍可基本使用。
做完后应该看到或拿到：得到三种同意状态下的展示、文案、页面可用性和事件结果。
怎样算完成：unset、Accept、Decline 都有记录，非必要事件不会在未授权或拒绝后错误发送。
如果结果不对或入口没出现：Decline 后仍发送广告事件时，定位来源是 App pixel、custom pixel、theme 或 GTM，检查 consent integration 后逐个复测。
留下证据：保存浏览器、市场、cookie 状态、事件调试结果和复测时间；一次接受状态不能代表全部状态。
失败处理：某市场看不到 banner 时，检查 Customer privacy 的 regions、market preview、缓存、语言和第三方 CMP 冲突。
配置数据共享与客户请求
确认 opt-out 页面或链接能被客户找到，并写清 Customer data request、delete 和 opt-out 的身份验证、时限、记录与处理人。不能只由一个人知道流程。
做完后应该看到或拿到：客户知道从哪里提出请求，团队知道如何验证、处理和留下记录。
怎样算完成：入口、负责人、身份验证和响应时限均可复核，测试请求不会暴露真实客户数据。
如果结果不对或入口没出现：客户找不到 opt-out 时，从前台隐私链接和目标市场菜单回溯，不要把后台开关当成客户入口。
留下证据：记录请求入口、流程负责人、身份核验方式、时限和测试结果。
审查 Customer events 中的 pixels
进入 Settings > Customer events，列出 App pixels 和 custom pixels，给每个 pixel 写清平台、所有者、事件列表、同意要求和是否还有主题或服务器来源。
做完后应该看到或拿到：得到每个平台的唯一主安装、事件清单、consent 行为和去重责任。
怎样算完成：每个 purchase、add_to_cart、view_item 等业务事件都能指出来源和是否需要同意。
如果结果不对或入口没出现：Purchase 出现两次时，对比 event source、timestamp 和 event ID，保留一套主安装，并为 browser/server 双路设置去重。
留下证据：保存 Customer events 清单、事件来源、event_id 设计和一条实际调试记录。
失败处理：不要用“pixel 已连接”作为完成证据；它不说明同意前后行为或重复事件已经解决。
清理主题和 App 重复事件
搜索 theme、GTM、App embed 和渠道 App 是否同时安装同一平台。一次业务动作只按设计发送一次；浏览器和服务器双路必须使用 event_id 去重。
做完后应该看到或拿到：重复安装被记录并移除或明确分工，purchase 等事件的来源和去重状态清楚。
怎样算完成：同一测试购买不会出现无法解释的双事件，必要事件和可选广告事件边界明确。
如果结果不对或入口没出现：删代码前先记录来源和 owner；移除一套后清 cookie、重载页面、重跑事件，避免一次删掉两套而失去可观测性。
留下证据：留下重复事件前后对照、event source、event_id、浏览器/服务器路径和复测时间。
测试同意前后和完整购买
分别在未选择、Accept 和 Decline 状态浏览商品、加购和测试购买。记录 network 或平台调试结果，确认必要事件、可选广告事件和 consent 信号符合设计，清 cookie 后重测。
做完后应该看到或拿到：得到一张按同意状态区分的事件矩阵和完整购买结果。
怎样算完成：三种状态、目标市场、关键事件和购买链路均有结果，且没有把一次测试夸大为长期保证。
如果结果不对或入口没出现：结果不一致时先清 cookie、确认市场和浏览器，再按来源逐个停用或修复，不要只刷新同一个已授权会话。
留下证据：记录状态、市场、浏览器、事件时间线、event_id、购买结果和负责人。
失败处理：如果未同意仍发送非必要事件或购买事件重复，先暂停上线并回到 Customer events 和 consent integration 修复。
现在把判断用到你的店铺
按目标市场建立清楚的 privacy policy、cookie preference 和 data-sharing 路径。Customer events 中每个平台保留一套受管 pixel，主题或旧 App 中的重复代码先记录再移除；用无痕环境分别拒绝和接受，检查 page_view、add_to_cart 与 purchase 是否按预期且不重复。
这一步先给出后台位置，再用一个实际情境检查你是否能做出决定。
把这一步用到你的店铺
完成后应得到：一份隐私和事件清单，包含适用市场、banner、opt-out、政策链接、客户请求负责人、每个 pixel 的所有者、事件列表、consent 行为和去重证据。
相关后台路径：Settings > Customer privacy and Settings > Customer events
先做判断，再对照原因
这不是记忆题。先选出能解决问题的动作，再看解释。
在店铺里逐项确认
按当前店铺的实际值逐项确认；这份清单不会替你保存设置或执行测试。
这一步还不能说明：隐私页面、banner 或 Customer events 列表不证明法律合规，也不证明浏览器、App 与所有事件状态没有重复或绕过 consent
继续条件：目标地区能看到正确入口，拒绝与接受后的事件差异可解释，page_view、add_to_cart、purchase 没有重复
暂停条件：如果 purchase 重复、拒绝后非必要像素仍运行，或客户请求没有负责人，先修复事件与治理
下一步：下一课审查 Apps 与 sales channels 的业务任务、权限、数据路径和退出方案。
先补齐判断或核对项。没有足够信息时，保持暂停比猜一个通过更安全。
按 consent 状态测试事件，不要只看 Pixel 已连接
这张矩阵用来验证访客选择与事件发送是否一致。测试前先写清目标市场、浏览器和使用的事件查看工具，并清空旧 cookie，避免把上一次会话当成本次结果。
| 状态 | 操作 | 预期结果 | 实际证据 | 结果 |
|---|---|---|---|---|
| 首次访问，尚未选择 consent | 打开无痕窗口并进入首页 | Banner 按目标市场规则显示；非必要事件在授权前不发送 | 浏览器、时间：________ | 通过 / 失败 |
| 拒绝非必要追踪 | 点击拒绝，再浏览商品与购物车 | 被拒绝的营销或分析事件不发送；必要功能仍可用 | 事件调试、时间：________ | 通过 / 失败 |
| 接受必要同意 | 点击 Accept，再浏览、加购和测试购买 | 允许的事件发送一次且 event_id 可解释 | 事件来源、ID：________ | 通过 / 失败 |
| 清 cookie 后重测 | 清除站点数据并重复三种状态 | 结果不依赖上一次会话，必要事件与可选事件边界稳定 | 复测负责人：________ | 通过 / 失败 |
这一课需要做出的决定
按行填写当前店铺的实际值，不要把示例或计划值当成完成。实际值符合条件并有保存或测试证据，才可以标记通过。
| 项目 | 推荐设置 | 为什么 |
|---|---|---|
| 隐私设置 | 按市场适用 | 不同地区要求和体验可能不同 |
| Pixel 真源 | 每个平台一套明确安装 | 避免 theme、App 和 custom 重复 |
| 客户请求 | 有身份验证和时限 | 保护客户数据并可复查 |
| 测试状态 | Unset、Accept、Decline | 不能只测同意后的事件 |
这些地方先不要乱动
- 不要把有 Cookie banner 说成已经完成法律合规。
- 不要让 theme、App 和 custom pixel 无人负责地同时发送同一事件。
- 不要只在已接受 consent 的会话里测试购买。
常见问题
有 Cookie banner 就等于完成隐私工作吗？
不是。还要按市场检查政策、opt-out、客户请求、同意前后事件、重复安装和实际购买链路；这也不自动构成法律合规结论。
浏览器和服务器都发 Purchase 一定是错的吗？
不一定。双路可以是设计的一部分，但必须有稳定 event_id 和平台去重证据，不能把两次计数当成两次购买。
Pixel 显示 connected 后还要测试吗？
要。connected 只说明安装状态，不能说明 consent 前后、拒绝状态、事件来源和重复问题都正确。
本课结论与继续条件
隐私与事件验收不是看到 banner 或 pixel connected，而是能解释每个市场、每种 consent 状态、每个事件来源和每次购买的实际结果。继续前确认客户请求有人负责、拒绝状态没有错误营销事件、双路事件可去重、清 cookie 后复测仍一致。