美洽转化归因怎么设置？

在美洽建立转化归因，核心就是：把访客的身份（visitor_id/会话ID）和来源信息（UTM、referrer、落地页）稳定存下来；在用户完成购买/注册时上报包含这些信息的转化事件；在美洽后台或自建分析服务里按选定的归因模型（首触、末触或多触）去匹配与去重，并做跨设备与离线订单的服务器端同步与验证。

先讲为什么要做转化归因（用最直白的话）

归因就像把顾客从一条线拉到另外一条线上看是谁先撒了网。没有归因，你可能会以为某个渠道效果好，但实际上是另一个渠道先吸引了用户。在客服场景里，归因还能告诉你：哪一类会话、哪个渠道带来的客户更容易成交、哪些话术/场景需要优化。

基本概念（一定要搞清楚这些名词）

• 访客ID（visitor_id）/会话ID：美洽用来识别访客与会话的唯一值，是把转化与聊天记录连起来的最关键字段。
• UTM 参数：utm_source、utm_medium、utm_campaign 等，来源渠道的关键线索。
• 首触/末触/多触模型：决定把转化归到哪个接触点上（最先、最后或按权重分配）。
• 事件上报：在用户完成关键动作（下单、填写表单）时，把事件数据传给美洽或你的分析后端。
• 去重/时间窗：两个订单来自同一访客时如何处理，以及归因的时间跨度（比如 7 天、30 天窗口）。

准备工作（先把基础打牢）

• 在美洽注册并完成账号基础设置，确认有权限管理埋点/数据上报。
• 在网站/小程序/APP 上安装美洽前端 SDK 或聊天埋点，并能读取到美洽返回的访客ID/会话ID（通常是 JS 全局对象或 SDK 回调）。
• 在落地页或全站统一位置捕获并持久化 UTM、referrer、landing page 等来源信息（用 Cookie 或 localStorage，保存时间视业务而定，一般 30 天左右）。
• 后端要有一个可调用的上报接口，用于接收订单/转化并将其与访客ID、UTM 关联后上报到美洽或写入自建分析仓库。

逐步实现：前端如何捕获并保存来源

想象你在给每个访客贴一张标签：标签上写着“谁带来的我、从哪里来、登陆哪页”。这样当他下单时，你就能把标签一并交给客服系统。

1）捕获 UTM 和 referrer 的通用脚本

思路：在用户首次到达站点时读取 URL 中的 utm 参数和 document.referrer，写入 cookie/localStorage，并记录首次来源（first_touch）。后续访问不覆盖首触，但可以更新末触（last_touch）。

/* 示意代码（需要根据项目安全与兼容性调整） */
(function(){
  function getQuery() {
    var q = {};
    location.search.replace(/^\?/, '').split('&').forEach(function(p){
      if(!p) return;
      var kv = p.split('=');
      q[kv[0]] = decodeURIComponent(kv[1] || '');
    });
    return q;
  }
  var q = getQuery();
  var utm = {};
  ['utm_source','utm_medium','utm_campaign','utm_term','utm_content'].forEach(function(k){
    if(q[k]) utm[k] = q[k];
  });
  // first touch cookie
  if(!localStorage.getItem('first_touch')) {
    var first = {
      utm: utm,
      referrer: document.referrer || '',
      landing: location.pathname + location.search,
      ts: Date.now()
    };
    try { localStorage.setItem('first_touch', JSON.stringify(first)); } catch(e){}
  }
  // always update last touch
  var last = {
    utm: utm,
    referrer: document.referrer || '',
    landing: location.pathname + location.search,
    ts: Date.now()
  };
  try { localStorage.setItem('last_touch', JSON.stringify(last)); } catch(e){}
})();

2）把美洽的访客ID/会话ID也存在同一地方

美洽 SDK 通常会返回一个访客标识（名字不一定相同）。把这个 ID 也写进 localStorage 或者发送到后端与订单绑定。示例：

/* 假设美洽 SDK 在 window.Meiqia，返回 visitorId */
window.Meiqia && window.Meiqia.getVisitor && window.Meiqia.getVisitor(function(visitor){
  try { localStorage.setItem('meiqia_visitor_id', visitor && visitor.id); } catch(e){}
});

当用户转化时（最重要）——上报转化事件的两种方式

上报事件有两条路：前端直接上报（轻实现，容易测试但安全性差），或者后端接收转化并代表前端上报（推荐，能处理订单验证与钩子）。以下描述更偏向实践推荐。

后端中台接收转化事件并上报的流程

• 用户在确认页点击“下单”，前端把订单信息连同 localStorage 的 first_touch/last_touch 和美洽 visitor_id 发送到你的后端接口（例如 /api/track-conversion）。
• 后端验证订单（防止伪造金额），做去重（通过 order_id 或外部支付流水），然后把事件写入数据仓库并调用美洽提供的事件上报 API 或者把信息同步到美洽的用户属性里。
• 如果你用的是美洽内建的归因模块（假设支持），把上报的字段包含到美洽指定字段里；如果美洽不支持，你可以在自建分析里做归因并把结果回填到美洽统计或客服视图中。

示意的后端接收 payload（JSON）模型：

向美洽上报（两种策略）

