EricZhu-42 / SteamTradingSiteTracker

Steam 挂刀行情站 —— 24小时自动更新的 BUFF & IGXE & C5 & UUYP & ECO 挂刀比例数据 | Track cheap Steam Community Market items on buff.163.com, igxe.cn, c5game.com, youpin898.com and ecosteam.cn.
https://www.iflow.work/
MIT License
1.93k stars 83 forks source link

希望额外增加一个按最新成交价的折扣排序 #48

Closed Cliencer closed 5 months ago

Cliencer commented 8 months ago

看了下爬虫源码,其中fetch_volume的过程中应该会收到形如以下的json返回,{"success":true,"lowest_price":"¥ 270.39","volume":"10","median_price":"¥ 212.02"},其中"median_price"就是最近一小时内的成交中位数价,不知道大佬为何不把这个数据利用起来呢,非常需要一个按最新成交价的折扣排序~~~ ———————————— 另外Steam的历史价格的请求格式如下 price_history_fmt = r"https://steamcommunity.com/market/pricehistory/?appid={appid:d}&market_hash_name={hash_name:s}" 返回的是json格式,其中prices包含了过去每一小时的交易价格以及交易数量,可以按照这个计算出某个物品24小时内的平均成交价,一周内的平均成交价等等,如果可以的话(听说Steam API限制很严格)希望能够加入到数据库中方便查阅,谢谢大佬们的无私奉献~~~~

Cliencer commented 8 months ago

已提交PR

EricZhu-42 commented 8 months ago

感谢贡献!我晚些来看一下。

其中"median_price"就是最近一小时内的成交中位数价

我们已经注意到 priceoverview 接口也返回了价格数据。但是,由于缺少可信的信息源以核实该价格数据的实际意义,我们一直没有将这部分数据纳入参考。此外,部分低成交量的饰品似乎不会返回该数据。如果有相关文档或讨论,欢迎随时补充。 _(例如: 若 lowest_price 是 24 小时内的最低成交价格,median_price 是中位数价格,那为何有时 median_price 反而比 lowest_price 更低呢?)_

另外Steam的历史价格的请求格式如下 ...

目前 Steam API 对请求频率限制极为严格。例如,从 itemordershistogram 接口获取实时求购/寄售单数量及价格需要高频更换代理 IP,其流量成本是目前 iflow.work 运行的最大支出项。通过历史价格计算出 24h/7d/30d 成交均价并展示的实现工程量不大,但带来的运行成本提升问题可能是无法忽视的。

总而言之,目前 iflow.work 提供的挂刀数据仅参考实时订单价格。对于某些成交量较低的饰品,通过实际成交价格计算挂刀比例的意义确实更大。如果 priceoverview 接口无法获得有意义的价格数据,通过解析 pricehistory 接口获取一定时间内的实际成交均价也是一种可行的方案。我们会积极考虑该提案,并在成本能够覆盖的情况下优先支持该功能。

Cliencer commented 8 months ago

感谢您的耐心回复。lowest_price并不是最低成交价,而是最低挂卖价,所以比median price高是很正常的,另外部分低成交量的饰品没有该数据可以通过对volume是否大于1来判断掉(您目前的源码就有这部分的判断),所以我认为在不增加额外的api请求情况下,增加这一部分的数据作为排序是比较方便的

Cliencer commented 8 months ago

出于成本考虑,如果不从官方api获取历史成交价格数据,可以考虑自行建立数据库,例如将每次获取的成交价格信息进行储存分析(实际上您目前关于这项api的请求仅利用了volume这个数据,其他的数据都被丢弃)

EricZhu-42 commented 8 months ago

更正 https://github.com/EricZhu-42/SteamTradingSiteTracker/issues/48#issuecomment-2026848176pricehistory 接口似乎验证登录 cookie,不带 cookie 时返回空结果 —— 那基本不太可能从这个接口拿数据了。

EricZhu-42 commented 8 months ago

感谢您的耐心回复。lowest_price并不是最低成交价,而是最低挂卖价,所以比median price高是很正常的,另外部分低成交量的饰品没有该数据可以通过对volume是否大于1来判断掉(您目前的源码就有这部分的判断),所以我认为在不增加额外的api请求情况下,增加这一部分的数据作为排序是比较方便的

似乎没什么问题,晚些我合一下 PR,但前端还需要相应做一些小的调整,我尽量近期有空的时候改好部署到线上。感谢~

Cliencer commented 8 months ago

更正 #48 (comment)pricehistory 接口似乎验证登录 cookie,不带 cookie 时返回空结果 —— 那基本不太可能从这个接口拿数据了。

原来要带cookie吗,这个我确实没有注意到,感谢您的提醒,那确实不适合作为高频获取数据的选择,但自建数据库获得历史价格分析请您再考虑一下,如果可以的话我可以做这方面的数据整理工作,但这需要使用一部分的历史数据,在数据储存方面的结构需要一定程度的调整

Cliencer commented 8 months ago

感谢您的耐心回复。lowest_price并不是最低成交价,而是最低挂卖价,所以比median price高是很正常的,另外部分低成交量的饰品没有该数据可以通过对volume是否大于1来判断掉(您目前的源码就有这部分的判断),所以我认为在不增加额外的api请求情况下,增加这一部分的数据作为排序是比较方便的

似乎没什么问题,晚些我合一下 PR,但前端还需要相应做一些小的调整,我尽量近期有空的时候改好部署到线上。感谢~

提交的PR中我对综合的挂刀比率进行了修改(拍脑子凭感觉进行的加权),这方面需要您再调整一下

EricZhu-42 commented 7 months ago

近期成交比例的显示及排序功能已在 iflow.work 上线。

我们计划重新设计 steam.iflow.work 的新 UI,并在功能完善后替换目前的默认 UI,届时将支持近期成交比例的显示功能。