Tracking Integration · 转化追踪
Tracking、Pixel、S2S 与 Postback 转化追踪服务
先把业务动作定义成可核对的事件，再根据客户的网站、Landing Page、APP、后端与广告平台条件，规划 Browser / Server 信号、Pixel、GTM、S2S、Postback、MMP 或其他适用连接。
本页介绍的是面向客户项目的 Tracking 服务，不会在 RedDot Media 本站安装广告 Pixel、分析标签或归因 SDK。具体实施范围取决于客户技术环境、平台权限、隐私要求与已确认的事件口径。
Tracking 方式
根据客户技术环境选择 Pixel、GTM、S2S、Postback 或适用组合
方法名称不等于完整方案。需要先确认事件发生在哪里、由哪个系统确认、要发送到哪些平台，以及客户是否具备相应权限与开发条件。
Platform Pixel
按客户项目和平台要求评估页面端基础代码、事件触发与参数配置。
Google Tag Manager
在具备适当容器权限时，集中管理客户网站需要的标签、触发器与变量。
Server-to-Server
由客户服务器或后端系统发送事件，适合需要服务器确认的业务动作。
Postback
按约定参数把 Affiliate、MMP 或其他系统中的有效事件回传至指定接收方。
APP SDK / MMP
配合客户选用的 SDK 或 MMP 规划安装、应用内事件和 Postback 路径。
Conversion API
在平台支持且客户具备技术条件时，评估服务器端事件连接与必要参数。
Analytics Event
把页面或产品行为整理为可分析的事件，支持漏斗检查和报告口径。
事件规划
先定义对业务真正有意义的事件，再决定如何记录和回传
每个事件应说明触发条件、发生位置、用途、必要参数与验收方式。页面浏览或点击可以帮助理解路径，但不应为了增加数字而被包装成最终转化。
Page View
页面到达与内容浏览。
CTA Click
重点按钮或外链点击。
Lead
符合定义的询盘或表单提交。
Registration
注册完成，而非仅开始填写。
Purchase
支付或订单状态达到约定条件。
APP Install
按归因系统确认的应用安装。
In-App Event
激活后的重点应用内动作。
Value / Revenue
在可用时回传订单价值或收入。
Qualified Action
通过项目规则验证的有效事件。
事件层级
主转化用于判断业务结果，辅助事件用于解释用户路径
层级按项目确定。同一个动作在不同业务中可能承担不同作用；只有与实际目标一致的事件，才适合作为主要优化或合作依据。
信号路径
从流量来源到报告核对，每一段都需要清楚的事件和责任边界
用户动作可以通过页面端或服务器端路径发送到广告平台、Analytics、MMP 或合作系统。实际链路会按客户项目缩短、扩展或组合。
- 01 · TRAFFICTraffic Source
- 02 · CLICKClick / Visit
- 03 · DESTINATIONWebsite / APP
- 04 · EVENTDefined Event
- 05 · CAPTUREBrowser / Server
- 06 · DELIVERYPixel / S2S / Postback
- 07 · PLATFORMAds / Analytics / MMP
- 08 · VALIDATEReport & Validation
Browser-side / 页面端
由用户浏览器中的 Pixel、Tag Manager 或事件脚本记录动作；会受到浏览器、同意管理、网络和隐私设置影响。
Server-side / 服务器端
由客户服务器、后端或业务系统确认并发送事件；需要可用接口、参数映射和访问权限。
Deduplication / 去重
浏览器端和服务器端同时发送同一事件时，需要按平台能力使用一致的事件标识或规则避免重复计算。
Attribution / 归因
点击标识、时间、来源与平台规则共同影响归因；Tracking 建立数据依据，但不能让所有系统数字完全相同。
Browser / Server 并非二选一；组合使用时必须确认事件标识、去重、同意管理和平台规则。图示只说明客户项目的数据路径，不代表本网站正在执行任何用户追踪。
事件数据
事件参数要支持核对，也要坚持必要、准确和最小化
字段应服务于已确认的衡量目的。不要把密码、验证码、支付凭证或无关的个人敏感数据作为 Tracking 参数；数据处理与保留方式需符合客户适用的规则。
Event Name
使用清楚、稳定且与业务定义一致的事件名称。
Event Time
记录事件发生时间，并确认时区与延迟处理方式。
Conversion / Transaction ID
平台或连接支持时，可用于识别、去重或核对事件；并非所有平台都要求。
Source / Medium
保留可用的来源、媒介、Campaign 或点击信息。
Value & Currency
只有在业务定义明确时才传递真实价值与币种。
Destination Context
记录与事件有关的页面、APP 或产品上下文。
Order / Lead Status
按约定状态区分开始、完成、取消或有效结果。
Data Minimization
只收集实现衡量所需的数据，并按适用规则处理同意、权限与保留范围。
平台连接
同一个核心事件，可以按项目映射到不同广告与分析系统
平台名称只表示可评估的连接方向，不代表官方合作、认证、全部功能支持或现成权限。接口、参数和可用能力以客户账户与平台当前条件为准。
Google Ads
网站或 APP 转化事件与广告优化连接。
Meta Ads
Pixel 与适用的服务器端事件连接。
TikTok Ads
网站或 APP 事件及适用的 Events API。
Analytics
事件、来源与转化漏斗分析。
Mobile MMP
安装、应用内事件和媒体 Postback。
Affiliate
点击标识、有效事件与 Postback 核对。
CRM / Backend
线索、订单或资格状态的业务端确认。
Tracking QA
上线前检查触发、参数、去重与平台接收，上线后继续复查变化
测试通过表示已覆盖约定的场景，不等于任何设备、浏览器、网络、用户状态或第三方处理都能永久保持一致。
触发条件
在正确动作发生时触发，不提前、不漏触发。
事件次数
检查刷新、返回与重复提交是否造成重复记录。
参数映射
核对名称、类型、真实值与币种，以及适用时的 Conversion ID。
页面与设备
检查关键页面、主流视口及适用的 APP 环境。
同意与隐私
按客户适用规则检查同意状态和数据最小化。
去重
核对浏览器与服务器事件是否按设计合并。
平台诊断
使用客户平台提供的测试或诊断界面检查接收状态。
报告口径
确认事件定义、时区、归因窗口和报告维度。
变更复查
页面、APP、结账或后端流程变更后重新验证。
数据差异
广告平台、Analytics、MMP 与业务后台的数据不一定完全相同
不同系统可能使用不同的归因模型、归因窗口、时区、设备识别、同意状态、处理延迟、去重规则和事件定义；取消订单、无效线索或跨设备行为也会形成差异。
适合场景
这些网站、APP 与广告项目可以评估 Tracking Integration
场景只用于说明可评估方向。实际方式、平台、开发量、权限、数据范围和验证深度仍需根据客户项目确认。
新网站或 Landing Page 上线
在上线前定义关键动作、标签方式和测试范围。
页面改版或技术迁移
检查旧事件是否需要保留、重命名、迁移或停止。
多平台广告投放
统一核心事件，再按不同广告平台映射所需信号。
线索质量核对
连接表单与后续业务状态，区分提交与合格线索。
电商与订单事件
明确商品、结账、购买、取消与真实价值的记录条件。
APP 用户获取
连接安装、应用内事件、MMP 与媒体 Postback。
CPA / Affiliate 合作
明确有效事件、点击标识、回传和双方核对规则。
现有 Tracking 检查
梳理重复、缺失、命名混乱或平台数据差异。
开始前准备
先准备业务、技术、平台与数据规则，才能确定 Tracking Scope
无需通过公开页面提交密码、验证码、私钥或用户敏感数据。项目需要访问时，应使用平台角色、测试环境或其他适当的最小权限方式。
业务与目标
- 网站 / Landing Page / APP
- 主要业务动作
- 主转化与辅助事件
- 报告与优化用途
技术环境
- 前端 / CMS / APP 技术
- Tag Manager 或现有代码
- 后端 / CRM / API 条件
- 开发协作与测试环境
平台与权限
- 广告平台或 Analytics
- MMP / Affiliate 系统（如适用）
- 按最小权限提供访问
- 不通过页面提交密码或验证码
数据与规则
- 事件名称与触发条件
- 归因、时区与去重口径
- 隐私 / 同意要求
- 验收场景与负责人
实施流程
从业务定义开始，再设计连接、实施联调与验证交接
实施时间和范围取决于客户技术环境、事件数量、平台、权限、开发协作、测试条件与变更情况；不承诺固定上线时间、数据量、归因结果或广告表现。
- 01
梳理目标与现状
确认业务路径、广告平台、现有 Tracking、主要问题和实际技术环境。
- 02
定义事件与口径
区分主转化和辅助事件，明确触发条件、参数、归因与去重规则。
- 03
设计连接方案
根据客户条件选择 Pixel、GTM、S2S、Postback、SDK、MMP 或适用组合。
- 04
实施与联调
在授权范围内配置标签或连接，并与页面、APP、后端和平台共同测试。
- 05
验证与交接
记录测试结果、已知差异、维护责任和后续变更后的复查要求。
Tracking Integration FAQ
开始前常见的 Pixel、S2S、Postback、去重与数据问题
先分清业务事件、信号路径、平台报告和客户后台各自的作用，再确认适用的实施方式与验收边界。
Pixel、GTM、S2S 和 Postback 应该选哪一种？
取决于网站或 APP、业务事件、广告平台、后端能力、隐私要求与现有工具。它们可以单独使用，也可以在明确去重和责任边界后组合使用。
只安装基础 Pixel 就能开始优化转化吗？
基础代码通常只建立连接。是否能用于优化，还要看事件定义、触发条件、参数、数据量、平台接收状态和 Campaign 设置。
浏览器端和服务器端事件有什么区别？
浏览器端由页面和用户设备发送，部署直观但会受到浏览器与隐私设置影响；服务器端由客户后端确认并发送，控制力更强，但需要开发条件、接口和正确的数据治理。
同时使用 Pixel 和 S2S 会重复计算吗？
可能。如果同一业务动作从两条路径发送，需要根据平台能力设计一致的事件标识或其他去重规则，并在测试中核对。
为什么广告平台、Analytics 和后台数据不一样？
常见原因包括归因模型与窗口、时区、设备与隐私限制、事件定义、处理延迟、去重方式、取消或无效订单处理，以及各系统报告逻辑不同。
可以保证所有转化都被记录或各平台数据完全一致吗？
不能。红点传媒可按确认范围规划、实施和验证，但浏览器、网络、用户同意、平台处理、第三方系统与业务变更都会影响记录和归因。
Tracking 服务会收集客户密码或敏感资料吗？
不应通过公开页面提交密码、验证码、私钥或用户敏感资料。项目访问应采用适当角色和最小权限，并只处理实现已确认衡量目标所需的数据。
APP Tracking 一定需要 MMP 吗？
不一定，但多渠道安装归因和应用内事件管理通常需要评估 MMP、SDK 或其他适用方案。选择取决于渠道、OS、预算、技术条件和报告要求。
页面或结账流程更新后还需要复查吗？
需要。DOM、路由、表单、支付、同意管理、APP 版本或后端接口的变化都可能影响事件，重要变更后应重新验证。
本网站现在是否安装了广告 Pixel 或用户行为追踪？
没有。本页只介绍面向客户项目的 Tracking / Pixel / S2S / Postback 服务；RedDot Media 本站不因本页而新增任何广告 Pixel、分析标签或归因 SDK。
Tracking 资料准备
先确认业务事件、技术环境和需要连接的平台，再安排 Tracking 方案
可先准备网站 / APP、主要转化、现有 Pixel / GTM / SDK / MMP、广告平台、后端或 CRM 条件、当前数据问题和隐私要求，再确认事件表、实施路径、权限、测试与交接范围。
联系红点传媒查看 Tracking 方式查看实施流程了解 Landing Page
本页不设置 Tracking 表单或任何可执行追踪代码；客户项目的访问方式、数据范围、平台连接、实施责任与验收条件均以确认的 Scope 为准。