美洽怎么设置访客来源追踪？

把访客来源数据准确记录到美洽，核心就是三件事：保证链接带上规范的UTM或能识别的参数；在页面端把这些参数读出来并保存在 cookie/localStorage（或传给后端）；最后把这些来源字段通过美洽的访客属性或 SDK/接口上报给美洽并映射到访客档案或会话标签。做到这三步，就能把流量来源、活动归因和转化路径在美洽里串起来，方便客服查看与后续分析。

先说个比喻：把访客来源“贴上标签”

想象每位访客是一个快递包裹，来源信息像包裹上的快递单号和订单备注。如果快递单没写清楚（没有UTM或referer），分拣时就看不出这是哪个渠道来的；如果写了，但下游系统（比如美洽）没把单号读进来，客服也看不到。要让美洽里能看见来源，需要三步联动：广告/链接→页面抓参→上报美洽。

整体流程（一步步来看，像搭积木）

• 第一块积木：前端保证URL带参数 —— 所有广告、推广链接、邮件、社媒链接最好都使用统一的UTM规范（utm_source、utm_medium、utm_campaign、utm_term、utm_content）。
• 第二块积木：页面端读取并持久化 —— 页面加载时用 JS 读取 URL 参数，写入 cookie/localStorage，避免刷新或跳转丢失。
• 第三块积木：把参数写入美洽 —— 通过美洽后台的访客自定义字段或通过美洽提供的 JS SDK / 后端 API，把这些参数关联到访客档案或会话标签。

准备工作（上线前先把基础搭好）

• 和市场确认UTM命名规范，形成一份对内标准（示例见后面的表格）。
• 在美洽后台创建对应的访客自定义字段或渠道字段（例如：utm_source、utm_medium、utm_campaign、origin_url、referrer）。
• 确定将来源数据映射到访客档案还是会话标签——前者便于长期用户画像，后者便于单次沟通的归因。
• 若有单点登录（SAML/OAuth）或后端识别用户的流程，规划如何把登陆后的用户ID和前端采集的来源字段合并。

在美洽后台需要做的设置（概念性步骤）

不同版本的美洽界面可能有细微差别，但通常要完成的事是相同的：创建访客属性、允许外部上报、以及把字段展示在会话界面。具体可以按下面顺序操作：

• 进入“设置”或“账号管理”类菜单，找到“访客属性”或“客户字段”。
• 新增字段（例如 utm_source、utm_medium、utm_campaign、utm_content、utm_term、first_visit_url、referrer），字段类型一般选文本或枚举。
• 在字段设置中允许通过 API/前端上报（通常会有“允许外部写入”之类的选项）。
• 在“会话/消息面板”设置中，把这些访客字段加入展示列，方便客服在聊天时直接看到来源信息。

前端：如何捕获并持久化来源参数（示例代码）

下面的代码示例说明了如何抓取 URL 参数并存入 cookie/localStorage，逻辑很直接：优先用 URL 的 UTM，若没有就用 referrer 或已有 cookie。

// 捕获 URL 参数的通用函数
function getQueryParams() {
  var params = {};
  var search = window.location.search.replace(/^\?/, '');
  if (!search) return params;
  search.split('&').forEach(function(pair) {
    var kv = pair.split('=');
    var k = decodeURIComponent(kv[0] || '');
    var v = decodeURIComponent(kv[1] || '');
    if (k) params[k] = v;
  });
  return params;
}

// 常用 UTM 字段
var utmKeys = ['utm_source','utm_medium','utm_campaign','utm_term','utm_content'];

(function(){
  var params = getQueryParams();
  var store = window.localStorage || {};
  var changed = false;

  // 如果 URL 有 utm，就写入 localStorage（持久化）
  utmKeys.forEach(function(k){
    if (params[k]) {
      try {
        store[k] = params[k];
      } catch(e){}
      changed = true;
    }
  });

  // 记录首次访问页面
  if (!store.first_visit_url) {
    try { store.first_visit_url = window.location.href; } catch(e){}
  }

  // 记录 referrer（外链来源）
  if (!store.referrer && document.referrer) {
    try { store.referrer = document.referrer; } catch(e){}
  }

  // 如果需要，把这些字段同步到 cookie（兼容一些后端）
  if (changed) {
    var cookieVal = utmKeys.map(function(k){ return k+'='+encodeURIComponent(store[k]||''); }).join('&');
    document.cookie = 'utm_info=' + cookieVal + '; path=/; max-age=' + 60*60*24*30;
  }
})();

说明（为什么要持久化）

用户经常会在多个页面之间跳转、或者从广告点到登录再到下单。把来源写入 localStorage 或 cookie，可以在用户后续行为（登录、表单提交）发生时继续读取并上报，避免来源丢失。

把来源数据上报给美洽：三种常见方式

具体项目中会选用一种或多种方式同时使用，互为补充。

方法一：依赖美洽的“自动抓取/归因”功能（最省力）

• 有些美洽版本会自动抓取 referer 和常见的 UTM 参数并在访客档案里展示。如果你的账号已包含此功能，确认在后台“来源追踪”或“渠道归因”类功能已开启。
• 优点：配置少；缺点：不可控性较高（可能抓不到在单页面应用或跨域场景下的来源）。

方法二：使用美洽 JS SDK（实时上报，适合透明交互）

当访客打开会话窗口或页面时，用 JS SDK 将本地存储的来源字段发送给美洽，写入访客属性或会话上下文。伪代码如下：

