CN114066346A - 用于从数字消息中获得信息的系统和方法 - Google Patents

Abstract

提供了用于从数字消息中获得信息的系统和方法。本公开部分地涉及用于使用消息中的统一资源定位符（URL）来获得信息的系统和方法。可以使用概率性方法从URL中获得信息，所述概率性方法可以比确定性方法实现更好的结果。此外，可以使用从与URL相关联的web资源获得的信息来补充和/或确认从URL获得的信息。根据实施例，从对应于消息的数字内容中获得web资源的URL。然后可以基于URL和web资源获得装运信息。装运信息可以包括web资源用于跟踪装运的指示、装运的跟踪号和装运的装运提供商中的至少一个。装运信息然后可以被存储，用于稍后获得装运的跟踪更新。

Description

用于从数字消息中获得信息的系统和方法

技术领域

本申请涉及从数字消息中获得信息，并且在特定实施例中，涉及从数字消息中获得装运信息。

背景技术

当顾客通过在线商店订购产品时，顾客可能接收到电子邮件或其他消息，其提供了用于跟踪产品装运的装运信息。该装运信息可以包括促成装运的装运提供商、装运的跟踪号以及对应于用于跟踪装运的网页或其他web资源的统一资源定位符（URL）。通过使用web资源，顾客可以能够查看装运的状态和/或装运的预期交付日期。web资源还可以包括装运提供商和/或装运的跟踪号。

发明内容

在一些情况下，提供装运信息的消息可能变得埋没在顾客的收件箱中，使顾客稍后难以定位消息并获得装运信息。对于频繁地在线订购产品的顾客来说，这个问题可能是复合的，并且在任何给定时间都可能具有多个待处理的产品装运。这些装运中的每一个的跟踪信息将通常以不同的消息提供，这组织起来可能具有挑战性且耗时。照此，顾客可能难以定位一些产品的装运信息，并且甚至可能失去对那些产品的跟踪。附加地或替代地，提供给定装运的跟踪信息的消息可以用顾客可能不太熟悉的语言来编写，并且这可能妨碍跟踪信息的标识、定位和/或理解。

本公开的一些实施例提供了用于从用户的数字消息（包括电子邮件消息、文本消息等）中自动提取装运信息的计算机实现的系统和方法。装运信息然后可以被添加到用户的装运信息的整合列表中，这允许用户避免手动组织和跟踪消息和/或装运信息。换句话说，一旦提取，装运信息等可以诸如例如以定义的和/或一致的格式呈现给用户，和/或可以用于提供这样的呈现。方便地，以这种方式，关于各种装运的信息可以呈现给顾客/用户一瞥，诸如例如所有未完成的（例如，尚未交付）装运的聚合汇总列表，其装运信息是基于消息集合（例如，用户的一个或多个收件箱中的消息）标识的。附加地或替代地，这样的装运信息可以用于其他目的，诸如例如，向用户提供关于他们的各种装运的更新，潜在地针对他们的一些或所有未完成的装运。例如，这样的更新可以以定义的和/或一致的格式一起呈现给用户。在特定示例中，这样的更新可以通过合适的聚合汇总的方式来呈现，其诸如可以列出或以其他方式提供对各种装运的跟踪信息/更新的访问。

基于诸如例如电子邮件消息之类的消息对装运信息的标识可能由于各种原因而非平凡。首先，提供装运信息的消息可能以多种格式。例如，提供关于来自特定商家/装运人/承运人的待处理装运的信息的消息可以以第一格式（例如，就消息的内容和/或其在消息中的布局/布置而言），而另一个商家/装运人/承运人可以采用不同的格式。此外，即使对于同一商家/装运人/承运人来说，这样的格式也可能不时改变或取决于各种因素而变化。附加地，在一些情况下，提供装运指示的消息可以不直接在消息中包括装运信息，而是可以包括可以用于访问网页或其他web资源的一个或多个URL，由此可以获得关于给定装运的信息。例如，这样的信息可以包括跟踪信息、跟踪号等。这些URL及其对应的网页的格式在商家/装运人/承运人之间可能变化，类似于如上面对于消息格式所讨论的。此外，不仅URL的格式和/或它们所对应的网页的内容/布局/格式可能在商家/装运人/承运人之间变化，在一些情况下，它们也可能不时地和/或基于给定商家/装运人/承运人的各种其他因素而变化或改变。

本申请描述了基于消息获得和提取装运信息的各种方式。例如，装运信息可以基于到达用户的（一个或多个）收件箱（诸如例如他们的电子邮件收件箱和/或他们的文本消息（SMS）收件箱）的消息来获得。在一些实施例中，通过以下方式从消息中获得装运信息：a）从消息中提取URL，b）分析URL以确定和/或确认装运信息，以及c）分析对应于URL的web资源以确定和/或确认装运信息。提供概率性方法来确定来自URL和/或web资源的装运信息。例如，当与确定性方法相比时，这些概率性方法可能更适合于处理大量的装运提供商、履行网络、邮政服务提供商和产品装运中可能采用的最后一英里交付服务。因此，概率性方法可以提供更可靠的方式来确定来自消息的装运信息。

根据本公开的一个方面，提供了一种计算机实现的方法。该方法包括为顾客标识多个消息，并从所述多个消息中提取至少一个装运的装运信息。提取包括获得对应于多个消息中的给定消息的数字内容，以及从数字内容中获得web资源的URL。该方法还包括基于该URL和该web资源确定装运的装运信息。装运信息包括web资源用于跟踪装运的指示、装运的跟踪号和装运的装运提供商中的至少一个。该方法进一步包括在存储器中存储装运信息，用于获得装运的跟踪更新。

装运信息可以用于获得所述至少一个装运的跟踪更新。可以提供跟踪更新，以供在为顾客呈现产品装运的聚合汇总中使用。

可以以多种不同方式中的任何一种从URL和web资源中确定装运信息。在一些实施例中，确定装运信息包括通过解析URL来确定跟踪号和装运提供商，以及通过解析web资源来确认跟踪号和装运提供商。在一些实施例中，确定装运信息包括通过解析URL来确定跟踪号和装运提供商中的一个，并且通过解析web资源来确定跟踪号和装运提供商中的另一个。在一些实施例中，确定装运信息包括通过解析web资源来确定跟踪号和装运提供商。

可以实现机器学习（ML）模型来帮助确定装运信息。这些ML模型中的任何一个、一些或全部可以是多任务学习（MTL）模型。在一些实施例中，确定装运信息包括将URL输入到ML模型中，并且基于ML模型的输出，从URL获得对应于跟踪号的文本串。确定装运信息可以进一步包括获得预测，该预测包括对应于URL中跟踪号的起始的第一索引和对应于URL中跟踪号的结束的第二索引，并且将第一索引和第二索引输入到ML模型中。

在一些实施例中，确定装运信息包括将URL输入到ML模型中，以及从ML模型的输出中获得对应于从预定义装运提供商集合中选择的装运提供商的文本串。

在一些实施例中，可以从消息的数字内容中获得多个URL。例如，该方法可以进一步包括从数字内容中获得第二web资源的第二URL。该方法还可以包括基于第二URL和第二web资源确定第二web资源用于跟踪装运、装运的第二跟踪号和装运的第二装运提供商。第一URL和第二URL可以与同一装运相关。因此，该方法可以进一步包括确定第一跟踪号匹配第二跟踪号，并且第一装运提供商匹配第二装运提供商。

在一些实施例中，该方法进一步包括基于数字内容确定消息与跟踪装运相关的步骤。该步骤可以包括将数字内容输入到ML模型中；从ML模型的输出中获得从预定义消息类别集合中选择的消息的消息类别；以及确定消息类别与装运跟踪相关。该步骤也可以或者取而代之地包括将URL输入到ML模型中；从ML模型的输出中获得从预定义URL类别集合中选择的URL的URL类别；以及确定该URL类别与装运跟踪相关。

在一些实施例中，消息对应于特定用户。该方法可以包括将与特定用户相关联的多个装运的装运信息存储在装运信息记录中。用户可查看该记录。照此，该方法可以进一步包括输出装运信息记录的至少一部分，以供显示在与特定用户相关联的设备上。

根据本公开的另一方面，提供了一种系统，该系统包括存储装运信息的存储器，以及执行如本文公开的任何方法的一个或多个处理器。

根据本公开的另外的方面，提供了一种存储指令的计算机可读介质，当所述指令被计算机系统的处理器执行时，使得计算机系统执行本文公开的任何方法。

根据本公开的另外的方面，提供了一种计算机程序，当在计算机的处理器上执行时，所述计算机程序被配置为实行本文公开的任何方法。

因此，提供了一种方法、系统和计算机程序，如随后的权利要求中详细描述的。

附图说明

将参考附图仅作为举例描述了实施例，其中：

图1是根据一个实施例的电子商务平台的框图；

图2是根据一个实施例的管理员主页的示例；

图3图示了图1的电子商务平台但包括消息分析引擎；

图4是图示了根据实施例的用于从数字消息中获得信息的系统的框图；

图5是图示了根据实施例的用于分析消息以获得装运信息的方法的流程图；

图6图示了根据实施例的与跟踪装运相关的电子邮件消息；

图7图示了对应于图6的电子邮件消息中的跟踪URL的网页；

图8图示了根据另一实施例的与跟踪装运相关的电子邮件消息；

图9图示了对应于图8的电子邮件消息中的跟踪URL的网页；以及

图10图示了根据实施例的装运信息的整合记录。

具体实施方式

出于说明性目的，现在将在下面结合各图更详细地解释具体的示例实施例。

示例电子商务平台

在一些实施例中，本文公开的方法可以在商务平台上执行或与商务平台相关联地执行，该商务平台在本文将被称为电子商务平台。因此，将描述电子商务平台的示例。

图1图示了根据一个实施例的电子商务平台100。电子商务平台100可以用于向顾客提供商家产品和服务。虽然本公开考虑使用装置、系统和过程来购买产品和服务，但是为了简单起见，本文中的描述将适用于产品。贯穿本公开的对产品的所有引用也应当被理解为是对产品和/或服务的引用，包括实体产品、数字内容、票、订阅、待提供的服务等。

虽然本公开通篇考虑“商家”和“顾客”可以不止是个人，但是为了简单起见，本文中的描述一般可以照此指代商家和顾客。贯穿本公开对商家和顾客的所有引用也应当被理解为对个人、公司、企业、计算实体等的群组的引用，并且可以表示为了盈利或不为了盈利的产品交换。此外，虽然本公开通篇涉及“商家”和“顾客”，并且照此描述了它们的角色，但是电子商务平台100应当被理解为更一般地支持电子商务环境中的用户，并且贯穿本公开对商家和顾客的所有引用也应当被理解为对用户的引用，诸如其中用户是商家用户（例如，产品的销售者、零售商、批发商或提供商）、顾客-用户（例如，产品的买方、购买代理或用户）、预期用户（例如，浏览并且尚未承诺购买的用户、针对在营销和销售产品中的潜在使用来评估电子商务平台100的用户等等）、服务提供商用户（例如，装运提供商112、金融提供商等）、公司或企业用户（例如，代表购买、销售或使用产品的公司；企业用户；顾客关系或顾客管理代理等）、信息技术用户、计算实体用户（例如，用于产品的购买、销售或使用的计算机器人）等。

电子商务平台100可以提供用于向商家提供用于管理其业务的在线资源和设施的集中式系统。本文所述的设施可以通过在可以是平台100的一部分或在其外部的一个或多个处理器上执行计算机软件、模块、程序代码和/或指令的机器来部分或全部部署。商家可以诸如通过以下各项来利用电子商务平台100管理与顾客的商务：经由在线商店138、经由渠道110A-B、经由物理位置（例如，实体店面或其他位置，诸如经由售货亭、终端、读取器、打印机、3D打印机等）中的POS设备152实现与顾客的电子商务体验，经由电子商务平台100管理其业务，以及经由电子商务平台100的通信设施129与顾客交互，或其任何组合。商家可以将电子商务平台100用作与顾客的仅有商务存在，或者与其他商家商务设施结合利用电子商务平台100，该利用诸如经由物理商店（例如，“实体（brick-and-mortar）”零售商店）、商家平台外网站104（例如，与电子商务平台独立地由商家支持或代表商家的商务互联网网站或其他互联网或web财产或资产）等。然而，甚至这些“其他”商家商务设施可被结合到电子商务平台中，诸如其中商家的物理商店中的POS设备152被链接到电子商务平台100中、其中商家平台外网站104被绑定到电子商务平台100中，诸如经由将内容从商家平台外网站104链接到在线商店138的“购买按钮”等等来绑定。

在线商店138可以表示包括多个虚拟店面的多租户设施。在实施例中，商家可以诸如经由商家设备102（例如，计算机、膝上型计算机、移动计算设备等）来管理在线商店138中的一个或多个店面，并且经由多个不同的渠道110A-B（例如，在线商店138；经由POS设备152的实体店面；电子市场；经由整合到诸如社交网络、社交媒体页面、社交媒体消息传送系统上的网站或社交媒体渠道中的电子购买按钮；等）来向顾客提供产品。商家可以跨渠道110A-B销售，并且然后通过电子商务平台100管理其销售，其中渠道110A可以在电子商务平台100内部提供，或者从电子商务渠道110B外部提供。商家可以在其实体零售店中、在弹出窗口处、通过批发、通过电话等进行销售，并且然后通过电子商务平台100管理其销售。商家可以采用这些的全部或任何组合，诸如通过利用POS设备152的实体店面来维护业务、通过在线商店138来维护虚拟店面、以及利用通信设施129来利用顾客交互和分析132以改进销售的概率。贯穿本公开，术语在线商店138和店面可以同义地用于指代通过电子商务平台100提供存在的商家的在线电子商务，其中在线商店138可以指代由电子商务平台100支持的店面的多租户集合（例如，针对多个商家）或者指代个体商家的店面（例如，商家的在线商店）。

