HubSpot、Pipedrive 与 Salesforce

1. 一句话说明作用

会话被识别时，我们会根据您发送的标识符在 CRM 中查找此人，并附加包含录制链接的备注。

仅此而已。不新建联系人、不新建交易，也不更改销售管道。每当有人访问价格页就生成重复联系人的 CRM，比没有集成更糟。

找不到此人时，不执行任何操作。 创建联系人意味着根据浏览器会话向 CRM 写入记录，而浏览器会话并不是判定谁是客户的权威来源。

2. 匹配字段：如何找到此人

这部分值得花十分钟了解，因为 CRM 集成通常就在这里悄悄出错。

我们通过网站告知的标识识别访客： MousePlayer.setUserId()、从分析工具读回的 distinct ID，或服务器端 identify 调用。CRM 也通过某个值识别此人。两边的值必须相同。

	查找依据	是否可更改
HubSpot	联系人的电子邮箱地址	不可，搜索端点以此为基础
Pipedrive	按关键词查找人员，优先电子邮箱	不可
Salesforce	一个由您指定的字段，默认是 `Email`	可以

为什么 Salesforce 会询问字段

Salesforce 部署很少以电子邮箱为键。您的部署可能使用 Customer_Number__c，或账单系统的外部 ID。如果仍按电子邮箱搜索，就会什么也找不到，却报告成功——这是最糟的失败，因为集成看起来还在正常运行。

因此表单会问： Contact 上哪个字段保存了我们发送给您的值？ 输入 API 名称，自定义字段需包含 __c 后缀。

字段名进入查询前会按严格模式校验。CRM 字段名只能包含字母、数字与下划线；其他内容一律拒绝，而非转义，因为转义可能出现细微错误，直接拒绝则不会。

3. 何时触发，何时刻意不触发

在识别身份时：网站调用 MousePlayer.setUserId()、分析桥接从 PostHog、Mixpanel 或 Amplitude 读回 distinct ID，或服务器调用 identify 端点时。

每次会话一次，而非每页一次

一个人登录后浏览十一页，只生成一条备注，而非十一条。CRM 时间线是供人阅读的。

没有标识符就不执行

匿名会话没有可用于匹配的值。我们不根据 IP 地址猜测，也不会把录制附加到恰巧共享该地址的人身上。

CRM 不认识此人时不执行

计为已完成，而非失败。潜在客户尚未进入 CRM 是常见情况，明天重试也不会改变。

4. 备注形式与令牌保存位置

联系人时间线上只有一条备注：一行说明会话已录制，再加上链接。销售人员点击后，即可观看此人在发来消息前实际做了什么。

凭据

以 AES-256-GCM 加密存储。保存后不再显示，字段只显示星号；以星号保存表单不会更改已存值。凭据也刻意不放入承载任务的内部队列：队列是共享状态，而共享状态不适合保存密钥。

Salesforce 需要三项，其他平台需要两项

Salesforce 通过带刷新令牌的 Connected App 认证，因此需填写 consumer key、secret、刷新令牌，以及实例 URL。HubSpot 与 Pipedrive 使用单个 API 令牌。三者中的应用都属于您；MousePlayer 不运营需要您信任的市场应用。

5. Zoho CRM 与 Freshsales

又增加了两个 CRM，它们的配置复杂度分别处于两端。

	Zoho CRM	Freshsales
需要提供	数据中心、客户端 ID、客户端密钥、刷新令牌	API 密钥与 Freshworks 域名
查找依据	您指定的字段，默认是 `Email`	您指定的字段，默认是 `email`
备注位置	联系人上，作为 Note 记录	联系人上，作为备注

Zoho 位于六个数据中心之一

账户位于 com、 eu、 in、 com.au、 jp 或 com.cn，密钥中没有任何信息能表明是哪一个。选错时 Zoho 会返回 INVALID_TOKEN ，看起来像密钥有问题，让人查错方向。正因如此，此字段采用下拉选择。

Self Client，只需一次

在 Zoho API 控制台创建 Self Client，为 ZohoCRM.modules.ALL 和 ZohoSearch.securesearch.READ生成 grant token，再一次性交换为刷新令牌。刷新令牌不会过期；每小时有效的访问令牌由其获取，且从不存储。

Zoho 拒绝时也可能返回 200

令牌交换与记录写入均可能返回 HTTP 200，却在正文中包含错误或逐条记录的状态。我们读取正文；若桥接只信状态码，就会对从未创建的备注报告成功。

此处提及的所有商标均属于各自所有者。MousePlayer 与这些提供商不存在商业关系。

需要什么帮助？