> 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
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=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.