要解决的问题
PriceWatch 不负责自动在网上寻找商品，也不负责判断不同网站上的商品是否属于同一个商品。用户自己填写想监控的商品名称、规格等信息，并主动指定一个或多个购物网站，因此可以默认这些网站就是用户希望放在一起比较的对象。
真正的问题是，同一个用户定义的商品在不同网站上的售卖形式可能不同。例如一个网站单件售价 €20，另一个网站 3 件装售价 €45。如果只比较网页显示的总价，会认为 €20 更便宜，但 3 件装的实际单位价格只有 €15。因此 PriceWatch 需要在不增加过多填写负担的前提下，让不同网站的价格具有可比性。
另外，一些网站可能出售商品加配件、赠品或其他商品组成的组合包。组合包与普通单品并不完全等价，如果强行计算单位价格并参与最低价排名，反而可能产生误导。
可选方案
- A. 所有网站只记录当前总价，直接按照网页显示价格进行比较，不处理不同包装数量或组合包。
- B. 用户为每个网站补充数量，PriceWatch 根据当前价格和数量计算 Unit Price，同时展示 Lowest Total Price 和 Lowest Unit Price。不处理组合包。
- C. 在 B 的基础上，组合包不进入普通价格排名。如果组合包本身是用户明确想长期监控的商品，可以创建一个独立商品追踪条目。
- D. 在 B 的基础上，如果用户主要关注原商品，但也希望在某个组合包达到特定价格时收到通知，可以在此商品追踪条目下增加一个独立的提醒，用于监控组合包总价低于某个目标值。
方案权衡
A 的创建流程最简单，但价格比较容易产生误导，尤其是面对单件和多件装时，因此只适合完全相同售卖数量的商品。
B 可以保持同一个商品追踪条目内的商品具有较好的可比性。用户只需要为每个网站多填写数量，普通单品可以视为数量 = 1，多件装则透明地展示“总价 ÷ 数量 = 单价”的计算结果。代价是创建商品追踪条目时增加了少量输入成本。而且组合包仍然参与普通价格排名，可能会产生误导。
C 将组合包作为独立商品追踪条目，可以保持数据模型和价格历史非常清晰，但是用户需要额外创建一个 Watch。
D 更适合组合包只是次要购买机会的情况。例如用户主要监控手机，但也愿意在“手机 + 充电器”低于 5000 kr 时购买。这种情况下没有必要为 Bundle 建立完整的价格比较，只需要追加一个独立提醒即可，而不影响原有 Watch 的价格排名。
最终选择 C。PriceWatch 的目标是帮助用户在不同网站之间进行价格比较，而不是自动判断商品是否相同。组合包的价值因个人而异，例如如果用户已经有充电器，那么“手机 + 充电器”中的充电器对该用户的价值可能接近 0；而另一位需要充电器的用户则会对同一个 Bundle 有不同的价值判断。因此，将组合包拆分为独立的商品追踪条目，可以保持数据模型和价格历史清晰，同时让用户自行决定是否需要监控组合包。
潜在风险
- 用户可能填写错误的数量。例如网站实际出售 24 件装，但用户填写为 12，最终单价会计算错误。因此界面需要明确展示计算依据，并允许用户方便地修改数量。
- 网站本身的售卖数量可能发生变化。例如创建追踪条目时商品是 12 件装，之后商家在同一个 URL 上改为 10 件装。如果用户没有同步修改数量，比较结果可能失真。
- 最低单价可能让用户忽略实际支出。例如 12 件装的单位价格虽然最低，但用户必须一次支付更高的总金额。因此界面必须同时展示单价、数量和总价。
- 用户可能把不同型号、容量或版本的商品加入同一个追踪条目里。PriceWatch 默认信任用户定义的比较关系，因此不需要自动进行商品匹配，但应该清楚展示用户填写的商品规格和每个网站的信息，方便用户自行检查。
- 如果创建追踪条目时要求填写过多字段，可能降低完成率。因此数量等结构化信息应该尽量简单，并只在实际需要价格标准化时出现。
成功指标
- 用户能够在较短时间内创建包含多个购物网站的追踪条目，并理解每个网站的数量和单价是如何参与比较的。
- 当用户输入的价格和数量正确时，单价、最低总价和最低单价的计算结果保持 100% 正确。
- 比较页面能够同时清楚展示总价、购买数量和单位价格，避免用户把最低单位价格误解为最低实际支付金额。
- 用户可以根据组合包的重要程度，在追踪条目上添加笔记，从而更好地区分不同商品或购买形式。
- 数量、总价、提醒条件和笔记能够被方便地修改，以应对购物网站售卖规格发生变化的情况。
- 整体方案能够在创建 Watch 的简单程度、跨网站价格比较的准确性和不同购买形式的灵活性之间保持合理平衡。