在一些实施例中，顾客可以通过如下各项进行交互：顾客设备150（例如，计算机、膝上型计算机、移动计算设备等）、POS设备152（例如，零售设备、售货亭、自动结账系统等）或本领域已知的任何其他商务接口设备。电子商务平台100可以使商家能够通过在线商店138、通过物理位置（例如，商家的店面或别处）中的POS设备152联系上顾客，以通过经由电子通信设施129的对话等来促进与顾客的商务，从而提供用于联系上顾客并且针对可用于联系上顾客并与顾客交互的现实或虚拟路径而便于商家服务的系统。

在一些实施例中，并且如本文进一步描述的，电子商务平台100可以通过包括处理器和存储器的处理设施来实现，处理设施存储指令集，该指令集当被执行时使得电子商务平台100执行如本文描述的电子商务和支持功能。处理设施可以是服务器、客户端、网络基础设施、移动计算平台、云计算平台、固定计算平台或其他计算平台的部分，并且提供在电子商务平台100、商家设备102、支付网关106、应用开发者、渠道110A-B、装运提供商112、顾客设备150、销售点设备152等等的电子组件之间以及它们的电子组件当中的电子连接性和通信。电子商务平台100可以诸如在软件和交付模型中被实现为云计算服务、软件即服务（SaaS）、基础设施即服务（IaaS）、平台即服务（PaaS）、桌面即服务（DaaS）、管理软件即服务（MSaaS）、移动后端即服务（MBaaS）、信息技术管理即服务（ITMaaS）等，诸如在软件和交付模型中，软件在订阅的基础上被许可并且被集中托管（例如，由用户使用客户端（例如，瘦客户端）经由web浏览器或其他应用访问、通过由POS设备访问等）。在一些实施例中，电子商务平台100的元素可以被实现为在各种平台和操作系统上操作，该各种平台和操作系统诸如是iOS、安卓、在web上等（例如，管理器114在针对iOS、安卓的给定在线商店以及针对web的多个实例中被实现，每个实例都具有类似的功能）。

在一些实施例中，在线商店138可以通过由电子商务平台100的服务器提供的网页来提供给顾客设备150。服务器可以从安装在顾客设备150上的浏览器或其他应用接收对网页的请求，其中，浏览器（或其他应用）通过IP地址连接到服务器，IP地址通过转换域名来获得。作为回应，服务器发送回所请求的网页。网页可以用超文本标记语言（HTML）、模板语言、JavaScript等或其任何组合来编写、或包括超文本标记语言（HTML）、模板语言、JavaScript等或其任何组合。例如，HTML是描述网页的静态信息的计算机语言，该网页的静态信息诸如是网页的布局、格式和内容。网站设计者和开发者可以使用模板语言来构建网页，网页将在多个页面上相同的静态内容和从一个页面到下一个页面改变的动态内容进行组合。模板语言可以使得有可能在利用来自在线商店的数据动态地填充页面的同时重新使用定义网页布局的静态元素。静态元素可以用HTML编写，而动态元素可以用模板语言编写。文件中的模板语言元素可以充当占位符，使得文件中的代码被编译并发送到顾客设备150，并且然后诸如当安装主题时模板语言被来自在线商店138的数据替换。模板和主题可以考虑标签、对象和过滤器。客户端设备web浏览器（或其他应用）然后相应地渲染页面。

在一些实施例中，在线商店138可以由电子商务平台100提供给顾客，其中，顾客可以浏览和购买各种可获得的产品（例如，将它们添加到购物车、通过购买按钮立即购买等）。在线商店138可以以透明的方式提供给顾客，而顾客不必意识到它是通过电子商务平台100提供的（而不是直接从商家提供的）。商家可以使用商家可配置域名、可定制HTML主题等来定制其在线商店138。商家可以通过主题系统定制他们网站的外观和感觉，诸如其中商家可以通过改变他们的主题同时具有在在线商店的产品层次内示出的相同的基础产品和商务数据来选择和改变他们的在线商店138的外观和感觉。主题可以通过主题编辑器进一步定制，该主题编辑器是使得用户能够在具有灵活性的情况下定制其网站的设计的设计接口。主题还可以使用改变诸如特定颜色、字体和预先构建的布局方案之类的方面的主题特定设置来定制。在线商店可以实现用于网站内容的内容管理系统。商家可以创作博客帖子或静态页面，并诸如通过博客、文章等将它们发布到其在线商店138，以及配置导航菜单。商家可以将图像（例如，用于产品的图像）、视频、内容、数据等上传到电子商务平台100，诸如供系统存储（例如，存储为数据134）。在一些实施例中，电子商务平台100可以提供用于对图像重新定尺寸、将图像与产品相关联、添加文本并将文本与图像相关联、添加用于新产品变体的图像、保护图像等的功能。

如本文所描述的，电子商务平台100可以通过包括在线商店138的多个不同的渠道110A-B、通过电话以及通过物理POS设备152（如本文描述）来向商家提供用于产品的交易设施。电子商务平台100可以包括与运行在线业务相关联的业务支持服务116、管理器114等，从而诸如提供与其在线商店相关联的域服务118、用于便于与顾客的交易的支付服务120、用于提供所购买产品的顾客装运选项的装运服务122、与产品保护和责任相关联的风险和保险服务124、给商家开账单等。服务116可以经由电子商务平台100或与外部设施相关联地提供，诸如通过用于支付处理的支付网关106、用于加速产品装运的装运提供商112等来提供。

在一些实施例中，电子商务平台100可以提供整合的装运服务122（例如，通过电子商务平台装运设施或通过第三方装运承运人），从而诸如向商家提供实时更新、跟踪、自动费率计算、大宗订单准备、标签打印等。

图2描述了用于管理器114的主页的非限制性实施例，其可以示出关于日常任务、商店的新近活动、以及商家为构建其业务可以采取的接下来步骤的信息。在一些实施例中，商家可以经由商家设备102诸如从台式计算机或移动设备登录到管理器114，并且管理其在线商店138的各方面，从而诸如查看在线商店138的新近活动、更新在线商店138的目录、管理订单、新近访问活动、总订单活动等。在一些实施例中，商家可能能够通过使用边注栏（sidebar）来访问管理器114的不同区段，诸如在图2上所示的。管理器114的区段可以包括用于访问和管理商家的业务的核心方面的各种接口，包括订单、产品、顾客、可用报告和折扣。管理器114还可以包括用于管理商店的销售渠道的接口，包括在线商店、使顾客可用于访问商店的（一个或多个）移动应用（移动App）、POS设备和/或购买按钮。管理器114还可以包括用于管理安装在商家的账户上的应用（App）的接口；应用于商家的在线商店138和账户的设置。商家可使用搜索栏来查找产品、页面或其他信息。取决于商家正在使用的设备102或软件应用，可以通过管理员114使得它们能够用于不同的功能。例如，如果商家从浏览器登录到管理器114，则他们可以能够管理他们的在线商店138的所有方面。如果商家从其移动设备登录（例如，经由移动应用），则他们可能能够查看其在线商店138的所有方面或其子集，诸如查看在线商店138的新近活动、更新在线商店138的目录、管理订单等。

可以通过获取报告或度量来查看关于商家的在线商店138的商务和访问者的更详细的信息，该报告或度量诸如显示商家的总体业务的销售概要、有效销售渠道的具体销售和参与数据等。报告可以包括获取报告、行为报告、顾客报告、财务报告、营销报告、销售报告、定制报告等。商家可以能够例如通过使用下拉菜单查看来自不同时间段（例如，天、周、月等）的不同渠道110A-B的销售数据。可以为想要更详细地查看商店的销售和参与数据的商家提供概况仪表板。可以提供主页度量区段中的活动提要以说明商家账户上的活动的概况。例如，通过点击“查看所有新近活动”仪表板按钮，商家可以能够看到其账户上新近活动的较长提要。主页可以诸如基于账户状态、增长、新近顾客活动等示出关于商家的在线商店138的通知。可以提供通知以辅助商家导航通过诸如捕获支付、将订单标记为已履行、将完成的订单存档等之类的过程。

电子商务平台100可以提供通信设施129和相关联的商家接口，其用于提供电子通信和营销，诸如利用电子消息传送聚合设施来收集和分析商家、顾客、商家设备102、顾客设备150、POS设备152等之间的通信交互，以聚合和分析通信，诸如用于增加提供产品销售的潜力等。例如，顾客可能具有与产品相关的问题，该问题可以在顾客和商家（或表示商家的基于自动化处理器的代理）之间产生对话，其中，通信设施129对该交互进行分析，并且向商家提供关于如何改进销售的概率的分析。

电子商务平台100可以提供金融设施120，其用于诸如通过安全卡服务器环境来与顾客进行安全金融交易。电子商务平台100可以可以将信用卡信息存储在诸如支付卡行业数据（PCI）环境（例如，卡服务器）中，以便核对财务、向商家开账单、在电子商务平台100金融机构账户和商家的银行账户之间执行自动化票据交换所（ACH）转账（例如，当使用资金时）等。这些系统可以具有Sarbanes-Oxley Act（SOX）合规以及在它们的开发和操作中所需的高水平的勤勉。金融设施120还可以诸如通过资金的借贷（例如，借贷资金、现金预付等）和保险的提供来向商家提供金融支持。另外，电子商务平台100可以营销和合作方服务的集合，并且控制电子商务平台100和合作方之间的关系。它们还可以将新的商家与电子商务平台100连接并搭载（onboard）起来。这些服务可以通过使商家更容易地跨电子商务平台100工作来实现商家增长。通过这些服务，可以经由电子商务平台100向商家提供帮助设施。

在一些实施例中，在线商店138可以支持大量独立管理的店面，并且每天针对各种产品处理大体量交易数据。交易数据可以包括顾客联系信息、账单信息、装运信息、关于所购买的产品的信息、关于所呈递的服务的信息、以及与通过电子商务平台100的业务相关联的任何其他信息。在一些实施例中，电子商务平台100可以将该数据存储在数据设施134中。交易数据可以被处理以产生分析132，该分析132进而可以被提供给商家或第三方商务实体，从而诸如提供顾客趋势、营销和销售洞察力、用于改进销售的推荐、对顾客行为的评估、营销和销售建模、欺诈趋势等，其与在线商务有关，并且通过仪表板接口、通过报告等来被提供。电子商务平台100可以存储关于业务和商家交易的信息，并且数据设施134可以具有增强、贡献、细化和提取数据的许多方式，其中随着时间的推移，所收集的数据可以使得能够实现对电子商务平台100的各方面的改进。

再次参考图1，在一些实施例中，电子商务平台100可以被配置有用于内容管理、任务自动化和数据管理的商务管理引擎136，以使得能够实现对多个在线商店138（例如，与产品、库存、顾客、订单、合作、供应商、报告、财务、风险和欺诈等相关）进行支持和服务，但是可通过应用142A-B扩展，这些应用使得能够实现适应日益增长的各种商家在线商店、POS设备、产品和服务所需的更大灵活性和定制过程，其中，应用142A可以在电子商务平台100内部提供或者从电子商务平台100外部提供应用142B。在一些实施例中，可以由提供平台100的同一方或由不同方提供应用142A。在一些实施例中，可以由提供平台100的同一方或由不同方提供应用142B。商务管理引擎136可以通过诸如按顾客标识符、订单标识符、在线商店标识符等划分（例如，分片）功能和数据来为了灵活性和可扩展性进行配置。商务管理引擎136可以适应特定于商店的业务逻辑，并且在一些实施例中，可以结合管理器114和/或在线商店138。

商务管理引擎136包括电子商务平台100的基本或“核心”功能，并且照此，如本文所述，并非支持在线商店138的所有功能都可能适于包括在内。例如，用于包括在商务管理引擎136中的功能可能需要超过核心功能阈值，通过该阈值可以确定的是：功能是商务体验的核心（例如，对于大多数在线商店活动是共同的，诸如跨渠道、管理器接口、商家位置、行业、产品类型等），是跨在线商店138可重复使用的（例如，可以跨核心功能重复使用/修改的功能），限于一次单个在线商店138的上下文（例如，实现在线商店“隔离原则”，其中，代码不应当能够一次与多个在线商店138交互，从而确保在线商店138不能访问彼此的数据），提供交易工作负载等。维持对实现什么功能的控制可以使得商务管理引擎136能够保持响应，因为许多所需特征要么由商务管理引擎136直接提供，要么通过接口140A-B来使能实现，诸如通过其经由到应用142A-B和渠道110A-B的应用编程接口（API）连接的扩展来使能实现，其中，接口140A可以被提供给电子商务平台100内部的应用142A和/或渠道110A，或者通过被提供给电子商务平台100外部的应用142B和/或渠道110B的接口140B。通常，平台100可以包括接口140A-B（其可以是扩展、连接器、API等），其便于与其他平台、系统、软件、数据源、代码等的连接和通信。更概括地说，这样的接口140A-B可以是商务管理引擎136的接口140A或平台100的接口140B。如果没有对限制商务管理引擎136中的功能给予关注，则则响应性可能诸如通过以下各项而受到损害：经由慢速数据库或非关键后端故障所致的基础设施降级、诸如在数据中心离线情况下的灾难性的基础设施故障、花费比预期更长的时间来执行的部署的新代码等。为了防止或减轻这些情形，商务管理引擎136可被配置为诸如通过利用超时、排队、反向压力来防止降级等的配置来维持响应性。

