到场率下降了：怎样从一个数字找到值得行动的线索？

数字变差了，服务一定变差了吗？

团队先把两个月的预约拆开。上个月工作日有 100 次预约，到场率 90%；周末也有 100 次，到场率 60%。总共 200 次预约，实际到场 150 次，所以总体是 75%。这个月工作日仍是 100 次，周末却增加到 300 次。两个分组的到场率都没变，实际到场变成 90 加 180，共 270 次，除以 400 次预约，恰好就是 67.5%。

原来总体下降，至少可以被预约构成的变化解释：到场率较低的周末，占了更大比例。这还不能说明服务没有问题，但已经足以让团队放下“所有场次都变差了”的最初猜测。分析的第一步，是让一个笼统数字逐渐变得具体。

继续往下查之前，团队还得统一计算方法。这里的一次预约按个人记录还是团体记录计算？已经取消的预约算不算？同一个人改期三次，算一条还是三条？分母就是比率所用的比较基数；基数里放了谁，结论就可能随之改变。只有口径和时间范围一致，两个月的数字才值得比较。

现在问题从“到场率为什么下降”变成了“周末新增的这批预约是什么情况”。这时，只有月度汇总表已经不够。团队需要回到构成数字的具体预约，并且找到与它们相关的场次和场馆。

本节事实核查：官方资料 [3]官方资料 [10]

怎样从一群预约，走到它们对应的场次？

假设业务本体中已经有“预约”“导览场次”“场馆”三类对象，并建立了预约属于哪个场次、场次位于哪个场馆的关系。对象保存的是有业务含义的记录，关系则让系统知道这些记录怎样连在一起。现在选中一批周末预约，就有一条明确的路可以走向它们关联的场次。

从一条具体记录开始，Object Explorer 很适合用来认识数据。工作人员可以搜索一位观众的预约，查看日期、状态和关联场次，再打开场次了解安排。这个过程像沿着已经标明名称的路径查资料，读者不需要先知道每一张底层表叫什么。

如果直接使用分散表格，分析人员通常要根据共同编号把表连接起来。例如用预约里的场次编号找到场次，再用场次里的场馆编号找到场馆。把这类关系预先定义在本体中，相当于让常用关联成为共享的业务知识。新的调查可以复用它，无须每次重新解释编号对应关系。

这份便利也有前提：对象定义和关系要正确，数据要更新到所需时间。对象索引会把来源资料整理成可搜索的对象数据，因此源系统刚刚修改，不一定意味着分析界面已经看到了新值。团队确认时间范围和更新时间后，才能继续追问：这些周末预约有没有共同特点？

本节事实核查：官方资料 [1]官方资料 [3]官方资料 [10]

把一个大问题，拆成能够一步步回答的小问题

团队先选中本月预约，筛出周末，再沿关系找到导览场次，最后按开始时间分组。这是一条分析路径：前一步的结果，成为下一步继续调查的范围。它保留了人是怎样缩小问题的，而不只留下一张最终图表。

Insight 用可视化方式组织这样的步骤。筛选留下符合条件的对象，关联步骤把注意力移向相连的对象，汇总步骤再比较不同分组。假如后来发现需要排除已经取消的预约，可以回到对应步骤调整。同事也能沿着路径理解：这个结论究竟是从哪些记录算出来的。

如果问题进一步变成“下午的场次最近几周有什么变化”，时间就成为重要维度。按小时、天或周排列的记录，就是时间序列。Quiver 可以分析对象和时间序列，并制作能继续筛选、查看细节的图表。团队可以把周末不同场次的预约数量和到场情况按时间放在一起，寻找变化出现的时点。

在这个虚构调查里，团队发现新增预约大多集中在周日下午，而这一时段的改期申请也很多。这是一个更有用的线索：问题可能与行程安排有关。但两个现象同时出现，还不能直接说明“改期困难导致了未到场”。下一步需要把线索变成可以检验的解释。

本节事实核查：官方资料 [2]官方资料 [3]

发现了关系，怎样判断它意味着什么？

团队提出几种可能性。观众可能低估了周末路上的时间；团体组织者可能在临近出发时才确定人数；也可能是改期步骤太繁琐，让一部分人直接放弃。相同的到场数字，可以对应不同原因，而不同原因需要的解决办法也不同。

已有对象关系可以帮助继续查证。例如按预约提前天数、个人或团体、是否申请过改期继续比较，再结合实际访谈了解发生了什么。关系让相关记录更容易被找到，因果判断则还需要合适的比较和证据。否则，任何与未到场同时出现的字段，都可能被误当成原因。

团队还想试一个方案：把一场导览移到另一间展厅，给临时改期留出余量。此时需要的结果已经从“看历史”变成“比较假设改变之后会怎样”。Vertex 可以用系统关系图支持这种分析，并在配置相应模型后计算变化的影响。

例如模型知道每个展厅能容纳多少人、哪些场次使用它、移动场次需要多少讲解员时间，就有可能计算可接待人数和排班影响。模型没有录入的条件，例如临时施工造成的通行困难，就不会自动出现在结果里。模拟因此提供一种有假设的方案比较，结果的可信程度取决于数据与计算规则。

除了已有业务对象，团队此时还收到了客服刚做的一份电话回访表。这份临时资料并没有建进业务本体。是不是必须停下调查，先把所有东西都建模？

本节事实核查：官方资料 [2]官方资料 [3]官方资料 [4]

临时表格和电子表格，也可以加入调查