// 假设有一个“上报到美洽”的全局方法（不同账号 SDK 名称可能不同）
function reportSourceToMeiqia(sourceObj) {
  // 伪函数：把 sourceObj 上报到美洽
  // 常见行为：set visitor properties / set visitor attribute / tag session
  if (window.MeiqiaSDK && typeof window.MeiqiaSDK.setVisitor === 'function') {
    window.MeiqiaSDK.setVisitor(sourceObj);
  } else {
    // 若 SDK 未加载，可在 SDK 加载后再执行一次上报
    window._meiqia_pending = window._meiqia_pending || [];
    window._meiqia_pending.push(function(){
      window.MeiqiaSDK.setVisitor(sourceObj);
    });
  }
}

// 读取本地的 utm 字段并上报
var sourceObj = {};
utmKeys.forEach(function(k){ if (localStorage[k]) sourceObj[k] = localStorage[k]; });
if (localStorage.first_visit_url) sourceObj.first_visit_url = localStorage.first_visit_url;
if (localStorage.referrer) sourceObj.referrer = localStorage.referrer;

reportSourceToMeiqia(sourceObj);

注意：上报时要确保字段名称与美洽后台创建的访客属性一致，或者在上报后在美洽后台做字段映射。

方法三：后端合并上报（适合登录/表单转化场景）

很多场景下用户在匿名浏览阶段没有登录，后续提交表单或注册时才产生可识别的用户 ID。这时候最好在后端把前端持久化的来源参数与用户 ID 绑定，并通过美洽的后端 API 把来源写入访客档案或会话。

• 优点：当用户登录或下单时可以把“匿名来源”准确合并到已识别用户，避免数据割裂。
• 实现方式：前端在登录/注册/提交表单时把 localStorage 的来源字段一并提交到你自己的后端，后端保存并调用美洽的“更新访客信息”或“创建会话”接口，把来源写入美洽。

把来源转成可用的“渠道归因”——字段设计建议（表格）

SPA / 跨域 / 深度链路的注意事项（常见坑）

• 单页面应用（SPA）：路由变化不会触发页面重载，URL 变化后需要在路由钩子里再次读取新 URL 的 utm（如果有），并且在第一次打开页面时就把初次 utm 写入 localStorage。不要只依赖 document.referrer。
• 跨域跳转：如果用户从不同域的支付或第三方页面回来，cookie 可能丢失。常见做法是把 visitor_id（或 UUID）通过 URL 参数回传，后端接到后把来源和用户关联。
• 短链/跳转链：某些第三方短链或转链会剥离 UTM，需要确保短链工具支持保留 query 参数或在跳转时把源参数追加回去。

移动端与小程序接入建议

• 移动应用里没有传统 URL 的 utm，通常由渠道参数（install referrer、app link）或第三方归因工具（Adjust、AppsFlyer）提供归因结果，再通过 App 的埋点 SDK 将这些数据写入美洽（通过美洽移动 SDK 的 setVisitor / identify 接口）。
• 微信内网页、H5 和小程序的归因需要特殊处理：微信内一般通过页面带参数或跳转时保存来源；小程序一般用云函数/后端来记录来源并在用户提交时上报。

如何在美洽把来源信息展示给客服（实践）

• 把关键字段（utm_source、utm_campaign、first_visit_url）加入会话侧边栏或访客详情的显著位置，方便客服在沟通时直接看到。
• 根据来源自动打标签：在上报来源时同时设置会话标签（例如“渠道：SEM / 来源：微博”），便于后续按渠道筛选会话。
• 把来源作为会话触发条件：例如“若 utm_campaign = spring_sale，则自动分配到活动客服组”。这样能把不同活动的用户分配给熟悉活动策略的客服。

测试与验收清单（上线前一项一项勾）

• 在浏览器地址栏直接用带UTM的测试链接打开，检查 localStorage/cookie 是否存在对应字段。
• 打开美洽控制台，创建测试会话或触发 SDK 上报，确认访客档案里相应字段已被写入并可展示。
• 测试用户登录流：匿名来源是否和登录后用户合并（在美洽里能看到历史来源）。
• 检测 SPA 路由跳转、跨域返回、表单提交等关键路径，确保来源不会丢失。
• 进行 A/B 测试的流量，核对美洽里的渠道分布和广告平台报表是否大致一致，找出漏计的情况。

常见问题与排查建议（个人经验写法）

• 为什么美洽看不到 UTM？
  可能原因：没有把字段建到访客属性里；前端未上报或上报字段名不一致；UTM 在跳转过程中被删除。排查步骤：用 devtools 查看请求、检查 localStorage、确认 SDK 上报日志。
• 来源有时是空白或显示为内部页面（self）？
  一般是因为用户直接输入或书签访问，或中间发生了从站内页面跳转（referrer 被识别为站内）。可以优先记录 first_visit_url 来保留首次流量线索。
• 跨设备用户怎么合并来源？
  只能通过登录后的唯一标识来合并。匿名阶段的来源应保存在后端并在用户登录/注册时进行合并上报。

隐私与合规（别忘了这些）

收集来源信息时要注意不要无意中收集敏感个人信息（PII）。在中国及其他地区都要遵守个人信息保护相关法律法规（比如《个人信息保护法》）。实现建议：

• 在隐私策略中说明会收集来源/UTM数据及用途。
• 对外部上报的字段做脱敏处理（如果包含可能识别用户的参数）。
• 设置数据保留策略，定期清理不再需要的来源数据。

小结式提示（边想边写的那种补充）

最后再提醒几句，别偷懒：UTM 规范要统一，前端要把参数持久化，登录后务必在后端把匿名来源和用户绑定——三处都做好了，数据才不会割裂。实施过程中多做端到端测试，尤其是 SPA、跨域和移动安装链路。我这边想了这些，用起来慢慢调，通常能把美洽里的来源追踪稳定下来。