尽管隔离在线商店数据对于维护在线商店138与商家之间的数据隐私是重要的，但例如诸如对于订单风险评估系统或平台支付设施的情况下可能存在收集和使用跨商店数据的原因，这两者都需要来自多个在线商店138的信息才得以良好地执行。在一些实施例中，不是违反隔离原则，而可以优选的是将这些组件移出商务管理引擎136并移入电子商务平台100内其自己的基础设施中。

在一些实施例中，电子商务平台100可以提供平台支付设施120，其是利用来自商务管理引擎136的数据但是可以位于外部以便不违反隔离原则的组件的另一示例。平台支付设施120可以允许与在线商店138交互的顾客使其支付信息由商务管理引擎136安全地存储，使得他们仅必须输入支付信息一次。当顾客访问不同的在线商店138时，即使他们以前从未去过那里，平台支付设施120也可以调用他们的信息以使能实现更快速和正确的结帐。这可以提供跨平台网络效果，其中电子商务平台100随着更多商家加入而变得对其商家更有用，诸如因为存在更多顾客，这些顾客由于相对于顾客购买的使用容易而更频繁地结账。为了最大化该网络的效果，给定顾客的支付信息可以从在线商店的结帐处可检索，从而允许信息跨在线商店138全局可用。对于每个在线商店138来说，能够连接到任何其他在线商店138以检索存储在那里的支付信息将是困难的并且容易出错。结果，平台支付设施可以在商务管理引擎136的外部实现。

对于未包括在商务管理引擎136内的那些功能，应用142A-B提供了向电子商务平台100添加特征的方式。应用142A-B可以能够访问和修改关于商家的在线商店138的数据，通过管理器114执行任务，通过（例如，通过扩展/API被表面显示的）用户接口为商家创建新流量等等。可以使得商家能够通过应用搜索、推荐和支持128来发现和安装应用142A-B。在一些实施例中，核心产品、核心扩展点、应用和管理器114可以被开发成一起工作。例如，应用扩展点可以构建在管理器114内部，使得核心特征可以借助于应用而被扩展，该应用可以通过扩展将功能交付给商家。

在一些实施例中，应用142A-B可以通过接口140A-B向商家交付功能，诸如在应用142A-B能够向商家表面显示交易数据的情况下（例如，App：“引擎，使用嵌入式app SDK在移动和web管理器中表面显示我的app数据）、和/或在商务管理引擎136能够要求应用按需求执行工作的情况下（引擎：“App，给我用于该结帐的本地税务计算”）。

应用142A-B可以支持在线商店138和渠道110A-B，提供商家支持，与其他服务整合等。在商务管理引擎136可以向在线商店138提供服务基础的情况下，应用142A-B可以为商家提供用以满足特定的并且有时是唯一的需要的方式。不同的商家将具有不同的需要，并且因此可以受益于不同的应用142A-B。应用142A-B可以更好地通过电子商务平台100被发现，这是通过开发应用分类法（类别），所述应用分类法（类别）使得应用能够根据它为商家执行的功能类型被标记；通过支持搜索、评级和推荐模型的应用数据服务；通过应用发现接口，诸如应用商店、主页信息卡、应用设置页面；等等。

应用142A-B可以通过接口140A-B连接到商务管理引擎136，诸如利用API来向应用的功能展示通过商务管理引擎136和在其内可用的功能和数据（例如，通过REST、GraphQL等）。例如，电子商务平台100可以向面向商家和面向合作方的产品和服务提供API接口140A-B，该面向商家和合作方的产品和服务诸如包括应用扩展、过程流服务、面向开发者的资源等。随着顾客更频繁地使用移动设备来购物，与移动使用相关的应用142A-B可以受益于对API的更广泛的使用，以支持相关不断增长的商务业务量。通过使用应用和API（例如，如为应用开发所提供的）而提供的灵活性使得电子商务平台100能够更好地适应商家（以及通过内部API的内部开发者）的新的和唯一的需要，而不需要对商务管理引擎136的持续改变，因而在商家需要他们所需要的东西时向他们提供它们。例如，可以通过装运或承运人服务API将装运服务122与商务管理引擎136整合，因而使得电子商务平台100能够提供装运服务功能，而不直接影响在商务管理引擎136中运行的代码。

许多商家问题可以通过让合作方通过应用开发来改进和扩展商家工作流来解决，诸如与后台操作（面向商家的应用142A-B）相关联的、以及在线商店138（面向顾客的应用142A-B）中的问题。作为进行业务的一部分，许多商家将每天使用移动和web相关的应用来进行后台任务（例如，推销、库存、折扣、履行等）和在线商店任务（例如，与其在线商店相关的应用，用于快闪销售、新产品供应等），其中，应用142A-B通过扩展/API 140A-B帮助使产品在快速增长的市场中易于查看和购买。在一些实施例中，合作方、应用开发者、内部应用设施等可以被提供有软件开发工具包（SDK），诸如通过在管理器114内创建将应用接口沙盒化的框架。在一些实施例中，管理器114可能不具有对框架内发生了什么的控制也意识不到框架内发生了什么。SDK可以与用户接口工具包结合使用，以产生模仿电子商务平台100的外观和感觉的接口，例如充当商务管理引擎136的扩展。

利用API的应用142A-B可以按需求拉取数据，但是它们通常还需要在发生更新时推送数据。更新事件可以按订阅模型来实现，例如诸如顾客创建、产品改变或订单取消。更新事件可以向商家提供关于商务管理引擎136的改变状态的所需更新，诸如用于同步本地数据库、通知外部整合合作方等。诸如通过更新事件订阅，更新事件可以使得能够实现此功能，而不必一直轮询商务管理引擎136来针对更新进行检查。在一些实施例中，当发生与更新事件订阅相关的改变时，商务管理引擎136可以诸如针对预定义的回调URL发布请求。该请求的主体可以包含对象的新状态和动作或事件的描述。可以在管理器设施114中手动创建或者自动创建（例如，经由API 140A-B）更新事件订阅。在一些实施例中，更新事件可以排队并且与触发它们的状态改变异步地处理，这可以产生未被实时分发的更新事件通知。

在一些实施例中，电子商务平台100可提供应用搜索、推荐和支持128。应用搜索、推荐和支持128可以包括：用以帮助应用开发的开发者产品和工具；应用仪表板（例如，用以向开发者提供开发接口、向管理器提供应用的管理、向商家提供应用的定制等）；用于安装和提供关于提供对应用142A-B的访问的许可的设施（例如，对于公共访问而言，诸如在安装之前必须满足准则的情况下，或者用于商家的私人使用）；应用搜索，用以使得商家易于搜索满足针对他们的在线商店138的需要的应用142A-B；应用推荐，用以向商家提供关于他们如何能够通过他们的在线商店138来改进用户体验的建议；对商务管理引擎136内的核心应用能力的描述；等等。这些支持设施可以由任何实体执行的应用开发所利用，所述任何实体包括开发其自己的应用142A-B的商家、开发应用142A-B（例如，由商家签订合同、凭他们自己开发以提供给公众、签订合同以供与电子商务平台100相关联地使用等）的第三方开发者、或者由与电子商务平台100相关联的内部个人资源开发的应用142A或142B。在一些实施例中，应用142A-B可以被分配应用标识符（ID），诸如用于链接到应用（例如，通过API）、针对应用进行搜索、进行应用推荐等。

商务管理引擎136可以包括电子商务平台100的基本功能，并且通过API 140A-B将这些功能展示给应用142A-B。API 140A-B可以使能实现通过应用开发构建的不同类型的应用。应用142A-B能够满足商家的各种需要，但是可以粗略地分为三类：面向顾客的应用、面向商家的应用、整合应用等。面向顾客的应用142A-B可以包括在线商店138或作为商家可以列出产品并让它们购买的地方的渠道110A-B（例如，在线商店、用于快闪销售的应用（例如，商家产品或来自第三方源的机会性销售机会）、移动商店应用、社交媒体渠道、用于提供批发购买的应用等）。面向商家的应用142A-B可以包括以下应用，这些应用允许商家管理其在线商店138（例如，通过与web或网站相关、或与移动设备相关的应用）、运行其业务（例如，通过与POS设备相关的应用）、增长其业务（例如，通过与装运（例如，投递装运）相关的应用、使用自动化代理、使用过程流开发和改进）等。整合应用可以包括提供参与业务运行的有用整合的应用，诸如装运提供商112和支付网关。

在一些实施例中，应用开发者可以使用应用代理来从外部位置获取数据并将其显示于在线商店138的页面上。这些代理页面上的内容可以是动态的、能够被更新等等。应用代理对于显示图像图库、统计、定制表单和其他种类的动态内容可以是有用的。电子商务平台100的核心应用结构可以允许在应用142A-B中构建数量日益增长的商家体验，使得商务管理引擎136可以保持关注于更普遍利用的商务业务逻辑。

电子商务平台100通过精编的系统架构来提供在线购物体验，该精编的架构使得商家能够以灵活且透明的方式与顾客连接。典型的顾客体验可以通过示例性示例购买工作流来更好地理解，其中，顾客在渠道110A-B上浏览商家的产品，将他们意图购买的东西添加到他们的购物车中，继续进行结账，并为他们的购物车的内容付费，从而导致针对商家的订单创建。然后，商家可以审阅并履行（或取消）订单。然后将产品交付给顾客。如果顾客不满意，则他们可以将产品退货给商家。

在示例实施例中，顾客可以在渠道110A-B上浏览商家的产品。渠道110A-B是其中顾客可以查看和购买产品的地方。在一些实施例中，渠道110A-B可以被建模为应用142A-B（可能的例外是在线商店138，其被整合在商务管理引擎136内）。推销组件可以允许商家描述他们想要销售什么以及他们在哪里销售它。产品和渠道之间的关联可以被建模为产品发布并且诸如经由产品列表API而被渠道应用访问。产品可以具有许多选项，如尺寸和颜色，以及将可用选项扩展到所有选项的特定组合的许多变体，如超小且绿色的变体或尺寸大且蓝色的变体。产品可以具有至少一个变体（例如，为没有任何选项的产品创建“默认变体”）。为了便于浏览和管理，可以将产品分组到集合中、为产品提供产品标识符（例如，库存单位（SKU））等。产品集合可以通过以下各项来构建：将产品手动分类为一类（例如，定制集合）、构建用于自动分类的规则集（例如，智能集合）等。可以通过虚拟或增强现实接口等等，作为2D图像、3D图像、旋转视图图像来查看产品。

在一些实施例中，顾客可以将他们意图购买的东西添加到他们的购物车（在替代实施例中，可以诸如通过如本文所述的购买按钮直接购买产品）。顾客可以将产品变体添加到他们的购物车。购物车模型可以是渠道特定的。在线商店138购物车可以由多个购物车排列物品（line item）组成，其中，每个购物车排列物品跟踪产品变体的数量。商家可以使用购物车脚本来基于其购物车中的内容向顾客提供特别的促销。由于向购物车添加产品并不意味着来自顾客或商家的任何承诺，并且购物车的预期寿命可以是大约几分钟（而不是几天），因此购物车可以被持久保存到短暂的数据储存区中。

然后，顾客继续进行结账。结账组件可以将web结账实现为面向顾客的订单创建过程。结账API可被提供为由某些渠道应用使用的面向计算机的订单创建过程，以代表顾客创建订单（例如，针对销售点）。收款台可以针对购物车而创建，并且记录顾客的信息，例如电子邮件地址、账单和装运细节。在收款台，商家承诺定价。如果顾客输入其联系信息但不继续进行支付，则电子商务平台100可以提供重新接入（re-engage）顾客的机会（例如，以放弃结账特征）。由于这些原因，收款台可以具有比购物车长得多的寿命（数小时或者甚至数天），并且因此持续。收款台可以基于顾客的装运地址来计算税款和装运成本。收款台可以将税款计算委托给税款组件，并将装运成本计算委托给交付组件。定价组件可以使商家能够创建折扣代码（例如，当在收款台输入时将新价格应用于收款台中的物品的“秘密”字符串）。折扣可以由商家用来吸引顾客并评估营销活动的表现。折扣和其他定制价格系统可以在同一平台片段顶上诸如通过价格规则（例如，先决条件集，其当被满足时意味着权利集）来实现。例如，先决条件可以是诸如“订单小计大于$100”或“装运成本低于$10”的物品，并且权利可以是诸如“整个订单的20%折扣”或“产品X、Y和Z减$10”之类的物品。

