> For the complete documentation index, see [llms.txt](https://help.impact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.impact.com/brand/zh/what-would-you-like-to-learn-about/creator-program/understanding-shared-credit-between-creator-and-performance-programs.md).

# 了解创作者与绩效计划之间的共享积分

当你同时运行 Creator 计划和 Performance 计划时，你可能会注意到，同一笔销售有时会同时归功于不止一位合作伙伴。本文将解释为什么会这样、为什么这并不意味着你为同一个结果被重复收费，以及你如何始终掌控计划成本。

## 为什么一笔销售会同时归功于不止一位合作伙伴

客户旅程很少只涉及单一接触点。典型的购买路径如下：

1. 创作者向购物者介绍你的品牌，并建立起最初的兴趣。
2. 购物者进一步研究，可能会访问优惠券或评价网站。
3. 购物者完成购买，有时是在点击了完全不同的链接之后。

在仅以最后一次点击归因的模型下，即使更早的某个接触点（例如创作者的内容）才是最初推动购物者考虑你的品牌的原因，只有获得最终点击的合作伙伴会得到归因。这意味着，创造需求的合作伙伴往往得不到回报，而那些只是最终捕获需求的合作伙伴则会获得全部归因。

当你的计划设置为识别多个接触点时，建立兴趣的创作者，以及你 Performance 计划中的合作伙伴（Performance 合作伙伴）——帮助完成最后一步的人——都可以因自己在这笔销售中的作用而获得归因。这反映了购买路径中真实发生的情况，而不是只把归因给最后一个链接。

## 这是否意味着一笔销售要支付两次费用？

在某些情况下，是的：如果创作者和 Performance 合作伙伴都为同一笔销售做出了贡献，那么你确实需要向两者支付佣金。这是有意为之，不是错误，也不是系统故障。而且你完全可以掌控这会带来多少成本。

原因在于：如果一笔销售始终只归因于最后一次点击，就会低估并削弱创作者在推动发现和认知方面所起的作用。随着时间推移，那些持续因自己带来的需求几乎得不到归因的创作者，往往会减少参与和发布内容，而你的计划也会失去真正创造这部分需求的动力。认可每位合作伙伴的真实贡献，能让你的整个漏斗，从上到下，都持续运转并保持积极性。

所以，虽然这可能意味着一笔销售要支付两笔佣金，但这并不表示你为同一件事支付了两次。你支付的是两种不同的价值：创作者创造的需求，以及 Performance 合作伙伴帮助完成的转化。

## 保持成本可控

识别多个接触点并不意味着放弃对支出的控制。你可以为每个计划自行设定佣金结构，因此可以根据自己的目标管理每笔销售的总成本。例如，为 Creator 计划设置 10% 的佣金，为 Performance 计划设置 2% 的佣金。如果两位合作伙伴都获得归因，合计佣金就是订单金额的 12%。变化的是谁获得认可，而不是你愿意总体花费多少。

## 了解它在实际中的运作方式

在实际中，创作者和 Performance 合作伙伴都因同一笔转化而获得归因的销售，通常只占总成交量的一小部分，而大多数转化仍然只归因于单一接触点。共享归因仅适用于确实有不止一位合作伙伴做出真实贡献的情况。

## 关键要点

* 一笔销售归功于不止一位合作伙伴，反映的是有不止一位合作伙伴为其做出了贡献。这不是对同一行为的重复计费。
* 你可以独立控制每个计划的佣金率，因此你的单笔销售总体成本会保持在你设定的范围内。
* 与只奖励最后一次点击的计划相比，认可创作者为其带来的需求的计划，往往能获得更好的创作者留存和参与度。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.impact.com/brand/zh/what-would-you-like-to-learn-about/creator-program/understanding-shared-credit-between-creator-and-performance-programs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.