同一条获客链接要投放到不同渠道时，常见做法是每增加一个渠道就再创建一条链接，或随手在地址后面加一些自拟参数。企业微信开发者中心《获客链接管理》给出的做法，是在同一条获客链接的地址后面拼接官方参数 customer_channel。先分清「官方允许拼接哪个参数」和「要不要另建一条链接」，比先复制出一串新地址更要紧。

官方允许拼接的参数是 customer_channel

2026年11月12日（北京时间）阅读的《获客链接管理》标注最后更新于2025年11月17日。创建获客链接成功后，返回结果里会给出这条链接的标识、名称、url 和创建时间。该页在返回说明之后写道：如为获取更好的跳转体验，也可将获客链接的 url 调整为 scheme 使用。具体方法是：在获客链接地址后面加上 customer_channel 参数，对该完整地址做 URL 编码，再接在 weixin://biz/ww/profile/ 后面，形成 scheme。页上的示例是：若创建的获客链接为 https://work.weixin.qq.com/ca/caXXXXX ，希望配置的 customer_channel 参数为 WORK，则生成的 scheme 为 weixin://biz/ww/profile/https%3A%2F%2Fwork.weixin.qq.com%2Fca%2FcaXXXXX%3Fcustomer_channel%3DWORK。

按这一表述，官方允许在获客链接后面拼接的参数名是 customer_channel，用来带上渠道或场景取值。页上先用 STATE 表示该取值，示例里又给出 WORK。需要分开的是：创建接口的请求参数里，并没有一项叫 customer_channel；渠道区分写在使用这条链接时对 url 的调整里，而不是再创建一条链接才算「配置了渠道」。该页没有把任意自拟参数都写成等效做法，本文也不把未在该页出现的其他参数名写成官方允许的渠道参数。

scheme 在该页里的表述是「也可」采用，目的写的是「获取更好的跳转体验」，并不是说只有改成 scheme 之后，customer_channel 才存在。无论继续使用原来的获客链接地址，还是按官方方法改写成 scheme，要核对的仍是：实际打开的地址里，是否带上了 customer_channel，以及取值是不是这次要区分的那一个渠道。本文未做客户端跳转实测，不把「更好的跳转体验」写成已经验证的打开效果。

要换成员或改名称，官方提供的是编辑同一条链接，不是默认另建

同一文档还提供了编辑获客链接接口，并写明：企业可通过此接口编辑获客链接，修改获客链接的关联范围或修改获客链接的名称。也就是说，需要调整这条链接关联到哪些成员、哪些部门，或只是改一个名称时，官方给出的能力是编辑现有链接，而不是必须再创建一条。创建和编辑时，关联范围都有人数边界：该页写明 range 覆盖的总用户数不得超过500人，编辑时还写明 range 为覆盖更新，覆盖的总人数不能超过500人。成员列表与部门列表不可同时为空。把「要区分渠道」理解成「必须再创建一条」，或把「要换一批成员」理解成「旧链接不能改、只能另建」，都会把对象用错。另建一条链接，得到的是新的链接标识和新的地址；已经发出去的旧地址，不会因为后来又创建了一条就自动带上新的渠道参数，也不会自动改到新的关联范围。

该页还有 priority_option，对应「客户与成员关系绑定」。它用于优先把客户分配给已有好友关系的成员，并区分两种类型：一是在全企业范围内优先分配，二是在指定范围内优先分配。这一项必须按原文标明边界：priority_option 仅部分经营类目企业支持，当前企业是否支持，可在「高级功能-获客助手」中查看该类目对应的功能是否包含「客户与成员关系绑定」。不能把这项能力写成所有企业都可以使用，也不能把它当成渠道参数 customer_channel 的替代写法。关联范围或指定优先分配的成员，还须落在应用可见范围或客户可建联的成员范围内。这些范围条件以该页原文为准，本文不另做权限类排查展开。

删除接口则写明：删除后的获客链接将无法继续使用。删除和编辑不是同一件事。如果只是要区分渠道或调整关联范围，先看的应是拼接 customer_channel，或使用编辑接口；一旦删除，原来那条地址按该页表述将无法继续使用。

事件通知里，State 对应的就是 customer_channel 的值

要确认不同渠道有没有被带到后续事件里，需要另看《获客助手事件通知》。该页本轮阅读时标注最后更新于2026年7月22日。在「微信客户打开获客链接事件」「微信客户发起好友申请」以及「客户删除成员事件」中，参数说明都写明：State 为「点击的获客链接配置的 customer_channel 值」。也就是说，官方把链接上配置的 customer_channel，回传到这些事件的 State 字段里，用来识别这次点击或这次添加对应哪一个渠道取值。

其中，「微信客户打开获客链接事件」另有明确边界：仅部分经营类目企业支持，当前企业是否支持，可在「高级功能-获客助手」中查看该类目对应的功能是否包含「链接打开回调」。不能把「打开链接就一定能收到带 State 的回调」写成所有企业的既成事实。另外，该页在成员首次收消息、成员多次收消息等事件的参数表里，列出的是链接标识等信息，并未在这些事件中写 State；本文只在原文已经写明 State 的事件上，把它与 customer_channel 对应起来，不推断所有获客事件都会带回渠道值。

上述事件通知页面向的是创建该链接的应用回调，本文只做官方对象辨析。趣码是否为获客助手的调用方，本轮并未核实，因此不写趣码后台的配置步骤，也不编造接入后的区分效果或转化数据。

拼接参数或另建链接之前，可以先核对这几件事

- 准备区分的是同一条获客链接上的不同渠道，还是本来就需要两条不同的获客链接

- 实际对外使用的地址里，是否按《获客链接管理》在后面拼接了 customer_channel，取值是否就是本次要区分的渠道；如改用 scheme，是否按该页方法对「原链接加该参数」进行了编码

- 若只是要改关联成员、部门或名称，是否应使用编辑接口，而不是默认另建或删除旧链接；编辑时 range 为覆盖更新，覆盖总人数是否仍不超过500人

- 若准备使用 priority_option，当前经营类目是否在「高级功能-获客助手」中包含「客户与成员关系绑定」

- 若准备依据打开链接或好友申请来识别渠道，事件里的 State 是否就是当时配置的 customer_channel 值；打开链接回调是否属于当前类目已支持的「链接打开回调」

- 所依据的文档页标日期，以及本轮核读日期

同一条获客链接要区分不同渠道，官方允许在链接后面拼接的参数是 customer_channel。换成员或改名称，应先看编辑接口，而不是把另建新链接当成默认动作。渠道有没有被带到后续事件，要看事件通知里的 State 是否等于当时的 customer_channel 值。以上均为开发文档的公开表述，最终仍以当时接口返回和实际打开结果为准。

参考资料

[1] 企业微信开发者中心：获客链接管理 https://developer.work.weixin.qq.com/document/path/97398，最后更新 2025/11/17，访问日期 2026-11-12（北京时间）。该页允许将获客链接 url 调整为 scheme，并示例在链接后使用 customer_channel 参数；编辑接口可修改关联范围或名称；range 覆盖总人数不得超过500人；priority_option 仅部分经营类目支持。

[2] 企业微信开发者中心：获客助手事件通知 https://developer.work.weixin.qq.com/document/path/101363，最后更新 2026/07/22，访问日期 2026-11-12（北京时间）。该页在打开获客链接、发起好友申请和客户删除成员等事件中写明：State 为点击的获客链接配置的 customer_channel 值；打开链接事件仅部分经营类目支持。