然后，顾客为他们的购物车的内容付费，从而导致针对商家的订单创建。渠道110A-B可以使用商务管理引擎136来向顾客和商家转移金钱、货币或价值存储（例如美元或加密货币）。与各种支付提供商（例如，在线支付系统、移动支付系统、数字钱包、信用卡网关等）的通信可以在支付处理组件内实现。与支付网关106的实际交互可以通过卡服务器环境来提供。在一些实施例中，支付网关106可以诸如通过与领先的国际信用卡处理器整合来接受国际支付。卡服务器环境可以包括卡服务器应用、卡槽（sink）、托管字段等。该环境可以充当敏感信用卡信息的安全关守。在一些实施例中，大多数过程可以由支付处理作业来编排。商务管理引擎136可以支持许多其他支付方法，诸如通过非现场支付网关106（例如，在那里顾客被重定向到另一网站）、手动（例如，现金）、在线支付方法（例如，在线支付系统、移动支付系统、数字钱包、信用卡网关等）、礼品卡等。在结账过程结束时，创建订单。订单是商家和顾客之间的销售合同，其中，商家同意提供订单上列出的商品和服务（例如，订货排列物品、装运排列物品等），并且顾客同意提供支付（包括税款）。可以在销售组件中对该过程进行建模。不依赖于商务管理引擎136结帐的渠道110A-B可以使用订单API来创建订单。一旦创建了订单，就可以将订单确认通知发送给顾客，并且经由通知组件将下订单通知发送给商家。当支付处理作业开始时可以预留库存以避免过度销售（例如，商家可以根据每个变体的库存策略来控制该行为）。库存预留可以具有短的时间跨度（分钟），并且可能需要非常快速和可缩放以支持快闪销售（例如，诸如以冲动购买为目标的短时间内提供的折扣或促销）。如果支付失败，则释放该预留。当支付成功并创建订单时，该预留被转换成分配给特定位置的长期库存承诺。库存组件可以记录变体库存的方位，并且跟踪启用了库存跟踪的变体的数量。它可以将产品变体（表示产品列表的模板的面向顾客的概念）与库存物品（表示其数量和位置被管理的物品的面向商家的概念）解耦。库存水平组件可以保持跟踪可用于销售、承诺给订单或从库存转移组件（例如，从供应商）传入的数量。

然后，商家可以审阅并履行（或取消）订单。审阅组件可实现业务过程，商家使用该业务过程以确保订单在实际履行之前适于履行。订单可能是欺诈性的，需要验证（例如，ID检查），具有需要商家等待以确保他们将收到他们的资金的支付方法等等。风险和建议可以被持久存储在订单风险模型中。订单风险可以从欺诈检测工具生成、由第三方通过订单风险API提交等。在继续进行履行之前，商家可能需要捕获支付信息（例如，信用卡信息）或等待接收它（例如，经由银行转帐、支票等）并将订单标记为已支付。商家现在可以准备用于交付的产品。在一些实施例中，该业务过程可以由履行组件来实现。履行组件可以基于库存位置和履行服务将订单的排列物品分组到工作的逻辑履行单元中。商家可以审阅、调整工作单元，并且触发相关的履行服务，购买装运标签和输入它的跟踪号，或仅仅把物品标记为已履行，该相关的履行服务诸如是通过当商家挑选产品并将其包装在盒子中时使用的人工履行服务（例如，在商家管理的位置处）。定制履行服务可以发送电子邮件（例如，不提供API连接的位置）。API履行服务可以触发第三方，其中，第三方应用创建了履行记录。遗留履行服务可以触发从商务管理引擎136到第三方的定制API调用（例如，由Amazon的履行）。礼品卡履行服务可以提供（例如，生成号码）并激活礼品卡。商家可以使用订单打印机应用来打印包裹单。当物品被包装在盒子中并且准备好装运、被装运、跟踪、交付、验证为被顾客接收到时等，可以执行履行过程。

如果顾客不满意，则他们可能能够将（一个或多个）产品退货给商家。业务过程商家可以经历“取消销售”物品，其可以由退货组件实现。退货可以由各种不同的动作组成，该各种不同的动作诸如是：回货，其中，被售出的产品实际上回到业务中并且可再次销售；退款，其中，曾从顾客处收取的钱被部分或全部退回；记下退款多少钱的会计调整（例如，包括是否存在任何回货费用、或未退款并仍留在顾客手中的商品）；等等。退货可以表示对销售合同（例如，订单）的改变，并且其中，电子商务平台100可以使商家意识到关于法律义务（例如，关于税款）的合规问题。在一些实施例中，电子商务平台100可以使商家能够跟踪对销售合同随时间推移的改变，诸如通过销售模型组件（例如，记录物品所发生的与销售相关的事件的仅附加基于日期的分类账）来实现。

分析电子商务平台中的消息

如上面所概述的，履行顾客下的产品订单可以包括促成产品向顾客的装运。例如，商家可以通过经由装运提供商112购买装运标签来安排该装运。替代地，第三方可以促成产品的装运。可以向顾客提供装运的装运信息，该装运信息尤其可以包括装运提供商、跟踪号、跟踪URL、装运状态和/或预期交付日期。例如，该装运信息可以通过诸如电子邮件消息、文本或短消息服务（SMS）消息或即时消息之类的消息提供给用户。在一些实现方式中，产品信息（即，关于包含在装运中的产品的信息）可以附加地或替代地包括在装运信息中（例如，以允许买方标识特定的装运）。电子商务平台100可以支持用于交付消息的消息传送服务。例如，电子商务平台100可以支持电子邮件消息传送服务，以与顾客和/或商家通信，并促成向顾客交付装运信息。消息传送服务也可以或取而代之地由第三方支持。

向顾客提供装运信息的消息可能对于顾客组织起来是困难和/或耗时的。值得注意的是，提供装运信息的消息可以存储在多个消息当中。例如，提供装运信息的电子邮件消息可能变得埋没在顾客的收件箱中，使顾客稍后难以在需要装运信息时定位该消息。在另一个示例中，由于缺乏不同类型消息的统一收件箱（例如，SMS、电子邮件、聊天/IM等）和/或给定类型的多个收件箱（例如，由于用于SMS的多个电话号码或用于电子邮件的多个电子邮件账户/地址），这样的消息可能跨一种或多种类型的一个或多个收件箱分散，并且因此可能难以定位。因此，存在对一种用于从顾客的（用户的）消息中获得和整合装运信息的计算机实现的系统的需要。

图3图示了图1的电子商务平台100但是包括消息分析引擎300。消息分析引擎300是用于从消息中获得装运信息并存储装运信息的计算机实现的系统的示例。作为举例，当顾客接收到与跟踪装运相关的电子邮件消息时，消息分析引擎300可以从电子邮件消息中提取装运信息，并将该装运信息添加到顾客的所有产品装运的聚合汇总。然后，顾客可以通过他们在电子商务平台100上的账户来访问该汇总，从而允许顾客快速且容易地查阅他们的每个装运的装运提供商、跟踪号、跟踪URL、装运状态和/或预期交付日期。顾客可以能够避免单独查看每个电子邮件消息来获得装运信息。因此，装运信息的聚合汇总为顾客节省了时间和精力，并且对于从众多在线商店购物并且同时有许多产品装运待处理的顾客特别有用。

应当注意，消息分析引擎300不限于从消息中获得装运信息。其他类型的信息也可以或取而代之地从消息中获得。例如，消息分析引擎300可以通过电子商务平台100获得并存储（并且潜在地聚合）交易数据、账单信息、关于购买的产品的信息、关于呈现的服务的信息以及与业务相关联的任何其他信息。

尽管消息分析引擎300在图3中被图示为电子商务平台100的独特组件，但这只是示例。消息分析引擎也可以或取而代之地由电子商务平台100的另一组件提供，或者作为平台100外部的独立组件或服务来供应。在一些实施例中，商务管理引擎136和/或应用142A提供消息分析引擎。电子商务平台100可以包括由一方或多方提供的多个消息分析引擎。多个消息分析引擎可以以相同的方式、以相似的方式和/或以独特的方式实现。此外，消息分析引擎的至少一部分可以在顾客设备150上实现。例如，顾客设备150可以作为软件应用本地存储和运行消息分析引擎。

消息分析引擎300可以实现本文描述的至少一些功能性。尽管下面描述的实施例可以与电子商务平台、诸如（但不限于）电子商务平台100相关联地实现，但是下面描述的实施例不限于图1至3的特定电子商务平台100。此外，本文描述的实施例根本不一定需要与电子商务平台相关联地实现或牵涉到电子商务平台。其他计算平台和设备可以实现本文公开的系统和方法中的至少一些。

从消息中获得装运信息

从消息中准确且一致地获得装运信息可能是困难的。存在大量的装运提供商、履行网络、邮政服务提供商、最后一英里交付服务等等，它们可以被用来将产品装运给顾客。每个商家和/或装运提供商通常具有其自己的消息格式和跟踪号系统。此外，数字通知可以采取各种形式/具有各种类型，诸如例如电子邮件消息、文本消息、即时消息等。此外，消息集合——无论是相同类型还是不同类型——都可能具有不同的格式。作为结果，可能包含装运信息的潜在消息格式的数量是巨大的。

对于该数量的潜在消息格式，实现用于从消息中获得装运信息的确定性方法可能是不可行的。确定性方法通常使用固定的规则集合从消息中提取装运信息。然而，为了既准确又一致，用于从消息中获得装运信息的确定性方法应当被主动配置为处理每种可能的消息格式。例如，确定性方法可能需要生成独特的规则或模板集合来对每个单独的消息格式进行模式匹配。可能的消息格式的数量将致使这过于耗时。附加地，还没有一致采用的格式用于跟踪各种类型的消息。此外，这样的标准化的尝试只看到有限的采用，并且在这样的有限的采用中，这样的标准经常不一致/不正确地实现。此外，装运提供商不断更新和更改他们的电子邮件消息格式，并且新的装运提供商、交付服务等正频繁地上线（即，创业）。因此，用于从消息中获得装运信息的确定性方法也将需要相应地进行主动更新。

从跟踪消息中的URL，而不是从消息的全部内容中获得装运信息可以帮助至少避免使用上面概述的确定性方法。跟踪URL可以指向包括特定装运的装运信息的web资源。虽然URL可能仅表示消息总内容的一小部分，但URL本身仍然可以提供消息中包含的大部分或者甚至全部装运信息。因此，跟踪URL可以用于获得装运信息，而无需解析消息的全部内容。URL也具有预定义的结构，其可以简化用于获得装运信息的分析。URL的结构包括方案、可选的权限、路径、可选的查询和可选的片段。

方案包括跟随有冒号（：）的字符串，其指示正在使用的web协议。方案的非限制性示例包括http、https、ftp、mailto、file、data和irc。

URL中的权限之前是两个斜杠（//）。权限可以包括提供用户名和可选密码的可选userinfo子组份、host子组份和可选的port子组份。

路径可以提供到服务器上特定web资源、文件或目录的映射。路径可以包括一个或多个路径段，其中每个路径段由斜杠（/）分隔。然而，路径可能取而代之是空的。

URL中的查询之前是问号（

）并且包括一个或多个参数。每个参数由和符号（&）分隔。查询可以指示由web资源提供的内容。例如，查询可以用于选择网页上显示的内容。

片段之前是散列（#），并且可以为辅助web资源提供方向。

