ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

影刀RPA实操指南:天猫超市与天猫旗舰店页面的差异化采集处理

影刀RPA实操指南:天猫超市与天猫旗舰店页面的差异化采集处理 影刀RPA实操指南天猫超市与天猫旗舰店页面的差异化采集处理同样是天猫天猫超市和天猫旗舰店的商品页结构完全是两套东西。我用影刀RPA做天猫商品采集的第一周就栽在这上面在旗舰店调好的流程切到天猫超市一跑价格抓出来是空的图片列表只抓到第一张翻页逻辑直接失效。如果你也要同时采这两个渠道的数据这篇把两边的页面差异、对应的等待策略、元素定位写法和翻页处理逐一拆开讲。核心观点先放这里不要追求一套流程通吃两个页面用If按URL分流两个分支各自维护各自的定位方案反而最稳。这套差异化处理我稳定跑了快一年下面全是实测出来的细节。两个页面的结构差异到底在哪先说差异的来源理解了原因处理方案就顺理成章。天猫旗舰店是标准商品详情页结构一个商品一个页面价格、SKU、主图都在固定区块里页面整体是服务端渲染加局部异步加载。天猫超市更接近卖场结构页面里有大量轮播区、推荐楼层、加购弹层而且很多区块要滚动到可视区域才真正渲染。同一个数据字段两边的DOM层级、class命名、出现时机都不一样。差异具体落在四个采集环节上采集环节天猫旗舰店天猫超市价格元素详情页固定区块加载即出现部分楼层异步渲染需滚动触发主图列表详情页轮播元素一次全渲染楼层图懒加载滚到才出现翻页方式搜索结果页标准页码卖场式加载更多或无限下滑弹窗频率相对少优惠券弹层、加购浮层频繁所以同一套流程在旗舰店跑得好好的到超市这边就是元素找不到、抓不全、翻不动页三种症状轮番出现。对症下药才是正解。URL分流一个入口进入两条处理线流程设计上我做一个统一的采集主流程第一步就是用If条件判断分流。判断依据用页面URL通过网页对象的get_url()方法或者【获取网址】类指令拿到当前URL主流程结构 1. 打开或接收商品/搜索页URL 2. 获取网址 → 存入变量 url 3. If url 包含 chaoshi → 走天猫超市分支子流程 4. Else → 走旗舰店分支子流程 5. 两个分支输出统一格式的数据列表 6. 主流程统一做清洗和写入分流要放在最前面而不是等到抓价格失败了才判断。两个分支各自封装成子流程输出统一的数据格式——商品名、价格、店铺、主图链接四个字段。格式统一这一步很关键下游的清洗和写表逻辑就完全不用关心数据来自哪个渠道。判断条件里还有个细节天猫超市的URL特征字段我实测用的关键词是chaoshi旗舰店常见特征是详情页的item.id参数结构。别用页面标题判断标题会变URL规则稳定得多。旗舰店分支标准详情页的采集要点旗舰店分支相对简单重点是把等待和定位做扎实。等待策略上打开详情页后用【等待元素(web)】等价格元素出现超时15秒。价格元素出现基本意味着核心区块渲染完成比固定等5秒可靠——大促期间页面加载慢固定等待经常翻车。价格定位的XPath我的写法供参考# 捕获元素旗舰店详情页促销价 # 用class含price的元素加父级约束避开划线价、会员价 //*[contains(class,tm-price) or contains(class,price)] [1] # 更稳的写法用参照物定位月销量文字前面的价格区块 //*[contains(text(),月销量)]/ancestor::div[1]//*[contains(class,price)]第二个写法是参照物定位的思路页面改版时参照文字比class存活率高。我两边都维护class的为主参照物的做备胎主定位失效时手动切一下就行。主图采集用【获取相似元素列表】拿轮播图的元素列表循环取每个元素的src属性。注意有些图是懒加载占位src可能是灰底小图真实地址在data-src这类属性里用【获取元素属性】指令指定属性名去取。天猫超市分支滚动、懒加载与弹窗三连超市分支是真正考验功力的地方三个问题要逐个解决。第一个是懒加载。楼层区块滚到可视区才渲染处理套路是边滚边采。用【模拟滚动】或按键PageDown往下滚每滚一段用【获取滚动条位置】拿当前位置和上次比较两次相同说明到底了。已采集的数据用index去重——给每个楼层元素一个序号属性采集时按序号去重避免滚回去重复采。第二个是弹窗。超市页面的优惠券弹层出现时机不固定乱序插入会打断元素操作。两套方案配合用主弹窗在流程里显式处理用【等待元素(web)】等弹窗关闭按钮出现就点掉零散的浮层用【自动处理弹框(web)】指令指定关闭按钮后它会在每次网页操作前自动检查并关掉弹窗。这里有个官方文档里明确标注的坑必须提自动处理弹框指令只对它之后打开的网页生效之前已经打开的网页不生效。所以这条指令要放在打开网页之前。我第一次用的时候放在了打开网页之后弹窗照弹查了半天文档才发现顺序错了。第三个是加载更多式翻页。卖场结构不给你标准页码处理循环是点一次加载更多→等新内容出现→判断是否还有按钮→没有就结束。判断还有没有按钮用【等待元素(web)】的短超时版等不到就认为加载完了。等待策略的选型对比两个分支对等待的依赖程度完全不同这里系统对比一下三种等待的实际表现等待方式旗舰店表现超市表现固定延迟执行稳定时段够用基本不可用【等待元素(web)】等标志元素首选15秒超时配合滚动用局部等待网页对象加载完成事件页面主体 useful楼层仍需二次等待超市页面的正确心态是分段等待页面主体用一个全局等待每个楼层滚动到位后再等该楼层的标志元素。颗粒度细一点稳定性高一截。我把超市分支的等待粒度做到了每个数据字段级别虽然指令数量翻倍但一年下来没因为等待问题崩过。数据格式的差异化清洗两个渠道采回来的原始数据也有差异。超市的价格经常带区间“99.0-199.0”主图链接里混着低清缩略图旗舰店则偶尔抓到划线原价。清洗逻辑放在主流程统一做用Python协同处理# 输入item 字典含 name / price / shop / img 四个字段# 输出清洗后的 item价格统一为 float主图为高清链接importre# 价格处理区间价格取下限去掉非数字字符后转 floatrawitem.get(price,)numsre.findall(r\d\.?\d*,raw)item[price]float(nums[0])ifnumselse-1.0# 主图处理把缩略图URL里常见的尺寸后缀替换成高清版imgitem.get(img,)item[img]re.sub(r_\dx\d\w*\.jpg,.jpg,img)清洗完写入Excel我按渠道分两个Sheet存原始数据再做一个汇总Sheet做跨渠道比价。运营要看的其实是汇总页原始数据留着是为了页面大改版后回溯核对这个设计在去年某次大改版时救过我。防限流与采集节奏天猫对高频访问的容忍度不高两个渠道的策略也略有差异。旗舰店详情页访问模式单一控制好频率即可超市页面操作多、交互密集反而要注意别让流程动作太快显得机械。我的节奏控制做法每次页面跳转之间随机延迟3到6秒同一批次控制在100个商品左右跑完休息一段时间再跑下一批单日总量控制社区版本身每天30分钟运行时长也倒逼你控制批量量大就得上创业版或企业版并配合调度。登录态维护用Cookie保持方案流程开头先检测登录后才有的元素比如用户名区块检测不到就中断流程发飞书通知让人工扫码。别让流程带着未登录状态硬跑采回来的全是游客态价格比价直接失真。调试两个分支的实用技巧两条分支并存时调试要有方法不然改了东边坏西边。用调试断点单步走在分支入口的If判断处打断点确认今天跑的URL走对了分支这是最常见的低级错误来源变量面板常开调试时盯着url变量和采集结果变量数据异常当场就能看到每个分支独立跑通再联调先单独跑超市分支子流程跑通后回到主流程串联输出日志带上渠道标签日志里每条都标超时-超市或超时-旗舰回看日志不用猜工程化上再补一句两个分支的子流程命名我用的编号前缀法“20_旗舰店_详情采集”、“21_超市_卖场采集”编号控排序名字带渠道和职责新人接手看流程树就能懂全貌。易错速查表最后照例给速查表这五个问题是我被问得最多的报错/现象原因解决超市页面抓到空价格楼层未渲染滚动到楼层再加等待元素弹窗关闭按钮点不到弹框指令放晚了自动处理弹框放在打开网页之前主图是灰色小图懒加载占位图取data-src等真实地址属性翻页死循环加载更多按钮一直存在加滚动条位置判断兜底两渠道数据混了分流判断失效核对URL特征词断点看url变量写在最后天猫超市和旗舰店的差异化处理本质是识别差异→分流处理→统一出口三段式。把差异关在各自的子流程里主流程和数据格式保持统一后续加天猫国际、加淘特都是新增一个分支的事。完整流程源码我放在代码仓库 home.linyan.cloud可以直接参考改造两个分支的XPath和滚动判断逻辑都有现成模板。官方文档方面帮助中心搜网页懒加载场景和解决方案、网页数据获取时需要翻页或下拉这两篇写得比我细配合食用效果最好。#影刀RPA #RPA自动化 #天猫采集 #数据采集 #网页自动化 #电商自动化作者林焱
返回列表