电话号码验证与活跃度检查：如何选择合适的文件任务
根据团队需要解决的问题选择 CarrierLookup 的号码验证或号码活跃度检查服务，并确保在对应的产品上下文中解读 activated 字段。
根据团队需要解决的问题选择 CarrierLookup 的号码验证或号码活跃度检查服务，并确保在对应的产品上下文中解读 activated 字段。
对于电话列表，CarrierLookup 的号码验证和号码活跃度检查是两种独立的异步文件处理产品。当问题涉及号码的有效性或激活判定时，请选择验证服务；当问题涉及产品记录的活跃度判定时，请选择活跃度检查服务。activated 列必须结合所选的服务上下文才有意义。
在选择服务前明确列表处理的目标
数据团队在进行新的工作流之前，可能需要清理客户电话列表。某些行可能格式错误，某些行是团队需要进行有效性或激活判定的号码，而另一些行可能需要单独的活跃度信号。这些并非同一个通用的“好号码”问题。请先写下后续的操作：团队是在决定是否在已验证输入的流水线中保留该号码，还是在询问该号码是否具有该产品的活跃度观测结果？答案决定了应请求哪种文件任务。
CarrierLookup 将 number_validation_batch 和 number_activity_batch 记录为两种不同的异步服务。前者处理有效性和激活状态；后者处理活跃度。在按照当前文件规则准备好号码后，可以将列表提交给相应的所选产品。请勿推断活跃度结果可以预测回复、通话连接或消息送达。
为什么相同的列名并不意味着相同的内容
两个结果 CSV 文件都包含 identifier 和 activated。在验证任务中，activated 代表该服务的有效性或激活判定。在活跃度任务中，它代表活跃度判定。因此，布尔值字段在导出任务后本身并不具备自描述性。请为每个导入的值存储服务类型、任务 ID 和检查日期。如果仪表板仅显示 activated=true 而没有产品上下文，则容易引导后续用户得出错误的结论。
明确的 false 值是所选产品已完成的否定答案。缺失值或失败的任务并不等同于 false。请保留单独的“未解决”或“处理中”状态，直到团队确认实际发生了哪种结果。当批处理输出稍后与联系人记录合并时，这一点尤为重要：空白单元格不得导致记录被丢弃，就像服务拒绝了该号码一样。
根据后续工作选择产品
对于数据质量审查，如果缺失的是有效性或激活判定，请选择号码验证。结果可以为团队提供依据，决定是否要求客户更新号码或在使用前检查记录。对于参与度规划审查，如果团队实际使用的是记录的活跃度判定，请选择号码活跃度检查。它不提供活跃度日期、计数、频率或指定的观测窗口。需要这些字段的团队不应根据布尔值结果自行臆造。
当两个问题都很重要时，请将它们视为两个独立的检查，并分别对待其结果含义和成本。一个号码拥有其中一个结果并不意味着它拥有另一个。在运行两个任务之前，请询问这两个值是否都会改变决策；如果第二个结果永远不会被使用，那么额外生成的文件只会增加工作量而没有信息价值。请将任何说明性的路由规则标记为客户的选择，而非服务要求。
保持原始归属运营商查询的独立性
CarrierLookup 的 carrier_batch 是第三种文件产品。它报告号码段最初分配的运营商及相关的分配字段。该答案并非验证或活跃度结果，也不是携号转网后的当前服务运营商。调查运营商分配的团队应直接选择该产品，而不应期望两个 activated 文件产品能揭示运营商字段。
一份有用的选择工作表应包含四列：业务问题、所选服务类型、预期输出字段，以及针对明确的否定或未解决输出所采取的行动。对于验证，请写下有效性判定和 activated；对于活跃度，请写下活跃度判定和 activated；对于分配，请写下运营商问题及其运营商字段。此简表可防止后续报告将不同证据合并在通用的号码状态标签下。
准备经得起 CSV 导入的对比
CarrierLookup 的两种信号文件产品在各自记录的任务限制下接受准备好的电话号码列表。请使用当前的 API 文档 获取接受的输入和实时限制。在应用程序中保留稳定的源行键，并将其与下载的结果进行核对。对于每次运行，请分别记录已提交和已完成的行、明确的 false 值、空值以及任务失败情况。即使源行未产生可用的判定，也应保持可见。
不要通过断言通用的准确率或响应预测来比较这些服务。应通过所回答的问题、实际返回的字段以及结果是否改变了实际的客户工作流来进行比较。下一步是选择一个代表性列表，在每个所选服务旁边写下其预期的判定，并在将其导入 CRM 规则之前，在正确的产品名称下验证生成的 activated 值。
了解更多
选择适合您工作流下一步的产品信息。