临时回访表可能只使用一次，团队可以先按表格分析。Contour 支持对表格进行筛选、计算和可视化，也能把结果保存为新数据集。这样，未建模的材料仍可参与调查，不必为每次临时问题都先建立一套长期对象定义。

数据形态和规模也会影响选择。官方用超过 5 万行的汇总、超过 10 万对象的连接举例，说明某些大规模表格操作适合评估 Contour。这些数字是选型场景的例子，并不是所有本体分析工具统一的性能上限。真正要理解的是：围绕已建立的业务关系探索，与对大量表行做计算，侧重点不同。

如果运营负责人习惯用单元格试算“增加一位讲解员需要多少费用”，Fusion 提供电子表格式的工作方式。它可以查询 Foundry 数据，进行计算，并把结果写回数据集。写回的是新的结果数据，不能由此推断为自动执行了所有业务修改；是否真正调岗或批准费用，还需要相应操作。

此时，调查已经有了一些可以保存的产物：需要跟进的预约名单、筛选这些预约的方法，以及会议讨论时使用的数字。它们看起来都能点“保存”，但保存下来的东西并不一样。

本节事实核查：官方资料 [5]官方资料 [6]

保存下来以后，明天打开为什么会变？

假设团队选出 20 条需要回访的预约。如果保存的是静态对象集合，保留的就是这 20 条对象的唯一编号。明天新增的预约不会自动进入名单，不过这 20 条预约自己的状态、金额等属性仍可能变化。固定名单与冻结所有内容，是两个不同的结果。

如果客服要每天看到“当前已取消但尚未退款”的预约，更适合保存动态对象集合。它保留筛选条件，打开时根据当前数据找出符合条件的对象。一条预约处理完退款后会离开待办，新出现的符合条件的预约会进来。因此名单变化，正是它按设计工作的表现。

回顾昨天会议为什么决定增加周末人手，需要的则是当时的数字和解释。Contour 可以把结果保存为数据集，但该数据集以后是否重新生成取决于配置。Notepad 可以把文字、对象和图表放进协作文档，并提供冻结内容的能力，以保留某个时点的上下文。团队可以在文档中写清观察、假设与待验证事项，让其他人读懂当时的判断。

这里还存在多个时间：原系统发生变化的时间、数据接入时间、对象索引更新时间、查询时间，以及文档保存时间。标明“数据截至何时”，能让读者知道自己看到的是最新情况还是历史记录。保存方式选清楚之后，结论就能够被交给真正负责处理问题的人。

本节事实核查：官方资料 [6]官方资料 [7]官方资料 [8]

分析找到线索，应用接着帮助人办事

调查最后把注意力集中到一个具体问题：观众临时想改期时，客服很难同时查到原预约、新场次名额和适用规则。团队于是准备把这些信息放进一个页面，让工作人员更快完成改期。到这里，分析给出了值得处理的问题，接下来需要设计的，是每天怎样把这件事办妥。

分析工具也可以连接操作。Insight 与 Quiver 支持通过 Actions 修改业务本体。例如从选中的预约发起一个已经定义好的处理动作。应用与分析因此可以衔接；它们的侧重点在于，前者把常见办理步骤安排清楚，后者帮助使用者继续提出新问题、寻找解释。下一篇会具体看一个办理页面怎样工作。

分享分析时，看到的范围也可能因权限不同而变化。区域主管只能访问自己场馆的数据，就可能得到与全馆负责人不同的统计结果。资源本身、对象与属性、下游数据和导出都有对应权限要求。图表说明自己的范围，读者才不会把一个区域的平均值当成全部业务的平均值。

应用上线以后，分析还会回来发挥作用。团队可以继续比较改期完成时间、到场率和用户反馈。如果到场数字变好，是因为客群变了，还是因为改期更方便了，仍需要类似的调查。Palantir 把共同的业务对象留在中间，让分析提出的问题能够接到应用，也让应用产生的结果重新成为分析材料。

本节事实核查：官方资料 [2]官方资料 [3]官方资料 [9]

适用边界与容易误解的地方

术语速查

时间序列

按时间顺序排列的一组观测。

分析路径

从选择数据到筛选、关联和计算的步骤记录。

动态对象集合

按保存的筛选条件确定当前成员。

分母

计算比率时作为比较基数的全部对象。

静态对象集合

固定保存一组对象编号；不表示这些对象的属性也被冻结。

来源与核查

对应原文

Rahul Garg · 2026-07-29 · Vanyar

1. Palantir：Object Explorer核对对象搜索与比较定位。
2. Palantir：Insight核对分析路径及动作能力。
3. Palantir：Quiver核对对象、时间序列与分析动作。
4. Palantir：Vertex核对系统图与模拟定位。
5. Palantir：Contour核对表格分析及规模选型示例。
6. Palantir：Fusion核对数据查询与电子表格写回。
7. Palantir：Notepad核对嵌入内容、协作与冻结功能。
8. Palantir：数据集与对象集合核对静态与动态集合以及结果保存。
9. Palantir：对象和属性安全策略核对读取权限与下游共享边界。
10. Palantir：对象索引核对来源资料到对象检索的准备过程。

资料核对日期：2026-09-15。本文用中文概括原文观点，结合一手资料独立讲解；分析、图解和教学示例由本指南编写。主题清单用于检查议题覆盖，不表示逐项复写原文全部细节。产品能力以所在部署的当前官方文档与实际配置为准。