因此，URL的结构可以定义为方案：[//权限]路径[

查询][#片段]。例如，考虑以下URL：

。这里，方案是https，权限是soup.myshopify.com，路径是pages/recipes，查询是param1=x&param2= y，并且片段是borscht。

至少与消息的全部内容相比，URL的结构化性质和相对短的长度允许使用概率性方法来获得装运信息。概率性方法基于概率分布做出决策，并且一般非常适合于牵涉到大量唯一的输入和对应具体输出的问题，这可以是用于从消息中获得装运信息的情况。概率性方法可以提供一定程度的灵活性，以适应许多不同的消息格式和消息格式的改变。

在一些实施例中，概率性方法通过识别URL中的特定参数或语法从URL中提取装运信息。例如，URL中的查询参数可能是country=CA&trackingId=368927473835，这指示装运的目的地在加拿大，并且跟踪号为368927473835。

机器学习（ML）模型是实现概率性方法的一种潜在方式。然而，ML模型可能是计算密集型的，并且可能需要大量的数据来训练。因此，使用ML模型分析大型输入数据集可能既昂贵又耗时。有利的是，URL通常具有相对少量的字符（通常在50和200之间），结构化良好，并且通常可以比消息格式更不频繁地改变（例如，至少在一些情况下，由于需要维护URL格式中的向后兼容性，因此对URL格式的改变可能受到限制，而消息的格式（诸如电子邮件正文的格式）诸如例如出于文体原因而可能更频繁地改变），并且因此非常适合使用ML模型进行分析。

除了从URL获得装运信息之外，还可以从链接到URL或以其他方式与URL相关联的web资源获得装运信息。例如，URL可以链接到装运提供商的网页，该网页提供装运提供商、跟踪号、装运状态和/或装运的预期交付日期。可以通过使用确定性方法和/或概率性方法解析web资源来获得装运信息。

分析URL和与URL相关联的web资源两者可以潜在地增加从消息中获得的装运信息量和/或在获得装运信息时提供一定程度的冗余。例如，从URL获得的装运信息可以由从与该URL相关联的web资源获得的装运信息来确认和/或补充，并且反之亦然。在一个示例中，分析从消息中提取的URL，以确定该URL是否用于跟踪装运，确定装运的装运提供商，和/或确定装运的跟踪号。从该URL获得的装运信息然后可以用从与该URL相关联的web资源获得的装运信息来补充和/或确认。在另一个示例中，从与URL相关联的web资源中确定装运信息，并且通过对URL的分析来可选地确认装运信息。

在从一个或多个用户消息中获得装运信息之后，可以为顾客编译装运信息的整合列表。该列表允许用户快速且容易地一次访问关于其任何、部分或全部待处理装运的信息。例如，当用户接收到具有装运信息的新消息时，以及当装运被成功交付给用户时，装运信息的列表可以被主动更新。此外，用户可以被给予更改列表的能力。例如，用户可以能够组织、添加、删除和/或修改列表中的装运信息。

装运信息仅是可以使用本文公开的系统和方法从用户的消息中获得的一种类型的信息。本公开还涉及从用户的消息中获得其他类型的信息。例如，关于用户在线购买的产品的信息可以从用户的消息中获得。可以实现分析这些消息中的URL以及可选地与那些URL相关联的web资源，来获得用户已经在线订购的产品的产品信息。例如，编译该产品信息可以允许来自一个商务平台的产品推荐结合用户从其他商务平台的购买。在另一个示例中，基于对用户消息中的URL的分析，可以获得其他潜在相关数据，诸如例如可以获得关于未来装运的信息。值得注意的是，这样的潜在相关数据可以包括与即将到来的装运相关的产品数据/信息。附加地或替代地，在至少一些情况下，这样的潜在相关信息可以包括在用户消息中不可用的/将不会经由消息传送给用户的信息。附加地或替代地，在至少一些情况下，潜在相关信息可以包括存在于消息中但在呈现消息时没有示出的信息。例如，潜在相关信息可以在消息中包括的元数据/标记中找到。在另一个示例中，当消息由某些类别的设备/客户端呈现时（例如，信息仅当在桌面计算机上呈现消息时可见，而当在移动设备上呈现消息以供展示时不可见）。

用于从消息中获得装运信息的示例系统和方法

图4是图示了用于从数字消息中获得信息的示例系统400的框图。系统400包括消息分析引擎402、网络420和用户设备430。

消息分析引擎402存储和分析消息以从消息中获得信息。然后，所获得的信息可以由消息分析引擎402编译和存储，并且可选地传输到用户设备430。虽然由消息分析引擎402获得的信息可以是或包括装运信息，但是也设想到其他类型的信息。例如，关于用户在线购买的产品的信息可以由消息分析引擎402获得。

消息分析引擎402的位置是特定于实现方式的。在一些实现方式中，消息分析引擎402至少部分由电子商务平台提供，或者作为电子商务平台的核心功能，或者作为电子商务平台支持的应用。例如，消息分析引擎402可以是图3的消息分析引擎300。在一些实现方式中，消息分析引擎402被实现为电子商务平台外部的或者至少部分由用户设备实现的独立组件、应用或服务。还设想到消息分析引擎402的其他实现方式。虽然消息分析引擎402被示为单个组件，但是消息分析引擎402可以取而代之地由例如经由网络420通信的多个不同组件来提供。

消息分析引擎402包括处理器404、存储器406和网络接口408。处理器404可以由执行存储在存储器406中或另一非暂时性计算机可读介质中的指令的一个或多个处理器来实现。这些指令可以实现本文描述的任何方法。替代地，处理器404的一些或全部可以使用专用电路来实现，诸如专用集成电路（ASIC）、图形处理单元（GPU）或编程的现场可编程门阵列（FPGA）。

网络接口408被提供用于通过网络420的通信。网络接口408的结构是特定于实现方式的。例如，网络接口408可以包括网络接口卡（NIC）、计算机端口（例如，插头或线缆连接的物理插座）和/或网络插槽。

存储器406存储消息记录410、装运提供商记录412、消息类别记录413、URL类别记录414、一个或多个ML模型416和装运信息记录418。

消息记录410包括正被存储以供消息分析引擎402分析的消息。这些消息可以包括电子邮件消息、文本消息、即时消息等。音频消息、诸如语音邮件消息和来自数字助理的消息例如也可以被包括在消息记录410中。在一些情况下，消息的序列化版本存储在消息记录410中。消息序列化版本的示例是电子邮件消息的EML文件。

消息可以仅在由消息分析引擎402分析之前和/或期间临时存储在消息记录410中。然而，消息记录410也可以提供消息的永久或半永久记录。

存储在消息记录410中的消息可以以多种不同方式中的任何一种获得。在一些实现方式中，消息分析引擎402被授权访问消息传送服务上的一个或多个用户账户。该访问可以允许消息分析引擎402从消息传送服务获得用户消息。消息传送服务的非限制性示例包括电子邮件服务、文本消息传送服务和即时消息传送服务。此外，用户可以授权消息分析引擎402访问他们在多个消息传送服务上的账户。因此，消息分析引擎402可以从一个或多个电子邮件账户、一个或多个文本消息传送账户和/或一个或多个即时消息传送账户获得用户的消息。

一旦消息分析引擎402具有对用户在消息传送服务上的账户的访问权，该消息传送服务上的任何、一些或所有用户消息就都可以存储在消息记录410中。可以从支持消息传送服务的服务器和/或从用户设备（例如，用户设备430）接收消息。在一些情况下，当用户在消息传送服务上接收到新消息时，消息记录410也可以获得并存储新消息。因此，消息记录410可以包括用户在一个或多个消息传送平台上接收的消息的整合列表。在一些情况下，用户主动选择哪些消息存储在消息记录410中，和/或定义确定哪些消息存储在消息记录410中的规则集合。例如，用户可以配置消息分析引擎402的访问，使得仅有来自某些发送者的消息被存储在消息记录410中。

装运提供商记录412包括已知装运提供商的列表或集合。在一些情况下，该列表可以自动构建或维护，诸如例如基于从一个或多个数据源获得的信息。关于这些装运提供商中的每一个的信息也可以存储在装运提供商记录412中，包括例如装运提供商使用的装运消息格式、装运提供商使用的跟踪URL格式和/或装运提供商使用的web资源格式。如本文别处进一步详细讨论的，装运提供商记录412可以用于帮助从消息中获得和/或确认装运信息。

消息类别记录413包括预定义消息类别的列表或集合。例如，这些预定义消息类别中的至少一些可以对应于不同的消息格式、模板或结构。

在一些实现方式中，消息类别记录413中的预定义消息类别是（至少部分地）基于消息的潜在功能来定义的。因此，确定消息的消息类别可以帮助确定消息的功能。这样的预定义消息类别的非限制性示例包括：

• 商务消息，包括例如商家广告、时事通讯和其他促销内容；

• 装运跟踪和/或确认消息；

• 交付状态更新消息；

• 订单确认消息；

• 个人消息；

• 工作消息；

• 账单；和

• 垃圾消息。

消息类别记录413中的预定义消息类别也可以或取而代之地（至少部分地）基于消息的发送者来定义。不同的商家、装运提供商和其他发送者可以具有他们的发送地址和/或他们自己的消息格式，它们中的每一个或两者可以单独或组合地对应于消息类别记录413中的相应消息类别。在示例中，可以定义多个装运跟踪消息类别，其中每个类别对应于在装运提供商记录412中定义的不同的装运提供商。

在一些实现方式中，消息类别记录413可以帮助标识可能潜在地包括装运信息的消息，并且甚至可以帮助确定消息中的至少一些装运信息。例如，可以确定特定消息对应于某个预定义消息类别。如果该预定义消息类别与装运跟踪相关联，则可以确定该消息也与装运跟踪相关联。此外，如果消息类别与特定的装运提供商相关联，则可以确定该装运提供商正在促成该装运。

URL类别记录414包括预定义URL类别的列表或集合。例如，这些预定义URL类别中的每一个可以对应于不同的URL格式、模板或结构。这些预定义URL类别可以用于帮助确定URL的功能和/或由该URL链接到的web资源的功能。换句话说，通过将特定的URL与存储在URL类别记录414中的预定义URL类别之一相匹配，可以确定由该URL链接到的web资源的目的。

在一些实现方式中，存储在URL类别记录414中的预定义URL类别中的至少一个是跟踪URL类别或者以其他方式与跟踪装运相关。URL类别记录414可以包括多个跟踪URL类别，其中每个跟踪URL类别可以特定于相应的装运提供商。例如，特定装运提供商使用的URL格式可以落入特定于该装运提供商的一个或多个跟踪URL类别。在一些情况下，URL类别记录414与装运提供商记录412关联，使得装运提供商记录412中的每个装运提供商具有在URL类别记录414中定义的一个或多个对应的URL类别。然而，多个不同的装运提供商可以使用具有类似格式的URL。附加地，在一些情况下，URL可以对应于装运信息聚合器，从该装运信息聚合器可以获得装运信息，即使该聚合器可能不负责处理装运的实际装运/交付。照此，跟踪URL类别可以与多个不同的装运提供商相关联。在URL类别记录414中也可以存在与装运跟踪无关的一个或多个预定义URL类别。

如本文别处进一步详细讨论的，在URL类别记录414中存储预定义URL类别可以帮助确定来自URL的装运信息。如果确定URL对应于与特定装运提供商相关联的跟踪URL类别，则可以推断该URL与跟踪由该装运提供商促成的装运相关。了解跟踪URL类别还可以允许从URL中提取跟踪号。在示例中，特定的跟踪URL类别对应于包括跟踪号的URL格式。跟踪号一般包括在URL格式中的相同位置处。照此，可以为该跟踪URL类别的跟踪号定义起始索引和结束索引，并将其存储在URL类别记录414中。起始索引对应于跟踪号的第一数字的位置，并且结束索引对应于跟踪号的最后数字的位置。使用起始索引和结束索引，可以从该跟踪URL类别的URL中提取跟踪号。起始索引和/或结束索引可以从URL的开头或从URL的结尾定义。换句话说，在URL中找到跟踪号的起始和/或结束可能牵涉到从URL的开头正向计数或从URL的结尾反向计数。

（一个或多个）ML模型416可由处理器404执行，以分析消息并从消息中获得信息（例如，诸如装运信息）。在一些情况下，（一个或多个）ML模型416实现用于从消息中获得信息的概率性方法。

（一个或多个）ML模型416可以使用本领域已知的任何形式或结构来实现。（一个或多个）ML模型416的示例结构包括但不限于：

• 一个或多个人工神经网络；

• 一个或多个决策树；

• 一个或多个支持向量机；

• 一个或多个贝叶斯网络；和/或

• 一个或多个遗传算法。

用于训练（一个或多个）ML模型416的方法也是特定于实现方式的，并且不限于本文。训练方法的非限制性示例包括：

• 监督学习；

• 无监督学习；

• 强化学习；

• 自学习；

• 特征学习；和

• 稀疏字典学习。

根据一些实施例，使用监督学习来训练（一个或多个）ML模型416中的一个或多个。在监督学习中，通过分析训练数据集中的输入数据、进行定量比较以及将结论与训练数据集中的已知结果进行交叉引用来执行训练。这些分析和比较的迭代细化允许ML模型在ML模型预测的结果和已知结果之间实现更大的确定性。该过程迭代地继续，直到解收敛或达到所期望的准确性。

根据一些实施例，使用无监督学习来训练（一个或多个）ML模型416中的一个或多个。在无监督学习中，ML模型从训练数据集中确定并绘制其自己的连接。这可以通过探究训练数据集中自然出现的数据关系或模式来完成。用于实现无监督学习的一种方法是聚类分析，其目的是要发现训练数据集内的组或聚类。聚类是变量集合，其由ML模型进行类似的处理。在聚类分析中，ML模型将对训练数据集进行细分，以确定具有高组内相似性和低组间相似性的聚类。聚类分析中使用的聚类数量可以在ML模型中可配置。

（一个或多个）ML模型416中的任何、一个、一些或所有ML模型416可以是或包括多任务学习（MTL）模型。通过同时执行多个任务，MTL模型可以帮助更准确和/或更高效地从消息中提取信息。例如，确定消息中的URL是否与跟踪装运相关、确定装运的装运提供商、确定装运的跟踪号以及确定发起装运的商家都可以被认为是可以由单个MTL模型解决的“任务”。这些任务之间的共性和差异可以帮助与被实现来分别解决每个任务的多个ML模型相比改进MTL模型的总体准确性。MTL模型可以被训练来跨所有任务同时改进结果，以提供改进的集体答案，而不是单独改进每个任务的结果，这给出了改进的个体答案，所述答案作为一个集体可能是不正确或不连贯的。此外，实现单个MTL模型而不是多个ML模型可以减少需要训练和维护的ML模型的总体数量。

装运信息记录418包括已经为一个或多个用户获得的装运信息。可以使用（一个或多个）ML模型416和/或本文别处公开的方法从存储在消息记录410中的消息中确定该装运信息。然而，装运信息也可以从其他来源获得，例如诸如经由用户设备430上的直接用户输入。在一些实现方式中，装运信息记录418为一个或多个用户编译或以其他方式提供装运信息的整合列表。装运信息列表可以主动更新。在一个示例中，当用户接收到装运时，对应于该装运的装运信息可以从装运信息记录418中移除。在另一示例中，当消息记录410获得新消息并且从该消息中获得装运信息时，则装运信息可以被添加到装运信息记录418。

尽管消息记录410、装运提供商记录412、消息类别记录413、URL类别记录414和装运信息记录418在图4中被单独示出，但是应当注意，在一些实施例中，这些记录中的两个或更多个可以取而代之地组合成单个记录。在一个示例中，消息记录410和装运信息记录418可以组合成单个记录。在另一个示例中，装运提供商记录412、消息类别记录413和URL类别记录414可以组合成单个记录。

用户设备430包括处理器432、存储器434、用户接口436和网络接口438。用户接口436可以包括例如显示屏（其可以是触摸屏）、手势识别系统、扬声器、耳机、麦克风、触觉装置、键盘和/或鼠标。网络接口438被提供用于通过网络420进行通信。网络接口438的结构将取决于用户设备430如何与网络420对接。例如，如果用户设备430是移动电话、耳机或平板计算机，则网络接口438可以包括具有天线的发射机/接收机，以向/从网络420发送和接收无线传输。如果用户设备是用网络线缆连接到网络的个人计算机，则网络接口438可以包括例如NIC、计算机端口和/或网络插槽。处理器432直接执行或指示由用户设备430执行的所有操作。这些操作的示例包括处理从用户接口436接收的用户输入、准备信息用于通过网络420传输、处理通过网络420接收的数据以及指示显示屏显示信息。处理器432可以由执行存储在存储器434中的指令的一个或多个处理器来实现。替代地，处理器432中的一些或全部可以使用诸如ASIC、GPU或编程的FPGA之类的专用电路来实现。

在图4中，作为举例示出了一个用户设备。多于一个用户设备可以与消息分析引擎402通信。

图5是图示了根据实施例的用于分析消息以获得装运信息的方法500的流程图。方法500将被描述为由图4的消息分析引擎402执行。然而，还设想到其他实现方式。例如，方法500可以全部或部分由用户设备430执行。

该方法可以包括标识与顾客相关联的多个消息。可以从多个消息中提取至少一个装运的装运信息。步骤502包括处理器404获得对应于给定消息的数字内容。该消息可以是多个所标识的消息之一。该数字内容可以包括消息中的任何、一些或全部内容（例如，消息的标题、文本和/或附件）、消息的发送者和/或消息的（一个或多个）接收者。在一些情况下，在步骤502中获得消息的序列化版本。例如，数字内容可以从消息记录410、从用户设备430和/或从托管消息传送服务的服务器获得。

步骤504包括处理器404从步骤502中获得的数字内容中获得一个或多个URL。每个URL与web资源相关联。URL对于阅读或以其他方式参与消息的用户来说可以是可见的（例如，是以文本示出的超链接），或者对于用户来说是不可见的（例如，是元数据或不可见的超文本标记语言（HTML）元素）。一般而言，在步骤504中，可以获得数字内容中的任何、一个、一些或所有URL。如果在数字内容中没有找到URL，则方法500可以结束。

步骤504可以使用多种技术中的任何一种来执行。在一些情况下，步骤504可以实现确定性方法、诸如字符串匹配算法来提取URL。例如，处理器404可以解析数字内容并移除包括特定于URL的语法的任何字符串。特定于URL的语法的非限制性示例包括http：、.html、.com、.org和.ca。概率性方法也可以或取而代之地在步骤504中实现。例如，（一个或多个）ML模型416中的一个或多个可以被训练来从数字内容中提取URL。

在步骤504中从消息中提取的URL可以存储在存储器406或另一个非暂时性计算机可读介质中。例如，提取的URL可以连同消息一起存储在消息记录410中。

步骤506是可选步骤，其包括处理器404基于在步骤502中获得的数字内容，确定该消息与跟踪装运相关（或可能与跟踪装运相关）。该步骤通知消息分析引擎402：应当使用方法500进一步处理该消息以获得装运信息。另一方面，如果步骤506确定消息与跟踪装运无关，则方法500可以结束。照此，步骤506可以帮助过滤由方法500处理的消息数量。

在一些实现方式中，步骤506包括对消息进行分类，并确定消息类别与装运跟踪相关联。例如，步骤506可以包括将数字内容输入到已经被训练为从消息的数字内容中标识消息类别的ML模型（其可以是（一个或多个）ML模型416之一）中。然后，该ML模型可以输出消息的消息类别，或者至少是消息类别的指示。在一些情况下，ML模型可以从存储在消息类别记录413中的预定义消息类别集合中选择消息类别。基于由ML模型确定的消息类别，可以确定消息是否与装运相关。例如，装运跟踪消息和订单确认消息可以被定义为可能与产品装运相关的消息类别。

用于从消息的数字内容中标识消息类别的ML模型可以用多种不同方式中的任何一种来训练。在一些实现方式中，用于该ML模型的训练数据集可以包括消息集合，每个消息都用已知的消息类别来标注。该训练数据集可以从计算平台上的用户反馈中获得。例如，当用户在计算平台上遇到消息问题时，他们可以报告该问题。在报告中，可以要求用户提交消息并指示消息的类别。消息的类别可以从存储在消息类别记录413中的预定义类别之一中选择。因此，这些报告可以提供已经由用户分类的大型消息集合，并且因此可以为ML模型提供合适的训练数据集。

在一些实现方式中，除了消息的整个数字内容之外或代替于消息的整个数字内容，步骤506使用在步骤504中获得的URL来确定消息与装运跟踪相关。在这些实现方式中，步骤506可以包括将URL的至少一部分输入到已经被训练来标识URL类别的ML模型中。该ML模型可以是（一个或多个）ML模型416之一。如果URL类别对应于装运跟踪，则可以确定消息本身也与装运跟踪相关。在一些情况下，ML模型可以从存储在URL类别记录414中的预定义URL类别集合中选择URL类别。

可以使用通过计算平台上的用户反馈获取的训练数据集来训练用于从URL中标识URL类别的ML模型。例如，当商家正在履行电子商务平台上的顾客订单时，商家可以提供用于跟踪订单装运的URL。照此，商家在这些情形中提供的URL可以分类为与装运跟踪相关。这些URL以及与装运跟踪无关的其他URL可以形成训练数据集的基础，该数据集用来训练ML模型对与装运跟踪相关的URL进行分类。

步骤508包括处理器404基于在步骤504中获得的URL和/或与该URL相关联的web资源来确定装运信息。装运信息包括web资源用于跟踪装运的指示、装运的跟踪号和装运的装运提供商中的至少一个。确定web资源用于跟踪装运可以指示URL是跟踪URL。照此，URL本身可以被添加到在步骤508中确定的装运信息。装运信息可以进一步包括正被装运的（一个或多个）产品、装运的订单号、装运状态、预期交付日期和/或发起装运的商家。在一些情况下，装运可以由多个装运提供商促成和/或具有多个相关联的跟踪号。可以在步骤508中确定多个相关联的跟踪号中的任何、一个、一些或全部。

在步骤508的一些实现方式中，使用至少一个ML模型从该URL获得至少一些装运信息，该至少一个ML模型可以是（一个或多个）ML模型416之一。到ML模型的输入可以包括URL。然而，整个URL可能并不总是输入到ML模型中。因为URL具有结构化的性质，URL的某些组份可以被提取并输入到ML模型中，以减少ML模型分析的字符总数。例如，可以实现确定性方法来提取URL的权限、路径和/或查询组份，并将那些组份输入到ML模型中。ML模型的输出可以包括URL是否与跟踪装运相关的指示、对应于装运的跟踪号的文本串、对应于装运的装运提供商的文本串和/或其他装运信息。在一些实现方式中，将对应于装运提供商的文本串与装运提供商记录412中的装运提供商列表进行比较。这可以帮助确定正在促成装运的确切装运提供商。

可以使用从计算平台的用户获得的数据来训练在步骤508中用于从URL获得装运信息的ML模型。例如，当商家正在履行电子商务平台上的顾客订单时，商家可以提供订单装运的跟踪URL、订单的装运提供商和订单的跟踪号。可以跨多个产品订单收集该信息，以形成用于ML模型的训练数据集的基础。例如，ML模型可以被训练为从每个URL预测正确的装运提供商和/或跟踪号。

在一些实现方式中，在步骤508中用于从URL获得装运信息的到ML模型的输入可以进一步包括对应于URL中跟踪号起始的第一索引的预测和/或对应于URL中跟踪号结束的第二索引的预测。这些预测可以改进ML模型确定跟踪号的准确性和/或可靠性。例如，预测可以允许ML模型在分析期间忽略URL中的一些字符。第一索引和第二索引的预测可以以概率分布的形式提供。对于输入到ML模型中的URL的每个字符，可以向ML模型提供该字符是第一索引的概率和/或该字符是第二索引的概率。

对URL中的跟踪号的第一索引的预测和第二索引的预测可以以多种不同方式中的任何一种来获得。在一些实现方式中，第一ML模型被实现来生成第一索引和/或第二索引的预测。如上所述，该第一索引和/或第二索引然后可以被输入到第二ML模型中，以获得对应于跟踪号的文本串。此外，在一些实现方式中，第一ML模型和第二ML模型可以使用单个MTL模型一起实现。

在一些实现方式中，第一ML模型通过确定URL最好地拟合（可选地存储在URL类别记录414中的）预定义URL类别集合中的哪个URL类别来对该URL进行分类。所确定的URL类别可以具有针对跟踪号一般具有固定位置的格式。照此，第一索引的预测和/或第二索引的预测可以基于所确定的URL类别从URL类别记录414中获得。该URL类别还可以与特定的装运提供商相关联，并且因此可以基于所确定的URL类别从URL类别记录414中附加地获得该装运的装运提供商。

在一些实现方式中，步骤506、508两者都可以至少部分地使用第一ML模型来实现。例如，第一ML模型可以对该URL进行分类，其中所确定的类别指示该URL与装运跟踪相关，并且还允许从该URL获得跟踪号和/或装运提供商。

类似于第二ML模型，可以使用从电子商务平台获得的训练数据来训练第一ML模型。例如，当商家正在向电子商务平台中输入跟踪URL以完成订单时，可以要求商家对该URL进行分类，并提供跟踪号和/或与该URL相关联的装运提供商。然后可以使用字符串匹配算法来确定URL中跟踪号的第一索引和第二索引，这可以形成用于第一ML模型的训练数据集的基础。

应当注意的是，在一些实现方式中，仅有第一ML模型被用来从URL获得装运信息。例如，第一ML模型可以确定提供跟踪号的第一索引、跟踪号的第二索引和/或装运提供商的URL的类别。然后，该信息可以用于通过从URL中的第一索引和第二索引之间提取跟踪号来获得跟踪号。因此，第一ML模型可能不总是与第二ML模型结合使用来确定装运信息。

在步骤508中，可以使用从与该URL相关联的web资源获得的装运信息来补充和/或确认从该URL获得的装运信息。替代地，装运信息可以完全从web资源获得。从web资源获得装运信息可以包括使用URL访问web资源、从web资源获得内容和/或解析内容以确定装运信息。解析内容可以包括例如文本和/或图像分析操作，并且可以至少部分地使用（一个或多个）ML模型416之一来执行。

解析与该URL相关联的web资源的潜在益处是处理器404可以能够确定该web资源是否是欺诈性的。例如，可以训练ML模型（其可以是（一个或多个）ML模型416之一）来识别欺诈性网页。在确定网页是欺诈性的之后，包含该网页的URL的消息可以被标记为网络钓鱼或垃圾电子邮件。

在一些实现方式中，跟踪号和装运提供商是从URL和web资源两者中获得的。例如，可以首先通过解析URL来获得跟踪号和装运提供商，并且然后可以通过解析web资源来确认跟踪号和装运提供商。这提供了一定程度的冗余，以帮助确保在步骤508中获得正确的跟踪号和装运提供商。在一些情况下，处理器404可以针对与从该URL获得的跟踪号和/或装运提供商相匹配的文本串搜索web资源。如果在web资源中找到这样的文本串，则可以确定跟踪号和/或装运提供商被web资源确认。其他确定性和/或概率性方法也可以或取而代之地用于确认web资源中的跟踪号和/或装运提供商。

在从URL获得的跟踪号和/或装运提供商与从web资源获得的不匹配的情况下，然后可以执行进一步的处理来解决差异性。例如，如果为URL确定了URL类别，则该URL类别可以用于确定是从该URL获得的装运信息还是来自web资源的装运信息被认为是最准确的。URL类别记录414可以存储从每个URL类别和/或从每个URL类别的相关联的web资源可以多准确地获得装运信息的指示。然后，不太准确的装运信息可以被丢弃。替代地，用户的手动干预可以用于解决URL和web资源之间的差异性。

例如，考虑如下情况，其中从URL中提取跟踪号，并且还从相关联的网页中提取跟踪号。如果这两个跟踪号匹配，则跟踪号被确认，并且可能不采取进一步的动作。替代地，如果这两个跟踪号不同，则不太准确的跟踪号可能被丢弃。在一些情况下，消息分析引擎可以被配置为将从URL中提取的跟踪号视为不太准确的跟踪号。在其他情况下，消息分析引擎可以被配置为将从网页中提取的跟踪号视为不太准确的跟踪号。

在一些情况下，通过解析URL来确定跟踪号和装运提供商中的一个，并且通过解析web资源来确定跟踪号和装运提供商中的另一个。因此，从web资源确定的装运信息可以添加到为消息获得的装运信息的累积记录。当无法通过解析URL来确定跟踪号或装运提供商，并且因此执行解析web资源来补充从URL获得的装运信息时，这种情况可能出现。例如，URL可能不包括跟踪号，或者跟踪号可以在URL中编码或散列。此外，多个不同的装运提供商可以使用类似的URL格式。照此，可能不可从URL的格式或所确定的类别推断出特定的装运提供商。

在一些情况下，无论是跟踪号还是装运提供商都无法从URL中获得。因此，在这些情况下，步骤508可以包括通过解析web资源来确定跟踪号和装运提供商两者。该URL用于访问web资源，然后解析该web资源以获得装运信息。

在一些情况下，在步骤508中，仅解析URL以获得装运信息。如果web资源不包括必要的装运信息，消息分析引擎402不具有分析web资源的能力，和/或装运信息是以足够的置信度从URL获得的，则这可能发生。

在一些情况下，给定的URL可以对应于包括装运信息的图像，诸如例如，估计到达时间。可以（例如，使用由这样的图像的示例组成的一个或多个训练集）训练机器学习模型来分析这样的图像，并且可以在从这样的图像提取信息中采用该机器学习模型。附加地或替代地，诸如例如光学字符识别之类的技术可以应用在从这样的图像提取信息中。

可以在步骤508中实现的ML模型是用于确定装运信息的概率性方法的示例。在一些情况下，可以对使用ML模型获得的装运信息执行后处理步骤。后处理的示例是实现确定性方法来确认和/或补充使用ML模型获得的装运信息。

如上面所指出的，在步骤504中，可以从数字内容中获得多于一个URL。在步骤508中，可以分析这些URL中的每一个。在一些情况下，数字内容中的两个或更多个URL可以包括装运信息。从两个或更多个URL获得的装运信息可以进行比较，以确定URL是与同一个装运还是不同的装运相关。还可以比较装运信息，以确定URL是否与在多个阶段中交付同一个装运的多个装运提供商相关。

如果两个URL与同一个装运相关，那么从两个不同URL获得的装运信息可以出于确认目的进行比较。此外，从消息中的两个URL获得的装运信息可以用于解决从URL之一获得的装运信息和从相关联的web资源获得的装运信息之间的差异性。例如，如果从第一URL提取的跟踪号也是通过分析消息中的第二URL确定的，则可以忽略从与第一URL相关联的web资源提取的不同跟踪号。

根据示例，在步骤504中，可以从数字内容中获得第一URL和第二URL。第一URL和第二URL分别与第一web资源和第二web资源相关联。这里，步骤508可以包括确定第一URL和第二URL对应于相同的装运，从第一URL、第二URL、第一web资源和/或第二web资源获得相同的跟踪号，和/或从第一URL、第二URL、第一web资源和/或第二web资源获得相同的装运提供商。

在一些情况下，在步骤504中从消息中提取的一个或多个URL可能不与装运跟踪相关。如果处理器404确定URL与装运跟踪无关，那么对该URL的分析结束，并且步骤508可以继续分析下一个URL或者继续到步骤510。

步骤510包括将在步骤508中确定的装运信息存储在存储器406中或另一个计算机可读介质中。在一些实现方式中，装运信息可以存储在装运信息记录418中。装运信息可以稍后用于获得装运的跟踪更新。例如，消息分析引擎402或用户设备430可以访问装运信息，以从正在促成装运的装运提供商获得更新的装运信息。这可以提供针对装运的更新的交付日期，其可以被添加到存储在存储器406中的装运信息。

如使用从步骤510到步骤502的箭头所图示，步骤502、504、506、508、510可以针对相应的消息重复多次。这可以在装运信息记录418中建立与多个装运有关的装运信息的累积记录。这些多个装运可以都是针对同一用户的。作为举例，步骤502的多个实例可以获得对应于与用户相关联的多个消息的数字内容。这些消息可以一次获得，或者在多个不同的时间获得。这些消息中的每一个可以对应于顾客的不同产品装运。步骤504的多个实例可以从每个消息的数字内容获得URL，并且步骤508的多个实例可以从URL和/或它们相关联的web资源获得装运信息。步骤510的多个实例然后可以将该装运信息存储在存储器406中。这可以将与用户的多个装运有关的装运信息添加到装运信息记录418。

装运信息可以用于获得顾客的一个或多个产品装运的跟踪更新。可以提供一个或多个产品装运的所获得的跟踪更新，以供在为顾客呈现所有（一个或多个）产品装运的聚合汇总中使用。

步骤512是可选步骤，其包括处理器输出装运信息记录418中的装运信息的至少一部分，以供在用户设备430或另一设备上显示。例如，使用方法500分析的（一个或多个）消息可以对应于用户设备430的用户，并且因此用户设备430可以被给予对存储在装运信息记录418中的至少一些装运信息的访问权。消息分析引擎402可以输出该装运信息中的任何、一些或全部，以供显示在用户设备430上。

用户设备430的用户可以被准许更改存储在装运信息记录418中的至少一些装运信息。例如，使用用户设备430，用户可以生成更改装运信息记录418的指令。更改装运信息记录418的非限制性示例包括：

• 添加装运信息，其可以是针对新装运或现有装运的；

• 当接收到装运时或当一些装运信息不正确时，移除装运信息；和

• 基于用户偏好重新组织装运信息。

附加地或替代地，更改装运信息可以包括校正不正确的装运信息。例如，这样的校正可以包括输入校正的装运信息。在一些情况下，可以向用户呈现替代装运信息的一个或多个选项。响应于这样的选项，可以接收装运信息的校正的输入，并且该输入可以对应于所呈现的选项之一的选择。值得注意的是，在获得装运信息时诸如例如以上面讨论的方式采用机器学习的情况下，在这样的替代列表中呈现的选项可以包括通过应用机器学习模型标识的装运信息的其他候选，诸如例如，机器学习模型标识为可能的装运信息但具有较低置信度的候选装运信息。附加地，在一些实现方式中，在接收到对装运信息的校正的情况下，那些校正（无论是通过输入校正的装运信息接收的、基于对替代装运信息的选择接收的，还是其他方式）可以稍后用于更新/重新训练机器学习模型（例如，通过将校正的信息添加到训练集）用于在着眼于改进准确性的情况下标识装运信息。

步骤502、504、506、508、510、512的顺序仅作为示例示出。也设想到步骤502、504、506、508、510、512的其他顺序。例如，在执行步骤504以从对应于消息的数字内容获得URL之前，步骤506可以确定消息与跟踪装运相关。

从消息中获得装运信息的示例

图6和图7图示了获得向顾客（“Meredith Zhao”）装运第一产品（“冬季仙境1000块拼图”）的装运信息的示例。首先参考图6，示出的是顾客从销售第一产品的商家（“皮尔斯拼图”）接收到的电子邮件消息600。电子邮件消息600包括对应于装运的订单号602、正被装运的第一产品的指示604、顾客的装运地址606、装运的跟踪号608、正在促成装运的装运提供商（“完美邮政服务”）的指示610以及装运的跟踪URL 612。跟踪URL 612包括对应于跟踪号608的文本串614和对应于装运提供商的另一文本串616。

图7图示了对应于跟踪URL 612的网页700。例如，如果顾客要在电子邮件消息600中选择跟踪URL 612，则可以将顾客引向网页700。网页700包括订单号602、跟踪号608、装运提供商的指示610和预期交付日期的指示702。

方法500可以用于获得向顾客装运第一产品的装运信息。在步骤502中，例如，对应于电子邮件消息600的数字内容可以从消息传送服务上的顾客账户中获得。该数字内容可以包括图6中所示的任何、一些或所有内容，可选地以序列化格式。在步骤504中，例如，使用字符串匹配算法从数字内容中提取跟踪URL 612。步骤506可以确定消息600与跟踪装运相关。这可以通过如下方式来执行：将电子邮件消息600的数字内容输入到ML模型中，以将电子邮件消息600分类为与装运跟踪相关的消息。替代地或者除此之外，跟踪URL 612的至少一部分可以被输入到ML模型中，以将跟踪URL 612分类为与装运跟踪相关。

在步骤508中，可以从跟踪URL 612和网页700两者获得第一产品的装运的装运信息。跟踪URL 612可以被解析以确定网页700用于跟踪第一产品的装运。跟踪URL 612也可以被解析以获得对应于跟踪号608的文本串614和对应于装运提供商的文本串616。文本串616可以针对存储在存储器中的装运提供商列表进行比较，以确定文本串616对应于装运提供商。销售和装运产品的商家在跟踪URL 612中被标识，并且因此也可以通过解析跟踪URL612来获得。

解析跟踪URL 612可能牵涉到将跟踪URL 612的至少一部分输入到一个或多个ML模型中。例如，查询组份（“Id=11111000 &装运提供商=PPS”）可以使用确定性方法从跟踪URL 612中提取，并输入到ML模型中。

在一些情况下，跟踪URL 612被输入到第一ML模型中，以对跟踪URL 612进行分类。跟踪URL 612的所确定类别可以预测出跟踪URL 612对应于商家和/或装运提供商。跟踪URL612的所确定类别还可以或取而代之地提供对应于文本串614的起始的第一索引的预测和/或对应于文本串614的结束的第二索引的预测。在所图示示例中，第一索引是42，并且第二索引是49（从跟踪URL 612的起始计数）。第一索引和第二索引可以用于从跟踪URL 612中提取跟踪号608。跟踪URL 612、预测的装运提供商、预测的第一索引和/或预测的第二索引然后可以被输入到第二ML模型中。第二ML模型的输出可以包括装运提供商和/或跟踪号的细化预测608。由于第二ML模型可以受益于第一ML模型的结果，因此在该多步骤方法中确定装运提供商和/或跟踪号608可以提供更准确的结果。替代地，第一ML模型或第二ML模型可以被单独使用来确定装运提供商和/或跟踪号608。

网页700还可以在步骤508中被解析，以确认从跟踪URL 612获得的装运提供商、商家和/或跟踪号608。此外，解析网页700可以根据指示702确定预期交付日期和/或确定订单号602。例如，使用ML模型实现的概率性方法可以用于解析网页700并获得该装运信息。

图8和图9图示了获得向顾客（“Meredith Zhao”）装运第二产品（“树上的书”）的装运信息的示例。首先参考图8，示出的是顾客从销售产品的商家（“图书批发”）接收到的电子邮件消息800。电子邮件消息800包括对应于装运的订单号802、正被装运的产品的指示804、装运的跟踪号806、正在促成装运的装运提供商（“快速交付”）的指示808以及超链接810。超链接810对应于图9中所示的跟踪URL 902。

图9图示了对应于跟踪URL 902的网页900。网页900包括订单号802、跟踪号806、装运提供商的指示808、顾客的装运地址904和预期交付日期的指示906。

方法500还可以用于获得向顾客装运第二产品的装运信息。在步骤502中，对应于电子邮件消息800的数字内容可以从消息传送服务上的顾客账户中获得。这可以是获得电子邮件消息600的同一消息传送服务，或者是不同的消息传送服务。在步骤504、506中，从超链接810中提取跟踪URL 902，并且确定电子邮件消息800与跟踪装运相关。

然后可以执行步骤508，以从跟踪URL 902和从网页900获得装运信息。解析跟踪URL 902可以确定在跟踪URL 902中标识的第二产品的装运的商家和/或订单号。然而，跟踪URL 902不包括对应于跟踪号806的任何字符串，并且因此可能不可能从跟踪URL 902确定跟踪号806。然而，跟踪号806可以通过解析网页900来确定。

在一些情况下，可以从跟踪URL 902确定装运提供商（“快速交付”）。例如，跟踪URL902可以被分类以确定跟踪URL 902对应于商家。如果商家通常仅使用一个装运提供商，那么跟踪URL 902的该分类也可以指示该装运的装运提供商。装运提供商也可以通过解析网页900来获得或确认。

还可以通过解析网页900获得另外的装运信息，包括订单号802和在906处指示的预期交付日期。

针对向顾客装运第一产品和向顾客装运第二产品而获得的装运信息可以被添加到装运信息的整合列表或记录。图10图示了顾客（“Meredith Zhao”）的装运信息的整合记录1000的示例。记录1000包括装运信息的三行1002、1004、1006，其中行1002、1004、1006中的每一行涉及不同的装运。行1002对应于第一产品的装运（“冬季仙境1000块拼图”），行1004对应于第二产品的装运（“树上的书”），并且行1006对应于另外的产品的装运。记录1000进一步包括每个装运的装运信息的多个列1008、1010、1012、1014、1016、1018。列1008指示每个装运的商家，列1010指示每个装运的订单号，列1012指示每个装运的跟踪号，列1014指示每个装运的装运提供商，列1016指示每个装运的估计或确认的交付日期，并且列1018包括具有每个装运的跟踪URL的超链接。

在所图示的示例中，如上面所讨论的，通过分析跟踪URL 612和网页700获得行1002中的装运信息。照此，行1002包括订单号602、跟踪号608、装运提供商的指示610和估计交付日期的指示702。位于行1002和列1018中的超链接对应于跟踪URL 612，其允许顾客从记录1000访问网页700。类似地，如上面所讨论的，通过分析跟踪URL 902和网页900获得行1004中的装运信息。照此，行1004包括订单号802、跟踪号806、装运提供商的指示808和估计交付日期的指示906。行1004和列1018中的超链接对应于跟踪URL 902，从而允许顾客从记录1000访问网页900。

记录1000可以随着顾客针对产品下新订单而持续地和/或间歇地更新，并且那些订单的装运信息通过顾客的消息变得可用。此外，顾客可以手动更改记录1000。

结论

尽管已经参考本发明的具体特征和其实施例描述了本发明，但是在不脱离本发明的情况下可以对其进行各种修改和组合。因此，说明书和附图应被简单地看作是对由所附权利要求限定的本发明的一些实施例的说明，并且被认为覆盖了落入本发明的范围内的任何和所有修改、变化、组合或等同物。因此，尽管已经详细描述了本发明及其优点，但是在不背离由所附权利要求限定的本发明的情况下，可以在此进行各种改变、替换和变更。此外，本申请的范围不限于说明书中描述的过程、机器、制造、物质组成、装置、方法和步骤的特定实施例。如本领域普通技术人员从本发明的公开内容中将容易理解的，根据本发明，可以利用目前存在的或以后将开发的、执行与本文所述的相应实施例基本相同的功能或实现与本文所述的相应实施例基本相同的结果的过程、机器、制造、物质组成、装置、方法或步骤。因此，所附权利要求旨在将这些过程、机器、制造、物质组成、装置、方法或步骤包括在其范围内。

此外，本文中例示的执行指令的任何模块、组件或设备可以包括或以其他方式访问用于存储信息的非暂时性计算机/处理器可读存储介质，诸如计算机/处理器可读指令、数据结构、程序模块和/或其他数据。非暂时性计算机/处理器可读存储介质的示例的非穷举列表包括磁带盒、磁带、磁盘存储或其他磁存储设备、诸如压缩盘只读存储器（CD-ROM）、数字视频盘或数字多功能盘（DVD）、Blu-ray Disc^TM或其他光学存储之类的光盘、以任何方法或技术实现的易失性和非易失性、可移动和不可移动介质、随机存取存储器（RAM）、只读存储器（ROM）、电可擦除可编程只读存储器（EEPROM）、闪存或其他存储器技术。任何这样的非暂时性计算机/处理器存储介质都可以是设备的一部分或者可访问或可连接到设备。本文描述的任何应用或模块都可以使用计算机/处理器可读/可执行指令来实现，所述指令可以由这样的非暂时性计算机/处理器可读存储介质存储或以其他方式保持。

本教导还可以扩展到以下编号条款中的一个或多个的特征：

条款

1. 一种计算机实现的方法，包括：

获得对应于消息的数字内容；

从数字内容中获得web资源的统一资源定位符（URL）；

基于所述URL和所述web资源，确定包括以下各项中至少一项的装运信息：

web资源用于跟踪装运的指示，

装运的跟踪号，和

装运的装运提供商；以及

在存储器中存储用于获得装运的跟踪更新的装运信息。

2. 根据条款1所述的计算机实现的方法，其中确定装运信息包括：

通过解析所述URL来确定跟踪号和装运提供商；和

通过解析web资源来确认跟踪号和装运提供商。

3. 根据条款1所述的计算机实现的方法，其中确定装运信息包括：

通过解析所述URL来确定跟踪号和装运提供商中的一个；和

通过解析web资源来确定跟踪号和装运提供商中的另一个。

4. 根据条款1所述的计算机实现的方法，其中确定装运信息包括：

通过解析web资源来确定跟踪号和装运提供商。

5. 根据条款1所述的计算机实现的方法，其中确定装运信息包括：

将所述URL输入到机器学习（ML）模型中；和

基于ML模型的输出，从所述URL获得对应于跟踪号的文本串。

6. 根据条款5所述的计算机实现的方法，其中确定装运信息进一步包括：

获得预测，所述预测包括对应于所述URL中的跟踪号的起始的第一索引和对应于所述URL中的跟踪号的结束的第二索引；和

将第一索引和第二索引输入到ML模型中。

7. 根据条款5所述的计算机实现的方法，其中，ML模型包括多任务学习模型。

8. 根据条款1所述的计算机实现的方法，其中确定装运信息包括：

将所述URL输入到机器学习（ML）模型中；和

从ML模型的输出中获得对应于从预定义装运提供商集合中选择的装运提供商的文本串。

9. 根据条款1所述的计算机实现的方法，其中，所述URL是第一URL，所述web资源是第一web资源，所述跟踪号是第一跟踪号，并且所述装运提供商是第一装运提供商，所述方法进一步包括：

从数字内容中获得第二web资源的第二URL；

基于第二URL和第二web资源确定：

第二web资源用于跟踪装运，

装运的第二跟踪号，和

装运的第二装运提供商；以及

确定第一跟踪号与第二跟踪号匹配，并且第一装运提供商与第二装运提供商匹配。

10. 根据条款1所述的计算机实现的方法，进一步包括：

基于数字内容，确定所述消息与跟踪装运相关。

11. 根据条款10所述的计算机实现的方法，其中确定所述消息与跟踪装运相关包括：

将数字内容输入到机器学习（ML）模型中；

从ML模型的输出中获得从预定义消息类别集合中选择的消息的消息类别；和

确定消息类别与装运跟踪相关。

12. 根据条款10所述的计算机实现的方法，其中确定所述消息与跟踪装运相关包括：

将所述URL输入到机器学习（ML）模型中；

从ML模型的输出中获得从预定义URL类别集合中选择的URL的URL类别；和

确定所述URL类别与装运跟踪相关。

13. 根据条款1所述的计算机实现的方法，其中：

所述消息对应于特定用户；并且

存储装运信息包括将装运信息存储在与特定用户相关联的多个装运的装运信息记录中，

所述方法进一步包括输出装运信息记录的至少一部分，以供在与特定用户相关联的设备上显示。

14. 一种系统，包括：

至少一个处理器，用于：

获得对应于消息的数字内容；

从数字内容中获得web资源的统一资源定位符（URL）；和

基于所述URL和所述web资源，确定包括以下各项中至少一项的装运信息：

web资源用于跟踪装运的指示，

装运的跟踪号，和

装运的装运提供商；以及

存储器，用于存储用于获得装运的跟踪更新的装运信息。

15. 根据条款14所述的系统，其中所述至少一个处理器进一步用于：

通过解析所述URL来确定跟踪号和装运提供商；和

通过解析web资源来确认跟踪号和装运提供商。

16. 根据条款14所述的系统，其中所述至少一个处理器进一步用于：

通过解析所述URL来确定跟踪号和装运提供商中的一个；和

通过解析web资源来确定跟踪号和装运提供商中的另一个。

17. 根据条款14所述的系统，其中所述至少一个处理器进一步用于：

通过解析web资源来确定跟踪号和装运提供商。

18. 根据条款14所述的系统，其中所述至少一个处理器进一步用于：

将所述URL输入到机器学习（ML）模型中；和

基于ML模型的输出，从所述URL获得对应于跟踪号的文本串。

19. 根据条款18所述的系统，其中所述至少一个处理器进一步用于：

获得预测，所述预测包括对应于所述URL中的跟踪号的起始的第一索引和对应于所述URL中的跟踪号的结束的第二索引；和

将第一索引和第二索引输入到ML模型中。

20. 根据条款18所述的系统，其中，ML模型包括多任务学习模型。

21. 根据条款14所述的系统，其中所述至少一个处理器进一步用于：

将所述URL输入到机器学习（ML）模型中；和

从ML模型的输出中获得对应于从预定义装运提供商集合中选择的装运提供商的文本串。

22. 根据条款14所述的系统，其中，所述URL是第一URL，所述web资源是第一web资源，所述跟踪号是第一跟踪号，并且所述装运提供商是第一装运提供商，其中所述至少一个处理器进一步用于：

从数字内容中获得第二web资源的第二URL；

基于第二URL和第二web资源确定：

第二web资源用于跟踪装运，

装运的第二跟踪号，和

装运的第二装运提供商；以及

确定第一跟踪号与第二跟踪号匹配，并且第一装运提供商与第二装运提供商匹配。

23. 根据条款14所述的系统，其中所述至少一个处理器进一步用于：

将所述URL输入到机器学习（ML）模型中；

从ML模型的输出中获得从预定义URL类别集合中选择的URL的URL类别；和

确定所述URL类别与装运跟踪相关。

24. 根据条款14所述的系统，其中：

所述消息对应于特定用户；

存储器进一步用于将装运信息存储在与特定用户相关联的多个装运的装运信息记录中；并且

所述至少一个处理器进一步用于输出装运信息记录的至少一部分，以供在与特定用户相关联的设备上显示。

25. 一种存储指令的非暂时性计算机可读存储介质，当由计算机系统的处理器执行时，所述指令使得计算机系统：

获得对应于消息的数字内容；

从数字内容中获得web资源的统一资源定位符（URL）；

基于所述URL和所述web资源，确定包括以下各项中至少一项的装运信息：

web资源用于跟踪装运的指示，

装运的跟踪号，和

装运的装运提供商；以及

在存储器中存储用于获得装运的跟踪更新的装运信息。

Claims (15)

1.一种计算机实现的方法，包括：

为顾客标识多个消息；

从所述多个消息中的消息提取至少一个装运的装运信息，所述提取包括：

获得对应于所述多个消息中给定消息的数字内容；

从数字内容中获得web资源的统一资源定位符URL；

通过将所述URL输入到一个或多个机器学习ML模型中，并且基于所述一个或多个ML模型的输出从所述URL中获得对应于跟踪号的文本串，来基于所述URL和所述web资源确定特定装运的装运信息，所述装运信息包括以下各项中的至少一项：

web资源用于跟踪特定装运的指示，

特定装运的跟踪号，和

特定装运的装运提供商；以及

在存储器中存储用于获得特定装运的跟踪更新的装运信息。

2.根据权利要求1所述的计算机实现的方法，进一步包括：

基于装运信息，获得所述至少一个装运的跟踪更新；和

提供跟踪更新，以供在为顾客呈现产品装运的聚合汇总中使用。

3.根据权利要求1或2所述的计算机实现的方法，其中确定装运信息进一步包括：

获得预测，所述预测包括对应于所述URL中的跟踪号的起始的第一索引和对应于所述URL中的跟踪号的结束的第二索引；和

将第一索引和第二索引输入到所述一个或多个ML模型中。

4.根据权利要求1或2所述的计算机实现的方法，其中确定装运信息包括：

将所述URL输入到所述一个或多个ML模型中；和

从所述一个或多个ML模型的输出中获得对应于从预定义装运提供商集合中选择的装运提供商的文本串。

5.根据权利要求1至4中任一项所述的计算机实现的方法，其中确定装运信息包括：

通过解析所述URL来确定跟踪号和装运提供商；和

通过解析web资源来确认跟踪号和装运提供商。

6.根据权利要求1至4中任一项所述的计算机实现的方法，其中确定装运信息包括：

通过解析所述URL来确定跟踪号和装运提供商中的一个；和

通过解析web资源来确定跟踪号和装运提供商中的另一个。

7.根据权利要求1至4中任一项所述的计算机实现的方法，其中确定装运信息包括：

通过解析web资源来确定跟踪号和装运提供商。

8.根据任一前述权利要求所述的计算机实现的方法，其中，所述一个或多个ML模型中的至少一个包括多任务学习模型。

9.根据任一前述权利要求所述的计算机实现的方法，其中，所述URL是第一URL，所述web资源是第一web资源，所述跟踪号是第一跟踪号，并且所述装运提供商是第一装运提供商，所述方法进一步包括：

从数字内容中获得第二web资源的第二URL；

基于第二URL和第二web资源确定：

第二web资源用于跟踪装运，

装运的第二跟踪号，和

装运的第二装运提供商；以及

确定第一跟踪号与第二跟踪号匹配，并且第一装运提供商与第二装运提供商匹配。

10.根据任一前述权利要求所述的计算机实现的方法，进一步包括：

基于数字内容，确定所述消息与跟踪装运相关。

11.根据权利要求10所述的计算机实现的方法，其中确定所述消息与跟踪装运相关包括：

将数字内容输入到所述一个或多个ML模型中；

从所述一个或多个ML模型的输出中获得从预定义消息类别集合中选择的消息的消息类别；和

确定消息类别与装运跟踪相关。

12.根据权利要求10所述的计算机实现的方法，其中确定所述消息与跟踪装运相关包括：

将所述URL输入到所述一个或多个ML模型中；

从所述一个或多个ML模型的输出中获得从预定义URL类别集合中选择的URL的URL类别；和

确定所述URL类别与装运跟踪相关。

13.根据任一前述权利要求所述的计算机实现的方法，其中：

所述消息对应于特定用户；并且

存储装运信息包括将装运信息存储在与特定用户相关联的多个装运的装运信息记录中，

所述方法进一步包括输出装运信息记录的至少一部分，以供在与特定用户相关联的设备上显示。

14.一种系统，包括：

至少一个处理器，被配置为实行前述权利要求中任一项所述的方法；和

用于存储装运信息的存储器。

15.一种计算机程序，当在计算机的处理器上执行时，所述计算机程序被配置为实行权利要求1至13中任一项所述的方法。

Images