• 写入美洽事件/属性：把订单事件和来源字段通过美洽事件上报 API 或“更新访客资料”接口写入，方便在美洽后台做简单筛选与统计。
• 自建归因，回填结果：在你自己的数据线（数据仓/BI）做归因后，把归因结果（归因渠道、归因触点、归因时间窗）回填到美洽作为访客属性，客服面板能直接看到最终来源。

如何选择归因模型（实际建议）

没有万能的模型，取决于你的业务：

• 首触（First-touch）：适合把注意力放在“获取新用户”的渠道优化，适用于拉新为主的周期短业务。
• 末触（Last-touch）：适合捕捉“最后一击促成购买”的投放效果，适用于决策路径很短或促销即刻成交的情形。
• 多触（Multi-touch）：适合复杂决策路径，能更公平地把归因分给多次接触，常用时间衰减或自定义权重。

跨设备与离线订单怎么处理

这两个问题是归因的常见坑。

• 跨设备：如果用户先在手机看到广告（有 UTM），后来在电脑上下单，这时只有你能把两端身份关联（站内登录 ID 是关键）。所以把访客ID与站内用户ID绑定，并在用户登录时把保存在 localStorage 的 first_touch 信息上传并合并。
• 离线/电话/线下：客服通过美洽接到电话或线下成交，需在客服系统里填写订单号并把来源字段回填，或在后端把线下订单与客服会话的 visitor_id 进行匹配并批量上报。

测试与验收（别偷这个环节）

• 测试用例：不同来源（有/无 UTM）、跨设备、离线订单、重复支付，分别验证归因结果是否符合预期。
• 时间窗测试：调整归因窗口（7/14/30天），观察渠道归因分布变化，选一个与业务周期匹配的窗口。
• 去重测试：对同一订单重复上报要能识别并抑制重复计入。
• 数据校对：把美洽显示数据与后端数据仓做日常对账，发现偏差及时排查网络丢包、时间戳不一致或 visitor_id 丢失等问题。

常见问题与排查思路

• 没有 visitor_id/会话ID：检查 SDK 是否正确初始化，或是否在匿名模式下禁用了访客 ID 的保存。
• UTM 丢失：很多单页应用（SPA）切页没有刷新 URL，确保在首次进入页面时就读取并保存 UTM。
• 跨域/子域导致 cookie 丢失：使用 localStorage 或后端在登录时主动合并来源信息。
• 重复上报：后端用 order_id 去重；前端在提交按钮加防抖与状态标识。

实践示例：端到端流程（简化版）

1. 用户点击广告，带 utm_source=ads1，落到首页。前端脚本保存 first_touch（UTM、referrer、landing）。
2. 用户打开美洽聊天，SDK 返回 visitor_id=V123，脚本保存到 localStorage，并把 visitor_id 发送给后端做绑定。
3. 用户若在另一设备上登录，则登录流程会把 first_touch 信息同步到服务端，与账号绑定。
4. 用户下单，前端将 order、meiqia_visitor_id、first_touch、last_touch 发送到后端 /api/track-conversion。
5. 后端校验订单，写入仓库，并调用美洽事件上报接口或在美洽中更新访客属性：attribution_channel=ads1、attribution_model=last_touch 等。
6. 在美洽后台或 BI 中观察渠道带来的订单与金额，并根据归因模型调整投放。

监控指标与看板建议

• 按渠道统计：转化次数、转化率、平均客单价（AOV）、投资回报率（ROAS）。
• 按会话类型统计：首次会话->成交率、复访会话->成交率。
• 归因窗口敏感度：每日对比不同归因窗口（7/30/90天）下的渠道占比变化。
• 异常检测：某渠道转化突然下降，同时检测会话量、客服响应率、页面性能是否异常。

实施清单（落地步骤一览表）

• 安装并验证美洽前端 SDK（确认能拿到 visitor_id）。
• 写脚本捕获并持久化 UTM/referrer/landing（first_touch/last_touch）。
• 在关键转化页埋点并把访客信息与订单一起发送到后端。
• 后端校验、去重后把转化事件写入仓库并同步到美洽或回填归因结果。
• 选择并配置归因模型，设置时间窗与权重（多触情况）。
• 编写自动化测试用例并上线前灰度验证。
• 上线后常态化对账与异常监控。

最后一点实用小技巧（能省很多调试时间）

• 把 visitor_id 和 first_touch 的保存放在页面尽早的位置（不要放在需要用户交互才加载的脚本后面）。
• 调试时在浏览器里打印 localStorage、cookie 与网络请求的 payload，做端到端对照。
• 对于广告投放，建议在落地页做短期的 sticky 参数（比如 30 天），这样可以覆盖大多数转化周期。
• 多触模型可以先用简单的时间衰减（近触点权重高），等数据量够了再用更复杂的算法。

好啦，这些是把美洽的转化归因从零搭到能用的全流程思路和实施要点。其实核心很简单：把“谁”和“从哪来”的信息可靠地保存下来，并在关键动作发生时把它们连带上报，然后选择合适的归因模型并做好跨设备与去重。现在去做一遍你会发现接下来主要是边测边改，数据会慢慢告诉你哪里需要优化。希望这份清单对你上手有帮助，做起来别急，先把数据链路跑通就行。