JPDD.AI
JPDD.AI是一个类似企查查和天眼查的企业搜索软件。
在这个项目中我的主要任务是如何扩张数据，如何分析用户数据，如何探索有价值数据。
我如何找到问题
我先使用 PostHog 分析真实用户如何使用产品。排除内部测试、机器人和异常流量后，我从数十位真实用户中重建了百余次会话和数百个页面轨迹，观察用户从首页、搜索结果到企业详情页的完整路径，以及结果点击、页面停留、滚动深度和各信息模块的使用情况。
埋点告诉我用户在哪里反复操作、在哪里中断；搜索评测则回答具体问题。我把实际查询放进独立测试链路，逐条检查搜索词能否找到目标企业、结果排在什么位置，以及每次查询的接口和搜索引擎耗时。两类证据结合后，我发现主要问题集中在搜索准确性、详情页信息过载和企业官网数据缺失。
我做的三件核心工作
-
重构企业详情页：原页面把大量信息塞进少数导航入口，用户很难判断某类数据是否存在。我按照企业调查的阅读逻辑，将内容整理为 7 个业务分类和 47 个数据维度，并统一导航、内容顺序和数据计数。长列表改用数字分页，较深内容按需加载，同时增加用户反馈入口，让问题能够回到产品迭代中。
-
建立企业官网核验方法：我分别从已有官网和缺失官网的数据中抽取数百条样本，结合法人番号、名称、地址、电话和代表者判断网站是否属于目标企业。搜索得到的网址先进入候选层，证据不足时交给人工复核，而不是直接覆盖主数据。这个过程后来被整理成可复用的核验流程。
-
设计搜索质量评测链路：我根据公司名、假名、英文名、别名和法人番号生成千余条查询，并人工审核其中数百条关键用例。每次调整搜索逻辑后，都能重新检查目标是否被召回、排名是否退化，以及 API 和 OpenSearch 的加载耗时，从而把“搜索体验不好”变成可以重复验证的问题。
我的思考
这个项目让我形成了一套更清晰的工作方式：先从用户行为和失败样本出发，再把问题拆成数据缺失、召回、排序、速度或信息结构，最后用测试验证修改有没有真正改善结果。
我也意识到，数据并不是越多越好。只有先定义证据等级、失败状态和验证口径，数据才能支持产品决策。比起继续堆叠功能，我更关注系统是否能够被观察、验证并持续改进。