位置智能客户体验利用地理上下文、经授权的业务数据和客户意图，帮助用户发现、比较并对正确的地点采取行动。传统的位置智能通常用于可视化地理空间数据，以支持内部分析。面向客户的产品则回答“哪个地点最符合当前需求”，并提供下一步行动，例如导航、预订、咨询或到店取货。库存和政策仍由可信系统作为权威来源；距离、行程时间和包含关系由地理空间服务计算；语言模型负责解释复杂意图。
下面的内容会先区分仪表盘式位置智能与面向客户的决策界面，然后介绍数据、架构、行业模式、衡量方法以及 Kaleidr 在其中的位置。相关阅读包括什么是位置智能 API？、什么是 Spatial AI？和地图感知 AI 助手：如何构建。
位置智能客户体验的核心原则
- 先定义决策： 在选择地图或模型之前，先明确客户要做出的选择以及业务希望促成的行动。
- 发现 → 比较 → 行动： 找到相关地点，展示可检查的权衡依据，然后进入宿主应用可以完成的下一步。
- 先做硬性筛选，再做排序： 资格和可用性应先于行程时间或偏好。
- AI 负责解释意图： 地理空间服务负责几何计算；业务系统负责库存和政策。
- 衡量行动，而不是热闹程度： 导航、预订、咨询、取货或收藏，比平移地图、点击标记和聊天消息数量更重要。
位置智能客户体验与分析有何不同？
供应商对位置智能的定义仍主要强调面向运营人员的洞察。Esri 目前将其定义为“通过可视化和分析地理空间数据获得的洞察”，通常是在智能地图或仪表盘上叠加人口、交通、环境、经济和天气等数据，使决策者能够规划下一步行动（什么是位置智能？）。Google Maps Platform 采用了相近的框架：将地图和地理空间数据与企业内部客户数据结合，以改善客户体验和业务流程（位置智能：数据驱动成功的新前沿）。Mapbox 在 2026 年 5 月的定义同样把地理空间数据、业务数据、移动和上下文联系起来，使团队能够在运营、战略和客户体验等方面做出决策（什么是位置智能？）。这些页面可以作为各供应商如何使用这一术语的权威说明，但没有任何一个页面定义面向客户的产品契约。
对产品团队而言，真正有用的区分是“产品要完成什么任务”，而不是品牌标签。面向分析的位置智能回答的是：应该在哪里开店、某个区域表现如何、需求集中在哪里。位置智能客户体验回答的是会话中的另一个问题：在这些限制条件下，此时此刻，哪个地点最适合这个客户？选址、区域设计和运营仪表盘仍然重要，但面向客户的这一层仍需获取符合条件的库存、计算空间关系、对剩余选项排序，并把选中的地点交给宿主应用的业务流程。
因此，只在地图上绘制标记并没有完成任务。客户仍要从可能与地图不一致的信息卡中自行推断行程时间、营业时间、库存和政策。决策界面应把这些事实维持在同一个共享状态中，并以企业能够完成的行动作为终点。位置智能 API 指南介绍了这种协调方式的可编程实现。
“发现、比较、行动”如何组织产品？
一个实用的面向客户模型包含三个阶段，并共享同一个搜索状态。“发现”根据起点、地理范围、类别、营业时间、库存和政策识别候选地点。“比较”把权衡关系展示出来，例如行程时间、营业状态、设施、无障碍条件、路线适配度以及企业定义的优先级。“行动”则是产品存在的最终目的——导航、预订、预约、咨询、购买、取货、收藏、分享或联系。以最终行动为起点逆向设计，可以避免做出一张看起来很完整、却让客户不知道下一步该做什么的地图。
“发现”阶段仍然适合传统搜索框和类别筛选器。比如查找活动场地附近的酒店、提供某项服务的门店，或通勤时间不超过某个阈值的房源，很多时候都可以用结构化控件表达。自然语言解释的价值在于客户把多个限制条件组合在一起，例如起点、时间窗口、服务和偏好；如果不用自然语言，这些通常会变成四个独立筛选器。语言模型应把这些条件返回为可查看、可编辑的状态，而不是把它们埋在聊天记录里。
“比较”阶段是地图真正体现价值的地方。普通列表可以按价格或评分排序，却可能隐藏两个“附近”选项其实位于河流两侧、超出步行范围，或位于单向道路的不利一侧。地图、列表和详情面板应始终使用相同的地点 ID，使任一界面的选择都能同步更新其他界面。卡片上展示的理由必须对应已计算或已检索的事实——例如从所选起点出发的行程时间、门店系统报告提供的服务，或业务系统报告的营业时间。
“行动”不是点击一个地图标记。交易、预订或向导航系统的交接由宿主应用负责；空间层应返回稳定的地点 ID、足够解释选择原因的上下文，以及宿主应用已经支持的结构化行动。地图感知助手指南会介绍这类交接所需的共享地图状态和经过验证的操作。
面向客户的地图需要哪些数据和架构？
面向客户的位置智能依赖多个由不同系统所有的数据类别。地点身份——门店、酒店、场馆或房产——属于企业或地点数据提供商。几何信息属于空间系统。库存、可用性、营业时间和预订窗口属于业务后端。客户的起点和偏好在取得同意后属于宿主应用。距离、路线时间和包含关系属于地理空间服务。排序政策属于宿主应用。交互历史属于分析系统。语言模型不应凭空生成已经存在于这些系统中的值。
| 数据类别 | 示例 | 典型所有者 |
|---|---|---|
| 地点身份 | 门店、酒店、场馆、房产 | 企业或地点数据提供商 |
| 几何 | 坐标、边界、路线 | 空间系统 |
| 业务状态 | 库存、可用性、状态 | 业务后端 |
| 时间 | 营业时间、预订窗口、活动日程 | 业务系统 |
| 客户上下文 | 所选起点、偏好 | 宿主应用 |
| 空间关系 | 距离、路线时间、包含关系 | 地理空间服务 |
| 排序 | 资格、相关性、偏好 | 宿主或排序层 |
| 交互 | 搜索、选择、行动 | 分析系统 |
操作顺序和数据本身同样重要。生产流程可以从宿主应用开始，经过授权和业务规则，然后获取地点和库存，执行空间计算、资格判断、排序、解释，再同步输出地图与列表并记录结果分析。如果先生成推荐，之后才检查业务现实，就颠倒了正确顺序，最终会向客户推荐实际上无法使用的地点。
精确几何仍应由空间引擎处理。OGC Simple Feature Access（同时以 ISO 19125 发布）定义了简单要素几何的通用架构，以及实现针对点、曲线、面和集合所提供的空间操作（Simple Feature Access — 第 1 部分）。W3C 与 OGC《Web 空间数据最佳实践》则强调采用 Web 架构和清晰的空间数据实践，使地理对象始终可发现、可复用。因此，在生产系统中，应让语言模型解释意图并选择操作，而由地理空间引擎或数据库计算距离、路线、相交和包含关系。
设备位置只是可选上下文，并非前提条件。W3C 的 Geolocation 规范（2026 年 3 月 26 日的 Candidate Recommendation Snapshot）规定，只有在获得明确许可后才能访问设备位置，而且规范明确指出 API 并不保证设备的真实位置。用户输入的地址、在地图上选择的点或保存的起点往往已经足够，也可以避免收集产品并不需要的精确坐标。关于私有目录和租户数据，请参阅AI 地图工作流中的私有位置数据。
如何让资格、排序和 AI 各司其职？
硬性资格是二元判断：地点是否营业、是否提供该服务、房源是否有效、房间是否可预订、门票是否覆盖该区域、配送范围是否包含该地址。软性偏好则用于比较：更短的行程时间、更符合期望的街区、更相关的设施、偏好的品牌、更低的价格或更合适的时间。系统应先应用硬性条件，再对偏好进行排序。即便坐标很方便，一家已经关门的门店也不应该排在第一位。
位置并不等于最近邻搜索。当步行时间、停车、公共交通、路线方向、服务区域、入口或无障碍条件决定出行质量时，距离最近的坐标可能恰恰是错误选择。有用的空间关系包括：附近、内部、沿路线、在时间预算内可达、同一服务区域、方位关系、两点之间、按路线最近、位于当前选中的地图区域内。产品应计算真正影响决策的空间关系，并把这一关系作为推荐理由展示出来。
当请求难以用单个筛选器表达时，AI 才真正增加价值。“这些酒店里，哪一家从机场最方便，同时又离活动现场近？”同时包含起点、交通方式和第二个目的地。“帮我找一家提供我需要的服务，而且晚上八点后仍营业的门店”同时包含库存或服务、营业时间和起点。语言模型可以把这类自然语言请求转成结构化意图，但可用性、路线时间和地点事实仍应来自可信系统。如果需求已经很简单，就保留确定性的控件，例如“现在营业”“指定半径内”“最高价格”“无障碍”“卧室数量”“支持取货”。当一个复选框更快时，不要强迫客户使用聊天。
把限制条件显示出来可以闭合整个反馈循环。如果客户要求“附近、支持取货、今晚营业”的门店，界面可以显示起点、取货、今晚营业等条件标签。地图和列表应由同一个状态驱动，这样客户修改条件时无需重新开始对话。通过一个共享模型维护起点、地理范围、筛选器、候选 ID、符合条件的 ID、排序和选中地点，可以让聊天、列表、地图和详情保持一致。结果上的理由应引用已检索或已计算的事实，而不是“助手更喜欢这个地点”。
酒店、预订、零售和房地产场景如何使用这一模式？
垂直行业会变化，但核心模式不会。Kaleidr 当前的 Spatial AI 页面介绍了一种 AI 宾客礼宾助手，帮助旅行者在地图上探索住宿、设施和附近合作伙伴，并说明回答可以基于企业自己的库存、品牌语调和政策，而不只是通用 Web 搜索（用于客户发现的 AI 地图聊天）。例如“酒店推荐、步行几分钟能到的晚餐地点”这样的酒店需求，仍应以酒店批准的合作伙伴名单作为数据源。语言模型解释宾客需求；地图展示空间上有效的选项；政策仍由宿主系统控制。
Kaleidr 当前的首页把平台定位在预订和市场平台体验上，其中地点、可用性和客户意图共同影响决策（面向企业的 AI 地图体验）。价格、库存和预订状态的权威来源仍然是预订引擎。空间层帮助客户根据行程匹配度、行程时间和地理上下文比较可用选项。零售也遵循同样的分工：带地图聊天的 AI 门店定位器让门店系统继续作为营业时间和服务的权威来源，再通过对话处理多条件的本地需求。房地产搜索可以在授权库存已有的房源事实之上，加入通勤、公共交通、设施和用户绘制区域等条件。当目的地和旅游地图使用的是精选目录，而非实时交易库存时，也可以采用类似架构；如何构建 AI 驱动的旅游地图介绍了这一工作流。
场馆和导航产品也遵循同样的边界。访客寻找无障碍入口，或查找下一场活动附近的参展商时，需要场馆系统持有的室内或园区几何、票务规则和日程数据。导航通常在“算路线”之前就已经开始，因为客户必须先选择目的地，路由引擎才应该计算路径。在这两类场景中，地理空间服务负责计算关系；访问规则和最终交接仍由宿主系统作为权威来源。
如果产品已经运行 Mapbox、Google Maps、MapLibre 或 Leaflet，团队应把这一层连接到现有渲染器。Kaleidr 当前的开发者文档将 Chat 描述为挂载在实时地图实例上的组件，可以连接这些渲染器，而地图、应用状态和业务流程继续由宿主应用保留（挂载 Chat）。如果体验是精选指南，而不是实时库存循环，可使用已发布的 Studio 地图。Kaleidr Studio 当前支持从提示词开始创作地图，并发布为独立页面或嵌入内容（面向品牌交互式地图的 AI 地图制作工具）。实时预订、门店或房源状态仍应放在开发者集成中。
团队应该如何衡量位置智能客户体验？
衡量方式应沿着客户实际经历的“发现 → 比较 → 行动”路径。Kaleidr Analytics 当前描述的是针对地图和地点互动的仪表盘——包括会话、浏览、交互、受众活动和空间趋势——而不是只围绕 URL 的 Web 分析（地图互动与位置分析）。客户体验项目仍需记录宿主应用本来就知道如何记录的结果事件：选中符合条件的地点、打开导航、开始预订或咨询、开始购买或取货、收藏房源、启动路线。地图平移、缩放和聊天消息数量只是辅助信号，不能证明地图改善了决策。
| 体验 | 有价值的结果 |
|---|---|
| 酒店与款待 | 客人找到地点或服务，或开始预订 |
| 预订 | 开始或完成预订 |
| 房地产 | 收藏房源或开始咨询 |
| 零售 | 选择符合条件的门店、打开导航或开始取货 |
| 活动与场馆 | 确定目的地或解决路线 |
| 导航 | 开始路线或到达目的地 |
| 市场平台 | 选择符合条件的服务提供方并开始交易 |
地理摩擦是传统页面分析很容易遗漏的失败模式。某一区域“无结果”比例高、某门店附近搜索量高但转化低、一些地点经常被比较却很少被选中、查询发生在覆盖范围之外、入口处路线请求频繁失败，或库存与需求地理不匹配，都可能说明数据或资格逻辑存在问题。空间分析仪表盘 KPI介绍了分母、受治理的地点标识符以及保护隐私的聚合方式。
即便单个字段看起来并不敏感，位置数据整体上仍可能高度敏感。精确当前位置、家庭住址、旅行计划或重复出现的搜索起点都可能暴露身份和行为。只有在无法使用用户输入或选择的起点时才收集设备位置；默认不要保存精确搜索坐标；尽可能对分析地理信息做聚合；并把公开地图上下文与私人账户数据分离。W3C Geolocation 规范要求 Web 应用在获取设备位置之前取得明确许可，并指出不同司法辖区的隐私法可能规定更多义务。应把这视为对平台规则的描述，而不是针对特定部署的法律建议。
面向客户的页面绝不应包含高权限服务器凭证。Kaleidr 当前的开发者模型使用可公开的浏览器密钥和面向可信后端的服务器密钥，并使用能力范围进行控制（身份验证与权限范围）。地图 API 身份验证介绍了来源限制和密钥隔离。
Kaleidr 在面向客户的技术栈中处于什么位置？
Kaleidr 当前在首页介绍四个相互关联的层：对话式 Spatial AI、Studio 中的品牌交互地图制作、地点级分析，以及企业开发者基础设施。Spatial AI 界面用于通过自然语言发现地点，并在交互式地图上提供具备地图上下文的推荐。Studio 用于以提示词优先的方式创建和发布品牌地图。Analytics 用于展示受众如何发现地图和地点并与之互动。Enterprise 则为已经拥有渲染器和业务系统的产品技术栈打包位置智能 API、排序和空间基础设施。
最终形成的组合更接近“Spatial AI + 位置智能 + AI 地图”，而不是后台 GIS 仪表盘。Spatial AI 不会取代 Mapbox、Google Maps、MapLibre、GIS 数据库、地理编码、路由，也不会取代宿主系统已经运行的预订和库存系统。数据、权限、业务规则、地图渲染和精确地理计算仍由宿主系统作为权威来源。Spatial AI 层让这些系统更容易被查询和操作，但它不是几何或库存的事实来源。
当工作流高度标准化且精选地图已经足够时，可使用 Studio 或模板路径。当实时应用状态和现有筛选器必须继续保持权威时，将 Chat 挂载到现有地图；如何在地图中加入 AI 聊天介绍了与渲染器的连接方式。当需要私有或授权数据、组织级使用，或需要根据内部系统进行排序时，使用 Enterprise 或 API 集成。
客户体验团队应避免哪些错误？
把位置智能当成只服务于仪表盘的能力，会让客户最终只能得到一个通用地点查找器。默认把最近坐标排在第一位，可能把不符合条件的地点推到前面。让语言模型凭空生成可用性，会让推荐失去可信度。把限制条件藏在聊天记录里，会让客户难以纠正搜索。让地图和列表使用不同查询，会割裂整个体验。只统计地图平移、标记点击或聊天消息，会把“活跃”误认为“价值”。默认收集精确位置，会在不改善决策的情况下增加隐私风险。用对话替代简单筛选器，会让一个复选框就能完成的任务变慢。明明只需挂载新层，却替换已经正常工作的地图技术栈，会增加迁移成本，却没有改变客户要完成的任务。
| 错误 | 结果 | 更好的做法 |
|---|---|---|
| 位置智能只用于仪表盘 | 客户体验仍然很通用 | 把空间上下文放到决策界面中 |
| 最近地点自动排第一 | 不符合条件的地点排在前面 | 先筛选资格，再按路线和意图排序 |
| 模型凭空生成可用性 | 推荐在实际服务点失败 | 让业务系统继续作为权威来源 |
| 聊天条件被隐藏 | 客户无法纠正搜索 | 把意图转成可见状态 |
| 地图和列表使用不同查询 | 各界面出现不一致 | 共享同一个搜索状态 |
| 只看地图交互指标 | 活跃度看起来像成功 | 衡量预订、导航、咨询和收藏 |
| 默认精确定位 | 隐私风险增加 | 只使用满足需求的最小起点信息 |
| 用聊天代替复选框 | 简单任务变慢 | 对明确条件保留筛选器 |
| 不必要地替换渲染器 | 迁移成本增加 | 在现有地图正常工作的地方挂载 Spatial AI |
最终结论
位置智能客户体验最有价值的时刻，是产品不再只告诉客户“地点在哪里”，而开始回答“在当前上下文中，此时此刻，哪个地点最适合这个客户”。Esri、Google Maps Platform 和 Mapbox 仍然围绕“地理空间数据 + 业务上下文”来定义位置智能，目标是帮助做出更好的决策。面向客户的任务则在这些定义之上增加了一层产品契约：发现符合条件的地点，用可检查的空间和业务事实进行比较，然后完成由宿主系统负责的行动。
最简洁的模式是“发现 → 比较 → 行动”，背后由可信业务数据、空间计算、资格判断、排序、解释、地图行动和结果分析共同支撑。语言模型解释意图。可信系统提供事实。地理空间引擎计算关系。应用把结果落实到行动。Kaleidr 当前通过 Spatial AI、Studio、Analytics 和 Enterprise 组织这一闭环，同时让现有渲染器和业务系统继续保持权威地位。
将位置智能加入你的产品
了解位置感知排序、地图感知推荐和企业级空间 API 如何适配现有产品技术栈。可**查看 Kaleidr Enterprise**，了解当前 API、SDK 接口和部署支持。
常见问题
什么是位置智能客户体验？
位置智能客户体验利用地理上下文、地点数据、业务数据和客户意图，帮助用户选择地点并采取下一步行动，例如导航、预订、咨询或到店取货。
面向客户的位置智能与传统位置智能有何不同？
传统位置智能通常支持选址、区域规划或运营等内部分析。面向客户的位置智能则把相关空间上下文放入搜索、预订、购物、房地产、酒店、场馆或导航体验中，让客户能够在当前会话内做出决定。
位置智能一定需要 AI 吗？
不需要。很多任务可以通过确定性的空间查询、筛选和排序完成。当请求组合多个限制条件、偏好或后续问题，而固定控件表达起来很繁琐时，AI 才更有价值。
AI 地图应该使用哪些数据？
坐标、库存、营业时间、可用性、状态和资格应使用权威的地点与业务记录。语言模型应该解释意图和说明结果，而不是创造运营事实。
为什么行程时间通常比直线距离更有用？
直线距离忽略道路、障碍、公共交通和进入方向。如果由路由或行程时间服务进行计算，行程时间通常能更准确表示客户的实际便利程度。
AI 应该替代地图筛选器吗？
通常不应该。筛选器仍适合明确、可重复的限制条件。对话最适合多变量请求，否则这些请求可能会变成很长的筛选表单。
地点应该如何排序？
先应用硬性资格条件，再根据行程时间、可用性、偏好和企业定义的规则对剩余地点排序。展示的理由应对应已检索或已计算的事实。
哪些行业适合面向客户的位置智能？
酒店与款待、预订、房地产、零售、市场平台、活动与场馆、旅游、出行和导航，都需要客户先选择一个真实地点，才能完成后续任务。
团队应该如何衡量这些体验？
衡量有价值的结果，例如选择符合条件的地点、打开导航、开始预订、提交咨询、开始购买、收藏房产或启动路线，而不仅仅是地图浏览量或聊天消息数。
Kaleidr 能与现有地图配合使用吗？
可以。Kaleidr 当前的开发者文档支持把对话式 AI 连接到现有 Mapbox、Google Maps、MapLibre 或 Leaflet 实现中，同时由宿主应用继续保留渲染器和业务系统。
参考资料
- Esri. What is Location Intelligence? 访问于 2026 年 8 月 22 日。 https://www.esri.com/en-us/location-intelligence/overview
- Google Maps Platform. Location intelligence: the new frontier for data-driven success. 访问于 2026 年 8 月 22 日。 https://mapsplatform.google.com/resources/blog/location-intelligence-new-frontier-data-driven-success/
- Kaleidr. AI Map Chat for Customer Discovery. 访问于 2026 年 8 月 22 日。 https://kaleidr.com/ai
- Kaleidr. AI Map Maker for Branded Interactive Maps. 访问于 2026 年 8 月 22 日。 https://kaleidr.com/studio
- Kaleidr. AI-Powered Map Experiences for Business. 访问于 2026 年 8 月 22 日。 https://kaleidr.com/
- Kaleidr. Auth & Scopes. Kaleidr Developer Docs. 访问于 2026 年 8 月 22 日。 https://docs.kaleidr.com/platform-api/auth-and-scopes
- Kaleidr. Chat attach. Kaleidr Developer Docs. 访问于 2026 年 8 月 22 日。 https://docs.kaleidr.com/sdk/chat-attach
- Kaleidr. Location Intelligence APIs and Map SDK. 访问于 2026 年 8 月 22 日。 https://kaleidr.com/enterprise
- Kaleidr. Map Engagement and Location Analytics. 访问于 2026 年 8 月 22 日。 https://kaleidr.com/analytics
- Mapbox. What is location intelligence? 2026 年 5 月 15 日。 https://www.mapbox.com/blog/what-is-location-intelligence
- Open Geospatial Consortium. Simple Feature Access — Part 1: Common Architecture. OGC 06-103r4 / ISO 19125. 访问于 2026 年 8 月 22 日。 https://www.ogc.org/standards/sfa/
- W3C. Geolocation. W3C Candidate Recommendation Snapshot，2026 年 3 月 26 日。访问于 2026 年 8 月 22 日。 https://www.w3.org/TR/geolocation/
- W3C and OGC. Spatial Data on the Web Best Practices. 访问于 2026 年 8 月 22 日。 https://www.w3.org/TR/sdw-bp/
@misc{esri_location_intelligence_2026,
title = {What is Location Intelligence?},
author = {{Esri}},
note = {Accessed 22 August 2026},
url = {https://www.esri.com/en-us/location-intelligence/overview}
}
@misc{google_maps_location_intelligence_2026,
title = {Location intelligence: the new frontier for data-driven success},
author = {{Google Maps Platform}},
note = {Accessed 22 August 2026},
url = {https://mapsplatform.google.com/resources/blog/location-intelligence-new-frontier-data-driven-success/}
}
@misc{mapbox_what_is_location_intelligence_2026,
title = {What is location intelligence?},
author = {Conti, Lorenzo and Schuette, Jazmyn},
year = {2026},
month = {5},
note = {Mapbox; 15 May 2026},
url = {https://www.mapbox.com/blog/what-is-location-intelligence}
}
@misc{ogc_sfa_part1_2026_08_22,
title = {Simple Feature Access -- Part 1: Common Architecture},
author = {{Open Geospatial Consortium}},
note = {OGC 06-103r4 / ISO 19125; accessed 22 August 2026},
url = {https://www.ogc.org/standards/sfa/}
}
@misc{w3c_geolocation_2026,
title = {Geolocation},
author = {{W3C}},
note = {W3C Candidate Recommendation Snapshot, 26 March 2026; accessed 22 August 2026},
url = {https://www.w3.org/TR/geolocation/}
}
@misc{w3c_ogc_sdw_bp_2026,
title = {Spatial Data on the Web Best Practices},
author = {{W3C and OGC}},
note = {Accessed 22 August 2026},
url = {https://www.w3.org/TR/sdw-bp/}
}
@misc{kaleidr_ai_2026_08_22,
title = {AI Map Chat for Customer Discovery},
author = {{Kaleidr}},
note = {Accessed 22 August 2026},
url = {https://kaleidr.com/ai}
}
@misc{kaleidr_home_2026_08_22,
title = {AI-Powered Map Experiences for Business},
author = {{Kaleidr}},
note = {Accessed 22 August 2026},
url = {https://kaleidr.com/}
}
@misc{kaleidr_studio_2026_08_22,
title = {AI Map Maker for Branded Interactive Maps},
author = {{Kaleidr}},
note = {Accessed 22 August 2026},
url = {https://kaleidr.com/studio}
}
@misc{kaleidr_analytics_2026_08_22,
title = {Map Engagement and Location Analytics},
author = {{Kaleidr}},
note = {Accessed 22 August 2026},
url = {https://kaleidr.com/analytics}
}
@misc{kaleidr_enterprise_2026_08_22,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
note = {Accessed 22 August 2026},
url = {https://kaleidr.com/enterprise}
}
@misc{kaleidr_chat_attach_2026_08_22,
title = {Chat attach},
author = {{Kaleidr}},
note = {Kaleidr Developer Docs; accessed 22 August 2026},
url = {https://docs.kaleidr.com/sdk/chat-attach}
}
@misc{kaleidr_auth_scopes_2026_08_22,
title = {Auth \& Scopes},
author = {{Kaleidr}},
note = {Kaleidr Developer Docs; accessed 22 August 2026},
url = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}